[osg-users] Renderer and SceneView classes

Doug McCorkle mccdo at iastate.edu
Mon Nov 9 06:00:00 PST 2009


Hello Robert,

On Nov 9, 2009, at 7:54 AM, Robert Osfield wrote:

> On Mon, Nov 9, 2009 at 1:28 PM, Doug McCorkle <mccdo at iastate.edu>  
> wrote:
>> Do you have an example of how to use this class with an existing  
>> windowing
>> toolkit? There was an FAQ on this subject related to SceneView that  
>> does not
>> seem to be present anymore. If you have an example related to  
>> osgViewer that
>> would be great.
>
> osgveviewerSDL and osgviewerGLUT both show how to use  
> GraphicsWindowEmbedded.

Thanks for the info. I will take a look at these.

>
>> Just as a note, while osgViewer offers more "features" than  
>> SceneViewer for
>> some apps needs those features are not needed and therefore the  
>> simple
>> interface of SceneView is more than sufficient and provides easy  
>> integration
>> with other windowing toolkits. Hopefully with
>> osgViewer::GraphicsWindowEmbedded offers a similar interface with low
>> computational overhead that does not bring along features that  
>> cause a
>> performance hit.
>
> There is essentially no overhead in using osgViewer vs SceneView.  As
> you'll see from the osgviewerSDL and osgviewerGLUT examples it's
> actually very straight forward to use.
>
> Another key benefit of using osgViewer over SceneView is that it means
> that you can move between using GraphicsWIndowEmbedded style app to
> one using the inbuilt GraphicsWindow functionality or GraphicsWindow
> window inheritance, you aren't locked into one style of viewer usage.
>
> Finally osgViewer usage is far more supportable by others in the
> community.  Using SceneView directly means that you can use and abuse
> it in ways that we can't second guess.   What makes it harder for us
> to support is a loss all round, both for you as you won't get the same
> quality of support as you'll get using mainstream classes, and for
> those attempting to support you as they just be wasting time trying to
> help you do stuff that osgViewer already solves.

I understand this point and for the most part we pay for support to  
address these issues (because of the points you raise above). As I  
pointed out before I really do not have a need for the features you  
mention above and therefore have not found it necessary to move to  
osgViewer. Anyway, thanks for the pointers to the examples. I will  
take a look at these and see what issues might arise in migrating our  
application to this interface.

Doug



More information about the osg-users mailing list