Best way to wrap behaviors?

Engines, Libraries and Tools Java 3D
#1

I want all the behaviours to be syncronized so that they all are called in one single main behaviour or so called “behaviour listener”.

Now I have multiple different behaviours such as animation, mouse handling, keyboard navigation and the behaviours occur as they wish.

Now I have all my behaviours the same style as j3D raw java suggested, but all the multiple “threads” (oops behaviours" don’t work as I want them to. They are all extending from behaviour and going downwards from that, however this is not the most ideal sollution.

Should I make one general behaviour that has all the behaviours in it or some sort of behaviour manager, which syncronizes the behaviours? In 2D it was best to have one thread that manages everything, would one behaviour be good that manages everything?

Is there any whitepaper about the internal processes on the behaviours that would explain what happens and where so that I could write my own behaviour system.

Writing everything in one behaviour class isn’t very good oop, but it would produce the best speed as I understand. Is there any middle ground? Do I have completely wrong picture about the behaviors?

Behaviour = Behavior.

#2

The only way to guarantee all of your application behaviours work correctly is to use a single WakeUpOnElapsedFrames(0). When this gets called you go and perform all the handling that you want. Once you start trying to build arbitrary behaviours into the scene graph all over the place, the performance really starts to drag. - not only from the synchronisation aspects, but also all the calculation J3D has to do internally to decide if your behaviour should run. The only way to build high-performance j3d apps is to maintain all your own application logic called through the single j3d behaviour.

#3

Agreed in principle, but WakeUpOnElapsedFrames(0) leads to unsmooth animation due to GC pauses and MT.
I’d prefer WakeUpOnElapsedTime(30) or so, safely undercommitting the abilities of the computer, bc. smooth animation needs first of all CONSTANT framerate, second HIGH framerate.

Our gaming prototype completey runs in a single behaviour callback.

#4

Hercules has a good point. What is the use of high frame rate if the animation is not smooth.

Btw, I know this is kind of retarded question, but will there ever be option to turn GC off and do the memory management by yourself? I think it would help a lot in some situations.

#5

If you are getting GC pauses, it’s certainly not due to using elapsedFrame(0) calls. Before you criticise a piece of code for “creating garbage”, first understand what you are talking about. Limiting your own internal framerate is not the way to build scalable applications.

We run profilers and decompilers over the J3D internals on an extremely regular basis (ie almost daily) and there is, with one exception in the picking utils, almost zero garbage generated by the Java3D runtime engine under normal circumstances. There is a call during the matrix inversion that sets up the view projection matrix each frame and that’s about it. The other times garbage may be generated is due to your use of geometry. For example, if you used any of the indexed geometry primitives, and change just the coordinate array, it will throw the entire internal structure away and rebuild the arrays. So, you dont use those structures and build your own unindexed arrays. I can get quite nice, smooth framerates (20-30) on my 800MHz laptop with 40K polygons with every coordinate being updated every frame, and never see a GC pause. Understand your tools first, before you blame them for causing problems.

#6

Who said that Java3D creates garbage?

But it’s good news that it doesn’t.

Anyway, elapsedFrame(0) causes one thread always ready to run. So there’s a race condition with other threads. If they get execution times, the elapsedFrame(0)-thread neccesarily does NOT run (assuming singleCPU boxes). If theres no sync in scheduling, this MUST lead to irregular frametimes varying on a one-by-one basis -> animation gets unsmooth (regardless of the framerate you achieve. Framerate says NOTHING about smoothness).

This problem vanishes if the app runs with more 85Hz or so and the painting thread get to sleep due to a vsync-wait. That’s where we see perfectly smooth 2D-games…

BTW, is there a 50Hz-limit within Java3D somewhere for a onscreen, windowed apps? Couldn’t see any framerated higher…

#7

That sounds strange… I get constant 85 with windowed onscreen rendering…

#8

hm, yes, I suppose it’s in my code…
Maybe the firerate of elapsedTime() is limited…

#9

[quote] Understand your tools first, before you blame them for causing problems.
[/quote]
But they’re complicated!