Posted by ThomasR on Aug 03, 2017; 6:32pm
URL: https://forum.jogamp.org/DirtyType-mechanism-tp4038074p4038093.html

Hi Julien,

Sorry for the late reply, I've been out a few days.

gouessej wrote

In my humble opinion, clearing attached dirty type makes sense only when it gets detached ... which is already done. It can't be compared to other dirty types, there is nothing strictly related to attachment that waits for an update unlike the bounding volumes and the rendering states, it's the reason why propagating the changes on the attached and detached dirty types doesn't make sense to me.

Yes, I agree. After studying the engine code myself it became apparent that this was not a bug, or an oversight, but I don't fully understand this rational quite yet. Of course, in the end, I really want to use Jogamp's Ardor3D as a support library, but also accepting we may have to take more responsibility for it going forward. I really appreciate the fair amount of comments in the source code, and that its written in English! I wish there was something like a white paper, or some kind of roadmap laying out architecture.

gouessej wrote

Moreover, you can use a DirtyEventListener to know when the attached dirty type of a spatial gets modified, there is no need to modify JogAmp's Ardor3D Continuation. If you fear to break the engine when there is already a listener set on a spatial, you can use a multicaster (com.ardor3d.scenegraph.event.SceneGraphManager) to merge the previous listener with yours. The listeners are there for this purpose, listening to events that aren't propagated exactly as you expect.

Thinking about your advice that updateFrame should not be called from multiple threads, I'm starting with a model of a simple runner thread calling updateFrame (only this one thread per display) and then the subsequent call to renderUnto checks if something has changed then calling draw only when necessary, so effectively a 'polling' model I guess. I have my own notion of 'dirty' for attach and detach, I was hoping I could just check the top level Node if something had been attached or detached. The listener model is maybe more complex? I'm hoping the simpler model will be a straightforward and robust solution: hats off to philjord who seems to understand all that bewildering Java3D Behavior stuff.

Tom