Using multiple FBOs at the same time messes the drawing

[Fastian]

I have been using FBOs to successfully do post processing effects in our engine. Things like Bloom work great at the moment. Now I am trying to add Portal support to our renderer as in Prey (A portal opens in the middle and you can see through to some other place.

Now I intend to use an FBO based render to texture for the portal scene and use that as a texture on a quad/whatever to display the portal. This works fine as long as I am just using 1 FBO for portal scene rendering. If I try to do both, portal and post processing at the same time, portal pixels don't come accross in the post process texture.

The process that i'm using is like this. The FBO for post processing is activated before the scene is rendered. During rendering, if a portal is encountered, a new FBO is created and the whole scene is rendered to the FBO from the portals POV. Finally the existing scene rendering is completed and postprocess FBO texture is used for further processing.

I'm attaching the FBO to the following targets in both the cases. I have appropriate independent textures attached to the targets for both of the cases.

GL_COLOR_ATTACHMENT0_EXT
GL_DEPTH_ATTACHMENT_EXT

My knowloedge of FBOs is obviously rusty here so any ideas/pointers on what could be wrong will really help.

Fastian

[jide]

I don't know if that's what you'd like, but when you bind a FBO the previous one isn't bound anymore.

[zed]

ive done portals no probs.
im not understanding the problem, the portal is just a texture (wether youve created it with a FBO or not is irrelavent)

hmmm then agian

The process that i'm using is like this. The FBO for post processing is activated before the scene is rendered. During rendering, if a portal is encountered, a new FBO is created and the whole scene is rendered to the FBO from the portals POV. Finally the existing scene rendering is completed and postprocess FBO texture is used for further processing.

it seems as if youre going about this a bit lopsided, personally i believe u should first do all the visabilty calculations etc before u do start drawing things (though not always 100% possible eg if u use hardware occlusion) this way you have all shadow textures/ poral textures ready to use in the main render

[Fastian]

Originally posted by zed:
it seems as if youre going about this a bit lopsided, personally i believe u should first do all the visabilty calculations etc before u do start drawing things (though not always 100% possible eg if u use hardware occlusion) this way you have all shadow textures/ poral textures ready to use in the main render

That's exactly what i'm doing. My renderer is based on hardware occlusion querries and it gives great performance. I have my geometry sorted against effects, than against textures. I just wanted to try out a scheme where I have a bunch of polygons with the portal effect applied to them (just like a shader effect). When the renderer enconters that effect, it creates a new FBO, renders the scene from portals POV to a texture and finally uses that texture for the polygons. After drawing all the portal effect polygons, it continues drawing the original scene.

I believe what I am trying to do is possible but I just haven't grasped the idea of FBOs correctly.

Shouldn't both the FBOs be independent? and can't both be active at the same time? By both I mean the base FBO used to render the entire scene to a texture for post processing. The second FBO created during scene rendering to handle portals.

[Fastian]

Originally posted by jide:
I don't know if that's what you'd like, but when you bind a FBO the previous one isn't bound anymore.

So that means when I am done with the second FBO, I should rebind the first one to continue drawing to it. Makes sense. I'll give it a try.

[zed]

i had a look at my code (heres the relative bits, hope u can understand, why they dont make this editbox a bit bigger escapes me, ie its not like we're all viewing the web in 640x480 anymore).
this does hardware occlusion as well i think mmm_is_visable is set if its visable (it might lag  a delay of one frame which is not noticable)
 
if ( !options.skip_rendering )
{
g_SC->portal_man.update_PortalManager();
g_SC->gamewindow_fbo.bind_fbo();
g_SC->render_scene( percentWithinTick );
g_SC->gamewindow_fbo.unbind_fbo();
g_SC->render_gamewindow_fbo_texture();
}
 
 
for ( vector<int>::iterator it = mmmIDs_attached_to_portal.begin(); it<mmmIDs_attached_to_portal.end(); ++it )
	{
		MMM *mmm = g_SC->mmmLIB.return_MMM_ptr_from_ID( *it );
		CHECK_NULL_PTR( mmm )
		if ( mmm->mmm_is_visable )
		{
			g_rm.ogl.bindTexture_2D_to_unit( 13, portal_texID );
			portal_fbo.bind_fbo();
			g_SC->render_scene( *this, 0.0 );
			portal_fbo.unbind_fbo();
		}
	}

[Fastian]

Originally posted by zed:

this does hardware occlusion as well i think mmm_is_visable is set if its visable (it might lag a delay of one frame which is not noticable)

Hmmm.... so you exclusively render to portals after you are done with your current scene rendering. I guess a delay of one frame for portals isn't that big of a deal. This way there won't be any conflicts with the two FBOS.

Looks good. Thanks Zed.

[zed]

no before i do the scene, i do the portals / shadowmaps (edit) so theyre all ready to be used in the scene so everything is running in sync, by mistake ive done it before with shadows being a frame behind + even though it looks good, u do get a small impression everythings not 100%. (edit)
btw there's no one frame delay with the portals. the one frame delay is from the occlusion test to see if the portal is visable. ie i use the result of the previous frame occlusiontest to see if the portal mesh is visable.
though u can avoid this if u wish relatively easily.

btw sorry bout the small text in the last post i was a bit pissed off, i was mumbling about this small box ive gotta type the text into, anyways finished then post. bastard, u cant have a parentesis. ok edit pos. bastard, u cant post within 60 seconds.

[Fastian]

Originally posted by zed:
no before i do the scene, i do the portals / shadowmaps ...
btw there's no one frame delay with the portals.

Ok got it.

So in a given scene, how many unique portals do you support. I realize it depends on the type of scene shown by portals but I believe going above one in a HL2 style level would be pretty taxing.

I'll post my findings once I get there. Am stuck with some other projects for now

btw sorry bout the small text in the last post i was a bit pissed off, i was mumbling about this small box ive gotta type the text into, anyways finished then post. bastard, u cant have a parentesis. ok edit pos. bastard, u cant post within 60 seconds.

lol... I figured that . But that snippet really helped. Thanks.

[zed]

So in a given scene, how many unique portals do you support. I realize it depends on the type of scene shown by portals but I believe going above one in a HL2 style level would be pretty taxing

theres no limit to the number of portals u can support, with my game each portal reduces performance about 10%. but this will depend on comp / scene etc