Thank for advice, we will try to follow this path ;-)
I further studied osgDistortion code. We will try to configure slave cameras
similarly.
I also though about using node mask. But also noticed that after some
redesign we could probably allocate and free slave camera when needed
instead of disable/enable.
We will slowly steer to complete removal of Elumens SPI. But at the moment
our customer uses spherical projection in its full range of use and wants
all its flexibility. We have to support configs that use 3 quads (like
osgDistartion) but also specific narrow 2 and 3 overlaping channels with
high def channel inserts with projector lens and observer positions moved
outside dome center. This brings some level of complexity in projection
maths that we want to avoid for now.
Wojtek
----- Original Message -----
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "osg users" <[email protected]>
Sent: Monday, May 28, 2007 10:37 AM
Subject: Re: [osg-users] osgViewer::Viewer slave camera questions
(Sphericalprojection)
Hi Wojtek,
On 5/28/07, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:
I'll start with my questions first (neccessary context goes later)
- How to achieve equivalent functionality to Producer::Camera::enable
::disable methods with new osgViewer::Viewer and osg::Camera ?
I'm never knew Produer had Producer::Camera::enable/disable methods,
so can't say how they might map.
Could you explain what you are after in general terms.
One thought is that perhaps the
camera->setNodeMask(0x0)/setNodeMask(0xffffffff) would be enough to
toggle on and off the camera for your purposes.
- Should I use osgViewer::Viewer or rather CompostieViewer for Elumens
SPI
rendering ?
An Elumens is most definately a single View on the a single Scene, so
osgViewer::Viewer is most appropriate. You could also use
CompositeViewer with a single View, but this would be adding an extra
layer of complexity you don't need.
For an example of multiple dome distortion correction have a look at
the camera setup in the osgdistortion example in SVN/1.9.x,
specifically try out:
osgdistortion --dome cow.osg
This is setup for a full sphere right now, but tayloring this approach
to a half dome should be straight forward. The basic idea is set up a
series of slaves cameras to render to texture cube map faces, then a
final camera to do a HUD style 2D rendering of the cube map to do the
distortion correction.
Below is larger context for things we want to do. Maybe someone can offer
some advice.
We are porting Elumens SPI rendering code from osgProducer to osgViewer
framework. In our former solution we had one main producer camera for the
viewer and up to six cameras for SPI channels. These SPI cameras where
enabled/disabled when we turned on/off some SPI configuration.
Configuration could change on the fly.
We are now trying to move this code to osgViewer::Viewer with six slave
cameras. But we want these cameras to be inactive on startup and turn
them
on/off when needed.
We used Producer::Camera pre & post Draw callbacks to redirect rendering
to
Elumens SPI channel render targets. This was bit hacky but worked. Below
is
a short description of the process:
For each SPI channel camera:
1 We cached current camera matrices and viewport,
2 Switched to SPI channel (SPIbegin ). SPIbegin adjusted GL
matrices/viewport,
3 We read matrices/viewport applied by SPI and used set them
Producer::Camera for OSG scene render.
4 Called update/ frame/ sync to render the scene for the SPI channel
5 Called SPI end to restore GL state
5 Restored original matrices for Producer::Camera
After all SPI channels were rendered final autput Spherical projection
was
rendered on main camera render surface (SPIPostRender & SPIFlush)
Whole process wass similar to osgDistortion example with this exception
that
Elumens SPI library manages FBO/PBuffer internally. We don't have the
access
to these buffers. SPIbegin/SPIend calls pair switches and restores render
target. How should we set up slave cameras to easily fit into this scheme
?
Personally I'd dump the Elumens code paths completely, its just adding
complexity where you don't need it. You can do all the distortion
correction using a mesh with appropriate tex coords and colour values.
The only trick you need to add is compute the tex coords and colours
to give you the correct maths for the distortion correction.
After 2.0 is out I'll will be do some more work on support distortion
correction via config files. I will also integrate some programmatic
ways to set up distortion correction similiar to the present
View::setUpViewAcrossAllScreens() method.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
