Hi Brian, In what way is the rendering not what you expect when you use osg::CameraNode? Its all OpenGL under the hood so most likely causes are some difference in OpenGL state or the depth of the colour buffer.
Robert. On 3 Jan 2007 16:54:12 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi Robert, Yes, I agree that using the CameraNode would be easier and more efficient than using the Producer. I have also implemented the code below using CameraNodes, and as far as I can tell the same shaders are being used in the same order. However, the output is clearly different. It's as though there is another step being performed by Producer that is causing the imagery to be rendered correctly. I'd like to say that my CameraNode implementation is the correct one, but I've been convinced otherwise. What I plan to do is to simplify the scenario a bit and work from there. As you've pointed out, the current implementation is a bit complex. Thanks, Brian On Wed, 3 Jan 2007 10:37:00 +0000, "Robert Osfield" <[EMAIL PROTECTED]> wrote : > Hi Brian, > > Your set up is too complex for me to get my head around remotely. > Personally I wouldn't use Producer for FBO work, the core OSG's > osg::CameraNode (now named osg::Camera in CVS) has support for FBO > while Producer doesn't. Please see the OSG RTT examples such as > osgprerender, osgprerendercubemap, osgshadowtexture etc. > > Robert. > > On 2 Jan 2007 23:45:37 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Hi Robert, > > > > Thanks again for the tips, but I'm still struggling with this issue. > > Here's what I'm attempting at a slightly deeper level. > > > > I'm using two cameras. One is my main scene, and the other is used to do > > multipass rendering. The multipass render camera uses a drawable object > > that does nothing but clear the color and depth buffers. Attached to this > > multipass camera are n additional cameras and a rendering surface. > > > > Each camera has a newly allocated drawable object as described above. > > Associated with each additional camera (Producer::Camera) is a new FBO, > > Geode, texture, scene handler, and render buffer. The FBOs are set up so > > that the output of the previous render will be used as the input to the > > next rendering cycle. Each texture has its own shader that is associated > > with it. > > > > In the multipass camera's main rendering function, all the additional > > cameras are rendered to produce a final image that is output to the > > display. This all works fine, and hopefully what I wrote makes sense. > > > > The problem that I'm having is that because the multipass camera has its > > own rendering surface, it also has its own window. Since this is a > > secondary camera, I'd like to take the final imagery that is generated for > > the multipass camera and use it in the main application window. I had > > hoped that it would be a simple matter of attaching a quad to a geode and > > then attaching the secondary window's final texture to the geode's > > stateset. Unfortunately, the only thing rendered to the main application's > > geode is a gray quad, whereas the secondary window is rendering correctly. > > > > I have verified that the pipeline is rendering the multipass camera before > > the main window's camera. I have also tried creating a camera node in the > > main camera using the final texture, FBO, and rendering surface from the > > multipass camera. This, too, failed. > > > > I hope that my explanation of what I'm trying to do makes sense. If not, > > I'd be more than happy to try and clarify. > > > > Thanks, > > Brian > > > > > Hi Brian, > > > > > > I'm just about to head away for a trip, so some quick pointers. Yes > > > you can share texture objects between separate graphics contexts in > > > certain situations, but its isn't universally supported by graphics > > > drivers/hardware. You can get the OSG/Producer to do it use but I > > > can't recall the details off the top of my head, so you'll need to dig > > > into the API of Producer. > > > > > > The quickest thing is probably to just have a HUD on the same window > > > that has your RTT texture. See the osgshadowtexture example for just > > > this type of usage. > > > > > > Robert. > > > > > > On 27 Dec 2006 23:17:37 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > wrote: > > > > Hi, > > > > > > > > I have developed an application that uses one camera that uses camera > > nodes > > > > to render a scene to a texture. It works fine and has no problems > > (that I > > > > know of.) > > > > > > > > I have recently been asked to create another window with a camera in it > > > > that simply displays the texture rendered in my original application > > > > window. I've tried setting up the new window's camera with either a > > shared > > > > RenderSurface object from the original application's window or its own > > > > private RenderSurface object. In both cases, I cannot get the texture, > > an > > > > osg::Texture2D object created for the original camera, to display. > > > > > > > > What I wind up seeing is my scene along with a *partial* rendered scene > > in > > > > the original window, and in the new window, I see my quad rendered as a > > > > gray image. The gray image persists even when the texture is not added > > to > > > > the geometry's state set, and the partial rendered scene that had > > appeared > > > > in the original window also disappears. This leads me to the conclusion > > > > that the texture itself is not being seen by the second camera. > > > > > > > > Is there a way to get the second camera to recognize and correctly > > display > > > > a texture rendered by the first camera? The RTT does its job fine, and > > a > > > > quad using the rendered texture can be displayed in the original window. > > > > It's only when I add the second camera that I have problems. > > > > > > > > Thanks, > > > > Brian > > > > > > > > _______________________________________________ > > > > 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/ > > > > > > > > > > > _______________________________________________ > > 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/ > > > _______________________________________________ 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/
