PDA

View Full Version : Are bsp maps drawn in immediate mode?



WhatEver
08-24-2002, 05:33 AM
I have been wondering this for a while now. Since the bsp tree makes maps so dynamic I'd assume that the maps use immediate mode.

I was told by a proffesional game programmer once that bsp trees are being phased out...what's phasing out the bsp trees? Quad trees? I didn't know much back when he said that.

jwatte
08-24-2002, 07:50 AM
BSP trees are often drawn in immediate mode, because of the way the geometry is generated from the traversal. You could also accumulate it into a set of vertex buffers, one per texture -- unless you use texgen which changes per surface; then just give up and go immediate.

Most game worlds these days seem to use a portal system for indoors visibility culling, with each portal zone being treated mostly as a polygon soup, and meshes being view frustum culled if they pass the portal visibility test (well, as the view frustum is the initial portal, that's a no-op :-)

For outdoors, some people are looking at occluders/occulters, but the benefits are not clear to me. If there are some tanks on the other side of a ridge, then you don't have to draw them, but as soon as you climb that ridge, you DO have to draw them, and everything else for miles around, so that's the scenario you need to optimize, not the "best case" of being able to cull out a bunch of things.

Make sense?

WhatEver
08-24-2002, 08:15 AM
I think so. When you say soup, you mean that there are like sections of map treated as one mesh so you can use glDrawElements on them? So when you enter a certain area it will draw all the "sections" that should be seen from that point and view direction.

I notice with Q3 in wireframe mode that a whole area you can't quite see all the way is still drawn but other areas you can't see at all are not drawn.

If this is true I'm assumning it's actually faster to group sections of the map and draw those with glDrawElements rather than use immediate mode.

I started thinking about this because of the comment made in another thread about drawing from front to back using a beam tree or something. To do that you'd either need to dynamicly generate indices so that it draws from front to back, or use immediate mode.

All this optimization stuff is becoming overwhelming. It's getting to the point where you have to have a masters degree in math before you can program this stuff.

knackered
08-24-2002, 09:23 AM
Originally posted by jwatte:
If there are some tanks on the other side of a ridge, then you don't have to draw them, but as soon as you climb that ridge, you DO have to draw them, and everything else for miles around, so that's the scenario you need to optimize, not the "best case" of being able to cull out a bunch of things.

Well, it's not the worst case scenario you should optimise for, it's the 'common case' scenario you should optimise for. If you're doing a tank game then your tank is going to be mostly operating below the horizon of most surrounding mountains, so you expend some effort culling out things beyond those horizons, to make for a smoother general appearance.
But if you were doing a flight sim, then obviously this would be a wasted effort, for the most part.

Korval
08-24-2002, 09:50 AM
Well, it's not the worst case scenario you should optimise for, it's the 'common case' scenario you should optimise for.

Not necessarily. It depends on how you want your program to perform. If you absolutely want your game to run at a good framerate on <insert minimum system>, then you have to optimize for the worst possible case.

There is something to be said for, depending on what your minimum system requirements are, just throwing everything at the card (and using the fastest way possible: VAR/VAO) and letting it deal with it. At least then you have fairly predictable performance.

knackered
08-24-2002, 12:01 PM
Originally posted by Korval:
Not necessarily. It depends on how you want your program to perform. If you absolutely want your game to run at a good framerate on <insert minimum system>, then you have to optimize for the worst possible case.

Not in any world I'm familiar with. The worst case scenario is generally something that you don't permit to happen very often (eg. by it being a tank game), therefore why optimise for it? If someone drives to the top of the hill then they have to expect a drop in frame rate - it's something I don't have problem with in the games I've played, because I wouldn't be on top of a hill very often.



There is something to be said for, depending on what your minimum system requirements are, just throwing everything at the card (and using the fastest way possible: VAR/VAO) and letting it deal with it. At least then you have fairly predictable performance.

You're talking specifically about brute force terrain rendering, I assume?

[This message has been edited by knackered (edited 08-24-2002).]

jwatte
08-24-2002, 05:57 PM
Well, in my main app, the camera can fly, so "long" view distance is common enough that occlusion culling outdoors just doesn't help enough. We gotta design for the bad case.

Our target is 30 fps on a GF2MX200, on a P-III/800 (we do software skinning and blending, too). We push 30,000 to 90,000 polys per frame with mostly view frustum culling and static lods, using vertex lighting and all-float vert formats in many cases (because of the soft skinning), in groups from 100-700 polys, on this platform, which is not too shabby all in all. The sad part is, we don't have the art or engineering bandwidth to really scale up on higher-end cards, so a 9700 will look just the same :-)

Umm... back to BSP trees: I think Q3 still uses them for, at a minimum, gross world culling and collission, although they probably don't split geometry, so you won't get zero overdraw as with the classic BSP technique.