Culling the rootNode?

Can I safely set the rootNode to CULL_NEVER in SimpleGame? It does not seem to me that it ever makes sense to cull the rootNode itself. And I have checked that children of CULL_NEVER marked Nodes are still culled… is that latter the desired behaviour btw.?

Yes, it can be quite confusing to have one child with a bounding volume, and another with CULL_NEVER, and having them both culled if the object with the bounding volume dissappears.

I think ideally, CULL_NEVER would traverse up the tree during the updating of the world bound, and all CULL_DYNAMIC "above" it should act like CULL_NEVER. Kinda like a "local" cull mode, and a "world" cull mode.

But I'm fine with this too, as long as we make sure we're consistent (also do it for rootNode in Applet).

I would say be careful with such changes because it will cause existing games to potentially run a slower since people coded for a certain set of functionality.

so, what is the behaviour in jme now?

Uh, yes you have a point… I forgot the default mode is INHERIT. Which means suddenly SimpleGame would not do any culling at all… Except that irrisor is saying this doesn't happen??

Well, if setting something to NEVER doesn't make INHERIT children also NEVER, we need to fix that first as that is the intended behavior.

Another "victim":

The reason for most issues is a mixed use of bounds and no bounds (and gui objects not having bounds).  We might consider giving everything at least the low cost bounding sphere to help mitigate that (or we could add an extra bounding sphere field that gets tested before more complex boundings are tested, I've read that this speeds up bounds testing quite a bit…)

Well solving it through the bounds system is a good idea too. I think object with CULL_NEVER should behave as having infinite bounds. Can't we use some kind of static bound object for this?

And maybe ORTHO queue object should behave like CULL_NEVER then? Will giving objects in ORTHO space a bounding sphere even fix it?

I agree about ortho queue items, the problem is, if you attach them to a 3d scene graph, it may cull before it gets to the items that are in the ortho queue.  Really, we should educate people to keep their 2d and 3d elements in seperate trees.

I like the inifinite sphere idea.  Mojo and I played around with the idea a while back.  I don't recall where that ended up.

I'm all for seperate trees, I've tried to tell users to do this before… I think we should at least let SimpleGame give the good example then though :slight_smile:

Still, it's not just GUI nodes. I recently did a project where I draw the same scene element several times (by overriding a Node), so with no bounds… Of course I put it all to CULL_NEVER. Then I added something else to my scene (with a boundingbox) and suddenly it started dissappearing. Of course I remembered after a while, because I've helped users with it before, but that doesn't make it less wrong :slight_smile: Anyway, an infinite bound should be able to fix it… and ofcourse merging other bounds with an infinite bound doesn't have to be that much of a performance slow down :wink:

I don't really agree that it's wrong behavior.  The scene graph culls as it goes down, and the cull flag is for use when making a cull decision at that node of the tree alone.  By forcing it to mean a global "draw me no matter what" you are forcing together two disparate concepts.

But yeah, using inifinite bounds would allow it to work as we all think. :slight_smile:

Well maybe not really "wrong", it works the way it does because me made it that way. But certainly counterintuitive… I don't suggest it should override CULL_ALWAYS if that's above it either, just that CULL_DYNAMIC respects CULL_NEVER like it would respect a bound that's in the view frustum.

So shall I try my hand at that, or does NCSoft still have some code lying around? (or enough experience with it to know it's not as easy as it seems ;))

infinite bounds feels nice…go!

Certainly feel free to try infinite bounds, but keep in mind as you code that bounds changes have been the most notorious for breaking everybodies code via regression, etc.  ;)  (I should know… )

People have become too confident in CVS…it's about time we introduced something that caused everyone take a second thought about using it. :wink:

Just read in another thread that you are aware of OBB issues, nvm

Have I told anyone lately how much I hate OBB?  :x

I think you might have mentioned it to me at some point.