Re: [osg-users] Multiple render targets not working.
I (sort of) solved the problem. I re-implemented the camera system according the Cookbook chapter 6 (which I only used partially the previous time) and frame buffer objects and multiple render targets worked. It was a combination of wrong camera settings and scene hierarchy. Although I did run into the problem again that screen resizing did not work and it requires a complete re-creation of the RTT camera's every time, while with my previous setup I only had to rescale the textures and viewports. Additionally for some reason the entities of the scene are in the wrong location compared to the spherical earth (from osgEarth). Since I already have spent too much time on this I will stick with the old setup for now and maybe come back to it some other time. Thanks for the help. Cheers, Sander -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61869#61869 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets not working.
I gave you the code ...can't do more -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61855#61855 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multiple render targets not working.
Hi,
I have a problem when using multiple color buffer render targets. If I use one
color buffer everything works fine, but when I use two; the render result
always ends up in the last buffer and the first one remains blank.
I have used the osgmultiplerendertargets example as a guide.
My main camera renders to a texture and a following post processing camera
renders to a screen quad.
I assign the color buffers as follows:
[code]
for (unsigned int i = 0; i 2; ++i) {
osg::Texture2D* texture = new osg::Texture2D();
texture-setInternalFormat(GL_RGBA);
texture-setTextureSize(size.x(), size.y());
texture-setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR);
texture-setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR);
texture-setWrap(osg::Texture::WRAP_S, osg::Texture::CLAMP_TO_EDGE);
texture-setWrap(osg::Texture::WRAP_T, osg::Texture::CLAMP_TO_EDGE);
mainCamera-attach(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0+i),
texture);
}
[/code]
And then bind the target textures as uniforms to the post process camera:
(I have also tried a simplified method of hard coding the bind instead of using
this function)
[code]
osg::StateSet* stateSet = this-getOrCreateStateSet();
for (int i = 0; i aNumbSourceTextures; ++i) {
auto bufferIt =
aConnectToCameraOrPPU-getBufferAttachmentMap().find(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0+i));
if (bufferIt != aConnectToCameraOrPPU-getBufferAttachmentMap().end()
dynamic_castosg::Texture2D*(bufferIt-second._texture.get())) {
stateSet-setTextureAttribute(i,
dynamic_castosg::Texture2D*(bufferIt-second._texture.get()));
std::ostringstream stm;
stm mTexture i;
stateSet-addUniform(new osg::Uniform(stm.str().c_str(), i));
}
}
[/code]
I write to the buffer in the shader:
[code]
gl_FragData[0].r = intTemp / 25.0f;
gl_FragData[0].g = fracTemp;
gl_FragData[0].b = materialIndex;
gl_FragData[0].a = mainTexture.a;
gl_FragData[1] = texture(mTexture0, gl_TexCoord[0].st);
[/code]
I read the bound texture in the post process shader as normal:
[code]
gl_FragColor = texture(mTexture0, gl_TexCoord[0].st);
[/code]
As far as I can tell this code should bind COLOR_BUFFER0 to uniform sampler2D
mTexture0 and COLOR_BUFFER1 to mTexture1. But instead the result of
COLOR_BUFFER0 ends up in mTexture1 and mTexture0 is full black.
We use OSG 3.2.0, osgEarth 2.5 and QT 4.8.5.
The graphics card is an Intel HD2500. (could the card be the problem?)
I have been struggling with this problem on and off for a couple of days now, I
hope someone can help.
Thank you!
Cheers,
Sander[/list][/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61813#61813
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets not working.
seams there's a problem in camera setup,but you didn't give it... There's plenty of entries in osg forum concerning RTT camera setup.. hope the further code help Code: setClearMask(GL_COLOR_BUFFER_BIT); // setClearMask( GL_COLOR_BUFFER_BIT); setClearColor(osg::Vec4(0.0f, 0, 0, 0.0f)); setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR); // set the camera to render before the main camera. setRenderOrder(osg::Camera::PRE_RENDER, 110); // tell the camera to use OpenGL frame buffer object where supported. setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); //setReadBuffer(osg::Camera::COLOR_BUFFER); setProjectionResizePolicy(osg::Camera::FIXED); setReferenceFrame(osg::Transform::ABSOLUTE_RF); setViewMatrix(osg::Matrix::identity()); setImplicitBufferAttachmentMask(osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT, osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT); setAllowEventFocus(false); setDrawBuffer(osg::Camera::COLOR_BUFFER0); setViewMatrix(osg::Matrix::identity()); -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61816#61816 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets not working.
[quote=mp3butcher]seams there's a problem in camera setup,but you didn't give it... There's plenty of entries in osg forum concerning RTT camera setup.. hope the further code help [code] setClearMask(GL_COLOR_BUFFER_BIT); setClearColor(osg::Vec4(0.0f, 0, 0, 0.0f)); setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR); // set the camera to render before the main camera. setRenderOrder(osg::Camera::PRE_RENDER, 110); // tell the camera to use OpenGL frame buffer object where supported. setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); setProjectionResizePolicy(osg::Camera::FIXED); setReferenceFrame(osg::Transform::ABSOLUTE_RF); setViewMatrix(osg::Matrix::identity()); setImplicitBufferAttachmentMask(osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT, osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT); setAllowEventFocus(false); //setReadBuffer(osg::Camera::COLOR_BUFFER); setDrawBuffer(osg::Camera::COLOR_BUFFER0); setViewMatrix(osg::Matrix::identity()); setProjectionMatrix(osg::Matrix::ortho2D(0, 1, 0, 1)); attach(osg::Camera::COLOR_BUFFER0, tex.get()); [/code][/quote] Indeed that would be useful. I have read all the RTT entries which I could find, but it didn't help me solve the problem. My camera code: [code] mainCamera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); mainCamera-setClearColor(osg::Vec4f(0.0f, 0.0f, 0.0f, 1.0f)); mainCamera-setRenderOrder(osg::Camera::PRE_RENDER); mainCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER); mainCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); [/code] I use FRAME_BUFFER because FRAME_BUFFER_OBJECT results in a black screen. I have tried your settings, but it doesn't make a difference and setDrawBuffer(osg::Camera::COLOR_BUFFER0) gives an invalid enumerant error. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61817#61817 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets Multisampling
Hi Anthousis, thanks for looking into this. rgds jp On 08/04/11 16:22, Anthousis Andreadis wrote: Ok i think i fixed the issue. When you have an FBO with Multisample you have to perform the blit operation from the MS FBO to a simple FBO. When the FBO has MRT you have to perform a blit operation per COLOR_ATTACHMENT. so basically you have to perform the glReadBuffer glDrawBuffer glBlitFrameBuffer once per attachment. In the RenderStage.cpp this was done only once. I will post a submission in the corresponding list with the changes. Anthousis Andreadis On Fri, Apr 8, 2011 at 1:04 PM, dimi christop dimi_chris...@yahoo.com mailto:dimi_chris...@yahoo.com wrote: As far I understand, what you are saying is that as soon as you enable multisampling on the FBOs you can not use the multiple render targets. All targets show the same thing as the first one. But this is not the case when you dont use a multisampled FBO. I had the exact same problem and dropped the efford to find a solution as soon I found that probably something inside osg was the culprit. All my pure OpenGL examples were running fine. What does OSGPPU do to handle multisampled FBOs? Dimi - Original Message From: Anthousis Andreadis anthou...@gmail.com mailto:anthou...@gmail.com To: osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org Sent: Thu, April 7, 2011 11:39:20 AM Subject: [osg-users] Multiple Render Targets Multisampling Hi, Has anyone tried to do any advanced* multisampled post effect using osg? If yes, I would like to know the best osg path to achieve this. *deferred rendered for example I have tried to attach a texture to a camera along with the multipleSamples and multisampleColorSamples values. This works ONLY when i have one rendertarget. In all other cases in the final compositing shader, i see only the first (and not the 2nd 3rd etc ) render target. The other render targets are not black, but they appear overwritten with the contents of the first render target. On the other hand i see the osgfpdepth example and it has a completely different approach to the subject, almost handling manually fbos and rendertargets. I tried searching on the mailing list for this subject, but almost all discussions seem to stop without a final result at about 2 years ago. Tnx for your time, Anthousis Andreadis anthou...@gmail.com mailto:anthou...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets Multisampling
As far I understand, what you are saying is that as soon as you enable multisampling on the FBOs you can not use the multiple render targets. All targets show the same thing as the first one. But this is not the case when you dont use a multisampled FBO. I had the exact same problem and dropped the efford to find a solution as soon I found that probably something inside osg was the culprit. All my pure OpenGL examples were running fine. What does OSGPPU do to handle multisampled FBOs? Dimi - Original Message From: Anthousis Andreadis anthou...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Thu, April 7, 2011 11:39:20 AM Subject: [osg-users] Multiple Render Targets Multisampling Hi, Has anyone tried to do any advanced* multisampled post effect using osg? If yes, I would like to know the best osg path to achieve this. *deferred rendered for example I have tried to attach a texture to a camera along with the multipleSamples and multisampleColorSamples values. This works ONLY when i have one rendertarget. In all other cases in the final compositing shader, i see only the first (and not the 2nd 3rd etc ) render target. The other render targets are not black, but they appear overwritten with the contents of the first render target. On the other hand i see the osgfpdepth example and it has a completely different approach to the subject, almost handling manually fbos and rendertargets. I tried searching on the mailing list for this subject, but almost all discussions seem to stop without a final result at about 2 years ago. Tnx for your time, Anthousis Andreadis anthou...@gmail.com ___ 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
Re: [osg-users] Multiple Render Targets Multisampling
Ok i think i fixed the issue. When you have an FBO with Multisample you have to perform the blit operation from the MS FBO to a simple FBO. When the FBO has MRT you have to perform a blit operation per COLOR_ATTACHMENT. so basically you have to perform the glReadBuffer glDrawBuffer glBlitFrameBuffer once per attachment. In the RenderStage.cpp this was done only once. I will post a submission in the corresponding list with the changes. Anthousis Andreadis On Fri, Apr 8, 2011 at 1:04 PM, dimi christop dimi_chris...@yahoo.comwrote: As far I understand, what you are saying is that as soon as you enable multisampling on the FBOs you can not use the multiple render targets. All targets show the same thing as the first one. But this is not the case when you dont use a multisampled FBO. I had the exact same problem and dropped the efford to find a solution as soon I found that probably something inside osg was the culprit. All my pure OpenGL examples were running fine. What does OSGPPU do to handle multisampled FBOs? Dimi - Original Message From: Anthousis Andreadis anthou...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Thu, April 7, 2011 11:39:20 AM Subject: [osg-users] Multiple Render Targets Multisampling Hi, Has anyone tried to do any advanced* multisampled post effect using osg? If yes, I would like to know the best osg path to achieve this. *deferred rendered for example I have tried to attach a texture to a camera along with the multipleSamples and multisampleColorSamples values. This works ONLY when i have one rendertarget. In all other cases in the final compositing shader, i see only the first (and not the 2nd 3rd etc ) render target. The other render targets are not black, but they appear overwritten with the contents of the first render target. On the other hand i see the osgfpdepth example and it has a completely different approach to the subject, almost handling manually fbos and rendertargets. I tried searching on the mailing list for this subject, but almost all discussions seem to stop without a final result at about 2 years ago. Tnx for your time, Anthousis Andreadis anthou...@gmail.com ___ 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] Multiple Render Targets Multisampling
Hi, Has anyone tried to do any advanced* multisampled post effect using osg? If yes, I would like to know the best osg path to achieve this. *deferred rendered for example I have tried to attach a texture to a camera along with the multipleSamples and multisampleColorSamples values. This works ONLY when i have one rendertarget. In all other cases in the final compositing shader, i see only the first (and not the 2nd 3rd etc ) render target. The other render targets are not black, but they appear overwritten with the contents of the first render target. On the other hand i see the osgfpdepth example and it has a completely different approach to the subject, almost handling manually fbos and rendertargets. I tried searching on the mailing list for this subject, but almost all discussions seem to stop without a final result at about 2 years ago. Tnx for your time, Anthousis Andreadis anthou...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Hi Bob, The answer is almost always answered by answering the simple question - no you logically have two separate views or do the two cameras that are taken the pictures share the same view. In your case it does sound like you have a single view, but two ways of rendering it - so you don't have multiple view's, and since you only have a single view then a osgViewer::Viewer (which is a View) will be appropriate. Robert. On Tue, Jun 16, 2009 at 9:59 PM, Bob Youmansbyoum...@knology.net wrote: Hi, thanks for the great advice. if i'm going to have 2 render targets, one a memory image (ultimately custom shader) and one the GUI view window, should i still use Viewer, or CompositeViewer? It would be nice to be able to turn off the visible one for more performance. They will have exactly the same transform matrix, but be different resolutions. So, i need to switch between user / program control of the transformation matrix, and also switch between rendering the memory / visible images (or both). Is this doable? Does it make sense? Thank you! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14052#14052 ___ 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
Re: [osg-users] multiple render targets / cameras
Hi, thanks for the great advice. if i'm going to have 2 render targets, one a memory image (ultimately custom shader) and one the GUI view window, should i still use Viewer, or CompositeViewer? It would be nice to be able to turn off the visible one for more performance. They will have exactly the same transform matrix, but be different resolutions. So, i need to switch between user / program control of the transformation matrix, and also switch between rendering the memory / visible images (or both). Is this doable? Does it make sense? Thank you! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14052#14052 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Mike Wozniewski wrote: It's probably osgViewer::CompositeViewer that you want, not osgViewer::Viewer. There's an example in the source. That way you create two different osgViewer::Views, and each can have it's own manipulator. I'm not sure why you'd need a CompositeViewer if both cameras are supposed to be in the same position orientation. Am I missing something? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] multiple render targets / cameras
Hi, thanks to the gurus for all the excellent guidance you provide to us lesser mortals.. I can likely mush my way through this but I wanted to ask the opinions of the osg gurus on my design approach before getting mired down in a less desirable approach. We have a geometry graph that we want to render to two separate places: (1) a bitmap image for additional automated analysis or use downstream in a shader (that will also render to a similarly sized memory image), and (2) the window context that can show the progress on the display, but not necessarily replicate exactly the underlying hi-resolution image in memory, for performance reasons. They'll probably have different resolutions, say 1024 x 1024 for the bitmap and whatever window size the user sets for the display. I'm thinking two separate cameras, and I've seen in the examples (osg distortion?) where the bitmap is setup, and I've also seen in other posts several discussions about multiple camera for multiple views. Then, I need to have these cameras under program control, say, iterating a rotation angle in 1 deg increments, and iterating the distance over some range and increment (or the corresponding camera position), drawing a frame of each (and ultimately processing the resulting image with downstream algorithms and code). Real time frame rates are probably not a reasonable expectation for this analyzer. I want the view version to give low-res feedback about the progress and correctness of the underlying hi-res memory image processing. My questions are currently: 1.What's the best way to connect the two cameras so they're the same position orientation, only rendering to different targets (e.g., update the matrix of one with the other using an update traversal, put both under a transform node in a tree, etc.)? 2. What's the best way to programmatically (vs TrackBallManipulator default) control the camera, and/or switch between these methods? Is my design sound, or should I pursue some other approach? If the separate window context with different resolution is a problematic design, I can let go of that, but I think we're really pursuing the memory image processing approach, ultimately needing a shader program and then finally combining two memory bitmaps, respecting the transparency of one, analogous to some kind of specially programmed x-ray view, then extract the transparent parts and average the color of it. Thanks, Bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Bob Youmans wrote: My questions are currently: 1.What’s the best way to connect the two cameras so they’re the same position orientation, only rendering to different targets (e.g., update the matrix of one with the other using an update traversal, put both under a transform node in a tree, etc.)? This sounds like a plain old osgViewer::Viewer with a slave camera is the way to go. You control the viewpoint with the master camera, and both cameras render wherever you need them. I think the osgsidebyside example may give you an idea how to set this up (it's not exactly what you're looking for, but a lot of the code is relevant). osgprerender might also be relevant. 2. What’s the best way to programmatically (vs TrackBallManipulator default) control the camera, and/or switch between these methods? The most straightforward way to do this is with an UpdateCallback. I think Paul Martz's OSG Quick Start Guide explains this pretty well. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Hi, about the view and slave cameras, i got it, thanks. one is the lo-res view for the GUI and the other is the hi-res (prerender) view for the memory bitmap. does it matter for the master/slave status for prerender vs the displayed camera. Also, how does one turn these on/off? is that easy to control? ... Thank you! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13725#13725 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Hi, regarding matrixmanipulators, almost all the example have TrackBallManipulator as the view's manipulator, separater from the cameras. So, if i have an update callback on a camera to set its (and its slave) position and orientation, how does that interact with a trackballmanipulator. can i remove it from the view and add it back? can i easily toggle on/off the trackballmanipulator, so i can control programmatic vs user control of these master/slave cameras? that would be really nice. Thank you! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13726#13726 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Bob Youmans wrote: Hi, about the view and slave cameras, i got it, thanks. one is the lo-res view for the GUI and the other is the hi-res (prerender) view for the memory bitmap. does it matter for the master/slave status for prerender vs the displayed camera. I don't believe it will matter for what you've described so far. Depending on how your application will work, you might prefer to have one or the other view be the master. Also, how does one turn these on/off? is that easy to control? I believe you can turn cameras on/off by using their node mask (set to 0x for on, and 0x for off). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
Bob Youmans wrote: Hi, regarding matrixmanipulators, almost all the example have TrackBallManipulator as the view's manipulator, separater from the cameras. So, if i have an update callback on a camera to set its (and its slave) position and orientation, how does that interact with a trackballmanipulator. Typically, you don't want to have both a manipulator and an update callback controlling the camera. can i remove it from the view and add it back? can i easily toggle on/off the trackballmanipulator, so i can control programmatic vs user control of these master/slave cameras? that would be really nice. If you look at the osgviewer source, there's an example of how to switch between manipulators on the fly using a KeySwitchMatrixManipulator. Instead of an update callback, you can also just write a simple matrix manipulator to control the camera in the way you described earlier. Then you'll be able to switch between them pretty easily. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple render targets / cameras
It's probably osgViewer::CompositeViewer that you want, not osgViewer::Viewer. There's an example in the source. That way you create two different osgViewer::Views, and each can have it's own manipulator. The control is up to you, but if you want automated rotations and panning, I usually use NodeTrackerManipulator instead of TrackBallManipulator. I just create a PositionAttitudeTransform somewhere in my scene that represents the camera position, and animate it in a callback like Jason suggests. -Mike Jason Daly wrote: Bob Youmans wrote: My questions are currently: 1.What’s the best way to connect the two cameras so they’re the same position orientation, only rendering to different targets (e.g., update the matrix of one with the other using an update traversal, put both under a transform node in a tree, etc.)? This sounds like a plain old osgViewer::Viewer with a slave camera is the way to go. You control the viewpoint with the master camera, and both cameras render wherever you need them. I think the osgsidebyside example may give you an idea how to set this up (it's not exactly what you're looking for, but a lot of the code is relevant). osgprerender might also be relevant. 2. What’s the best way to programmatically (vs TrackBallManipulator default) control the camera, and/or switch between these methods? The most straightforward way to do this is with an UpdateCallback. I think Paul Martz's OSG Quick Start Guide explains this pretty well. --J ___ 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] Multiple render targets
Hi, As far as I know MRT is not supported in some ealier version of OSG, there is no call to glDrawBuffers (as opposed to glDrawBuffer) which is needed for MRT. I don't know current vesion of OSG supprot it or not, if not ,is there any solutions available in the osg community today? I would greatly appreciate if you can give some examples. Thanks in advance, zhangguilian 2008-04-06 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
Robert checked-in the support and example JP wrote for MRT several days ago, so I guess the last svn update should help you with that. Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of zhangguilian Sent: Sunday, April 06, 2008 5:16 PM To: osg-users Subject: [osg-users] Multiple render targets Hi, As far as I know MRT is not supported in some ealier version of OSG, there is no call to glDrawBuffers (as opposed to glDrawBuffer) which is needed for MRT. I don't know current vesion of OSG supprot it or not, if not ,is there any solutions available in the osg community today? I would greatly appreciate if you can give some examples. Thanks in advance, zhangguilian 2008-04-06 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi, I think we have discussed this issue before. I also not familiar with the general framework use of SetState, I myself implemented solution similar to that of JS with the exception that I activated the glDrawBuffer extension in the apply method of the FBO. I also made another difference, I didn't use vector for the draw buffers, but counted the attachments of different color buffers, and only if those were greater than one, applied the drawBuffers extension. But I thought to myself, is it true to use it ONLY when FBO's are on? I'm not familiar enough with attachments when not using FBO (like PBuffer or maybe in the future there will be separate frame buffers for separate screens) and this returns the location of applying the extension back to the RanderStage as JS did. (That's why I was quiet until now :) ) Now, suppose I do understand a little about SetStates, this is not applicable here since if there is more than one color buffer attachment you must use the extension, and if not, there is no point in using the extension, so why let the user set the state? What I think should be done is instead of adding the setDrawBuffers(BuffersVec) method, in the RenderStage setUpCamera function one should count the attachments to different color buffers and decide whether to use the extension or not, and in the InnerDraw apply the extension according to the flag found in the setUpCamera. Besides that I think JS has done very nice work. Bravo. (or cheers or as we say in Israel Kifak-Hey) :) Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Tuesday, April 01, 2008 2:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi Art, Art Tevs wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. Yes, I've compiled osgPPU and ran the examples; cannot say that I fully understand the code yet :) However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? I think having the MRT selection going through FBO-class could be a good option. However, I do not know how to add the StateAttribute. We might need an enable/disable and setDrawbuffers, or can a StateAttribute take a vector? I do not know how to pass the vector of render targets using an attribute? - At the moment I have: Camera-setDrawBuffers(vec) - this sets the intention to use MRT and also passes the list of targets. RenderStage-runCameraSetup - this queries the camera for the buffers, and if there are any, creates a vector of GLenums. RenderStage-drawInner - The existence of the target vector is used to determine if MRT is enabled. glDrawBuffers is called using the vector. - I think what you propose is: Camera-setDrawBuffers(vec) RenderStage-runCameraSetup - since this creates the FBO anyway, it might as well pass the camera settings regarding MRT to the FBO. Maybe using _fbo-setDrawBuffers. RenderStage-drawInner - instead of checking the member _drawBuffers, query the FBO to determine if MRT should be enabled and also get the list of targets from the FBO. - This could work, and I can probably integrate it into the patch, but I'm not sure how you get your FBOs into renderstage at present. Also, how do you control the reading back of textures/images? At the moment the readback attachment map is also setup in camera. Would this also need to be moved? Cheers, Art rgds jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hello, In continue to what I said before, I don't believe it's possible to change the subgraphs MRT definitions, since all the subgraph under the camera renders to the camera attachments. So if the camera is using MRT, then all the subgraph is rendered MRT. The differences in the subgraphs could be the shaders using or not using the MRTs. That brings the issue that if shaders use MRT and we didn't set the attachments correctly, a problem will occur. So what I think should happen is that whether using StateSet attribute to declare the need for MRT by sub-graphs or by testing the Shaders, the camera should activate some visitor on it's sub-graph, find the draw buffers required, and then setup itself for the maximum need. But then the setting would be the same for the whole sub-graph. Does it makes sense? Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, April 01, 2008 3:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi Art J.P, I'm curious about the going for a custom StateAttribute for DrawBuffers. In terms of encapsulation osg::Camera isn't a bad place for it, as there is already lots of RTT support there already. If there are cases when you want to enable/disable different combinations of DrawBuffers within on RTT subgraph then the StateAttribute is certainly the way to go. I haven't yet player with MRT yet though so can't really give too much insight based on experience so am all ears. Robert. On Tue, Apr 1, 2008 at 1:08 PM, Art Tevs [EMAIL PROTECTED] wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? Cheers, Art --- J.P. Delport [EMAIL PROTECTED] schrieb: Hi Wojtek, Wojciech Lewandowski wrote: I tried to compile it and link on Windows with latest SVN. Compiled and linked fine.I ran osg prerender and shadow exmples with fbo. Again no problems. But frankly haven't tested MRT functionality at all. thanks for the testing, I'm glad other fbo code is still fine. We are using MRT for two projects here and it works on Windows and Linux, so 'it works for me (TM)'. I'll submit it. thanks jp Cheers, Wojtek -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi Guy, Thanks for jumping in on the discussion, it does remind me of part of the original intent of the osg::Camera BufferComponent is that it'd map to MRT, but... I'm rather cold on the subject having not visited it for over a year. Your suggestion of computing the glDrawBuffers setting from the BufferComponents makes sense, actually it's probably what I was vaguely hoping for in my original code. Alas I never got further than just wiring up standard FBO's though, and haven't had the time to experiment with MRT so have to defer to others that have. Perhaps on review of J.P's code how the extension is used will make more sense and how to do the above mapping automatically will come to me. Feel free to propose your own code though... Robert. On Wed, Apr 2, 2008 at 8:15 AM, Guy [EMAIL PROTECTED] wrote: Hi, I think we have discussed this issue before. I also not familiar with the general framework use of SetState, I myself implemented solution similar to that of JS with the exception that I activated the glDrawBuffer extension in the apply method of the FBO. I also made another difference, I didn't use vector for the draw buffers, but counted the attachments of different color buffers, and only if those were greater than one, applied the drawBuffers extension. But I thought to myself, is it true to use it ONLY when FBO's are on? I'm not familiar enough with attachments when not using FBO (like PBuffer or maybe in the future there will be separate frame buffers for separate screens) and this returns the location of applying the extension back to the RanderStage as JS did. (That's why I was quiet until now :) ) Now, suppose I do understand a little about SetStates, this is not applicable here since if there is more than one color buffer attachment you must use the extension, and if not, there is no point in using the extension, so why let the user set the state? What I think should be done is instead of adding the setDrawBuffers(BuffersVec) method, in the RenderStage setUpCamera function one should count the attachments to different color buffers and decide whether to use the extension or not, and in the InnerDraw apply the extension according to the flag found in the setUpCamera. Besides that I think JS has done very nice work. Bravo. (or cheers or as we say in Israel Kifak-Hey) :) Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Tuesday, April 01, 2008 2:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi Art, Art Tevs wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. Yes, I've compiled osgPPU and ran the examples; cannot say that I fully understand the code yet :) However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? I think having the MRT selection going through FBO-class could be a good option. However, I do not know how to add the StateAttribute. We might need an enable/disable and setDrawbuffers, or can a StateAttribute take a vector? I do not know how to pass the vector of render targets using an attribute? - At the moment I have: Camera-setDrawBuffers(vec) - this sets the intention to use MRT and also passes the list of targets. RenderStage-runCameraSetup - this queries the camera for the buffers, and if there are any, creates a vector of GLenums. RenderStage-drawInner - The existence of the target vector is used to determine if MRT is enabled. glDrawBuffers is called using the vector. - I think what you propose is: Camera-setDrawBuffers(vec) RenderStage-runCameraSetup - since this creates the FBO anyway, it might as well pass the camera settings regarding MRT to the FBO. Maybe using _fbo-setDrawBuffers. RenderStage-drawInner - instead of checking the member _drawBuffers, query the FBO to determine if MRT should be enabled and also get the list of targets from the FBO. - This could work, and I can probably integrate it into the patch, but I'm not sure how you get your FBOs into renderstage at present. Also, how do you control the reading back of textures/images? At the moment the readback attachment map is also setup in camera. Would this also need to be moved? Cheers, Art rgds jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi,
Since the change I suggest is very small from what JP has implemented I
don't submit files here just the differences:
I removed getDrawBuffers and setDrawBuffers from the Camera.cpp / h
In RenderStage the changes are as follows:
RanderStage //.h
Added vector of GLEnum named _drawBuffers.
RenderStage.cpp
In function runCameraSetUp, before the attachments loop (line 245)
_drawBuffers.clear();
In the loop, add at the start of the loop the few lines:
if(itr-first = COLOR_BUFFER0 itr-first =
COLOR_BUFFER7)
_drawBuffers.push_back(itr-first -
COLOR_BUFFER0 +
GL_COLOR_ATTACHMENT0_EXT);
And removed the line JP added (about line 404)
// set up draw buffers if using multiple render targets
osg::Camera::DrawBufferVector cam_buffers =
_camera-getDrawBuffers();
_drawBuffers.clear();
for (osg::Camera::DrawBufferVector::iterator buf =
cam_buffers.begin();
buf != cam_buffers.end();
++buf)
{
_drawBuffers.push_back(GL_COLOR_ATTACHMENT0_EXT+(*buf -
osg::Camera::COLOR_BUFFER0));
}
Then in function drawInner, in the second line JP wrote:
bool using_multiple_render_targets = !(_drawBuffers.empty());
I changed it to
bool using_multiple_render_targets = (_drawBuffers.size() 1);
That's all the changes. So if JP can check it (I have a mess of OSG1.2
and OSG2.3 code) then you can decide what to submit.
Now after the follow up discussion of the matter, it still won't be a
complete solution. I think in the setUpCamera code, the render stage
should run custom visitor on the camera and it's sub-graphs that checks
for nodes requests for MRT, for the camera it would be the color
attachments, and for nodes, whatever data that could be implemented in
the StateAttribute, that later would mapped to Color Attachment, and
only after collecting all the requests and having all the attachments
that will be used, the RenderStage will set up the _drawBuffers as
implemented above.
This is more complicated to implement and since I'm not very good with
visitors I can only suggest a pseudo code to write in the renderstage
setUpCamera before the _drawBuffers initialization (about line 245)
something like this should happen:
RTTVisitor rttVS;
Camera-accept(rttVS);
_drawBuffers = rttVS.getDrawBuffers();
And remove the code that push_back stuff to the _drawBuffers.
Now the RTTVisitor apply methods should be something like
Apply(Camera cam)
{
Foreach attachment in AttachmentBuffers
If( COLOR_BUFFER0 = attachment = COLOR_BUFFER7)
_drawBuffers.pushback(attachment - COLOR_BUFFER0 +
GL_COLOR_ATTACHMENT0_EXT);
cam.Traverse();
}
This is what should implemented and I'm not sure how
Apply(Node node)
{
Foreach attachment in Node.GetStateAtrributeMRTStuff
If( COLOR_BUFFER0 = attachment = COLOR_BUFFER7(
_drawBuffers.pushback(attachment - COLOR_BUFFER0 +
GL_COLOR_ATTACHMENT0_EXT);}
node.Traverse();
}
What do you think? Will that give a full solution? I think that this way
even if the MRT code is down there somewhere at some node, the camera
will be set correctly, the fixed pipeline will render to COLOR_BUFFER0
and the specific node with the shader can render what it wants to what
buffer it wants.
Is that what Art ment?
Thanks,
Guy.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi Guy, Robert, Robert Osfield wrote: Hi Guy, Thanks for jumping in on the discussion, it does remind me of part of the original intent of the osg::Camera BufferComponent is that it'd map to MRT, but... I'm rather cold on the subject having not visited it for over a year. Your suggestion of computing the glDrawBuffers setting from the BufferComponents makes sense, actually it's probably what I was vaguely hoping for in my original code. Alas I never got further than just wiring up standard FBO's though, and haven't had the time to experiment with MRT so have to defer to others that have. Selecting glDrawBuffer/s according to the attachment map does make sense; however, Like Guy, I'm not sure if multiple attachments would always imply the intention to use MRT and for this reason I added the explicit setDrawBuffers call. The explicit call also lessens the risk for code breakage of current uses of the attachment map. Perhaps on review of J.P's code how the extension is used will make more sense and how to do the above mapping automatically will come to me. Feel free to propose your own code though... I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Robert. jp On Wed, Apr 2, 2008 at 8:15 AM, Guy [EMAIL PROTECTED] wrote: Hi, I think we have discussed this issue before. I also not familiar with the general framework use of SetState, I myself implemented solution similar to that of JS with the exception that I activated the glDrawBuffer extension in the apply method of the FBO. I also made another difference, I didn't use vector for the draw buffers, but counted the attachments of different color buffers, and only if those were greater than one, applied the drawBuffers extension. But I thought to myself, is it true to use it ONLY when FBO's are on? I'm not familiar enough with attachments when not using FBO (like PBuffer or maybe in the future there will be separate frame buffers for separate screens) and this returns the location of applying the extension back to the RanderStage as JS did. (That's why I was quiet until now :) ) Now, suppose I do understand a little about SetStates, this is not applicable here since if there is more than one color buffer attachment you must use the extension, and if not, there is no point in using the extension, so why let the user set the state? What I think should be done is instead of adding the setDrawBuffers(BuffersVec) method, in the RenderStage setUpCamera function one should count the attachments to different color buffers and decide whether to use the extension or not, and in the InnerDraw apply the extension according to the flag found in the setUpCamera. Besides that I think JS has done very nice work. Bravo. (or cheers or as we say in Israel Kifak-Hey) :) Thanks, Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Tuesday, April 01, 2008 2:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi Art, Art Tevs wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. Yes, I've compiled osgPPU and ran the examples; cannot say that I fully understand the code yet :) However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? I think having the MRT selection going through FBO-class could be a good option. However, I do not know how to add the StateAttribute. We might need an enable/disable and setDrawbuffers, or can a StateAttribute take a vector? I do not know how to pass the vector of render targets using an attribute? - At the moment I have: Camera-setDrawBuffers(vec) - this sets the intention to use MRT and also passes the list of targets. RenderStage-runCameraSetup - this queries the camera for the buffers, and if there are any, creates a vector of GLenums. RenderStage-drawInner - The existence of the target vector is used to determine if MRT is enabled. glDrawBuffers is called using the vector. - I think what you propose is: Camera-setDrawBuffers(vec) RenderStage-runCameraSetup - since this creates the FBO anyway, it might as well pass the camera settings regarding MRT to the FBO. Maybe using _fbo-setDrawBuffers. RenderStage-drawInner - instead of checking the member _drawBuffers, query the FBO to determine if MRT should
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi Guy and J.P,
Still struggling to keep up, partly cause I'm a bit cold on the
subject, and partly because I've gone done with a rather pesky cold...
On Wed, Apr 2, 2008 at 10:47 AM, J.P. Delport [EMAIL PROTECTED] wrote:
Selecting glDrawBuffer/s according to the attachment map does make
sense; however, Like Guy, I'm not sure if multiple attachments would
always imply the intention to use MRT and for this reason I added the
explicit setDrawBuffers call. The explicit call also lessens the risk
for code breakage of current uses of the attachment map.
The BufferComponent's in the AttachmentMap area meant to be reasonable
unambiguous, COLOR_BUFFER1 upwards all require MRT to be implemented,
they can't be implement in any other way, so I don't think
implementing the backend to use MRT automatically would be
inappropriate or break previous code.
enum BufferComponent
{
DEPTH_BUFFER,
STENCIL_BUFFER,
COLOR_BUFFER,
COLOR_BUFFER0 = COLOR_BUFFER,
COLOR_BUFFER1 = COLOR_BUFFER+1,
COLOR_BUFFER2 = COLOR_BUFFER+2,
COLOR_BUFFER3 = COLOR_BUFFER+3,
COLOR_BUFFER4 = COLOR_BUFFER+4,
COLOR_BUFFER5 = COLOR_BUFFER+5,
COLOR_BUFFER6 = COLOR_BUFFER+6,
COLOR_BUFFER7 = COLOR_BUFFER+7
};
I'm sure you will see that there is no magic to my current
implementation. The difficult part is to figure out when to enable it.
Can we not just do it when COLOR_BUFFER1 upwards are enabled?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi, Guy wrote: Hello, In continue to what I said before, I don't believe it's possible to change the subgraphs MRT definitions, since all the subgraph under the camera renders to the camera attachments. So if the camera is using MRT, then all the subgraph is rendered MRT. The differences in the subgraphs could be the shaders using or not using the MRTs. Mixing shaders in the subgraph that have different target requirements would definately be a problem, but I don't think there is an easy workaround for this. That brings the issue that if shaders use MRT and we didn't set the attachments correctly, a problem will occur. Yes, this is also true. Care must be taken with the setup, just as with a lot of the other OpenGL state. So what I think should happen is that whether using StateSet attribute to declare the need for MRT by sub-graphs or by testing the Shaders, the camera should activate some visitor on it's sub-graph, find the draw buffers required, and then setup itself for the maximum need. But then the setting would be the same for the whole sub-graph. I would place this functionality at a different level than the Camera. Potentially all the functions are already in OSG to do the visitor yourself before attaching the subgraph to the camera and setting up the camera. This is an example of the two sided coin: Should OSG try to protect the user and infer intentions and possibly disallow some conbination of settings or Should it listen to explicit instructions. The current implementation follows the explicit path, but once we see how it is being used it could possibly change. Does it makes sense? Yes, all the comments are valid. We should maybe create a todo list for MRT, but I hope to get something in so people can start playing with it. Thanks, Guy. cheers jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi,
Robert Osfield wrote:
Hi Guy and J.P,
Still struggling to keep up, partly cause I'm a bit cold on the
subject, and partly because I've gone done with a rather pesky cold...
On Wed, Apr 2, 2008 at 10:47 AM, J.P. Delport [EMAIL PROTECTED] wrote:
Selecting glDrawBuffer/s according to the attachment map does make
sense; however, Like Guy, I'm not sure if multiple attachments would
always imply the intention to use MRT and for this reason I added the
explicit setDrawBuffers call. The explicit call also lessens the risk
for code breakage of current uses of the attachment map.
The BufferComponent's in the AttachmentMap area meant to be reasonable
unambiguous, COLOR_BUFFER1 upwards all require MRT to be implemented,
they can't be implement in any other way, so I don't think
implementing the backend to use MRT automatically would be
inappropriate or break previous code.
enum BufferComponent
{
DEPTH_BUFFER,
STENCIL_BUFFER,
COLOR_BUFFER,
COLOR_BUFFER0 = COLOR_BUFFER,
COLOR_BUFFER1 = COLOR_BUFFER+1,
COLOR_BUFFER2 = COLOR_BUFFER+2,
COLOR_BUFFER3 = COLOR_BUFFER+3,
COLOR_BUFFER4 = COLOR_BUFFER+4,
COLOR_BUFFER5 = COLOR_BUFFER+5,
COLOR_BUFFER6 = COLOR_BUFFER+6,
COLOR_BUFFER7 = COLOR_BUFFER+7
};
I'm sure you will see that there is no magic to my current
implementation. The difficult part is to figure out when to enable it.
Can we not just do it when COLOR_BUFFER1 upwards are enabled?
Problem is that enabling MRT with just COLOR_BUFFER0 and then using
glFragData[0] in a shader is also a valid use of glDrawBuffers. I know
this is a special case (MRT with one buffer), but it's useful when e.g.
automatically generating code.
If we ban or don't expect this type of use, then enabling MRT when
COLOR_BUFFER1 upwards are enabled should be fine.
jp
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their
support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi J.P, I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Can we not just do it when COLOR_BUFFER1 upwards are enabled? Problem is that enabling MRT with just COLOR_BUFFER0 and then using glFragData[0] in a shader is also a valid use of glDrawBuffers. I know this is a special case (MRT with one buffer), but it's useful when e.g. automatically generating code. OK. I see the issue now. If we ban or don't expect this type of use, then enabling MRT when COLOR_BUFFER1 upwards are enabled should be fine. Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. The other possibility would be to explictly enable MRT support via an option in osg::Camera. My concern about having both Camera::setDrawBuffers and the BufferComponent attachments is that its more code and open for people making mistakes in the implementation i.e. they two are set without being properly matched. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi, Robert Osfield wrote: Hi J.P, I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Can we not just do it when COLOR_BUFFER1 upwards are enabled? Problem is that enabling MRT with just COLOR_BUFFER0 and then using glFragData[0] in a shader is also a valid use of glDrawBuffers. I know this is a special case (MRT with one buffer), but it's useful when e.g. automatically generating code. OK. I see the issue now. If we ban or don't expect this type of use, then enabling MRT when COLOR_BUFFER1 upwards are enabled should be fine. Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. The other possibility would be to explictly enable MRT support via an option in osg::Camera. The special option would have the same problems as my setDrawBuffers at the moment. One could get the option and attachments out of sync. My concern about having both Camera::setDrawBuffers and the BufferComponent attachments is that its more code and open for people making mistakes in the implementation i.e. they two are set without being properly matched. Yes, I agree with this. I think your suggestion to separate COLOR_BUFFER and COLOR_BUFFER0 is the best. In RenderStage the check to enable MRT would then be as Guy suggested. See if the _drawBuffers GLenum vec has something in it. The vec is populated from the camera attachments. Robert. jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi J.P, On Wed, Apr 2, 2008 at 1:10 PM, J.P. Delport [EMAIL PROTECTED] wrote: Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. I will tweak the osg::Camera API to differentiate between COLOR_BUFFER and COLOR_BUFFER0 but not merge your changes to Camera and RenderStage right now. I will also tweak your example to work with the new Camera convention and check this in too. Then we can look at the implementation in RenderStage.cpp. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi J.P, On Wed, Apr 2, 2008 at 1:30 PM, Robert Osfield [EMAIL PROTECTED] wrote: I will tweak the osg::Camera API to differentiate between COLOR_BUFFER and COLOR_BUFFER0 but not merge your changes to Camera and RenderStage right now. I will also tweak your example to work with the new Camera convention and check this in too. Then we can look at the implementation in RenderStage.cpp. I have now checked in the changes to include/osg/Camera the .osg support in src/osgPlugin/osg/Camera.cpp and added your osgmultiplerendertargets example. An svn update will get all these changes. I haven't made any changes to RenderStage.cpp yet so MRT doesn't yet work with SVN, all it needs is some code detecting MRT and then added the appropriate glDrawBuffers call. I have a number of tasks that I need to get on with so if others are able to jump in and complete the job it'd be appreciated. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi,
Guy wrote:
Hi,
Since the change I suggest is very small from what JP has implemented I
don't submit files here just the differences:
I removed getDrawBuffers and setDrawBuffers from the Camera.cpp / h
In RenderStage the changes are as follows:
RanderStage //.h
Added vector of GLEnum named _drawBuffers.
RenderStage.cpp
In function runCameraSetUp, before the attachments loop (line 245)
_drawBuffers.clear();
In the loop, add at the start of the loop the few lines:
if(itr-first = COLOR_BUFFER0 itr-first =
COLOR_BUFFER7)
_drawBuffers.push_back(itr-first -
COLOR_BUFFER0 +
GL_COLOR_ATTACHMENT0_EXT);
And removed the line JP added (about line 404)
// set up draw buffers if using multiple render targets
osg::Camera::DrawBufferVector cam_buffers =
_camera-getDrawBuffers();
_drawBuffers.clear();
for (osg::Camera::DrawBufferVector::iterator buf =
cam_buffers.begin();
buf != cam_buffers.end();
++buf)
{
_drawBuffers.push_back(GL_COLOR_ATTACHMENT0_EXT+(*buf -
osg::Camera::COLOR_BUFFER0));
}
Then in function drawInner, in the second line JP wrote:
bool using_multiple_render_targets = !(_drawBuffers.empty());
I changed it to
bool using_multiple_render_targets = (_drawBuffers.size() 1);
That's all the changes. So if JP can check it (I have a mess of OSG1.2
and OSG2.3 code) then you can decide what to submit.
The newest submission is essentially what you have above, but the change
Robert made to the attachment enum allows empty to still work properly.
The vector is also automatically only populated for COLOR0.
cheers
jp
Thanks,
Guy.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their
support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi, Using MRT with one target at gl_Data[0] really makes a problem. I still don't think it is required to set manually the Camera for using MRT unless it's a patch until the MRTVisitor is implemented. When the visitor is implemented, if a node is using MRT it's probably because the user attached a shader that uses gl_Data[], and then it will set on the flag whether it has one or many COLOR BUFFER attachments, or maybe the attribute will be something like (MRT, State::ON) and this will turn on the flags. For the cameras, if there are more than one COLORBUFFER attachments, it should turn the flag on whether the StateAttribute is ON or OFF, but if there is only one attachment (or less), and the user didn't set the StateAttribute to ON, the drawBuffers extension shouldn't be applied. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Robert Osfield wrote: Hi J.P, I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Can we not just do it when COLOR_BUFFER1 upwards are enabled? Problem is that enabling MRT with just COLOR_BUFFER0 and then using glFragData[0] in a shader is also a valid use of glDrawBuffers. I know this is a special case (MRT with one buffer), but it's useful when e.g. automatically generating code. OK. I see the issue now. If we ban or don't expect this type of use, then enabling MRT when COLOR_BUFFER1 upwards are enabled should be fine. Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. The other possibility would be to explictly enable MRT support via an option in osg::Camera. The special option would have the same problems as my setDrawBuffers at the moment. One could get the option and attachments out of sync. My concern about having both Camera::setDrawBuffers and the BufferComponent attachments is that its more code and open for people making mistakes in the implementation i.e. they two are set without being properly matched. Yes, I agree with this. I think your suggestion to separate COLOR_BUFFER and COLOR_BUFFER0 is the best. In RenderStage the check to enable MRT would then be as Guy suggested. See if the _drawBuffers GLenum vec has something in it. The vec is populated from the camera attachments. Robert. jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi, Guy wrote: Hi, Using MRT with one target at gl_Data[0] really makes a problem. I still don't think it is required to set manually the Camera for using MRT unless it's a patch until the MRTVisitor is implemented. There are no more manual settings in Camera in the latest version. When the visitor is implemented, if a node is using MRT it's probably because the user attached a shader that uses gl_Data[], and then it will set on the flag whether it has one or many COLOR BUFFER attachments, or maybe the attribute will be something like (MRT, State::ON) and this will turn on the flags. For the cameras, if there are more than one COLORBUFFER attachments, it should turn the flag on whether the StateAttribute is ON or OFF, but if there is only one attachment (or less), and the user didn't set the StateAttribute to ON, the drawBuffers extension shouldn't be applied. Attaching COLOR_BUFFER0 or greater now enables MRT, so no other setting that can get out of sync is needed anymore. If user does not want MRT, attach COLOR_BUFFER only. Matching shaders to attachments is still the user's responsibility. jp Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Robert Osfield wrote: Hi J.P, I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Can we not just do it when COLOR_BUFFER1 upwards are enabled? Problem is that enabling MRT with just COLOR_BUFFER0 and then using glFragData[0] in a shader is also a valid use of glDrawBuffers. I know this is a special case (MRT with one buffer), but it's useful when e.g. automatically generating code. OK. I see the issue now. If we ban or don't expect this type of use, then enabling MRT when COLOR_BUFFER1 upwards are enabled should be fine. Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. The other possibility would be to explictly enable MRT support via an option in osg::Camera. The special option would have the same problems as my setDrawBuffers at the moment. One could get the option and attachments out of sync. My concern about having both Camera::setDrawBuffers and the BufferComponent attachments is that its more code and open for people making mistakes in the implementation i.e. they two are set without being properly matched. Yes, I agree with this. I think your suggestion to separate COLOR_BUFFER and COLOR_BUFFER0 is the best. In RenderStage the check to enable MRT would then be as Guy suggested. See if the _drawBuffers GLenum vec has something in it. The vec is populated from the camera attachments. Robert. jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi J.P, Guy and Art et. al, On Wed, Apr 2, 2008 at 3:53 PM, J.P. Delport [EMAIL PROTECTED] wrote: When the visitor is implemented, if a node is using MRT it's probably because the user attached a shader that uses gl_Data[], and then it will set on the flag whether it has one or many COLOR BUFFER attachments, or maybe the attribute will be something like (MRT, State::ON) and this will turn on the flags. For the cameras, if there are more than one COLORBUFFER attachments, it should turn the flag on whether the StateAttribute is ON or OFF, but if there is only one attachment (or less), and the user didn't set the StateAttribute to ON, the drawBuffers extension shouldn't be applied. Attaching COLOR_BUFFER0 or greater now enables MRT, so no other setting that can get out of sync is needed anymore. If user does not want MRT, attach COLOR_BUFFER only. Matching shaders to attachments is still the user's responsibility. I agree totally with J.P.. matching shaders to attachments is really the users responsibility for constructing the scene graph in the appropriate way. Trying to come up with clever visitors to try and guess at what is meant and required is not something that is practical in a general purpose way, and for the most users there is no need as they'll no whether they intend to use MRT or not based on their shaders and Camera setup. W.r.t the MRT support decoupled from osg::Camera I'd suggest this is something we'll need to address separately, before you start trying to come up with a solution we'd need to tie down some particular usages models that require it and aren't served by the standard osg::Camera RTT support. Writing an OSG example of this would a good first step for providing a concrete usage example that even if it doesn't compile or work, would still give us something to work on. I'm about to review J.P's final changes so hopefully we'll have one piece of the jigsaw in place very soon. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
JP, Thanks for the clarification, I just thought that only when the visitor is implemented the user responsibility for matching the shaders to attachments should be by setting the StateAttribute and not the Camera since many users don't want to know about camera's but still wants to write MRT shaders. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 4:54 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Guy wrote: Hi, Using MRT with one target at gl_Data[0] really makes a problem. I still don't think it is required to set manually the Camera for using MRT unless it's a patch until the MRTVisitor is implemented. There are no more manual settings in Camera in the latest version. When the visitor is implemented, if a node is using MRT it's probably because the user attached a shader that uses gl_Data[], and then it will set on the flag whether it has one or many COLOR BUFFER attachments, or maybe the attribute will be something like (MRT, State::ON) and this will turn on the flags. For the cameras, if there are more than one COLORBUFFER attachments, it should turn the flag on whether the StateAttribute is ON or OFF, but if there is only one attachment (or less), and the user didn't set the StateAttribute to ON, the drawBuffers extension shouldn't be applied. Attaching COLOR_BUFFER0 or greater now enables MRT, so no other setting that can get out of sync is needed anymore. If user does not want MRT, attach COLOR_BUFFER only. Matching shaders to attachments is still the user's responsibility. jp Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Robert Osfield wrote: Hi J.P, I'm sure you will see that there is no magic to my current implementation. The difficult part is to figure out when to enable it. Can we not just do it when COLOR_BUFFER1 upwards are enabled? Problem is that enabling MRT with just COLOR_BUFFER0 and then using glFragData[0] in a shader is also a valid use of glDrawBuffers. I know this is a special case (MRT with one buffer), but it's useful when e.g. automatically generating code. OK. I see the issue now. If we ban or don't expect this type of use, then enabling MRT when COLOR_BUFFER1 upwards are enabled should be fine. Rather than ban this type of usage perhaps we could come up with another scheme. Would making COLOR_BUFFER0 be separate from COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they COLOR_BUFFER0+i, if they just want standard then just use COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. The other possibility would be to explictly enable MRT support via an option in osg::Camera. The special option would have the same problems as my setDrawBuffers at the moment. One could get the option and attachments out of sync. My concern about having both Camera::setDrawBuffers and the BufferComponent attachments is that its more code and open for people making mistakes in the implementation i.e. they two are set without being properly matched. Yes, I agree with this. I think your suggestion to separate COLOR_BUFFER and COLOR_BUFFER0 is the best. In RenderStage the check to enable MRT would then be as Guy suggested. See if the _drawBuffers GLenum vec has something in it. The vec is populated from the camera attachments. Robert. jp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi All, I've just merged J.P changes to RenderStage to add support for glDrawBuffers in conjunction with my tweak to osg::Camera::COLOR_BUFFER0. J.P's osgmultiplerendertargets example is also now checked into SVN. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request for Comments/Testing
Hi J.P, On Tue, Apr 1, 2008 at 11:29 AM, J.P. Delport [EMAIL PROTECTED] wrote: is anyone looking at this, or should I assume no news is good news and just submit it as a patch? I'm afraid I haven't yet had a chance to test, feel free to submit the changes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
I tried to compile it and link on Windows with latest SVN. Compiled and linked fine.I ran osg prerender and shadow exmples with fbo. Again no problems. But frankly haven't tested MRT functionality at all. Cheers, Wojtek - Original Message - From: J.P. Delport [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, April 01, 2008 12:29 PM Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, is anyone looking at this, or should I assume no news is good news and just submit it as a patch? rgds jp J.P. Delport wrote: Hi, over the weekend I have consolidated previous hacks to enable MRT into what I hope would be an acceptable patch for OSG. I would like to have it tested a bit before sending it to submissions. Attached are the changes to OSG's Camera and RenderStage. Camera got a new method called setDrawBuffers (instead of the normal setDrawBuffer), which mirrors the OpenGL extension glDrawBuffers. setDrawBuffers takes a vector of BufferComponents and this vector is then translated in RenderStage to a vector of GLenums that is passed to glDrawBuffers. The new calls are orthogonal to current use cases, so hopefully no other code/examples would be affected. The attached example shows sample usage. The example is very contrived, but I hope it explains the concept. I have some other examples that I can contribute later. Please let fly with comments/observations. regards jp PS. How do I add an example to OSG? The CMakelists in the examples directory contains a list of directories, but when is the CMakelists in a specific example directory created? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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
Re: [osg-users] Multiple Render Targets - Request for Comments/Testing
Hi, is anyone looking at this, or should I assume no news is good news and just submit it as a patch? rgds jp J.P. Delport wrote: Hi, over the weekend I have consolidated previous hacks to enable MRT into what I hope would be an acceptable patch for OSG. I would like to have it tested a bit before sending it to submissions. Attached are the changes to OSG's Camera and RenderStage. Camera got a new method called setDrawBuffers (instead of the normal setDrawBuffer), which mirrors the OpenGL extension glDrawBuffers. setDrawBuffers takes a vector of BufferComponents and this vector is then translated in RenderStage to a vector of GLenums that is passed to glDrawBuffers. The new calls are orthogonal to current use cases, so hopefully no other code/examples would be affected. The attached example shows sample usage. The example is very contrived, but I hope it explains the concept. I have some other examples that I can contribute later. Please let fly with comments/observations. regards jp PS. How do I add an example to OSG? The CMakelists in the examples directory contains a list of directories, but when is the CMakelists in a specific example directory created? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi J.P. I am also using MRT, however completely without osg::Camera. However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? Cheers, Art --- J.P. Delport [EMAIL PROTECTED] schrieb: Hi Wojtek, Wojciech Lewandowski wrote: I tried to compile it and link on Windows with latest SVN. Compiled and linked fine.I ran osg prerender and shadow exmples with fbo. Again no problems. But frankly haven't tested MRT functionality at all. thanks for the testing, I'm glad other fbo code is still fine. We are using MRT for two projects here and it works on Windows and Linux, so 'it works for me (TM)'. I'll submit it. thanks jp Cheers, Wojtek -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi Art, Art Tevs wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. Yes, I've compiled osgPPU and ran the examples; cannot say that I fully understand the code yet :) However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? I think having the MRT selection going through FBO-class could be a good option. However, I do not know how to add the StateAttribute. We might need an enable/disable and setDrawbuffers, or can a StateAttribute take a vector? I do not know how to pass the vector of render targets using an attribute? - At the moment I have: Camera-setDrawBuffers(vec) - this sets the intention to use MRT and also passes the list of targets. RenderStage-runCameraSetup - this queries the camera for the buffers, and if there are any, creates a vector of GLenums. RenderStage-drawInner - The existence of the target vector is used to determine if MRT is enabled. glDrawBuffers is called using the vector. - I think what you propose is: Camera-setDrawBuffers(vec) RenderStage-runCameraSetup - since this creates the FBO anyway, it might as well pass the camera settings regarding MRT to the FBO. Maybe using _fbo-setDrawBuffers. RenderStage-drawInner - instead of checking the member _drawBuffers, query the FBO to determine if MRT should be enabled and also get the list of targets from the FBO. - This could work, and I can probably integrate it into the patch, but I'm not sure how you get your FBOs into renderstage at present. Also, how do you control the reading back of textures/images? At the moment the readback attachment map is also setup in camera. Would this also need to be moved? Cheers, Art rgds jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi Art J.P, I'm curious about the going for a custom StateAttribute for DrawBuffers. In terms of encapsulation osg::Camera isn't a bad place for it, as there is already lots of RTT support there already. If there are cases when you want to enable/disable different combinations of DrawBuffers within on RTT subgraph then the StateAttribute is certainly the way to go. I haven't yet player with MRT yet though so can't really give too much insight based on experience so am all ears. Robert. On Tue, Apr 1, 2008 at 1:08 PM, Art Tevs [EMAIL PROTECTED] wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? Cheers, Art --- J.P. Delport [EMAIL PROTECTED] schrieb: Hi Wojtek, Wojciech Lewandowski wrote: I tried to compile it and link on Windows with latest SVN. Compiled and linked fine.I ran osg prerender and shadow exmples with fbo. Again no problems. But frankly haven't tested MRT functionality at all. thanks for the testing, I'm glad other fbo code is still fine. We are using MRT for two projects here and it works on Windows and Linux, so 'it works for me (TM)'. I'll submit it. thanks jp Cheers, Wojtek -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go ___ 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
Re: [osg-users] Multiple Render Targets - Request forComments/Testing
Hi Robert, J.P., Of course the camera is a good place for it. However I would also prefer to have it somewhere else, because I am not always using cameras to make render to texture. Ok, maybe I am the one who is using the FBOs and RTT functionality out of the camera ;-) Hmm, maybe I was to fast in the conclusion that MRT support as StateAttribute would be a good idea. What I thought was to have it somewhere in the State, so that one can enable or disable draw buffers independently of the camera. The State do already contain such specific stuff like Multitexturing or Matricies (projection and view matrix). Hence additional methods to manage the draw buffers, may be helpful in the future. Best regards, Art --- Robert Osfield [EMAIL PROTECTED] schrieb: Hi Art J.P, I'm curious about the going for a custom StateAttribute for DrawBuffers. In terms of encapsulation osg::Camera isn't a bad place for it, as there is already lots of RTT support there already. If there are cases when you want to enable/disable different combinations of DrawBuffers within on RTT subgraph then the StateAttribute is certainly the way to go. I haven't yet player with MRT yet though so can't really give too much insight based on experience so am all ears. Robert. On Tue, Apr 1, 2008 at 1:08 PM, Art Tevs [EMAIL PROTECTED] wrote: Hi J.P. I am also using MRT, however completely without osg::Camera. However since I am working with FBOs directly I would prefer to have something like an extra StateAttribute or something which should setup the MRT. Or maybe the setDrawBuffers as an extra method in the FBO code. I think having the MRT (enable/disable) as a StateAttribute would be the more general way. However this would probably require some extra changing in the RenderStage or wherever to detect that extra StateAttribute. What do you think, guys? Cheers, Art --- J.P. Delport [EMAIL PROTECTED] schrieb: Hi Wojtek, Wojciech Lewandowski wrote: I tried to compile it and link on Windows with latest SVN. Compiled and linked fine.I ran osg prerender and shadow exmples with fbo. Again no problems. But frankly haven't tested MRT functionality at all. thanks for the testing, I'm glad other fbo code is still fine. We are using MRT for two projects here and it works on Windows and Linux, so 'it works for me (TM)'. I'll submit it. thanks jp Cheers, Wojtek -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go ___ 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 Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multiple Render Targets - Request for Comments/Testing
Hi, over the weekend I have consolidated previous hacks to enable MRT into what I hope would be an acceptable patch for OSG. I would like to have it tested a bit before sending it to submissions. Attached are the changes to OSG's Camera and RenderStage. Camera got a new method called setDrawBuffers (instead of the normal setDrawBuffer), which mirrors the OpenGL extension glDrawBuffers. setDrawBuffers takes a vector of BufferComponents and this vector is then translated in RenderStage to a vector of GLenums that is passed to glDrawBuffers. The new calls are orthogonal to current use cases, so hopefully no other code/examples would be affected. The attached example shows sample usage. The example is very contrived, but I hope it explains the concept. I have some other examples that I can contribute later. Please let fly with comments/observations. regards jp PS. How do I add an example to OSG? The CMakelists in the examples directory contains a list of directories, but when is the CMakelists in a specific example directory created? -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. OSG_MRT_200803.tgz Description: application/compressed-tar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multiple render targets
Hi,
is there anything else I need to do to render to two textures with the same
fragment shader? I have the following code:
cam-setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
cam-attach(Camera::COLOR_BUFFER0, _texture.get());
cam-attach(Camera::COLOR_BUFFER1, _texture2.get());
And the following fragment shader:
void main(void)
{
gl_FragData[0] = vec4(1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4(0.4, 0.4, 0.0, 1.0);
}
The first texture comes out red as expected, but the second one (which is
identical in size and format as the first) comes out black.
-J
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
Hi,
as far as I know its not supported in current version of OSG, there is
no call to glDrawBuffers (as opposed to glDrawBuffer) which is needed
for MRT.
I have a version of RenderStage.cpp that I modified to allow MRT for one
of our projects, but its a hack and I still need to properly organise it
before I can submit a patch.
I can post it with instructions if you want it?
regards
jp
John Donovan wrote:
Hi,
is there anything else I need to do to render to two textures with the same
fragment shader? I have the following code:
cam-setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
cam-attach(Camera::COLOR_BUFFER0, _texture.get());
cam-attach(Camera::COLOR_BUFFER1, _texture2.get());
And the following fragment shader:
void main(void)
{
gl_FragData[0] = vec4(1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4(0.4, 0.4, 0.0, 1.0);
}
The first texture comes out red as expected, but the second one (which is
identical in size and format as the first) comes out black.
-J
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their
support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
Ah! That'd explain it :) Thanks JP.
It would be handy to have a look at what you've done; perhaps we can both faff
about with it to make it submittable.
-J
J.P. Delport wrote:
Hi,
as far as I know its not supported in current version of OSG, there is
no call to glDrawBuffers (as opposed to glDrawBuffer) which is needed
for MRT.
I have a version of RenderStage.cpp that I modified to allow MRT for one
of our projects, but its a hack and I still need to properly organise it
before I can submit a patch.
I can post it with instructions if you want it?
regards
jp
John Donovan wrote:
Hi,
is there anything else I need to do to render to two textures with the same
fragment shader? I have the following code:
cam-setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
cam-attach(Camera::COLOR_BUFFER0, _texture.get());
cam-attach(Camera::COLOR_BUFFER1, _texture2.get());
And the following fragment shader:
void main(void)
{
gl_FragData[0] = vec4(1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4(0.4, 0.4, 0.0, 1.0);
}
The first texture comes out red as expected, but the second one (which is
identical in size and format as the first) comes out black.
-J
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
J.P. Delport wrote: Hi, OK, here goes. Thanks JP, that worked a treat! We need some mechanism to store/assign more than one drawbuffer inside camera and possibly a flag to indicate we want MRT. RenderStage can then inherit/query these values to properly call glDrawBuffer(s). Yeah, I can see it's a bit hacky, but not as bad as I was expecting! Robert, do you have any plans for doing MRT stuff, or are you happy with JP and me to come up with something workable and submit it? The changes JP has made are fairly trivial, so it wouldn't take much to make it more robust. If you have time, give it a bash. I won't have time to look any deeper until next week, but it does at least work :) -JD __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
On 9/14/07, John Donovan [EMAIL PROTECTED] wrote: Robert, do you have any plans for doing MRT stuff, or are you happy with JP and me to come up with something workable and submit it? The changes JP has made are fairly trivial, so it wouldn't take much to make it more robust. Send me a patch and I'll review it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
