next »

[kerno]

hi,
silly problem, probably it's been discussed before but i can't find any relevant thread...
i'm creating a tree of Group instances (say, oct tree for 256x256x16 tile map). i create it from root to leaves. now, each addChild seems to try to update the bounds up to the root, but then the update seems to propagate back to other branches (all). the result is that making this oct tree takes minutes on modest but not very old machine. my quick solution was to call setIgnoreBounds(true) on each group just after creation. then when everything is ready i un-ignore bounds and manually force updateBounds on root node.
what would be the proper way of doing a big modification to tree of xith nodes?
i've previously had similar problem - while moving models around the map, each updateTransform was updating bounds which propagated to root, then to all branches. at that time i solved it by setting ignore bounds on root node as it's the direct parent of all my moving models. but this obviously didn't work now.
any suggestions/links/thread references higly appreciated. thanks

[Marvin Fröhlich]

Haha. Use the brandnew org.xith3d.scenegraph.OcTreeGroup . I highly advice you to use BoundingBoxes for the inserted shapes, since they can be much better positioned in the OcTree. Even if culling boxes is slightly more expensive than culling sphere, it will pay off.

Well, the other solution would be to insert from leafs to root, which shouldn't be a big change in your code (breadth-first to depth-first).

Marvin

[kerno]

thanks, i'll try to use the OcTreeGroup. but what i meant was (if i got the code right ) :

GroupNode::updateBoundsCheap, lines 780-818 (the loop)

Code:

for ( int i = 0; i < n; i++ )
...

and in particular line 815:

Code:

getWorldBounds().combine( node.getWorldBounds() );

• let's say we have lots of nodes added to a parent node, and only one of these child nodes moves, now there's complete recalculation of bounds on the parent (line 815 is called for each child).. perhaps it'd be enough to only combine the changed bouds?
• besides - setting bounds auto compute to false on parent doesn't seem to prevent the bounds from recalculating (only ignore bounds does the trick). is this intended behaviour?
• if it is intended (ie. using setIgnoreBounds(false)) - how should i do any updates (ie. moving, adding) of nodes, not to trigger complete recalculation of bounds on highly populated nodes? as said before: currently, parent of all my moving models has ignore bounds set to true to prevent the updates propagating, however this seems a little strange way to solve that - is this the proper one?
  

this doesn't prevent things from being done, just a question about how should it be done (from client code side)

[Marvin Fröhlich]

let's say we have lots of nodes added to a parent node, and only one of these child nodes moves, now there's complete recalculation of bounds on the parent (line 815 is called for each child).. perhaps it'd be enough to only combine the changed bouds?

This is exactly, that is done. See Node::setParent()

Code:

if ( parent != null )
{
    if ( !parent.boundsDirty )
        parent.expandBounds( this, true );
    else
        parent.updateBoundsCheap( true, false, true, false );
}

besides - setting bounds auto compute to false on parent doesn't seem to prevent the bounds from recalculating (only ignore bounds does the trick). is this intended behaviour?

boundsAutoCompute = false doesn't behave as you're expacting. It sets the bounds of a Group and all of its children to a fixed value (all the same as the master group).

if it is intended (ie. using setIgnoreBounds(false)) - how should i do any updates (ie. moving, adding) of nodes, not to trigger complete recalculation of bounds on highly populated nodes? as said before: currently, parent of all my moving models has ignore bounds set to true to prevent the updates propagating, however this seems a little strange way to solve that - is this the proper one?

this doesn't prevent things from being done, just a question about how should it be done (from client code side)

There's definitely work to be done. New properties like "don't trigger bounds-update on child added/removed" or "set this and only this Group's bounds fixed" must be introduced.

Fixing bounds behavior is extremely tricky. I tweaked the bounds-update-code a year ago and it was like hell, since it was very difficult to get good and fast behavior for all cases.

I will definitely try to improve the bounds-update-code when I have time. But for now I have other things to do. so this must wait a few weeks. Please remind me, if it isn't done within the next two or three weeks.

Marvin