BSP Rendering with Vertex Buffers
Author
In my 3D engine, we use a BSP for our levels. The engine uses old technology to render at the moment (DX7), but we have a working Direct3D 9 driver. We are in the process of converting to hardware T&L using shaders for transformations (removing the fixed function pipeline). Our dilemma is we are not sure of the most optimal way to render the BSP (which is subtractive like Unreal) using D3D9 vertex buffers. We don't want to get rid of the BSP because our toolset is one of the main features of the engine (we have an UnrealEd style editor) and we don't want to make calls to DrawIndexedPrimitive() for each leaf which only contains 1 face.
Can anyone point us in the right direction?
There have actually been a lot of threads about this lately on gamedev. The answer which is correct is also probably the one you don't want to hear, unfortunately: you shouldn't render by traversing the BSP. As you noted, it makes batching impossible; you can't afford to draw every face separately.
You can probably still keep your BSP based construction tools, but you will have to divide your geometry into larger chunks to pass to DrawIP. I'd consider looking at how quake 3 and doom 3 do their rendering; they have BSP'd worlds, but they use portals to do geometry culling. I don't know the details of how they chop up their worlds into cells (which are connected by portals, which I believe do make BSP splits), it probably involves the BSP somehow.
So in short, keep your bsp for collision and construction, but use portals to render. Not that portals are the only way of doing culling, but they seem to integrate well with BSP engines.
You can probably still keep your BSP based construction tools, but you will have to divide your geometry into larger chunks to pass to DrawIP. I'd consider looking at how quake 3 and doom 3 do their rendering; they have BSP'd worlds, but they use portals to do geometry culling. I don't know the details of how they chop up their worlds into cells (which are connected by portals, which I believe do make BSP splits), it probably involves the BSP somehow.
So in short, keep your bsp for collision and construction, but use portals to render. Not that portals are the only way of doing culling, but they seem to integrate well with BSP engines.
Author
Thanks for your reply. I was hoping that you wouldn't say that. :) I kinda had the same feeling. The only thing is that our BSP is more like Unreal's BSP as it's subtractive. Does anyone know how Unreal renders it's BSP? I'm sure UT2003 and 2004 don't render one poly at a time. :)
Admittedly I've only ever had a passing experience with the details of BSP-based rendering, but from my understanding they are very good at creating (or determining) the exact subset of geometry that appears on-screen.
Back in the day, that was crucial for performance - especially so if you had any element of software vertex/pixel processing.
However, on current GPU's you'll usually find that sending an extra few-100 (or few-1000) triangles to be rendered in few calls is going to be a lot quicker than sending exactly the right number of triangles but in a lot of draw calls.
What I'm getting at is that you might want to explore the possibilities of being less accurate with your BSP tree (even just the traversal) with the idea that sending some extra data down the pipeline isn't really such a bad thing.
If you traversed that sort of tree, you might go all the way down to determining if each LegN was visible... but that won't (necessarily) help batching. Instead, you could just stop at Table and render everything below it as a single batch. Might not be so accurate, but it might be faster [smile]
That make any sense?
hth
Jack
Back in the day, that was crucial for performance - especially so if you had any element of software vertex/pixel processing.
However, on current GPU's you'll usually find that sending an extra few-100 (or few-1000) triangles to be rendered in few calls is going to be a lot quicker than sending exactly the right number of triangles but in a lot of draw calls.
What I'm getting at is that you might want to explore the possibilities of being less accurate with your BSP tree (even just the traversal) with the idea that sending some extra data down the pipeline isn't really such a bad thing.
World | +---------+---------+ | | Room1 Room2 | +---------+-------+ | | | Table Wall1 Wall2 |+----+----+----+| | | |Leg1 Leg2 Leg3 Leg4 If you traversed that sort of tree, you might go all the way down to determining if each LegN was visible... but that won't (necessarily) help batching. Instead, you could just stop at Table and render everything below it as a single batch. Might not be so accurate, but it might be faster [smile]
That make any sense?
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
