Spatial data structure
Author
I have built BSP trees for my level and I see problems up ahead.
Now I draw the level mesh by mesh and I cehck if the mesh is visisble or not. The BSP leafs don't contain meshes, but a set of triangles. So should I build a vertex index array for each subset of triangles that is in a different mesh or is in a different material group but still in the same object? That sounds very complex. Is there a better way?
if you are using hardware I would advise not using a bsp tree for rendering, the problem is that the leafs of the tree usually store a very small amount of triangles which will result in a lot more draw calls to your graphics card. Also, the mesh will be split countless times breaking any sort of state/material sorting you have done. You would be better to use some other techinque such as portals, octree etc. bsp trees are mostly used for collision detection in todays games.
Author
Should I divide the level with the octree or the objects too? If I do that, I may get the same problems as with the BSP tree.
Quote:Original post by staticVoid2
if you are using hardware I would advise not using a bsp tree for rendering.
Technically, wouldn't that disregard KD-Trees and ABTs? I'm gonna assume you mean BSP in the sense that Doom, Quake, etc do it by using polygons themselves as the dividing planes, rather than being axis aligned, or wisely selecting (pre-processed) a dividing plane for a given map? I'm curious as I've implemented an Octree myself in my own engine, and currently reimplementing it using a binary tree, but kinda like the way an ABT or KD-Tree works.
What do you want to index (objects or polygons making up objects) and for what purpose? (frustrum culling, occlusion culling, visible surface determination, collisions, visibility checking, lighting..)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement