OK thank you for the information. So whatever aspects of SceneView that Renderer is using now will eventually become part of the Renderer itself. I see that now. I'm not really interested in creating a separate library I just want to get OSG working for this project, but I can see that it would be a huge task porting it to a different language with different constraints. Anyway it's been a great learning experience going through the code.
One further question, does actual rendering get invoked via the Renderer->cull() method? It looks like that then calls cull() and then draw() on the SceneView. Or is it the GraphicsContext->runOperations() that ends up rendering? Thanks, Dan On Sun, Nov 8, 2009 at 12:26 PM, Robert Osfield <robert.osfi...@gmail.com> wrote: > Hi Dan, > > SceneView is part of the original beginnings of the OSG, when it was > single threaded, single context, and is now scheduled for deprecation. > It will eventually be replaced entirely by functionality in > osgViewer::Renderer, but for now I've simply reused SceneView. > > With any project that is a decade in the making you'll find a lot of > history of it's evolution still in it, it's partly down to reusing > code that does the job, and partly about maintaining backwards > compatibility during transitions. So if you want to learn about the > scene graph design and implementation keep this it mind that is living > project, it's not only evolved alot through it's history, but it's > still evolving a good old rate. > > As for creating a new scene graph in another language, I guess the OSG > isn't too bad a place to start, but if you want to develop a really > successful project you'll need under stand about wider project > management as well as just the technical aspects of design and > implementation. It also take a lot of work to write a full featured > scene graph, hundreds of thousands of lines of code, and many man > hours. > > Robert. > > On Sat, Nov 7, 2009 at 12:46 PM, Dan R <nice...@gmail.com> wrote: >> Hello, I'm new to OSG and am just looking over the code structure to >> better learn how a proper scene graph library is laid out. I'm >> interested in using (porting a stripped down version) of osg for a >> project I'm working on in another language. I pretty much understand >> the flow of the graph, however, when it comes down to the actual >> rendering traversal I get a bit lost. So I have these two questions, >> but maybe being directed to some older posts would be good answers... >> >> 1) The osgViewer::Renderer class appears frequently throughout the >> code, however, it seems to be based around the osgUtils::SceneView >> class. The SceneView class says that it's deprecated. Does this also >> mean that the Renderer class is deprecated, or simply that any calls >> to SceneView are no longer used in the normal work flow? >> >> 2) In a SingleThreaded case, where are the operations that result in >> rendering the Drawables get added? I see that in the >> renderingTraversals method, it first traverses the graph with a >> getBound() call, then goes through each camera and does a cull() (this >> uses a Renderer object from my first question), then goes through each >> GraphicsContext and calls runOperations. Where I get lost is, where >> are the operations for the GraphicsContext defined and added, that >> actually end up doing the work of rendering the drawables? >> >> Any direction in this case would clear a lot up for me, thanks, >> >> Dan >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
