[osg-users] remove updatecallback stably and reliably

[Robert Osfield]

On Sun, 27 Dec 2020 at 01:01, 蔡少波 <beijihuohu at 126.com> wrote:

>    I have some problems encountered in the project to ask everyone.
>

As a general tip, it's best to post a single question per post so that the
threads that follow can remain focused on one topic rather than have
several topics all interleaved together making it harder to follow and
harder for others later who are searching for answers.



> Question 1: The following function parameter t does not seem to be set to
> the specified value. It is found in the callback function of osg::Node that
> even if t is set to the specified value, the ReferenceTime in the callback
> function still starts from 0. Is there any way to make ReferenceTime from
> the specified value?
> viewer->getFrameStamp()->setReferenceTime(double t)
>

The FrameStamp has a ReferenceTime and SimulationTime, for animations it's
recommended you use the SimulationTIme.

The FrameStamp is set on each new frame in the Viewer::advance(double
simulationTime) method, so if you are writing your own frame loop you'll
call this with the parameter you want.

If you are calling the higher level Viewer::frame() method then it also
takes the optional simulationTime, or the higher still Viewer::run() that
also takes an optional double parameter for setting the simulationTime.



> Question 2: osg:Group cannot generate and add a large number of nodes at
> one time, nor can it repeatedly add and delete all child nodes, otherwise
> it will crash. Is there any way to add a large number of nodes at once?
> Can repeatedly add and delete a large number of child nodes?
>

You can add and removing large number of children but how to do it safely
will depend upon the threading model your applcation you are using and how
you got about adding/removing the nodes.

As a general note, it's likely very inefficient to create and delete
objects, especially ones that OpenGL objects associated with them.  If you
can reuse data or change how you do things to avoid creating and deleting
entirely then this will be the most efficient way to do things.  For
instance it may be possible to move work entirely to the GPU so the scene
graph itself is almost entirely static and only uniforms or small packets
of data need updating each frame.

You don't provide any information about how you are doing things or for
what reason so we can't provide any specific recommendations.  The best
thing to do would be to take a big step back and describe what you are
trying to achieve in your application from a really high level rather
diving into low level details about how you've decided to implement
something.


> Question 3: How to remove the updatecallback of a node stably and
> reliably? How to remove a node that is being updated stably and reliably?
>        My rendering is done in a separate thread,
>     while(!viewer->done())
>     {
>         osg->PreFrameUpdate();
>         viewer->frame();
>         osg->PostFrameUpdate();
>     }
> I call node->removeUpdateCallback(callback) in the
> preFrameOpration->Operation()  function  will cause a crash.
>   I call node->setUpdateCallback(callback) again for a node that has
> already called node->setUpdateCallback(callback) will cause a crash.
> Do you have a stable and reliable way to achieve this goal?
> void PreFrameUpdate()
> {
>    if (preFrameOpration != nullptr)
>    {
>       preFrameOpration->Operation();
>       delete preFrameOpration;
>      preFrameOpration = nullptr;
>  }
> }
>

Again you don't really provide enough information for us to be able to
guide you in a specific direction.

Best I can say is that the osgViewer by default will run the
Viewer::frame() operations multi-threaded.  Running the frame loop itself
in it's own thread could also introduce problems if you are updating the
scene graph at the same time as another thread is reading it.

You could set the Viewer threading model to SingleThreaded via
viewer.setThreadingModel(osgViewer::Viewer::SingleThraeded) and see what
happens.  It might provide some insight.

But again best I can do is arm wave at this point as you've provided small
bits of you what you are doing. so much is left to our imaginations.  You
haven't provided any information about the nature of the crash/stack trace.

Rather than attempt to provide lots more low level chunks of information
the single best thing you can do it to describe what you are trying to
achieve with your application, then describe what approach you've decided
to implement and why, then go into the nature of the crash, information
about your OSG version, platform etc.

I say this as there could well be a very different approach you should be
taking that will avoid such much complexity and inefficiency.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20201227/527462f0/attachment.html>