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

蔡少波 beijihuohu at 126.com
Sun Dec 27 06:11:25 PST 2020


Hi Robert,

The last few questions were too fragmented. I will introduce the needs of our project. We need to read symbol information from the database and generate symbols based on their coordinates, including text and geometry. The number of these symbols is about several thousand to several.Between 10,000, users are unwilling to use the display and hide switch to gradually generate symbols. In addition to these symbols, the project requires a dynamic simulation function. This simulation process is a dynamic simulation of several different objects. The simulation action uses time as theMarked, so we use AnimationPathCallback, but this faces a time benchmark problem. Although the method of pre-calculating relative time can be used to circumvent this problem, it is not a good way to solve the problem mechanically. The last problem is toTo meet the needs of users to start and stop the simulation process at any time, this requires a safe and secure RemoveUpdateCallBack and delete nodes generated during the simulation process.


在 2020-12-27 20:42:05,"Robert Osfield" <robert.osfield at gmail.com> 写道:

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/3bfd65aa/attachment.html>


More information about the osg-users mailing list