[osg-users] Multiple Render Targets - Request for Comments/Testing
J.P. Delport
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.
J.P. Delport
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-...@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-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Robert Osfield
On Tue, Apr 1, 2008 at 11:29 AM, J.P. Delport <jpde...@csir.co.za> 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.
Wojciech Lewandowski
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
J.P. Delport
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
Art Tevs
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" <jpde...@csir.co.za> schrieb:
Lesen Sie Ihre E-Mails auf dem Handy.
www.yahoo.de/go
J.P. Delport
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
Robert Osfield
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.
Art Tevs
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 <robert....@gmail.com> schrieb:
Robert Osfield
I wouldn't be too discouraged from the ideal of having an
osg::DrawBuffers StateAttribute, it wouldn't be something you'd
integrated into osg::State though any more than you'd do it with other
OpenGL state.
Whether it should be a StateAttribute is really down to how useful it
will be outside the context of osg::Camera, it is, and it looks to be
the case for you then it makes sense. However, there if its only you
who needs it because you don't use osg::Camera's RTT support then
there is nothing stopping you from implementing yourself as you own
custom StateAttribute.
Robert.
Guy
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: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] 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
J.P. Delport
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