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 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 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
