Yes, thats exactly the plan but I need the images back in the FB to get
the 3rd party stuff working. This means I have to call
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to
distortion-code or the function won't work. This assumes the image in
GL_BACK and GL_BACK has to be stored to the FBO afterwards.
How to do this?
Greetings
MAthias
Am 05.08.09 14:08, schrieb Robert Osfield:
HI Mathias,
Given your setup it's pretty clear that you'd need to not use the OSG
in built stereo support (that is implemented internally using
osgUtil::SceneView), and instead setup up two slave camera sets that
do the render to texture/post render for each eye and in the final
step do the checkboard stereo at the same time
Robert.
On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhr<[email protected]> wrote:
Hi Robert,
thank you for your answer.
I'll try to give some more details on the current setup:
- multiple physical displays/projectors which overlap to produce a single
(flat-)screen
- alignment and blending of the displays is done with the 3rd-party stuff
- the displays support checkerboard-stereo
In mono-mode my integration of OSG and the 3rd party stuff works perfectly
and all display do what they are supposed to do. The post-processing is done
in the camera's postDrawCallback without any magic :) The problem starts
when I enable OSGs checkerboard-stereo because the image-distortion in the
postDrawCallback will result in an unusable checkerboard-frame. So basically
I'm trying to get checkerboard-stereo to work.
Due to the described problem, I need access to the left and right frames to
distort them individually. Normally they are "blend together" via stenciling
in osg::RenderStage::draw(). As far as I know, there is no direct access to
these frames. I could either implement some kind of callback into OSG or
implement a variant of checkerboard-stereo myself.
Currently I'm trying to render both frames individually to an FBO and
putting them together afterwards. In this case I would have control of both
frames and I would be able to manipulate them with the help of the 3rd-party
code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't
able to do the trick since I've found no way to access the FBO OSG utilizes.
Therefore I've tried my own implementation (currently on a single display)
with the following setup and the given result in the post before (take a
look at the attached picture).
The current implementation is very similiar to the osgprerender example
(stereo is not enabled) except that I'm creating my own FBO in a
preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and
is used as the rendertarget for the first (left) (RTT-)camera.
RenderTargetImplementation for this camera has not been explicitly set. The
texture is attached to a rectangular geometry, which is itself a child of
the osgViewers camera. Unfortunately the result of the RTT looks like the
attached image. The image was saved in the postDrawCallback. I'm pretty sure
I've messed something up or missed something. RTT with OSGs FBO works fine
and I've looked at the code but I didn't find anything.
Does someone have an idea? Or maybe another way to implement
checkerboard-stereo? It looks like some faces get culled away. If its useful
I'll post some code.
@Robert: I'm not using osgUtils low level stereo right now but I guess some
of the code would later be useful to get the correct left and right
camera-position-setup.
Nice greetings and thanks for any help or hint!
Mathias Buhr
P.S.: I was already able to do the distortion with that implementation (with
blitting the FBO-image back to the window-system provided FB to get the 3rd
party stuff working).
Am 04.08.09 19:14, schrieb Robert Osfield:
Hi Mathias,
You don't really provide enough info about your overall viewer setup
to give a direct answer. It sounds like you are using the OSG's low
level stereo support in osgUtil and combining this with a 3rd party
code that does distortion correction or similar. Doing low level
stereo and distortion correction is really going to work visually even
if you got it to work code wise, as the low level stereo support in
osgUtil assumes a flat display.
Have a bash at explaining what your system is trying to do at a high
level and then others will have a better chance of suggesting how to
go about it.
Robert.
On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhr<[email protected]> wrote:
Hi,
before going into the details of the problem, I'd like to explain what
I'm
trying to do and what I have done until now.
I have a 3rd-party function/method which is out of my scope. It seems to
read and write the window-system provided framebuffer and
manipulates/distorts the image. The first implementation was through
calling
this function in a postdraw-callback. Everything works fine this way.
Unfortunately this is not possible if the CHECKBOARD flag is set because
the
postdraw-callback is called after the complete frame (including the
stenceling for the checkerboard) is rendered. The function would distort
the
checkerboard. Hence, I have to apply this function for each "eye"
separately.
This seems possible with some changes to OSG itself but it also would
break
the possibilty to upgrade later. So I decided to take another approach:
I've tried rendering to an FBO (RTT, similar to osgprerender) but I can't
apply the function anymore in the postdraw-callback (gives GL errors).
Since
there is no access to the OSG-managed FBO (for bliting from FBO to FB) I
have implemented my own and rendered to that instead. I'll give you a
brief
overview for that:
MainCamera
- addChild(QUAD_STRIP) //an osg:Geode with an
osg::Texture2D
- addChild(LeftCamera)
- PreDrawCallback:
- if (!fbo) glGenFramebufferEXT
- glBindFramebufferEXT
- glFramebufferTexture2DEXT //attach the
osg::Texture2D
- PostDrawCallback:
- glBindFramebufferEXT(0) //bind window-system fb
LeftCamera is set to PRE_RENDER
This approach gives me the result which is shown in this picture:
http://www.apparatus.de/test1.png
Does someone have an idea what is going wrong or what I've missed? I've
looked at the RenderStage code (and much more :-) ) but I haven't found
something that might be the problem.
Or maybe there is another (better) approach to this problem. Any hints
for
that?
I would appreciate any help! Thank you very much for reading :-)
Greetings
Mathias
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
