hi,
i have a small problem. I’ve tried to test a small scene with a top down view where a spaceship is flying around. The principle is simple: a behavior is triggered every frame to update the ship motion. Simple enough. There is no other behavior interfering, nor any other time consuming methods called on the side, nor other threads running.
The issue is that, despite of a good average FPS, the motion is still jerky some times. It makes some jerky little move every one or two second. And this is not due to a motion update method. It is due to the time elapsed between rendered frames. Usually it is around 2 or 3 ms per frame, but sometimes it jumps to over 100ms for a single frame! Making a small jump for the spaceship.
Since the method is always computed the same way, there is no reason for it to take longer sometimes. And there is nothing running in parrallel. So i don’t understand why there are such annoying glitches!
And it’s not the GC either, every object is pre-allocated and i checked the gc activity at runtime to ensure it is not the cause of this.
Any idea?
Nope, I woudl have suspected a memory leak triggering over-use of GC.
I suggest you run a profiler. Thats how I find and fix these things.
Netbeans has a free one thats easy to use. Eclispe has a free one too but ist a mess to install and I personally have never made it work 
There is also a good commerical one thats free for open source projects to use. I forget the name but its been mentioend around here a few times.
Thats a problem I suffer from since the very first days of FlyingGuns. Never got any help about possible reasons.
Definately it is NOT the GC. And is not a matter of performance for it occurs only here and then. So I don’t think a profiler can help very much.
I think that looking at the most simple HelloUniverse example shows this phenomenon. I always wanted to create a testcase that clearly demonstrates frametime artifacts, but I never did.
I suspect some multithread effects … there are some threads around in J3D…
Odd. I’ve never seen this sort of problem form Java3D in JNWN.
The only time I had anything that looked at all like this, it was a memory leak in Java3D’s pick code causing GCs. I profield, found the problem, and they fixed it.
shrug