Re: [osg-users] remove updatecallback stably and reliably

[Robert Osfield]

On Sun, 27 Dec 2020 at 01:01, 蔡少波 <beiji...@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.

 

[Robert Osfield]

How are the symbols represented in the scene graph and on screen?  How many different types of symbols do you have?

What are the dynamic aspects to the simulated objects, as you mention AnimationPathCallback I presume you are animating a transform.  Is this just xyz translations?

I don't yet understand enough about the specific usage case but in principle I'd suggest looking at geometry instancing as a possible technique for leveraging the GPU more and minimizing the CPU overhead.  It may be possible to just position your objects using an osg::UniformArray and an appropriate shader to unpack this and create the required modelview matrix to position/colour each instance of a symbol.