I did some profiling of Xith3d and decided to list some parts of Xith methods and classes that create most work for the garbage collector. I do not know if any of these object creations can be avoided, e.g. by reusing existing objects but I decided to list the methods anyway as I got the report easily while evaluating the profiler.

My test application consisted of 200 objects that are constantly rotated and positioned. The instance count list below consists of Xith objects only. The counts are a result from 2000 view.renderOnce() calls only, so you can double the counts below after each 2000 more frames etc. GC was disabled.

Yes, it's helpful. Because it also confirms what I experienced some days ago. Please have a short look at my thread here: the interesting article is the second one named "Question B) jerky movement".

In that thread Yuri replied:

Quote

To minimize problems caused by full GC, we should try to minimize memory allocations inside Xith3D rendering engine. abies already did a lot to reduce memory allocations, but there are still some things to do in that area.

Interesting though, that aside the Xith3d developers and helpers (Abies?) just you and me noticed these "full GC delays". Like my recent poll indicates, the Xith3d user base is still very small... as are Java interested game programmers in general. :-(

I dont know if all object creation can be reasonably avoided but some optimizations could be done over there. Because now you have to tweak GC a bit in order to avoid small freezes from happen, e.g. use incgc to avoid freezes but all solutions lower general performance somewhat as long as GC has a lot of work to do.

Note that if you have any tight loops e.g. iterators that go through every visible object and set new coordinates and orientations to your application, make sure you are not unneccessarily creating e.g. Vector3f and Matrix3f objects per each step. This strains GC even more. Just create your transform temporary objects once and re-use them, this helps some.[/quote]

Quote

Interesting though, that aside the Xith3d developers and helpers (Abies?) just you and me noticed these "full GC delays".

Put several hundred objects moving to your scene and you are bound to see freezes with standard JVM parameters, GC has a lot to collect..

Summary, Xith might have more important tasks first before optimizing excessive object creation. Then again, maybe not.

PS. Do you have clue what makes those doubles, is it vecmath that has a bug? I got around this by creating my own setScale method.

As for the vecmath, use Kenji Hiranabe version - it is a lot better, as it creates no temporary objects (except one method somewhere, I have corrected it at some point and forgotten now). I have not even started profiling without this change, because data was skewed too much by java3d vecmath garbage. Funny thing is that java3d itself managed to avoid using this heavy methods - it was generating next to none garbage (something like 2 objects per frame for non-trivial scene).

As far as I remember (I have checked it some time ago), one of major garbage generators left in xith3d is ShapeAtom. AFAIK, it is created from scratch for any change in any state of shape3d. I have changed it some time ago to reuse the object and reuse all shaders if they have not changed - this reduced amount of garbage considerably. Unfortunately, I was not able to code it in way that looks elegant (spagetti code is real bad) and I was a bit afraid about possible side effects on state sorting routines, as I'm not fully aware of the way they work.

@Jani: Yes, I always use tempory Transfrom3D() objects which aren't being destroyed and re-created when a model is being translated/rotated.

@Abies: Ah, so you suggest to use Kenji Hiranabe's Vecmath. Good hint, I'll try that.

In a thread here in the forum you quoted an URL to a slightly modified version of this improved Japanese Vecmath. (Inside the Zip there's a Readme file but the URL to the original Japanese Web site doesn't work anymore...)

Since you and Yuri say that the slightly modified Japanese Vecmath is good to use with Xith3d: maybe William should replace the Java3d Vecmath on the Xith3d download site with the improved one?

In zip on my page I have also added few methods which are not really needed (I was not aware that opengl has transpose-matrix extension, so I have added methods to vecmath). Tonight I'll try to prepare version with just bugfixes/missing Tex4f.

In zip on my page I have also added few methods which are not really needed (I was not aware that opengl has transpose-matrix extension, so I have added methods to vecmath). Tonight I'll try to prepare version with just bugfixes/missing Tex4f.

Thanks a lot! :-)

With your current Vecmath version the full GC does occur a little rarer on my example jnlp with 100 rotated objects (mentioned in my first post). However a full GC still occurs every ~7 seconds when all 100 objects are visible.Well, that's an improvement compared to the full GC occuring every ~3 seconds with the original J3d Vecmath.

{Edit}: Inspired by the thread named "RFE: SERVER jvm into JRE" I've run the same test program with 100 rotating objects with the -server VM switch on Windoze, and voila: when the program runs for 2-3 seconds and is "warm", the full GC just occurs every ~3 minutes or so, which is a lot better. So it's not a real problem for my test program anymore. (I'm using Abies' japanese Vecmath.)

9. Why do none of the methods accept doubles like Java3D did?Since the underlying graphics hardware only supports floats - a design decision was made to only use floats for all method calls in Xith3D.

PS: However there's some talk in the forums that today on modern machines the difference between using doubles and floats (all done on the co-processor) doesn't mean a big performance problem anymore... isn't it?

Considering the coming Java gaming contest, I'd like to ask again about the state of Xith memory usage.

Does anyone have ideas if Xith's memory management can be fixed in a month or so? Theres plenty of classes that use the dreaded new clause quite excessively and this strains garbage collector quite a lot. It slows down the performance or causes minor jerking on bigger scenes that have hundreds of objects constantly being transformed.

Again, the "hotspot" that causes excessive object creation is TransformGroup.setTransform(Transform3D), it calls various classes and does several functions, various classes create a lot of new objects and discard old values.

I tried to help a bit by giving a summary of the classes that do excessive object creation (see first mail on this thread), perhaps I might help out some more but Xith internals are new to me.

YInteresting though, that aside the Xith3d developers and helpers (Abies?) just you and me noticed these "full GC delays". Like my recent poll indicates, the Xith3d user base is still very small... as are Java interested game programmers in general. :-(

This perhaps is the cause of the jerkiness I see in *almost* every one of the Xith demos on the website? About one jerk per second (nb: I don't have much RAM, only 256 and desktop linux is an evil memory hogger). The silly thing is that apart from that its smooth, it just has a regular (very small) jerk - especially noticeable on the terrain / heightfield demo.

Seeing the simple official demos run poorly on a gefroce2 @ 1ghz is enough to give *anyone* serious 2nd thoughts I'd think...

With exception of collision routines, it CAN be corrected withing a month - it is really just few places where considerable amount of garbage is generated. Question is, if somebody will do it...

Can you tell me the people that can affect to this issue in any way? Sure the people are watching these threads also, but I'm considering to send annoying but polite query for some people and ask experts opinions about this issue (how complex is it, is there plans to fix it in the near future, time estimates).

This perhaps is the cause of the jerkiness I see in *almost* every one of the Xith demos on the website? About one jerk per second. (nb: I don't have much RAM, only 256 and desktop linux is an evil memory hogger). The silly thing is that apart from that its smooth, it just has a regular (very small) jerk - especially noticeable on the terrain / heightfield demo.

{Edit} Now I see what you mean: small jerks, yes, they're visible with the demos on my Winblows box, too. Maybe it's something with their renderloops.In a "real" application, with timed simulation & render loop, I just see jerks when many objects (100+) with transformations are inside the view. Then every few seconds I see jerks. This is due to a full GC which occurs every few seconds in the Xith transformation code. I think Jani's memory observation explains it.

Generally these GC related jerks can be examined by tring the following: start the demos or/and your app with: java -verbose:gc ...However with the Xith demos I can't get it to work right now.

However using the server VM solves most of my full GC problems with Xith (the jerks appears every few minutes only). However it isn't a solution when it comes to deployment via Webstart or similar. So, like Jani, I'm too interested in this being fixed within Xith.

The new 1.5 collectors rock. The -XX:MaxGCPauseMillis=nnn will tune the garbage collector automatically for you. A bit like staring at that graphical profily thing and fiddling with the old tuning parameters in 1.4 until it doesn't jerk.

OK, I'll try sometime (I've only been running the JWS demos so far, and I'm too busy right now to sit down for more than about 1 minute!)

I sincerily believe the only right solution is to get rid of these excessive object creations. I'm sure JOGL, LWJGL or jME (scenegraph also) do not act like this.

Sure you can set your -Xms -Xmx into 1gigabyte and "buy" big timewindow before first gc bang occurs, or use -incgc and tweak your garbage collector to run all the time on the background, but the overall performance suffers from this. I haven't done benchmarks but I believe fps takes a noticeable hit because of this. I am now talking about scenes that have hundreds of objects moving.

Again, the "guilty" part is TransformGroup.setTransform() call. It does several functions and trashes memory bigtime.

Quote

I'll have a go with 1.5beta as well, see if the same thing happens.

I am positive that it happens, or at least in the expense of performance. Nothing changes the facts that there's lots of work for GC to do in any case.

Last words and reasons why I started this thread:Ok, perhaps we should remember that Xith is heavily under development and just accept the facts, I'm sure this will be corrected before v1.0 is out, I just wanted to prioritize this issue a bit more on the development queue :-)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org