[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