Are "downgraded" 3D models generated in real time?

This is something random I just wondered. What I mean by "downgraded" is a lower poly model used when it is further away from the camera. I doubt it, but what seems like would be the easiest way to go about this would be to do a sort of subdivide feature in reverse, having polygons stored a certain way in memory to where you can skip every other one. Sure, this is limiting and not the most efficient for the renderer, (and requires more CPU time, but that doesn't seem to be the thing limiting game performance 90% of the time) but it saves on space and even makes doing this to scenery possible. This is something especially important for 5th and 6th generation systems for not having a lot of ram, although I don't know how much space models typically take up.

The term you're looking for is LOD, or Level of Detail.

No, you would not normally procedurally mangle your models that you already have in RAM, for a number of reasons:

1. Automatic mesh downsampling like that usually looks horrendously awful, except in very simple cases (e.g. terrain heightfield). Most low LOD meshes are made by hand, though they might use an automated tool to give them a starting point to start editing from.

2. The size of the additional data for a low LOD is usually not a big concern compared to its "big brother". If you have enough space for the full LOD, the low LOD verison is easy to manage. The low LOD isn't usually 50%, it's probably less than 25% of the data, if even that much.


LOD is also important for streaming data, where you load in the low LOD first as a placeholder until the high LOD version has time to load off the disk asynchronously. Again, in this case you end up having to have enough RAM to have them both around anyway, and the low LOD might be useful for the case you mentioned too (i.e. far distance draws) so you might as well keep it anyway.

You can have more than two LODs but it's easy to extend these ideas further. For loading it's not common to have more than 1 level of placeholder for loading in, but for distance efficiency you might want more levels of LOD for that. It's all a big tradeoff between several dependent factors.

Yeah, you're right; thanks. The existence of the "Details on Discrete LOD" answered my question, although it doesn't list any examples of how it's done. The easiest way I can think of is to what I sort of described earlier and subdivide polygons, like in this example I made:


The red is the least detail, the green is middle, and the blue is most detail. How this would be stored in memory is beyond me, especially taking into account having points connecting to other low quality points.

I see rainwarrior made a post as I was finishing this...


I didn't think models were streamed real time; I thought they were almost always sitting in ram.


Oh yeah, I wasn't thinking about that... I do find the quality dip to be too obvious for the most part though, either switching quality too close up or only having two or so changes.

I'm getting the impression that it's better to just have multiple models made for characters, but I heard you said it can be useful for terrain. What I wonder, is do you mean just straight up montains, or for everything that isn't an object? (So 3D equivalent of a BG layer, basically.) The big thing I can think of about this is that while you can just use different models based on just checking the distance from the camera for objects, you can't do this with the background because it's both close to and far away from the camera. You'd have to have multiple layers away from the camera, each with their own LOD. I don't think the example I had shown before would look too bad here, especially considering the background is typically less complex geometrically.

I mentioned terrain because it's a case where I've seen automatic downsampling applied (not at run-time though). A simple heightfield on a grid of quads is well suited to automated processing like that. Kind of the polar opposite of a complicated topology like the human hand or something.

Still, even in that case I don't think you'd want to do the thing you suggested where you simply decimate the vertices, using every second one, etc. You can probably automate the LODs for a case like that, but there's a lot of things you'll likely want to do, e.g. averaging instead of decimating, doing something with the edges to prevent seams between low/high LOD connections, etc.

Generally this stuff is done offline. The main exception I can think of is texture mipmaps, which in some cases might be stored in the file (+50% data size) or sometimes might be generated automatically when the texture is loaded. However, if you store the mipmaps in the file you can also use DXT compression on the mipmaps too (smaller RAM usage, better cache performance, etc. but slow enough you probably don't want to do it at load time), so... again there's decisions to be made that are specific to your application.

I'd have figured that on a machine old enough where you'd worry enough about the number of polygons to reduce the LOD like this, you wouldn't have enough CPU time to do anything more complicated, Then again, the power of even the N64 is amazing to me; you obviously have a lot more freedom in what you can do.

Just because you can save a few cycles or a bit of RAM or a bit of disk space to approximate something doesn't mean that approximation is useful. How good the approximation is always matters. Sometimes the result just isn't good enough for what you get.

If you're asking about N64, I don't think multiple levels of detail was even done there (though if you look hard enough you can probably find an example somewhere). Models were already about as low poly as they could be, in general, draw distances were usually quite short, and you didn't often have open streaming worlds that would need placeholders.

LOD systems are more relevant to newer machines, not less. GPU power is still a limited resource that requires careful management techniques.

Appropriateness of a solution highly dependent on the nature of what you're using it with.

Right off the bat, I can tell you Mario degrades the further away he is from the camera in Super Mario 64. Like black bars in SNES games, it's not rare, but it's not the norm. I was thinking more of the GameCube when I wrote this though.


...Even though you'd think it would be more useful for old ones?...

I'll have to take your word for it, but this is what he looks like with the camera up close:

You're telling me that there's some degraded lower poly version of this? It doesn't really have vertices to spare, IMO.

If there's an LOD change in this video, I couldn't spot it:
https://www.youtube.com/watch?v=MzHjJ-guSJg


No, you'd think that. I know how it applies to modern systems.

The only way it wouldn't apply is if you're intentionally underutilizing your GPU. Like if you're making a PS2 game and running it on a PS3, maybe you could get away with turning off its LOD systems? I mean, it's a quality for speed tradeoff; you can always deal with the problem other ways, like by just drawing less stuff overall, you have to have a problem that LODs are suited to for them to apply, but there's a reason every modern game engine has an LOD system.

I mean, I thought it would be on everything.


It never really shows up unless you set the camera though. I found a good video that demonstrates it: https://www.youtube.com/watch?v=xSynNINQJyQ

F-Zero X has multiple LOD levels for the machines, and even the track sometimes seems to wiggle in the distance in such a way as to imply something similar (IIRC it's most noticeable with cylinders). It's amazing what you can get away with in 240p...

Wow, that's quite unexpected! I don't remember ever noticing that while playing it. (It looks terrible too, ha ha.)

I'm no 3D expert, but I've heard the term "imposter" used.

Basically if something is far enough in the distance, switch it out with an imposter, which could be as simple as one textured quadrilateral.

Yeah, that's what we were going over. All the stuff involved in 3D blows my mind. I've always wanted to program a 3D video game, but seeing my level of success with even the SNES... (I love looking at the GameCube register list and trying to make even some sense of it.)

Do they use this as a way to fake antialiasing on textures that far away?

It is my understanding that that is exactly what mipmaps are.

Textures themselves can have multiple sizes, with the smaller ones more blurred as they're shrunk down, and is recommended for objects like the notorious vertical picket fence texture that otherwise shimmers horribly in the distance during movement.



I think lately though, there's been more focus on real-time multipoint sub-sampling of textures. Basically one pixel is a blend of 8 or so nearby texels.




Books! There are good books (and bad books) that talk about this stuff.

Game Coding Complete, Fourth Edition: Mike McShaffry

I was kind of looking at this general overview book, and although it does not get into great detail, it seems to cover a lot. If anything it's more like a compilation of experiences.

Unfortunately (or fortunately?) Gamecube, Xbox, and beyond basically require the official devkit (or derivations thereof) to get much use out of the hardware other than sound and 2D drawing. Complexity (and hardware bugs) grow up exponentially at this generation.

I once wrote a program that incrementally simplified 3D models, it would calculate the "cost" of merging vertices, and favor merging the lowest "cost" ones. It kept a sorted list and you could just keep doing down the list and picking the number of times to merge vertices, or go back up the list and restore the triangles.

And yes, the simplified model looked like crap.

But yes, this system did let you generate downgraded 3D models in real time.

Where I've heard the term "imposter" it was specifcally only referring to replacing a mesh with a textured card like that (or sometimes 2 cards in an X so you can see if from various angles without rotating it to face the camera). These are generally not used for animated characters, but for static things. Trees are the one I've seen use this most often.

But yeah, it's basically the end game of LOD reduction, but by the time you get to single quads you're probably batching/instancing a big group of things into a single draw call. With the huge overhead of any given draw call, unless you can group things reducing the number of vertices isn't a very good optimization by itself. (To go back to the example of trees; they're a good use case for this because they often come in groups, i.e. forests).


Yes, this is correct.

They couldn't even get Mario's nose the right size. Do other characters have downgraded models from far away?

@Espozo
When I started with 3d, I read through a few OpenGL books (the official one, the shader one, and the superbible), then played around with Irrlicht. Irr is very easy to start with, try playing around with that to get familiar with 3d. It doesn't take many lines to load a Q3 level and then run around in it.

Enemies don't even spawn until you're within a certain radius, so I wouldn't expect it. I didn't expect Mario to do it either, though.

That seemed quite bizarre, almost seems to me like they were trying LOD at some point to see if it made a difference, and then forgot about it. Mario's probably the least effective character to put a low LOD on, since there's only ever one of him onscreen anyway, and he's almost never far enough away to trigger that! ?