Jump to content
  • Advertisement
Sign in to follow this  
littlekid

Ways to Render Nowadays

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What is the common way for rendering a scene nowadays? Is it still using a BSP to sort the scene polygons and render them or is the trend shifting to usage of other methods like scenegraph, octree, etc.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.


No PVS? Did they use portals instead of pre-calculated PVS?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
The common way to render is pretty varied, but the most interesting bet right now is to do as little CPU-work as possible to determine what should be rendered and let the GFX card take the minor hit of processing a few too many objects. The basic idea is that the CPU and GFX card should work simultaneously and not wait for eachother.

Scene graphs are not very well defined, personally I use one as a 'scene-manager' for all objects registered in a world. The renderer polls the scene graph for visible objects and the scene graph in turn asks its objects what's visible.

Doom3 uses portals.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Max_Payne
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.


I don't know who the first person is either (probably an employee of a graphics card manufacturer), but it's very applicable to the "real world". NVidia for instance highly recommends batching:

http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf

You're right that you don't want to spend excessive time lighting unseen surfaces, but that doesn't mean you have to cull triangle by triangle. Just do a fast ZFill pass before rendering anything else. Then you're only lighting visible pixels.

littlekid is absolutely right that you don't want to mess with individual triangles. Your app's CPU performance will be destroyed by the huge number of draw primitive calls if you split up things too finely. I have seen it in the "real world".


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!