It has been my opinion that for the vast majority of cases, LOD is worthless at best and counterproductive at worst.
Rendering meshes works best when you set the VBOs and material, then draw all instances of the mesh. Adding another version of the mesh into this has the effect of creating a larger number of smaller batches. This is bad.
LOD only helps with the vertex fill rate. This is usually not a bottleneck on modern hardware.
I am interested in hearing any other ideas that would make LOD a practical feature. You could store all LOD versions in one VBO, and have the indice lists access different parts of the vertex buffers. For example vertices 0-300 might be the first resolution model, then vertices 300-450 contain the second level of detail, and so on. But my understanding is that all vertices in the VBO will be transformed each draw call, even if the indice array does not use them. In other words, a 1-triangle draw call on a 1000 vertex VBO will transform all 1000 vertices. Is this correct?
There are several kind of LOD: on geometry (less vertices, the one you’re thinking about), simpler material (faster shader), switching off shadows, replacing several small entities with one imposter…
In one of my previous games, doing LOD on animations did save quite some fps.
No it’s not. Only used vertices are transformed, and in the order they’re used/indexed.
If you truly believe this, then try it yourself and prepared to be disproved. Rendering ANY model a thousand times at full vertex/material resolution is extremely inefficient and doesn’t even come close to the optimizations obtained when using LOD, imposters, ect…
Just because some game studios say LOD is worthless or that they don’t use it in their games because they found it unnecessary on current hardware, doesn’t mean its true for all situations.
Some folks don’t like LOD and pretend it doesn’t matter just so they can sneak away from the complexity of adding it to their graphics engine.
You can of course do away with it if you severely restrict your view distance or otherwise limit the number and complexity of objects visible in the scene, but that’s a tradeoff and a cross the individual developer must bear on an application-specific basis.
For example, there is no geometry lod for terrain in ETQW apparently, but everything else heavily use LOD : terrain texture, enemies, buildings, vegetation, etc.
Yea, It really depends on the type of game you do.
The thing about LOD is that you cant change it until it won’t be noticed, so a game with a lot of long distance views like battlefield or ETQW, or extreme use of high poly models like UT3 and GoW will benefit greatly from LOD.
While games that have only short range views like doom3 or any generic fighting game, or lowpoly models like WoW generally don’t.
I think doom 3 only uses something like 1 or 2 LOD levels.
I think LOD will play an even larger role in the coming years as amd and nvidia start using unified shader units, in that case if you can reduce the poly count to the lowest possible level without it being noticable you will also increase the fill rate and thus the FPS.
Terrain is a different thing altogether, dynamic lod uses up to much processing power, especially as terrain quality increases, so in this case it’s better for the time being to have no lod.
Dynamic LOD only uses a lot of processing power if you code it incorrectly or naively. I’ve coded up my own version of a geomipmap lod terrain that uses basically 0 cpu time when switching between lods. All you have to do is cache cache cache…As long as you precompute any calculations, there’s no need for cpu cycles.
LOD will certainly make a difference for animated models and certain high-poly objects. But I have always found for models under a few thousand vertices, it seemed like drawing batches with the same mesh always made a bigger difference than drawing an extra low-res version.
What have your findings been with objects less than, say, 3000 polys? The LOD in HL2, for example, seems very silly to me, like it is designed for old GPUs.
The reason ET:QW doesn’t use LOD is because they can’t. Their art pipeline goes like this:
-Model a terrain mesh in max and unwrap UV coords.
-Export to their texture painting tool.
-Paint textures and export to game format.
So once their terrain geometry is done, it’s done for good. I’m surprised more people haven’t pointed out the limitations of their technique. Once I realized it, I saw what a step backwards it was.
What have your findings been with objects less than, say, 3000 polys?
It depends on what your vertex shader is doing and how many of these 3,000 vertex models you intend to draw.
The LOD in HL2, for example, seems very silly to me, like it is designed for old GPUs.
If the game seems like it’s designed for old GPUs, that’s because it is. It expects to be able to run reasonably well on Radeon 9500s. The game is 3 years old, after all.
I think mega-textures are a cool new technique and the results are very impressive.
However, you correctly point out, that it also seems to be a major pain in the butt, if you would like to change anything late in development.
For example, most games use instanced objects today (not talking about “instancing” as in glDrawInstanced, or so). So you create your object, and the place it thousands of times in your levels.
If you later on change that object, it will be replaced in all levels either when it is recompiled or when it is loaded the next time (depends on the engine).
HOWEVER, if you have a mega-texture and allow every object, even instanced ones, to be textured differently, this can become quite a problem. Now your geometry might still be instanced, and the texturing is done once and then copied into each levels mega-texture, but the moment you start to paint in your levels to make objects look unique, you are forced to keep your template-objects as they are and never change them again, because if you change their geometry, all the details, that some artist painted into a level’s mega-texture, are worthless.
So, if you have a mega-texture system, that can handle all objects equally, even instanced ones, you need to push the “unique painting activity” at the absolute end of your development, when you are sure everything is fixed. This might be possible, but i doubt it is easy.
to Leadwerks and Jan :
ET:QW (idtech4) only have megatexture for terrain. Not for buildings, objetcs, trees etc.
As terrain is almost heightmap (only some limited overhanging parts and tunnels etc), changing the mesh does not mean changing a lot the texture. For lod, it is a non issue. Moreover, the base texture layer is procedurally generated. So it is merely a matter of adding skid marks, etc.
For rage / idtech5 objects, as i understand it, the technique simply allow artists to import directly their models from CG tools like max, maya, without worrying about hardware texture ram constraints.
The ability to “paint the world” seem mostly valuable for the terrain, and I said before, terrain geometry changes should not be too much trouble.
What I mean is, in the case of geomipmapping, you precompute every permutation of index buffers you will need for each LOD level, then when rendering each patch of the terrain, select an appropriate LOD level, then using this LOD level, select one of the precomputed index buffers and to use for rendering. So it IS dynamic in the sense that you are changing the LOD level of each patch during runtime, but there is no sense in recomputing index buffers each frame.
What exactly is silly about HL2’s LOD system? I think it works very well, it isn’t very noticeable.
I mean that HL2 seems to perform detail version switches on pretty low-poly models that don’t seem like they need it, like rocks and logs.
I turned the settings on Crysis all the way up, and LOD popping wasn’t noticeable at all. Even in medium settings, I don’t notice it switching models…it just hides rocks when they get too far away.
So I guess if you had a good model pipeline, you could merge all LOD versions for each limb into a single VBO, and just draw parts of it for each version. Of course, this does not account for things like billboards, where one detail level is a completely different material and structure from another.
So it IS dynamic in the sense that you are changing the LOD level of each patch during runtime, but there is no sense in recomputing index buffers each frame.
But this is hardly what most people would consider dynamic. When people talk about dynamic LODs, they’re talking about generating the LODs dynamically. That is, generating the geometry itself dynamically. That is what people are talking about when they say “dynamic terrain LOD”.
I mean that HL2 seems to perform detail version switches on pretty low-poly models that don’t seem like they need it, like rocks and logs.
“seem like they need it” on what hardware? A GeForce 7800? A Radeon X1800? Remember, HL2 is supposed to be functional on DX8 hardware. That means as far back as GeForce 4600s and so forth.
HL2 even got a DX7 renderer. Though i don’t know, whether it is functional or more like a “proof of concept”.
The stuff i said about mega-textures were not targeted at ETQW, i know they only use it on the terrain there. However, Rage is supposed to use mega-textures for everything, at least it sounds like that (and it is technically possible).
Crysis i couldn’t “play” at high settings (heck, i couldn’t play it at low settings, but at least it ran with 15+ frames then). Maybe with the intended hardware the LOD popping isn’t noticeable anymore.
About dynamic terrain: I think it is mostly useless. So far i haven’t seen a game, that actually used terrain-deformation in some sensible way. I don’t see why one needs anything else, then static terrain. The only thing that one CAN do, is to allow grenades to make small craters, but that’s only some games, that would need it and you need to make sure, that nothing else breaks (like that you can make holes beneath a house or so).
