Hi Don, A couple of nit-picks...
On Fri, 2006-09-15 at 07:13 -0600, Don Burns wrote: > OSG uses a read-only protection of data on a single copy of the scene > graph for each of the downstream phases. The advantages of this > approach, at least meets the problems of a multi-buffered approach > mentioned above. The one rule that this imposes, is that you cannot > modify the scene graph during the cull/draw phase. I assume these "downstream phases" introduce latency as with any pipeline configuration? How deep is the OSG pipeline? Also another concern (as you know :-) of cull/draw modifications is respecting real-time and time-of-applicability of an input event that is reflected in the scene. Rendering the scene representing time T should not be affected by an event at T+1 and directly accessing the cull/draw stage of a pipeline would do that. A system of timestamps can play around with dataflow in the simulation to minimize latency but usually not to push "future events" into the past. > But this is an easy rule to live with. If one really, really needs to > modify the scene graph during this time, it is a simple exercise to > effect double buffering of the scene graph, allowing a separate thread > to work on the buffer that is not being used by cull/draw pairs. > Double buffering is a far cry from Multi-buffering and it retains > nearly the linear scalability of a non-buffered approach. > > One other disadvantage of a mult-buffered system is increased latency. Isn't the presence of a pipeline the reason for the latency? Multi-buffering is just one way to implement such a pipeline. Regards, Marcus _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
