Hi Jan,
On 2/27/07, Jan Ciger <[EMAIL PROTECTED]> wrote:
Now that osgProducer is gone from the core OSG, could somebody tell me whether
and how the osgViewer supports stereo? I am specifically talking about the
following env. variables which work with Producer but do not seem to do
anything with osgViewer. They get loaded into osg::DisplaySettings and that's
it - nobody is ever using the values.
OSG_EYE_SEPARATION=0.06
OSG_STEREO_MODE=QUAD_BUFFER
OSG_SCREEN_HEIGHT=2.0
OSG_SCREEN_DISTANCE=2.0
OSG_SCREEN_WIDTH=5.0
Stereo itself seems to work, but without the ability to set the eye separation
and the screen settings it is unusable.
Currently SceneView does the stereo, just as it did with osgProducer,
but I haven't wired up part of the stereo distance calibration yet.
This isn't a huge amount of work, just sitting there in the queue
awaiting attention.
Later on I plan to provide better stereo support, and do so at a high
level directly within osgViewer rather than relying upon SceneView.
The high level support will be done through setting up slave
osg::Camera in pairs, or with even more Camera's for display systems
that work in more than stereo. This will all be configurable for an
ascii file.
I could (and will) use osgProducer for the time being, but I am a bit afraid
that it will just slowly die off - Don has his own implementation in Producer
and this is not part of the core library anymore.
My focus of work will be osgViewer, and in any where where it doesn't
yet match osgProducer I'll try and close that gap, and have it all
working before the next release.
With osgProducer my intention is to maintain it for the purposes of
backwards compatibility for those users who wish to stick with
osgProducer for as long as they wish. I don't have ambitions for
osgProducer beyond this, so if the community want to push it to new
places then they are welcome to driver development or it, or perhaps
even take over the reins of project leadership on it.
Personally I'd like people to steadily move over to osgViewer, as its
hard for me to keep track of multiple projects and push them all
forward. My hope for osgViewer is that it unify viewer usage and cut
down on support, as over the last few years many different users have
either not used osgProducer or have used it in ways that it didn't
support well, "going off road".
If we can make osgViewer sufficiently general purpose and powerful
then it should be work both for basic viewer needs all the way up to
3rd party windowing toolkit integration, multi-pipe stereo
visualization, multiple view multiple scene, and distortion correction
usage. With this unification will be all using the same classes,
using the same concepts and language.
The areas in osgViewer that are currently lacking are the stereo
setup, config file support and complete of the GraphicsWindow
implementations for the various 3rd party windowing toolkit.
Considering how far osgViewer has already come, these items aren't too
distant.
Robert.
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
