Robert,
You present a valid use case for the current behavior and I
understand your
desire to avoid catering to this specific behavior. I also
understand not wanting
to include the warning message, it was more of a place holder to help
identify the
change I wanted to make. Perhaps having a boolean flag the user sets
to control this
behavior would make the API the easiest to use without trying to
"guess" at what the
user wants.
In our code base switching to pbuffer causes our application to
crash. Our theory
behind this is that we are not using Producer for our windows. I
notice in your code that
you call osg::GraphicsContext::createGraphicsContext() to create a
new pbuffer graphics
context. For each new context, do you need a new context ID (ie:
call osg::GraphicsContext::createNewContextID()?
The problem with osg::GraphicsContext::createNewContextID() is that
it will dynamically update the
MaxNumberOfGraphicsContexts(). For my application, using pbuffers
could result in more than 32 total context IDs. Hopefully they can
share textures/display lists.
My questions for you are:
1) What must I do to let Qt allocate the pbuffer instead of producer?
2) Are there any potential pit falls with using pbuffers and multi-pipe?
3) Say I don't want to use pbuffers, but use the Frame Buffer
technique without any patches to OSG, how could I render the current
value of the texture to the frame buffer at the beginning of my draw
phase? Patrick has tried multiple techniques yet the texture is
always black.
Thanks,
Dan
On Aug 9, 2006, at 2:58 AM, Robert Osfield wrote:
Hi Daniel,
Thanks for the explanation. I finally understand where you are coming
from, and why things work with FBO and pbuffers but no frame buffer.
First up I'm not inclined to merge the waning output, as it catches
you usage, but would wrongly emit a warning if the end users wanted to
modify and record the results of working on the main screen. Yes FBO
and pbuffers wouldn't work in the usage case, but then how would you
detect this?
Perhaps only one could emit your warning only when the user had
actually required a FBO or pbuffer but got a frame buffer instead.
Anyway there will always be limits in how much the OSG can cover over
the gaps between FBO, pbuffer and frame buffer RTT. I we try to
encode fallbacks for nieche usage then the code will just grow more
and more complicated and convoluted and in the end buggy. So I am
very wary about begining to go down this route.
Personally I'd be tempted to make the feature you are after only
supported on systems that support FBO or pbuffer. pbuffer is pretty
widely available, and FBO is getting more so as time goes on.
Another thing to bare in mind w.r.t frame buffer RTT is that is
someone puts a window over the area that you are reading from the
OpenGL implementation might just give back the contents of the colour
buffer in the form of the overlapping window. There isn't any
workarounds for this, its always going to be a poor mans solutions.
I don't think Producer support pbuffer under AGL,CGL OSX yet, but OSX
does support pbuffers so perhaps this is one avenue to look into - to
add this implementation.
Robert.
On 8/8/06, Daniel Larimer <[EMAIL PROTECTED]> wrote:
All,
Patrick and I have identified a change that we are not
sure how to
implement or if you want to implement it. Essentially it boils down
to the difference between pbuffers, fbos, vs FRAME_BUFFER rendering.
When you use FBO or PBUFFER you expect that the current
state of the
COLOR, DEPTH, STENCIL, and ALPHA buffers are the same as the last
time you rendered; however, if you are using FRAME_BUFFER mode then
the buffers are no longer in the same condition as you last left
them. This is not a problem if you call glClear() at start of every
frame because you put the buffers in a known state.
The only way to make the behavior appear the same using
all three
rendering methods would be to restore the Frame Buffer to the current
state of the texture when the clear mask is 0.
If the user does no updates to the texture then you have
an extra 2
copies... texture to frame buffer and frame buffer to texture.
If the user only updates a subset of the texture or is using
accumulation across the entire buffer then this is the EXACT behavior
you NEED.
At the end of the day, the user will probably place a
switch above
the camera node to prevent any update from occurring if no change is
made to the texture solving the first performance problem.
What are your thoughts? What is the best way to restore
the color/
depth buffers?
I have attached a patch that will print out a nice little
warning
message if the user attempts to use this combination and shows you
where I think the new code needs to go.
Dan
900a900,904
>
> if( _clearMask & GL_COLOR_BUFFER_BIT && _camera-
>getRenderTargetImplementation() == osg::CameraNode::FRAME_BUFFER )
> {
> osg::notify(osg::NOTICE)<<"restore old image, we are using
FRAME_BUFFER but are not clearing the image so the user expects the
old image to be there just like when using FBO or pbuffers. Not
currently implemented, sorry\n";
> }
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
