Just curious about that. . . With the advent of hardware HSR, is doing that in software necessary anymore? I know that the Unreal Engine (as used in Unreal Tournament) only draws what the player can see. I'm guessing that this was what Tim Sweeny was refering to when he said that the engine had a great software renderer, which also limited the game's hardware rendering capabilities. Is it generally slower for a game to use software HSR in combination with hardware HSR than to -just- use hardware HSR?
Do modern engines still do hidden surface removal in software?
- Thread starter Ostsol
- Start date
Mintmaster
New member
NitroGL said:
Say, are the advantages of BSP significantly higher than an Octtree? An octree seems very easy to implement, and it seems to work quite well.
I'm planning on making a 3D engine, and so am wondering if a BSP tree is worth the effort, and what it really has to offer.
Mintmaster said:
BSP trees are the best method I've heard of for ensuring that everything is rendered back to front. This is necessary in the case of surface that's transparent. If you render from front to back, the result is that the transparent surface appears to be behind everything. This happened to me the first time I tried working with transparent polygons. Took me a while to realize what was wrong.
NitroGL
Active member
Mintmaster said:
Depends on what your engine is doing. If it's an indoor type engine, then BSP+Portal would be the best bet, for outdoor (terrain, etc) Octree would be best.
In my experence, the Octree transversal process actually is SLOWER than just rendering the whole model, but my Octree implementation wasn't the best either.
Mintmaster
New member
Ostsol said:
Well, for performance reasons it is much better to render from front to back, and then do alpha textures from back to front. Rendering front to back allows HSR algorithms and Z optimizations to work, such as Hierarchical Z.
I also thought of a way to make Octrees render almost in order (any direction). After all, an octree really can be viewed as a less flexible, simple BSP. It should be good enough to keep transparencies in check, and rendering in order from front to back.
Mintmaster
New member
NitroGL said:
Depends on what your engine is doing. If it's an indoor type engine, then BSP+Portal would be the best bet, for outdoor (terrain, etc) Octree would be best.
In my experence, the Octree transversal process actually is SLOWER than just rendering the whole model, but my Octree implementation wasn't the best either.
OK, thanks.
Still, the portal algorithm could be applied to an octree as well, couldn't it? Also, what's the best way of determining portal visibility?
I was thinking of an object based tree (with bounding boxes) rather than a polygon based one because once you start incorporating vertex shaders and even ordinary TCL, you can't track the polys anymore, can you?
It seems like view frustrum culling is quite easy and efficient with octree, but you can get unbalanced nodes in certain circumstances. A BSP solves these inefficiencies at the expense of added complexity, right? Still, view frustrum culling seems pretty annoying with a BSP though.
Correct me if I am wrong...
The only Problem with BSP+Portal is that it is of strictly limited use in any scenario except indoors with many not too large rooms and without long sightlines, though doing that it's very fast.
Outdoors or multi-purpose HSR, especially for arbitrary Polygon Meshes is much more difficult. There, it is wise to take a look at Octree based Algorithms, perhaps with Hardware Occlusion Query Support (See NVidia, I don't think ATI supports this), because without that you have to scan-convert many Objects to test them for visibility (for interactive Scenes precompiling visibility is not possible). However I advise you (all of you) to take a look at recent scientific publications under Keywords like "Visibility" or "Occlusion" "Culling" etc. (see citeseer.nec.co.jp).
Outdoors or multi-purpose HSR, especially for arbitrary Polygon Meshes is much more difficult. There, it is wise to take a look at Octree based Algorithms, perhaps with Hardware Occlusion Query Support (See NVidia, I don't think ATI supports this), because without that you have to scan-convert many Objects to test them for visibility (for interactive Scenes precompiling visibility is not possible). However I advise you (all of you) to take a look at recent scientific publications under Keywords like "Visibility" or "Occlusion" "Culling" etc. (see citeseer.nec.co.jp).
Mintmaster said:
I've been wondering about that for a while. I've been trying to incorporate BSP trees into my little program, but realized that the fact that I'm using vertex arrays means that the vertex data is inaccessible outside of the vertex shader. In any case, pulling vertex data from the array for the purposes of BSP calculations or colision would totally defeat the point of the vertex array itself. The only solution I can think of is to have a secondary copy of the vertex data in system memory. . .
Mintmaster
New member
Barkas said:
Actually, ATI does support this now, AFAIK. Check this out:
http://www.rage3d.com/board/showthread.php?s=&threadid=33620181
Look for Humus's response.
Occlusion query can be very useful for portals I'm told. Is it possible to do viewport frustrum culling with a BSP? It can be done very nicely with an octree, but I can't see how it can be done efficiently with a BSP. If you can't, I guess that would why outdoor scenes are so much better with an octree.