[osg-users] Renderer and SceneView classes
robert.osfield at gmail.com
Mon Nov 9 01:16:24 PST 2009
Renderer::cull() just does the cull traversal - i..e just collects a
rendering graph of what drawables and state that visible to the
The Renderer::draw() does the dispatch of the graph of what needs rendering.
On Sun, Nov 8, 2009 at 12:09 PM, Dan R <nicetan at gmail.com> 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?
> On Sun, Nov 8, 2009 at 12:26 PM, Robert Osfield
> <robert.osfield at 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
>> On Sat, Nov 7, 2009 at 12:46 PM, Dan R <nicetan at 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,
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users