Hi Dan, Renderer::cull() just does the cull traversal - i..e just collects a rendering graph of what drawables and state that visible to the Camera.
The Renderer::draw() does the dispatch of the graph of what needs rendering. Robert. On Sun, Nov 8, 2009 at 12:09 PM, Dan R <[email protected]> wrote: > 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 > <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
