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<mathias...@gmx.de> 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<mathias...@gmx.de> 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 >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
