Having read some whitepapers and other stuff on OctTrees (I'll let BSP alone since it doesn't quite work in Irrlicht) I wanted to check its real efficency (in rendering of .bsp maps, not collision detection).
To be honest it doesn't seem to reduce rendered polygon count to such an extend as it should, I guess. Only in very special cases does it cut off poly render by more than 30% - normally almost 90% of the map's polys are rendered. Would BSP which as far as I am concerned is used in most comercial fpp games give a better performance boost?
Another issue - is there any way to do some extra culling to improve speed? Maybe some fog (like in an old Turok)?
And the final one - could anyone recommend a good profiler preferably for VS.NET 2001?
A matter of performance
Part of irrlicht's problem with hte octree rendering is I believe it uses the bounding box of the view frustum for picking the poly's in the octree. If the actual frustum were used, there was a 90 degree FOV, you were in the center of the map and the polys were evenly distribute you would render about 1/8 of the map. Those are ideal conditions, however. If I'm rigth about irrlciht using the aabb of the frustum it would probably be easy to change it ito use the actual frustum, whcih should yield lower polycount although the visibility test against an aabb is faster than against a frustum so i'm not sure which would end up faster.
BSP should be much better than octree for indoor levels. I believe that a bsp can be constructed is such a way as to allow occlusion queries, or at elast draw front-to-back. I know nothing about how to construct a bsp, however. It's rather complicated, I believe.
Another way to do extra culling: probably portal rendering would be my pick and I don't think it owuld be too hard to implement, though I have not actually tried it yet. Splitting up the static level geometry into the sectors woud be somewhat difficult and it might make sense just to use a bsp for that, if irrlichts bsp scenen ode worked. For smaller objects portal rendering shouldn't be too hard to implement. Each sector maintains a linked list of objects in it. There would be portal scen nodes which would each contain a link to their sector. When a portal node was rendered it would construct clipping planes wit the camera position and its edges, then test everything in its sector agains the new clipping frustum. That's how I'd implement that, anyway. Note that that's all theory. I have not actually done this.
Fog culling could be done, though I don't know if irrlicht does, and unless you were making a gmae where it was continuosly densely foggy I think that the fog culling would not help much.
BSP should be much better than octree for indoor levels. I believe that a bsp can be constructed is such a way as to allow occlusion queries, or at elast draw front-to-back. I know nothing about how to construct a bsp, however. It's rather complicated, I believe.
Another way to do extra culling: probably portal rendering would be my pick and I don't think it owuld be too hard to implement, though I have not actually tried it yet. Splitting up the static level geometry into the sectors woud be somewhat difficult and it might make sense just to use a bsp for that, if irrlichts bsp scenen ode worked. For smaller objects portal rendering shouldn't be too hard to implement. Each sector maintains a linked list of objects in it. There would be portal scen nodes which would each contain a link to their sector. When a portal node was rendered it would construct clipping planes wit the camera position and its edges, then test everything in its sector agains the new clipping frustum. That's how I'd implement that, anyway. Note that that's all theory. I have not actually done this.
Fog culling could be done, though I don't know if irrlicht does, and unless you were making a gmae where it was continuosly densely foggy I think that the fog culling would not help much.
You do a lot of programming? Really? I try to get some in, but the debugging keeps me pretty busy.
Crucible of Stars
Crucible of Stars