DirtyType mechanism...

Hi,

Hi,

attachChild, detachChild doesn't seem to change the the associated Dirty state at, above or below in the scene graph. I'm hoping a runner thread can avoid the renderer.draw() if the scene is clean. It does seem to work for DirtyType.Transform if the Node is part of a MouseControl. What am I missing?

Are there any restrictions on who (Threads) can call Updater.updateFrame()?

Tom

Hi

There is no such restriction but I'm not sure that calling Updater.updateFrame() on several threads is a good idea. I'll investigate concerning the dirty state.

Hi Julien,

I found that in com.ardor3d.scenegraph.Spatial, DirtyType.Attached is not part of the EnumSet ON_DIRTY_ATTACHED. If I add, the flag is set as I expect. But where to clearDirty(DirtyType.Attached)? In updateGeometricState()? It seems like the clear belongs somewhere else.  I believe this should be done in Jogamp Ardor3D somewhere, but not by the application itself. What do you think?

Tom

Hi Julien,

I guess this is a question on the rendering workflow related to DirtyType marks: Let's say I have a Scene wherein objects to be rendered are all added to a single Transform (so that they rotate, translate, ... together) and that these children may
be large complex meshes. Sometime later the application would like to add another possibly large mesh or texture. Will a draw() on the top node only render what was recently added (by checking the DirtyType.Attached), or will it draw() everything again? Will the app need to recursively check the sub-graphs, or does Ardor3D do that for us (I hope!)

Tom

It will draw everything again. I don't see how redrawing only newly attached nodes would help. When you add a new node into a scene, it won't be always in front of all other nodes in your frustum, redrawing only the new node without clearing some buffers might lead to something visually completely wrong.

You know that you can already redraw on demand, you're not forced to redraw everything always.

What would you like to avoid?

Thank you for reply!

gouessej wrote

It will draw everything again. I don't see how redrawing only newly attached nodes would help. When you add a new node into a scene, it won't be always in front of all other nodes in your frustum, redrawing only the new node without clearing some buffers might lead to something visually completely wrong.

Okay, that makes sense: adding or pairing the scene requires everything to be redrawn. So the most general, safest approach is to redraw when anything in the scene changes?

gouessej wrote

You know that you can already redraw on demand, you're not forced to redraw everything always.

Not sure what you mean by "redraw on demand"? You had said above that updateFrame() should not be called from multiple threads so I have a single runner thread which does this:

        while (!exit) {
           if (!pause) {
              frameWork.updateFrame();
           }
           delay(20); // 50 fps
        }

Apparently updateFrame schedules on some other thread which ultimately calls Scene.renderUnto wherein I check
conditions like isDirty(DirtyType.Transform) before redrawing.

gouessej wrote

What would you like to avoid?

I'm just trying to understand how to get the best performance with this impressive software.

Tom

Only to clarify: I had to change Ardors3D's code to get the expected result: a dirty scene w.r.t Attach when a child is added to a Node. Can you advise, I'm willing to make and commit the changes? The problem is that the scene is never cleaned w.r.t Attach? I don't think the application (game) should to do that, in my humble opinion, Ardor3D should clear that out.

The safest approach consists in redrawing everything when something changes, yes.

I'm just trying to understand your bottlenecks, the things that have an important impact on your performance.

I advise you to make a pull request. Then, I'll carefully look at your changes and check whether it causes any regression.

Thanks again for your help!

Many of the examples have simply a thread which runs forever w/o pause, redrawing on each iteration, this
is too cpu intensive for us. I want to restrict redraw to situations with changing view, adding/removing objects, changing
attributes etc. How do more substantial Jogamp Ardor3D projects approach this? For example, your sophisticated game?

In numerous games including mine, there is just a simple loop in which we update the world and we render it.

Either you have to redraw everything only when this is necessary by using the frame handler only in this case (you don't use the frame handler when nothing changes), or you have to use some offscreen rendering to draw the scene in a FBO and then you use the content of the FBO when nothing changes and you redraw the scene when something changes. You can drive your rendering interruptible in order to stop rendering a large mesh when the end user (re)starts moving it and you can hierarchical buffering with several layers (GPU, CPU, hard drive, network) to render huge meshes. It's not specific to JogAmp's Ardor3D Continuation but it's easier to implement with a flexible scenegraph API.

Hi

I think that I will try to solve your problem when I have some free time in one or two weeks. If the dirty attached state is never cleaned, it's a bug and I will fix it.

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.

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.

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

Hi

The Java API documentation of our engine needs to be improved, there is already a bug report about this aspect but I admit that there is no white paper.

I fear that you'll need to use several listeners per node, it might be a bit tricky to use if you have numerous Spatial instances parented directly or not to a node.