BSPs are still used in the are of FPS games because they are highly effective for indoor areas (which is what FPS games are mostly about). Doom 3 used BSP with no PVS.

If you want to mix indoors and outdoors, you can use a "hybrid" approach where you use BSP for buildings and an octree for the outside environment. So you have BSP trees inside some octree nodes.

Scene graphs I find are well suited to space simulator games.

Quote:Original post by Max_Payne
BSPs are still used in the are of FPS games because they are highly effective for indoor areas (which is what FPS games are mostly about). Doom 3 used BSP with no PVS.

BSPs (in traditional sense) are not used for rendering in D3 (or any other recently released similar game).

Quote:Original post by Max_Payne
Scene graphs I find are well suited to space simulator games.

Depending on some definitions BSP is a form of scenegraph.

littlekid: One of the most important things now is to batch as many polys in single call. You don't ever want to mess with individual triangles. As for spatial tree, you the one that fits your needs. There is not one-for-all (ATB comes close).

Quote:Original post by _DarkWIng_

Quote:Original post by Max_Payne
BSPs are still used in the are of FPS games because they are highly effective for indoor areas (which is what FPS games are mostly about). Doom 3 used BSP with no PVS.

BSPs (in traditional sense) are not used for rendering in D3 (or any other recently released similar game).

Wrong. They are used, in nearly the same way they were used in Quake 3, Quake 2, Quake, and other previous games, with the difference that they have no associated PVS data. This information comes from John Carmack himself.

Quote:

Quote:Original post by Max_Payne
Scene graphs I find are well suited to space simulator games.

Depending on some definitions BSP is a form of scenegraph.

Wrong again. There is only one proper definition of a scene-graph. This definition implies that child nodes are transformed in the referential of the parent node. Scene graphs are very well adapted to dynamic environments, where there are many objects moving relatively to one another. BSPs have not much to do with this, and are hardly suited for dynamic worlds.

Quote:littlekid: One of the most important things now is to batch as many polys in single call. You don't ever want to mess with individual triangles. As for spatial tree, you the one that fits your needs. There is not one-for-all (ATB comes close).

I don't know who's the first person that came up with this idea. It might be very applicable to terrain rendering, where the entire terrain is just a big batch of polygons forming one surface, but in the *real world*, it doesn't work. What actually matters is to avoid rendering what you can't see. Videocards may be getting faster, but the rendering work is also largely increasing. Performing dynamic lighting in hardware is *slow*, and you can't afford to render that many invisible surfaces, especially in large environments.

What you actually need to do is subdivide the scene using your favorite method (as suggested), and then batch the objects to render per-material (materials encompassing a set of shaders and textures applied to a surface), this will save costly render-state changes. As for avoiding render calls. Simply store the polygons in a vertex buffer, and reference them from there when you need them.

Quote:Wrong. They are used [in D3], in nearly the same way they were used in Quake 3, Quake 2, Quake, and other previous games, with the difference that they have no associated PVS data. This information comes from John Carmack himself.

You're correct, in the sense that in neither case do BSP's play a significant part in the rendering process, other than perhaps initially navigating to the camera position. Quakes 2 and 3 used a PVS set. Doom 3 uses a portal system.

I suppose the BSP may be used to do some sorting of transparent polys, but I think Doom 3 simply attaches to each particular material a rendering priority instead.

The BSP was used mainly for other purposes, such as collision detection.

[Edited by - MumbleFuzz on June 16, 2005 12:29:07 PM]

Quote:Original post by Max_Payne

Quote:

Quote:Original post by Max_Payne
Scene graphs I find are well suited to space simulator games.

Depending on some definitions BSP is a form of scenegraph.

Wrong again. There is only one proper definition of a scene-graph. This definition implies that child nodes are transformed in the referential of the parent node. Scene graphs are very well adapted to dynamic environments, where there are many objects moving relatively to one another. BSPs have not much to do with this, and are hardly suited for dynamic worlds.

Actually, Scene Graphs are high-level structures that are usually used to express logical relationships between dynamic(mainly) objects, not spatial ones. So you can't really compare BSP or octrees with scene graphs, they're not used for the same thing. Spatial structures are used for HSR(Hidden Surface Removal) or collision detection, whereas it's an abuse to use SG for that.

Let's take your example(space simulator). A system of planets will be described in a scenegraph, where planets(or spaceships) are orbiting around other planets, where in turn the orbit around others... A spaceship belongs to a small group of ships following a leader, where in turn they belong to a fleet, and so on. Those are logical relationships, used for physics,animations or AI(and not just for "transformations"). But you won't use the SG to do frustum culling on the geometry. Spatial stuctures like ABT or octrees will be used for HSR.

Yann L has cleared for me many things up in some threads about SG, I suggest you do a search and read them.

Quote:Actually, Scene Graphs are high-level structures that are usually used to express logical relationships between dynamic(mainly) objects, not spatial ones. So you can't really compare BSP or octrees with scene graphs, they're not used for the same thing. Spatial structures are used for HSR(Hidden Surface Removal) or collision detection, whereas it's an abuse to use SG for that.

Explain how exactly it constitutes an "abuse" to adapt something to your needs?

Quote:Let's take your example(space simulator). A system of planets will be described in a scenegraph, where planets(or spaceships) are orbiting around other planets, where in turn the orbit around others... A spaceship belongs to a small group of ships following a leader, where in turn they belong to a fleet, and so on. Those are logical relationships, used for physics,animations or AI(and not just for "transformations"). But you won't use the SG to do frustum culling on the geometry. Spatial stuctures like ABT or octrees will be used for HSR.

I would make it so that each parent node contains a bounding sphere radius, which is appropriately dynamically updated. Since the density of objects in space is low, and the movement of objects is relatively slow, compared to the size of the system, this would be very efficient for frustum culling, and trivial to implement.

As for squads, its very easy to simply store a list of all squad members, or a reference to the squad leader. I don't see the point in having any more complex logical relationship.

Quote:Yann L has cleared for me many things up in some threads about SG, I suggest you do a search and read them.

I know Yann L has quite a following around here, but my understanding of scene graphs, in the practical sense, is very fine, thank you.