[osg-users] Clearing two Color Buffers separately
Thorsten Roth
I have multiple render targets attached to separate color buffers in my
application. One of them is used to store linearized, normalized depth
values as well as absolute depth values and some additional information.
My problem now is that this color buffer should in fact be cleared with
the value 1 for the normalized depth component instead of the background
color component which is set for the viewer camera.
So, is there any (easy?) way to do this? Can i use separate clear colors
for separate color buffers? Would be really important, as I do not
really want to be forced to do a further "normalization" of my buffer
afterwards... ;-)
Thanks!
-Thorsten
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
J.P. Delport
On 07/12/10 18:47, Thorsten Roth wrote:
> Hi,
>
> I have multiple render targets attached to separate color buffers in my
> application. One of them is used to store linearized, normalized depth
> values as well as absolute depth values and some additional information.
> My problem now is that this color buffer should in fact be cleared with
> the value 1 for the normalized depth component instead of the background
> color component which is set for the viewer camera.
>
> So, is there any (easy?) way to do this?
If you consider a fragment shader running prior to you rendering easy,
then yes :)
> Can i use separate clear colors
> for separate color buffers?
I don't think so.
> Would be really important, as I do not
> really want to be forced to do a further "normalization" of my buffer
> afterwards... ;-)
How are you writing to the buffers? glFragData?
jp
>
> Thanks!
>
> -Thorsten
> _______________________________________________
> osg-users mailing list
> osg-...@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.
Thorsten Roth
Am 08.12.2010 11:14, schrieb J.P. Delport:
> Hi,
>
> On 07/12/10 18:47, Thorsten Roth wrote:
>> Hi,
>>
>> I have multiple render targets attached to separate color buffers in my
>> application. One of them is used to store linearized, normalized depth
>> values as well as absolute depth values and some additional information.
>> My problem now is that this color buffer should in fact be cleared with
>> the value 1 for the normalized depth component instead of the background
>> color component which is set for the viewer camera.
>>
>> So, is there any (easy?) way to do this?
> If you consider a fragment shader running prior to you rendering easy,
> then yes :)
In which way exactly? You mean as a separate rendering pass? Well, I
believe at least I could live with it...though it's not yet quite clear
to me ;)
>> Can i use separate clear colors
>> for separate color buffers?
> I don't think so.
>
>> Would be really important, as I do not
>> really want to be forced to do a further "normalization" of my buffer
>> afterwards... ;-)
>
> How are you writing to the buffers? glFragData?
Yup.
Currently, the problem is only solved by having a -1 in the alpha
channel where there is an object. Everything else is then considered as
background. Of course this is not really satisfying, as I need to run a
filter on it afterwards, so I still need to change the background pixels
to the maximum depth (far plane) value...
> jp
J.P. Delport
On 08/12/10 13:04, Thorsten Roth wrote:
> Hi,
>
> Am 08.12.2010 11:14, schrieb J.P. Delport:
>> Hi,
>>
>> On 07/12/10 18:47, Thorsten Roth wrote:
>>> Hi,
>>>
>>> I have multiple render targets attached to separate color buffers in my
>>> application. One of them is used to store linearized, normalized depth
>>> values as well as absolute depth values and some additional information.
>>> My problem now is that this color buffer should in fact be cleared with
>>> the value 1 for the normalized depth component instead of the background
>>> color component which is set for the viewer camera.
>>>
>>> So, is there any (easy?) way to do this?
>> If you consider a fragment shader running prior to you rendering easy,
>> then yes :)
>
> In which way exactly? You mean as a separate rendering pass? Well, I
> believe at least I could live with it...though it's not yet quite clear
> to me ;)
Yes, a pass where the camera looks at a screen aligned quad. You just
fill in whatever you want into all the MRT buffers using glFragData. You
attach the same textures as for the second pass. Let me know if you need
more info.
rgds
jp
>
>>> Can i use separate clear colors
>>> for separate color buffers?
>> I don't think so.
>>
>>> Would be really important, as I do not
>>> really want to be forced to do a further "normalization" of my buffer
>>> afterwards... ;-)
>>
>> How are you writing to the buffers? glFragData?
>
> Yup.
>
> Currently, the problem is only solved by having a -1 in the alpha
> channel where there is an object. Everything else is then considered as
> background. Of course this is not really satisfying, as I need to run a
> filter on it afterwards, so I still need to change the background pixels
> to the maximum depth (far plane) value...
>
>
>> jp
>
> -Thorsten
> _______________________________________________
> osg-users mailing list
> osg-...@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.
_______________________________________________
Thorsten Roth
Am 08.12.2010 12:19, schrieb J.P. Delport:
> Yes, a pass where the camera looks at a screen aligned quad. You just
> fill in whatever you want into all the MRT buffers using glFragData. You
> attach the same textures as for the second pass. Let me know if you need
> more info.
>
> rgds
> jp
>
Best thing would be a code snippet, if you have one at hand ;-) ..tried
several things such as using a slave camera with a different clear color
today, but somehow that didn't seem to do the job, so I am quite
interested in your approach :)
Thank you!
J.P. Delport
On 08/12/10 20:54, Thorsten Roth wrote:
> Hi,
>
> Am 08.12.2010 12:19, schrieb J.P. Delport:
>> Yes, a pass where the camera looks at a screen aligned quad. You just
>> fill in whatever you want into all the MRT buffers using glFragData. You
>> attach the same textures as for the second pass. Let me know if you need
>> more info.
>>
>> rgds
>> jp
>>
>
> Best thing would be a code snippet, if you have one at hand ;-) ..tried
> several things such as using a slave camera with a different clear color
> today, but somehow that didn't seem to do the job, so I am quite
> interested in your approach :)
It need not be a slave camera, it can just be a camera in your scene. We
have some initial code for an image processing lib here:
http://code.google.com/p/flitr/source/checkout
have a look at:
examples/glsl_shader_pass/simple_shader_pass.cpp
for an example. This uses only a single render target, but the concept
is the same for many. Just attach more textures to the camera output and
push data into it with glFragData.
Attach like so e.g.:
// attach the output textures
Camera_->attach(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0+0),
OutputTexture_.get());
Camera_->attach(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0+1),
OutputShortTerm_.get());
Camera_->attach(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0+2),
OutputLongTermA_.get());
Camera_->attach(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0+3),
OutputLongTermB_.get());
You can also just chain passes together by attaching more passes to your
scene.
I also recently posted an example with two cameras rendering over each
other here:
http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/62892/
rgds
jp
>
> Thank you!
>
> -Thorsten
> _______________________________________________
> osg-users mailing list
> osg-...@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.
_______________________________________________
Thorsten Roth
Am 09.12.2010 08:07, schrieb J.P. Delport:
> It need not be a slave camera, it can just be a camera in your scene. We
> have some initial code for an image processing lib here:
> http://code.google.com/p/flitr/source/checkout
Quite interesting, as I am also working on an image processing library
in course of my Master Thesis :) (more precisely, as you might already
assume from my questions, it's more an image SPACE processing library
;)) ..though mine is not explicitly based on OpenGL/GLSL and is designed
to easily allow to tie together several filters with different
implementation details (e.g. one uses CUDA, another one uses OpenCL,
another one is completely CPU-based...). I'll have a look at your stuff.
Thanks again! :-)
Regards
J.P. Delport
On 09/12/10 12:14, Thorsten Roth wrote:
> Hi,
>
> Am 09.12.2010 08:07, schrieb J.P. Delport:
>> It need not be a slave camera, it can just be a camera in your scene. We
>> have some initial code for an image processing lib here:
>> http://code.google.com/p/flitr/source/checkout
>
> Quite interesting, as I am also working on an image processing library
> in course of my Master Thesis :) (more precisely, as you might already
> assume from my questions, it's more an image SPACE processing library
> ;)) ..though mine is not explicitly based on OpenGL/GLSL and is designed
> to easily allow to tie together several filters with different
> implementation details (e.g. one uses CUDA, another one uses OpenCL,
> another one is completely CPU-based...). I'll have a look at your stuff.
> Thanks again! :-)
great, there might be some overlap. We have some of the same plans ito
the processing chain. Currently we use mostly GLSL for processing, but
have done some experiments with osgPPU and osgCompute for CUDA stages.
The whole reason for existence for the framework we made is for helping
some of the students we sponsor for Masters/PhDs in image processing to
get going faster and focus on the algorithms and not the glue code (and
of course to use their algorithms without too much porting :). We'd be
very interested in your work.
I'd like to get a Thrust processing stage going soon. If you have not
checked it out, the Thrust talk at GTC2010 was quite good:
http://www.nvidia.com/object/gtc2010-presentation-archive.html
talk 2220
rgds
jp
>
> Regards
> -Thorsten
> _______________________________________________
> osg-users mailing list
> osg-...@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.
_______________________________________________