Re: [osg-users] FBO resizing problem
On Dec 2, 2007 11:21 PM, Himar Carmona [EMAIL PROTECTED] wrote: Well, comments apart, is there any place where i could document the proposed changes to FBO functionality in RenderStage and stand there until i (or anyone else) have time to try to incorporate it to the osg distribution? Something like osg-submissions, maybe? This is what we have the wiki for, just add an entry into the community section. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO resizing problem
Hi,
this little hack makes this approach work:
Change to Image (header): Added bool allocateIfRequired to ReadPixels.
Controls if Image is free or not to allocate the desired memory buffer, or
app want to take care of it (true means Image has control). App must
guarantee _data is initialized and have the proper format (and size) or a
memory problem could happen.
void readPixels(int x,int y,int width,int height,
GLenum pixelFormat,GLenum type, bool allocateIfRequired = true);
Change to Image.cpp: Make call to allocateImage dependant of flag state.
void Image::readPixels(int x,int y,int width,int height,
GLenum format,GLenum type, bool allocateIfRequired)
{
if (allocateIfRequired)
allocateImage(width,height,1,format,type);
glPixelStorei(GL_PACK_ALIGNMENT,_packing);
glReadPixels(x,y,width,height,format,type,_data);
}
Change to RenderStage.cpp (drawInner): Added false to the call of
readPixels. Means app have control (and responsability) of memory.
itr-second._image-readPixels(static_castint(_viewport-x()),
static_castint(_viewport-y()),
static_castint(_viewport-width()),
static_castint(_viewport-height()),
pixelFormat, dataType,
false);
Now, simply setting the image to the desired FBO size, the viewport of
the camera controls which region is transfered.
I know this is not the right place to comment that, but so this thread is
now complete for everyone who read it.
Summary for the future readers: The main topic was 'How to use FBO with
resizing requisites and readback render results to main memory (for new
users like me).'
Problem: RenderStage is not sensitive to changes in the FBO or its
attachment (w.r.t. size at least) ) once it is created in runCameraSetUp.
Alternative 1: Resize the FBO and have it always of the desired size
(first workaround in this thread).
Alternative 2: Set a FBO larger than the maximum size possible and let the
camera viewport control which region is desired. (need hack in this message)
Alternative 3: (Not yet implemented). Change RenderStage and implement the
desired behaviour (if image attached to an FBO chages size, let leave FBO
refresh its attachments).
None is perfect, 1 and 2 have pros and cons. Best seems 3, but requires
more knowlegde of OSG that i don't yet have.
Thanks for the wise replies.
Himar.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO resizing problem
Hi Himar, If you are just resizing occassionally and its you don't have a frame rate critical app then the overhead of recreating an FBO shouldn't be a great issue. Ease of use wise tweaking the internals of RenderStage to recreate the FBO when the setup changes would be the right thing to do long term, I'm too busy right now to go chasing such features, but you are welcome. Otherwise stick to your workaround, or just aim for a large enough FBO enough for the maximum window sizes you expect to encounter. FBO's can go up to 4k by 4k with is far in excess of what window will ever be so you have plenty of head room. Robert. On Dec 1, 2007 7:10 PM, Himar Carmona [EMAIL PROTECTED] wrote: Hi Robert, i only resize (i.e. recreate) the FBO when a resize operation is performed (when it is detected as finished). 99% of the time this will not happen. Really, my app performance is dropping due to the readback operation every frame. In my case this is acceptable, as i don't need constant frame rate (i'm rendering on demand, my app is a CAD like one). OSG is so fast doing its work, that the response time is good enough. This is my workaround to the problem i mentioned in my post: osgViewer::Renderer* renderer = (osgViewer::Renderer*)camera-getRenderer(); renderer-getSceneView(0)-getRenderStage()-setCameraRequiresSetUp(true); renderer-getSceneView(0)-getRenderStage()-setFrameBufferObject(NULL); These lines force the RenderStage to recreate the FBO, but this only happens when the resize operation ends. Your idea is better of course. But my app must be able to handle a multimonitor system. How can i determine in this situation what is the largest region i need? Is this region independent of the multimonitor configuration? Thank you for your advices, Robert. I really appreciate them. Himar. ___ 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] FBO resizing problem
Hi Robert, thanks again. For now i will stand with my workaround. I'm also running for a deadline and really i have no time for things other than my project (i think there must be some sort of pandemic disease upon the programmers beings, i will not believe the day one programmer comes and says 'i have a lot of time to spend on this project...') Well, comments apart, is there any place where i could document the proposed changes to FBO functionality in RenderStage and stand there until i (or anyone else) have time to try to incorporate it to the osg distribution? Something like osg-submissions, maybe? Best regards, Himar. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO resizing problem
Hi Robert, i only resize (i.e. recreate) the FBO when a resize operation is performed (when it is detected as finished). 99% of the time this will not happen. Really, my app performance is dropping due to the readback operation every frame. In my case this is acceptable, as i don't need constant frame rate (i'm rendering on demand, my app is a CAD like one). OSG is so fast doing its work, that the response time is good enough. This is my workaround to the problem i mentioned in my post: osgViewer::Renderer* renderer = (osgViewer::Renderer*)camera-getRenderer(); renderer-getSceneView(0)-getRenderStage()-setCameraRequiresSetUp(true); renderer-getSceneView(0)-getRenderStage()-setFrameBufferObject(NULL); These lines force the RenderStage to recreate the FBO, but this only happens when the resize operation ends. Your idea is better of course. But my app must be able to handle a multimonitor system. How can i determine in this situation what is the largest region i need? Is this region independent of the multimonitor configuration? Thank you for your advices, Robert. I really appreciate them. Himar. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FBO resizing problem
Hi, i'm using FBO to render offscreen and i have found a little problem when i need to resize the target object. i have the following scenario: 1. I set up a camera to use FRAME_BUFFER_OBJECT (as osgprerender). 2. I attach an Image to it with camera.attach (leaving OSG to control de RenderBuffer object). 3. I render once. (viewer.frame()). 4. I take a snapshot of the image using osgDB.writeImageFile Until here all runs ok. I have a pretty file with the rendered frame as expected. But since i want to be able to resize the target (Image) between frames render, i do next the following: 5. Simulate a resizing (growing up), changing the image size (hence changing the internal buffer) or creating a new Image with different size. 6. setting Viewport from the camera to the desired size. 7. I attach the new image to the camera (or the original resized one). 8. I render once again. (viewer.frame()). 9. I take a snapshot of the image. The problem is that the internal FBO that RenderStage controls doesn't notice the attachment's change, and therefore doesn't call fbo.setAttachment, so what i have in the second snapshot (step 9) is only a piece of the image rendered. If i have understand correctly the framebuffer_object spec, it says that the FBO doesn't have sizing fields internally, and the final size is governed by the attachment (here the image). I 'feel' that renderstage only calls fbo.setAttachment when the fbo is initialized. If this where the case, then how can i force RenderStage to reattach the fbo without creating it again? I will try to use the fbo.dirtyAll, but first i must realize how can i get at it. Of course, i also could have missed something. I have a test code with the problem, so if it must be tested, i can upload it. Another side effect of renderstage (independent for this problem) is that it also attach another renderbuffer to the depth_component internally, with or without being said. Is this avoidable? Thanks. Himar. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
