Distant 3D object rendering [games]

Question

What is the basic premise behind technology such as is found in Oblivion (and other games, I'm sure; haven't played enough to know), wherein objects from afar are vaguely shown when you view them from a distance? For example, a large tower is a mile away and you see the vague rectangle of it sticking up from the horizon... Obviously a giant 3D scene cannot all be rendered, and I know that in the case of heightmaps there are just approximation algorithms that are used to reduce the heightmap quality further away from the camera, but for specific objects, what is the best way to show those?

I was thinking perhaps a pre-rendering technique, wherein you pick specific places around the landscape and then make a program that draws all of the heightmap and 3D models around that spot and takes a picture. It would take several pictures, and then when the player is near that spot, the pictures would be used as a skybox.

Another more obvious technique is to store really rough 3D models, but then how does the 3D rendering system specifically choose to render the rough model of the building and not the rough models of other less significant (and probably not-viewable-from-that-distance) objects? How would you store something like that along with your heightmap? Maybe by design, only have a few such significant landmarks and then just store the list of them in a small file, and on each frame render the ones that are less than x really-far-distance away?

I am aware that the Halo series chooses to divide the game into levels and then each level has a different hand-made skybox. This is kind of what I was going for in the first suggestion, but I'm not sure about it. I guess I'm really just trying to collect other ideas or refinements or issues in my ideas, so that I can choose which ones to prototype with my limited time and knowledge.

Another related topic is how to display mountains at a distance, since they would be part of the heightmap and not 3D models on top of it, so they wouldn't really be able to have a rough version, and the heightmap approximation algorithm might screw up the mountain from a really far distance like that (assuming you would even try to approximate and render such distant geometry, which you probably would not). Bonus points if you cover this in your answer too. :)

Thanks!

P.S. I'm using OpenGL. I am just looking for the basic concepts but if you choose to post example code, please use OpenGL functions and terms! :)

EDIT: Thanks for the answers! For documentation purposes here is another resource I found: Chapter 4.9 in Game Programming Gems 2 covers the concept of rendering distant scenery to a skybox: http://books.google.com/books?id=1-NfBElV97IC&lpg=PA416&ots=SOpnfijZly&dq=render%20distant%20to%20skybox&pg=PA416 (unfortunately that preview is only the first page of the chapter... I'll have to grab that book from my university's library as soon as I get back in August)

Also after reading these things, I am still of the opinion that LOD is for objects that are at a still reasonably close distance. If the objects aren't even one pixel large, but you're still feeding them to the graphics card, you're just wasting power, whether using LOD or not. And that would be the case for everything but the absolute largest distant objects; a few tall buildings and some mountains, in most cases, but the small detail models (bushes, even trees, rocks, whatever other scenery...) would not be visible from such a distance. So I do like the render to skybox technique, and when I get to this bridge, that's how I'll cross it; and I'll make sure to use LOD for all models, I just won't render such a distance.

I am, by the way, thinking more along the lines of an Oblivion game, so the answer may depend on the game genre.

Answer 1

One technique is LOD (level of detail). The farther an object is from the camera, the less triangles are drawn. Here's a link: http://www.stefan-krause.com/

Answer 2

I think this is what your looking for Level of Detail (LOD)

Answer 3

For 3d models, the technique is called level of detail. Essentially, multiple versions models are kept available the the right one use based on context. It is not always just for distance, it can also be used to maintiain framerate in other situations.

Be careful though, you should have mipmapping enabled or you'll get sparkling on the larger textures on the lower res models, and be careful of animation. Switching the model beneath an animating skeleton is tricky so one technique is to maintain the same skeleton even when LOD-ing the model.

There are dynamic LOD systems for both terrain and for object models, but these can be CPU heavy.

Answer 4

You can render to textures for distant objects however you have to re-render the texture every time the perspective changes beyond some threshold. It works great for distant objects where the perspective won't change that often like your example of the mountains in the distance however if the the view source is moving too fast or you are too close then you will get a fish eye effect kind of like the early days of sky rendering in quake. This kind of system lends it's self to worlds like eve online which contain vast distances.

This of course is but another trick in your arsenal and you will still need LOD to some extent.

Answer 5

Low-detail versions of models work especially well for vehicles and objects It's really tricky with terrain. I've worked on battlezone-type games and PC flight simulators. A little fog helps cover up the "pops" between details.

At the lower details, texture-mapping is often replaced with a few single-color polygons.

---

"Another more obvious technique is to store really rough 3D models, but then how does the 3D rendering system specifically choose to render the rough model of the building and not the rough models of other less significant (and probably not-viewable-from-that-distance) objects? How would you store something like that along with your heightmap?"

You can grid your terrain and keep a list of which objects are visible in each grid cell.

Answer 6

A few techniques, including the ones you've mentioned:

• Level of detail. Outlined above.
• Mipmapping. For textures.
• Field of view. Restrict how many things your camera can 'see' by picking an appropriate zoom level. See also view frustrum culling.
• Far-clipping plane. Occlusion of far-off places: most games use fog, mountains, or some other excuse to have a hard cut-off on how far away you can see. This can be implemented using octrees, or some other such technique. This may be based on whole objects, or polygons, or whatever, and is usually set to occur right behind those aforementioned mountains.
• Arenas/levels/areas/whatever -- again most games artificially restrict you to playing in one arena at a time; the benefit is obvious (you get to ignore objects in all other arenas)
• Pre-rendering -- this is what you're suggesting above. For static scenes that are far off, render the scene in a 'typical' view and make it a texture on the background, or use it for the skybox / reflection map / etc.

The idea is to throw away as much detail as is possible before users start to notice.

There are a number of pre-existing toolkits that will do these things automatically, but they tend to cost money. If you're looking at a serious app, I would recommend at least researching the solutions they include.

Answer 7

One way to handle terrain is to have multi-resolution tiles. Much like how Virtual Earth and Google Maps do it, they divide the world into tiles in a recursive fashion. So, there are 4 tiles at level 0, 16 at level 1, etc... Then, using some LoD algorithm to determine the zoom/scale, you would load the appropriate terrain tiles for the given area.

Answer 8

The technique of dynamically caching pre-rendered views of distant objects is usually called 'impostors'. Here's an article from an old Game Programming Gems book on the subject.

There are many techniques for handling level of detail for heightmap terrain. Take a look at vterrain.org for an overview of some common techniques. The general principle is the same in most variants - break the terrain into sections and use lower resolution geometry and textures in the distance - but the details vary.

To reduce the number of objects that get submitted to the graphics card some kind of visibility culling will usually be implemented. At it's simplest this may be just completely dropping models whose bounding sphere covers less than a certain threshold of screen pixels (you'll be calculating this anyway when choosing which LOD to use if you have an LOD system). For greater efficiency some kind of hierarchical spatial data structure for culling may be used - quadtrees or octtrees, sphere trees, portal systems (not generally much used for outdoor environments), simple grid-based schemes, etc. The basic idea is to save work by culling a higher level node in the hierarchy and thus avoiding even looking at many leaf nodes. A simple example would be culling a building and effectively culling all of its child nodes (objects inside or on top of the building) without looking at them individually.

For a game like oblivion they are probably also doing some kind of occlusion culling - culling objects before submitting them to the graphics hardware based on determining that they are hidden behind other objects. There are a variety of techniques for doing this, some of them can be quite complex.