Skip to main content
gamedev.net
🔒 Locked

BSP trees

Started by THACO Apr 14, 2005 at 2:27 PM 4 replies 1k views
Original Post
THACO
THACO
Ok, so I am working on creating a bsp tree, I have already created a simple program to generate the tree, and also one to draw it, minus the textures. How could I go about optimizing it so I write to a vertex array or buffer. Should I go through the bsp tree and for each node that will displayed put that triangle information into a vertex array / buffer then after going through the whole tree send the vertex array down the pipeline, also whats the deal with textures, becuase if I use them. Will I have to create seperate arrays for each texture? or could I send an array of textures to a vertex shader(Cg) along with an index to that array for each triangle, is that possible. I hope this all makes sense, I am trying to think of the whole picture so I don't get stuck later on. -THACO
JohnBolton
JohnBolton
Quote:
Original post by THACO
... Should I go through the bsp tree and for each node that will displayed put that triangle information into a vertex array / buffer then after going through the whole tree send the vertex array down the pipeline, ...

That's how it's done.


Quote:
Original post by THACO
... Will I have to create seperate arrays for each texture? or could I send an array of textures to a vertex shader(Cg) along with an index to that array for each triangle, is that possible. ...

There is a limit to the number of textures that can be simultaneously referenced, so if you stay under that limit, you can pick which texture (or combinations of textures) a pixel uses in the pixel shader. If you can't fit within the limit then you must use separate "batches".

Keep in mind that if you are using the BSP tree to determine drawing order, you must create a new batch every time you switch textures (assuming you can't do it all in one batch). This could result in a performance bottleneck and is one of the reasons BSP trees are rarely used to sort polygons these days.
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
MickeyMouse
MickeyMouse
Hi!

Quote:
Original post by THACO
Should I go through the bsp tree and for each node that will displayed put that triangle information into a vertex array / buffer then after going through the whole tree send the vertex array down the pipeline, also whats the deal with textures, becuase if I use them. -THACO


I doubt this will hardly optimize your renderer. Of course GPU will do A LOT faster with triangles in a single array, but CPU will have a hard time copying them here and there all over the time.

I'd rather recommend you create once an array of triangles for each BSP leaf, then use it without any copying / modifying. Every time you traverse your BSP to collect visible meshes, you'll simply collect arrays (not triangles). Even better if those arrays were 'neighbours' in a single vertex buffer, so you wouldn't need to switch between different vertex buffers when rendering neighbourous BSP leafs.

btw. BSP's have no future as a structure for rendering (it might be a lot of fun to learn how they work however).

Hope this helps.
Maciej Sawitus
my blog | my games
noVum
noVum
Mickey you are wrong, batching is really important. You have to consider that you need a seperate array per material, so the per node thing is really not a good idea.

Dynamic vertexbuffers are much faster in this case, especially when using Direct3D: http://www.mvps.org/directx/articles/vcache.htm
MickeyMouse
MickeyMouse
Quote:
Original post by noVum
Mickey you are wrong, batching is really important. You have to consider that you need a seperate array per material, so the per node thing is really not a good idea.


I think there was some misunderstanding. Batching is a good thing and I did recommend it, but I suggested different way of creating batches - not creating batches every frame (copying single triangles from leafs to some arrays), but precomputing them (no copying at run-time at all).

About 'the per node thing' - I made a slight simplification, but still in most cases you can put multiple meshes (e.g. from the same node) using different materials into the same vertex buffers. Just different offsets in them. What you gain is data locality in your spatial structure (less switches between vertex buffers).
Maciej Sawitus
my blog | my games
noVum
noVum
Quote:
but precomputing them (no copying at run-time at all).
BSP leafs have a way to low polycount to precompute anything. Copying is much faster, believe me.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.