FBO's and triangle strips...

[MarkS]

I'm about to begin work on a portal engine and in the process, jump past GL 1.1. I've been doing some research on FBO's and it seems that arranging the faces into strips will increase performance. However, in my case, the FBO would be created on the fly from the triangles returned from the portal culling code. Even if the model being clipped is constructed of triangle strips, the resulting faces potentially will not be. What kind of performance hit could I expect from not having the faces arranged in strips and how do you arrange an arbitrary face list into strips?

[Brolingstanz]

Well if you're portal rendering a static world then you're probably culling by sector or a sector group so it probably does make sense to strip along those lines; though honestly I wonder if strips will be much of an improvement over lists on modern HW. I guess it sort of depends on your geometry-material granularity and batch dispatch overhead, along with any target hardware goodies you can throw at it (e.g. texture arrays, etc.)

[knackered]

you mean VBO (vertex buffer object), not FBO (frame buffer object), I'm assuming.
if you're portal culling at the triangle level, then whether your triangles are arranged in lists or strips is the least of your worries. The GPU will be spending most of its time waiting for work to do.

[MarkS]

Yes, sorry. VBO...

[MarkS]

if you're portal culling at the triangle level, then whether your triangles are arranged in lists or strips is the least of your worries. The GPU will be spending most of its time waiting for work to do.

OK, I've been thinking about this comment quite a bit and I'm lost... Triangle level portal culling as opposed to what? Isn't the purpose of a portal renderer to cull any invisible polygons from the scene?

[knackered]

it's to cull invisible batches of triangles from the scene these days (unless you're programming for a software rasterizer, of course).

[MarkS]

it's to cull invisible batches of triangles from the scene these days (unless you're programming for a software rasterizer, of course).

I'm sorry if I sound dense, but that is what I thought I would be doing. Portal culling is just an extended form of frustrum culling, is it not? I'm a little bit behind the times. I'm still using GL 1.1 and have never even touched an extension. I obviously need some refreshers. Still, I thought I would test each polygon in the sector against the portal's frustrum and cull from there. I guess this is outdated? What is the best way now?

[Ilian Dinev]

Portal culling is completely different (nowadays). You use occlusion-queries, not maths.
Making the gpu draw 2000 poly is faster than manually doing the culling of 20 poly, etc etc.

First, do a simplistic depth-only pass for the walls of current room (you just need vertex-positions, no normals etc). Then with an occlusion-query draw the invisible small mesh of each portal (1-5 tris usually). If you try to retrieve query-results immediately, you'll stall the cpu; so do some useful work: add the current meshes/stuff from this room to the "to-draw" list. Now, get the query-results, they will show which rooms are visible through portals. Repeat the above stuff for each visible room.
In the end you'll have the "meshes to draw" lists, and have laid-out rough depth info. Have the meshes sorted by material and texture (actually you should have been doing automatic bucket-sorting when adding more to the lists). Draw the stuff. Done.