Re: [osg-users] Improving multisampled FBO
Thanks.Building now, will test shortly. -Paul Wojciech Lewandowski wrote: Hi Paul, I have just submitted proposed changes to osg-submissions. Please, see [osg-submissions] DisplaySettings masks for implicit buffer attachments thread for details. Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Paul,
I have just submitted proposed changes to osg-submissions. Please, see
[osg-submissions] DisplaySettings masks for implicit buffer attachments
thread for details.
Cheers,
Wojtek Lewandowski
- Original Message -
From: Paul Martz pma...@skew-matrix.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Monday, October 26, 2009 10:09 PM
Subject: Re: [osg-users] Improving multisampled FBO
Yes it's quite confusing.
The RenderStage code was already set up as follows: If doing MSFBO (and
therefore need two FBOs, one for multisampled rendering and one for final
resolve), then configure fbo as the resolve FBO, and When done
configuring, swap it into _resolveFbo (see line 554). But, if not using
MSFBO, then fbo is just the render fbo.
(I did not write this code, I am just the poor sap left to maintain it.
:-)
My code handles this correctly: If using MSFBO, then resolveBuffersMask is
the value set by the app for the resolve buffers. But if not using MSFBO,
then resolveBuffersMask is the value set by the app for render buffers. In
both cases, resolveBuffersMask is used to configure fbo.
So, my code is correct, in light of how the existing code is written.
I attempted to explain this briefly in code comments at lines 349-351 and
also lines 377-378, but perhaps to clarify things further, you could paste
this email from me as a code comment about line 442.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ http://www.skew-matrix.com/
+1 303 859 9466
Wojciech Lewandowski wrote:
Hi Paul,
Thanks. I am almost done with modifications for DisplaySettings. I have
to test it and will submit the code tomorrow. But I have one question
regarding your changes in RenderStage.cpp. I have understood that
RenderMask defines implicit attachments for main FBO and ResolveMask
defines implicit attachments for multisample FBO. I noticed that when
multisampling is not used both masks are actually set to RenderMask value
(RenderStage.cpp line 352). But when multisampling is on, it looks like
masks are swapped because ResolveMask is used to force implicit buffers
for main FBO and RenderMask is used to force implicit buffers for MS
FBO. Its bit surprising to me, but maybe its correct ?
For example: see excerpt from RenderStage lines 440-455 if
(!depthAttached)
{
if( resolveBuffersMask osg::Camera::USE_DEPTH_BUFFER )
{
fbo-setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width,
height, GL_DEPTH_COMPONENT24)));
depthAttached = true;
}
if (fbo_multisample.valid()
( renderBuffersMask osg::Camera::USE_DEPTH_BUFFER ) )
{
fbo_multisample-setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width,
height, GL_DEPTH_COMPONENT24, samples, colorSamples)));
depthAttached = true;
}
}
Cheers,
Wojtek Lewandowski
- Original Message -
From: Paul Martz pma...@skew-matrix.com
mailto:pma...@skew-matrix.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
Sent: Monday, October 26, 2009 2:56 PM
Subject: Re: [osg-users] Improving multisampled FBO
Wojciech Lewandowski wrote:
I will prepare and submit a code with these modifications if you
accept
general direction.
Sounds good to me, please go ahead and make these changes (including
the
entry point name change). And thanks for the help with this.
-Paul
___
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
___
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] Improving multisampled FBO
Hi Paul, I hope Robert also reads this ;-) I compiled your code. Everything seems fine. I agree that setImplicitBuffers() or even setImplicitBufferAttachments() would be more self explanatory. I would also like to have one more (global) level of control where I would be able to set defaults for _renderBuffersMask _resolveBuffersMask for all cameras. I guess Robert saw a need for this as well, when he proposed to extend DisplaySettings for this purpose. It could be useful for already existing code like osgShadow shadow map techniques. By zeroing _RenderBuffersMask we could make these techniques more efficient, as most of the shadow map cameras does not need to use COLOR_ATTACHMENTS. Extrapolating Robert sugesstion (I am trying to guess how he would tackle this) I would add _implicitBufferAttachmentsRenderMask _implicitBufferAttchmentsResolveMask flags and corresponding setters and getters to DisplaySettings structure. I would also initilize them to defaults you had set up for the camera in your submission: ie USE_COLOR_BUFFER | USE_DEPTH_BUFFER. In the Camera class I would add one more enum value USE_DISPLAY_SETTINGS_MASK and would make it a default for the Camera. This flag would mean that Camera honors flags set in associted DisplaySettings. So it would be possible to setup defaults for all cameras by simply changing masks in DisplaySettings instance. And it would be easy to override global defaults with the flags and methods you added when creating a camera. Would this work for you ? I will prepare and submit a code with these modifications if you accept general direction. Cheers, Wojtek Lewandowski - Original Message - From: Paul Martz pma...@skew-matrix.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Saturday, October 24, 2009 10:38 PM Subject: Re: [osg-users] Improving multisampled FBO Wojciech Lewandowski wrote: Hi Paul, Thank You. I like your solution. I cannot test it now, will do it on monday and let you know how it went. Have a good weekend. :-) I'm starting to think a better name for this entry point would be setImplicitBuffers(), as that's what it really does: it lets the app tell OSG what buffer attachments to create implicitly. But take a look when you have time and give me your thoughts, I'm open to suggestions. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ 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] Improving multisampled FBO
Hi Wojtek and Paul. On Mon, Oct 26, 2009 at 12:06 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: I hope Robert also reads this ;-) Sorry missed it completely :-) I will prepare and submit a code with these modifications if you accept general direction. I believe you guessed correctly what type of approach I'd take w.r.t setting global defaults in DisplaySettings. The suggestion of ImplicitBufferAttachment also sounds like it conveys an appropriate meaning. So you have my thumbs up for making the mods and submitting these. I haven't had a chance to review Paul original yet, so I'm just do a best guess from this thread and the previous ones. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Wojciech Lewandowski wrote: I will prepare and submit a code with these modifications if you accept general direction. Sounds good to me, please go ahead and make these changes (including the entry point name change). And thanks for the help with this. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Paul,
Thanks. I am almost done with modifications for DisplaySettings. I have to test
it and will submit the code tomorrow. But I have one question regarding your
changes in RenderStage.cpp. I have understood that RenderMask defines implicit
attachments for main FBO and ResolveMask defines implicit attachments for
multisample FBO. I noticed that when multisampling is not used both masks are
actually set to RenderMask value (RenderStage.cpp line 352). But when
multisampling is on, it looks like masks are swapped because ResolveMask is
used to force implicit buffers for main FBO and RenderMask is used to force
implicit buffers for MS FBO. Its bit surprising to me, but maybe its correct ?
For example: see excerpt from RenderStage lines 440-455
if (!depthAttached)
{
if( resolveBuffersMask osg::Camera::USE_DEPTH_BUFFER )
{
fbo-setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width, height,
GL_DEPTH_COMPONENT24)));
depthAttached = true;
}
if (fbo_multisample.valid()
( renderBuffersMask osg::Camera::USE_DEPTH_BUFFER ) )
{
fbo_multisample-setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width, height,
GL_DEPTH_COMPONENT24, samples, colorSamples)));
depthAttached = true;
}
}
Cheers,
Wojtek Lewandowski
- Original Message -
From: Paul Martz pma...@skew-matrix.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Monday, October 26, 2009 2:56 PM
Subject: Re: [osg-users] Improving multisampled FBO
Wojciech Lewandowski wrote:
I will prepare and submit a code with these modifications if you accept
general direction.
Sounds good to me, please go ahead and make these changes (including the
entry point name change). And thanks for the help with this.
-Paul
___
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] Improving multisampled FBO
Yes it's quite confusing.
The RenderStage code was already set up as follows: If doing MSFBO (and
therefore need two FBOs, one for multisampled rendering and one for
final resolve), then configure fbo as the resolve FBO, and When done
configuring, swap it into _resolveFbo (see line 554). But, if not
using MSFBO, then fbo is just the render fbo.
(I did not write this code, I am just the poor sap left to maintain it. :-)
My code handles this correctly: If using MSFBO, then resolveBuffersMask
is the value set by the app for the resolve buffers. But if not using
MSFBO, then resolveBuffersMask is the value set by the app for render
buffers. In both cases, resolveBuffersMask is used to configure fbo.
So, my code is correct, in light of how the existing code is written.
I attempted to explain this briefly in code comments at lines 349-351
and also lines 377-378, but perhaps to clarify things further, you could
paste this email from me as a code comment about line 442.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ http://www.skew-matrix.com/
+1 303 859 9466
Wojciech Lewandowski wrote:
Hi Paul,
Thanks. I am almost done with modifications for DisplaySettings. I have
to test it and will submit the code tomorrow. But I have one question
regarding your changes in RenderStage.cpp. I have understood that
RenderMask defines implicit attachments for main FBO and ResolveMask
defines implicit attachments for multisample FBO. I noticed that
when multisampling is not used both masks are actually set to RenderMask
value (RenderStage.cpp line 352). But when multisampling is on, it looks
like masks are swapped because ResolveMask is used to force implicit
buffers for main FBO and RenderMask is used to force implicit buffers
for MS FBO. Its bit surprising to me, but maybe its correct ?
For example: see excerpt from RenderStage lines 440-455
if (!depthAttached)
{
if( resolveBuffersMask osg::Camera::USE_DEPTH_BUFFER )
{
fbo-setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width,
height, GL_DEPTH_COMPONENT24)));
depthAttached = true;
}
if (fbo_multisample.valid()
( renderBuffersMask osg::Camera::USE_DEPTH_BUFFER ) )
{
fbo_multisample-setAttachment(osg::Camera::DEPTH_BUFFER,
osg::FrameBufferAttachment(new osg::RenderBuffer(width,
height, GL_DEPTH_COMPONENT24, samples, colorSamples)));
depthAttached = true;
}
}
Cheers,
Wojtek Lewandowski
- Original Message -
From: Paul Martz pma...@skew-matrix.com mailto:pma...@skew-matrix.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
Sent: Monday, October 26, 2009 2:56 PM
Subject: Re: [osg-users] Improving multisampled FBO
Wojciech Lewandowski wrote:
I will prepare and submit a code with these modifications if you accept
general direction.
Sounds good to me, please go ahead and make these changes (including the
entry point name change). And thanks for the help with this.
-Paul
___
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Wojtek and others -- I've posted a proposed change to osg-submissions. With my change, there is no longer a need for the #defines Wojtek had added to RenderStage.cpp to stop implicit creation of attachments. This is now under application control. In my code, I've added a new Camera method, setUseBufferMask(), and there are three bits you can OR into the parameters. For example, if you wanted color and stencil but not depth, you'd call: camera-setUseBufferMask( osg::Camera::USE_COLOR_BUFFER | osg::Camera::USE_STENCIL_BUFFER ); If you don't use this entry point, then you get the old default behavior, which is the same as USE_COLOR_BUFFER|USE_DEPTH_BUFFER. If you explicitly set your own attachment with attach() and then call setUseBufferMasks but leave the corresponding bit out, your attachment is not removed: The bit mask controls implicit creation of attachments only. If you are doing MSFBO, you pass in two masks to control attachments to the multisampled FBO and the resolve FBO respectively. In my case, I was using MSFBO to render to texture, and I only needed to resolve color, not depth. So I can now call: camera-setUseBufferMask( // Buffers in FBO for multisampled rendering: osg::Camera::USE_COLOR_BUFFER | osg::Camera::USE_STENCIL_BUFFER, // Buffers in resolve FBO: osg::Camera::USE_COLOR_BUFFER ); This produces a color and depth attachment to the multisampled FBO, but only color (my texture map) in the resolve FBO. So OSG will no longer create and blit to an unnecessary resolve depth buffer. I know this isn't the complete overhaul / explicit FBO interface we had both expressed a desire for, but I think it creates a minimum of disruption for the upcoming stable release and preserves backwards compatibility, which is important. Please test if you can, and if there are better fixes or ways to improve this change, please suggest or submit them. Thanks. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Paul, Thank You. I like your solution. I cannot test it now, will do it on monday and let you know how it went. Cheers, Wojtek Lewandowski -- From: Paul Martz pma...@skew-matrix.com Sent: Saturday, October 24, 2009 10:22 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Improving multisampled FBO Hi Wojtek and others -- I've posted a proposed change to osg-submissions. With my change, there is no longer a need for the #defines Wojtek had added to RenderStage.cpp to stop implicit creation of attachments. This is now under application control. In my code, I've added a new Camera method, setUseBufferMask(), and there are three bits you can OR into the parameters. For example, if you wanted color and stencil but not depth, you'd call: camera-setUseBufferMask( osg::Camera::USE_COLOR_BUFFER | osg::Camera::USE_STENCIL_BUFFER ); If you don't use this entry point, then you get the old default behavior, which is the same as USE_COLOR_BUFFER|USE_DEPTH_BUFFER. If you explicitly set your own attachment with attach() and then call setUseBufferMasks but leave the corresponding bit out, your attachment is not removed: The bit mask controls implicit creation of attachments only. If you are doing MSFBO, you pass in two masks to control attachments to the multisampled FBO and the resolve FBO respectively. In my case, I was using MSFBO to render to texture, and I only needed to resolve color, not depth. So I can now call: camera-setUseBufferMask( // Buffers in FBO for multisampled rendering: osg::Camera::USE_COLOR_BUFFER | osg::Camera::USE_STENCIL_BUFFER, // Buffers in resolve FBO: osg::Camera::USE_COLOR_BUFFER ); This produces a color and depth attachment to the multisampled FBO, but only color (my texture map) in the resolve FBO. So OSG will no longer create and blit to an unnecessary resolve depth buffer. I know this isn't the complete overhaul / explicit FBO interface we had both expressed a desire for, but I think it creates a minimum of disruption for the upcoming stable release and preserves backwards compatibility, which is important. Please test if you can, and if there are better fixes or ways to improve this change, please suggest or submit them. Thanks. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ 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] Improving multisampled FBO
Wojciech Lewandowski wrote: Hi Paul, Thank You. I like your solution. I cannot test it now, will do it on monday and let you know how it went. Have a good weekend. :-) I'm starting to think a better name for this entry point would be setImplicitBuffers(), as that's what it really does: it lets the app tell OSG what buffer attachments to create implicitly. But take a look when you have time and give me your thoughts, I'm open to suggestions. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Paul and Wojtek, I've had my head down doing desgin work/development pretty solidly for the last 6 weeks, all open sourced work, but enough intensity of thought and effort that I've had to cease trying to multi-task, with in the OSG context means not chases up all topics, and merge submissions. I really dislike getting this behind, and have been craving a little respite from other work to allow me to pop my head up and contribute more widely on various topic. Alas I have just completed one set of feature deliverables for a client only to run straight into another major chunk of client work that has near term time constraints, which this is good for business, and in the long term good for the OSG capabilities, it does mean the window of opportunity for me to step back more centrally into the OSG mix of deep discussions + development has closed for at least another month. In this particular thread it'll mean that I'll be happy to defer to others to discuss and propose a good solution. I'm glad to see Wojtek diving into this thread as he's both on the ball on the topic of FBO's and fresh from having been contributing to this area. Between you guys and anyone else able to contribute hopefully you'll be able to spot a good way forward. I would also suggest following the work I'll be doing over the next month, as I'll be need to do be doing pretty sweeping changes to lots of the OSG backend implementation and parts of the API. My aim will be to minimize the impact for every day OSG users, but if you're hacking at the lower level back elements of the OSG you'll be far more exposed to potential changes. I'll explain a bit more about what I'll be up to on Monday when I embark on the work in earnest. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Paul, That's _almost_ what I'm looking for, but not quite. I'm specifically interested in the case where a single Camera creates two FBOs to support multisampling, and I want a depth buffer in one FBO but not the other. (See my original post for more detail.) Currently, I always get a depth buffer in both FBOs which is not what I want. With your change, if I attach depth to the Camera, then I also get a depth buffer in both FBOs, and if I don't attach a depth buffer to the Camera, then I don't get a depth buffer in either FBO, which is also not what I want. So your solution, as currently coded, won't help with my situation. Ok, thanks, now I see whats the problem. I thought you were using two cameras. I was unaware that RenderStage allocates second multisample FBO. Indeed, turning off FORCE_DEPTH_ATTACHMENT won't help much. For this case it should be possible to seperately define attachments for main FBO and mutlisample FBO. Maybe you can overcome your problem with creative use of two cams and FORCE_DEPTH_ATTACHMENT == 0: One without multismapling but with depth buffer and shared texture as color buffer. And second camera which would have multisample buffer, no depth buffer, and would share main color buffer texture with first camera. I now its not long term solution but maybe such hack would temporarily work for you ? Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Paul,
Month (or two) ago we merged a patch to disable color/depth buffer
enforcement in FBO setup in RenderStage. Idea was to put responsibilty for
selected attachments on the programmer. If he/she did not add depth
attachment it would be honored by RenderStage. We almost did it, but... If
you look at our changes in 2.9.5 in trunk you will notice that there are
two defines in RenderStage.cpp: FORCE_COLOR_ATTACHMENT and
FORCE_DEPTH_ATTACHMENT. They are currently set to 1. Which means missing
attachments are still added automatically. We wanted to ultimately set them
to 0, but at that moment few of the examples (osgPrerender) were relying on
adding default depth. Robert also noticed problems in osgShadow with ATI
under Linux when color attachment was not added.
Final goal is to replace this defines with flags that could be changed at
runtime. Its pretty straightforward but we did not do this last step.
Mostly because we did not decided on interface to change them. Robert
proposed that it would be good idea to select default attachment policy
through DisplaySettings. I initially objected but in the end I agreed that
this is probably the most reasonable approach. And disussion stopped then.
Others remained silent. I guess Robert had and still has so much on his
plate he could not tackle this yet. If its real emergency maybe you will be
the one who will finish it.
Cheers,
Wojtek Lewandowski
--
From: Paul Martz pma...@skew-matrix.com
Sent: Saturday, October 03, 2009 4:53 PM
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Subject: [osg-users] Improving multisampled FBO
Hi Robert -- I'd like to make a change to how multisampled FBO works. In
short summary: I want to allow applications to optionally disable the
depth buffer bit in the call to glBlitFramebuffer, so that only color is
copied.
In order to render multisampled to a texture, (with pre-GL3.2) we need
to render into a multisampled renderbuffer then glBlitFramebuffer into
the texture. (I've attached some very simple code that exercises this
code path.) To support glBlitFramebuffer, there needs to be two FBOs:
one with multisampled renderbuffers attached (call it FBO A), and one
with the texture attached (call it FBO B).
OSG creates these FBOs during RenderStage::runCameraSetUp. OSG correctly
assumes that I need both color and depth multisampled renderbuffers
attached to FBO A. This is correct and is exactly what I want. OSG
creates this for me.
However, OSG _incorrectly_ assumes that I also want a depth renderbuffer
attached to FBO B, and it creates and attaches one. In fact, this is not
always necessary and is wasteful of GPU memory when it's not needed. I'm
only interested in the color buffer, and I don't need the depth buffer.
The problem is compounded during the glBlitFramebuffer call (occurs in
RenderStage::drawInner). The code determines that since both FBO A and
FBO B have color and depth attachments, that it must blit both color and
depth. Specifically, when it calls glBlitFramebuffer, the mask parameter
is (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT). This is unnecessary and
inefficient. It causes the blit to copy extra data that is not needed.
I understand that the depth attachment to FBO B might be needed in some
cases, and it's impossible for OSG to know whether it's needed or not
needed. So, I propose that OSG continue to work this way by default, but
osg::Camera should support some type of interface that allows the
application to tell OSG that the depth attachment in FBO B is not
needed, so that OSG won't bother to create it and won't include it in
the blit.
I'm on vacation/holiday Oct 4-9, and I'll be glad to make this change
after I return from my break.
All this investigation was done with v2.8.2. I've been unable to see how
things work with current svn head due to server issues and recent code
changes that prevent me from building (as noted in another post).
Finally, I'm going to need this change in order to work around an
apparent driver bug that I'm encountering on OSX with dual GF8800 cards
driving four monitors. If the resolve blit is performed with both depth
and color, it hangs my entire desktop (yuck). Removing the unnecessary
depth bit from the blit call avoids this issue. I'm still reviewing the
OpenGL spec to understand whether this is a driver bug or a problem with
OSG's usage.
Anyhow, let me know what you think. Thanks for your review time on this
change.
--
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ http://www.skew-matrix.com/
+1 303 859 9466
// Copyright (c) 2008 Skew Matrix Software LLC. All rights reserved.
#include osg/Node
#include osg/Camera
#include osg/Geode
#include osg/Geometry
#include osg/Texture2D
#include osgDB/ReadFile
#include osgViewer/Viewer
#include string
const int winW( 800 ), winH( 600 );
osg::Node*
postRender( osgViewer::Viewer viewer )
{
osg::Camera*
Re: [osg-users] Improving multisampled FBO
Hi Wojciech and thanks for the reply. In my specific case, I'm rendering multisampled to a texture, which requires actually rendering to multisampled renderbuffers and then doing a resolve blit to the texture. This requires 2 FBOs. And I want one to have depth, but not the other. Once I get back from break, I'll take a look at current svn and see if it satisfies this criteria. But from your post, it sounds like if I attach a depth buffer to this Camera, then it will implicitly create a depth attachment for the resolve FBO, which is what I'm trying to avoid. All this is pretty easy to do in OpenGL, but the fact that OSG's Camera interface hides FBOs from the developer makes things more complex. I'd be in favor of an interface that exposes FBOs to the developer. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Wojciech Lewandowski wrote: Hi Paul, Month (or two) ago we merged a patch to disable color/depth buffer enforcement in FBO setup in RenderStage. Idea was to put responsibilty for selected attachments on the programmer. If he/she did not add depth attachment it would be honored by RenderStage. We almost did it, but... If you look at our changes in 2.9.5 in trunk you will notice that there are two defines in RenderStage.cpp: FORCE_COLOR_ATTACHMENT and FORCE_DEPTH_ATTACHMENT. They are currently set to 1. Which means missing attachments are still added automatically. We wanted to ultimately set them to 0, but at that moment few of the examples (osgPrerender) were relying on adding default depth. Robert also noticed problems in osgShadow with ATI under Linux when color attachment was not added. Final goal is to replace this defines with flags that could be changed at runtime. Its pretty straightforward but we did not do this last step. Mostly because we did not decided on interface to change them. Robert proposed that it would be good idea to select default attachment policy through DisplaySettings. I initially objected but in the end I agreed that this is probably the most reasonable approach. And disussion stopped then. Others remained silent. I guess Robert had and still has so much on his plate he could not tackle this yet. If its real emergency maybe you will be the one who will finish it. Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Hi Paul, Once I get back from break, I'll take a look at current svn and see if it satisfies this criteria. But from your post, it sounds like if I attach a depth buffer to this Camera, then it will implicitly create a depth attachment for the resolve FBO, which is what I'm trying to avoid. Yes, because we did not turn former policy off. But we made all the steps to make it possible to turn off. Now its just a mater of replacing 1 with 0 in FORCE_COLOR_ATTACHMENT and FORCE_DEPTH_ATTACHMENT macros. Simply change these two #defines or only FORCE_DEPTH_ATTACHMENT to 0 and recompile OSG. Now when you don't attach DEPTH_BUFFER it won't be implicitly created. Isn't it what you are looking for ? All this is pretty easy to do in OpenGL, but the fact that OSG's Camera interface hides FBOs from the developer makes things more complex. I'd be in favor of an interface that exposes FBOs to the developer. I agree, it would be cool if we could have more control over FBO management. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving multisampled FBO
Wojciech Lewandowski wrote: Yes, because we did not turn former policy off. But we made all the steps to make it possible to turn off. Now its just a mater of replacing 1 with 0 in FORCE_COLOR_ATTACHMENT and FORCE_DEPTH_ATTACHMENT macros. Simply change these two #defines or only FORCE_DEPTH_ATTACHMENT to 0 and recompile OSG. Now when you don't attach DEPTH_BUFFER it won't be implicitly created. Isn't it what you are looking for ? That's _almost_ what I'm looking for, but not quite. I'm specifically interested in the case where a single Camera creates two FBOs to support multisampling, and I want a depth buffer in one FBO but not the other. (See my original post for more detail.) Currently, I always get a depth buffer in both FBOs which is not what I want. With your change, if I attach depth to the Camera, then I also get a depth buffer in both FBOs, and if I don't attach a depth buffer to the Camera, then I don't get a depth buffer in either FBO, which is also not what I want. So your solution, as currently coded, won't help with my situation. However, it's good to know that there are others besides myself who have concerns about the efficiency of the present FBO implementation. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
