[osg-users] how safe is to add nodes in cull traversal

[Trajce Nikolov NICK]

Hi Robert

> How long have you been using the OSG now?

Since 2003? :-) .. I knew the answer but I was "hoping" to maybe see some
light in dealing with sort of very complex code. Here is the situation in
brief:

- for every frame I have dynaimic list of objects (lights, with rtt cameras
attached)
- In custom cull visitor I am getting a new list of sorted cameras (this
must happen in the cull traversal for reasons)
- now after the cull is done, I have to make the new list from the cull
traversal 'active' for the frame (active means, disable/erase the old list
and making the new one actual - and these is by updating the scenegraph)

But, while writing this I just recall what you did for the txp loader for
the smart mesh handling with the TileMapper, where custom cull traversal is
launched before the frame

Please take my apologize for asking 'stupid' questions ;-), but sometime I
struggle and the panic is faster then the rational thinking and the
experience. I need it in written :-). Thanks again for the good
description. Hope it will help others too

Cheers,
Nick

On Sat, Sep 10, 2016 at 6:49 PM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> On 10 September 2016 at 12:42, Trajce Nikolov NICK
> <trajce.nikolov.nick at gmail.com> wrote:
> > Hi Community,
> >
> > me again :-) ..  As the subject says, I an having the viewer setup with
> > CullDrawThreadPerContext and I want to add nodes in the cull traversal.
> Is
> > it safe to do so?
>
> How long have you been using the OSG now?
>
> Short answer. NO.  Longer answer, NO it's not safe.
>
> Full answer: It's *not* generally safe to add nodes during any
> traversal, especially the cull traversal.  There are very specific
> circumstances when it can be done during during a traversal but you
> have to be fully aware of what can go wrong and make sure you don't
> fall foul of any of the potential problems.
>
> A major gotcha with changing the scene graph in the cull traversal is
> that multiple camera's can have multiple threads running cull
> traversals on them on parallel.  If you wanted to go change the scene
> graph when threading is happened then you'd need to lock the node in
> some way to prevent problems happening.  There are lots of threading
> pitfalls here - both for performance and obscure threading crashes.
>
> Another major issue is invalidation of iterators.  If you have code
> that traverses through a vector of children and as you handle one of
> the children you decide it's time to add/remove/insert and new child
> into the list being iterated then any reallocation of the vector being
> iterator will invalidate the iterators.  Invalidate the iterators and
> bang you're app will go down in flames.
>
> So.... in almost all instances trying to add/remove/insert nodes
> during the cull traversal is REALLY BAD IDEA.
>
> If you really want to do it. Go do it, you have the source code, you
> have debuggers, you can go shoot yourself in the foot or if your lucky
> work out a really narrow and safe way to do what you want to do.  I
> won't nurse you along in this route though.  Strong recommendation,
> don't play silly buggers, don't try it. It'll save you lots of time.
>
> Far better is do what other multi-threaded parts of the OSG do, do
> what the DatabasePager does, load data in a background thread,
> incremental compile new objects, when compilation is complete merge
> the subgraph with the main scene graph as an update operation prior to
> the update and event traversals.    This approach is safe, scales
> well, is well established to work well for multi-threaded and
> applications that need to target a solid 60hz.
>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
trajce nikolov nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160910/b5f670a2/attachment-0003.htm>