nesdev.org

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...

rainwarrior wrote: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.

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

rainwarrior wrote: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.

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.

rainwarrior wrote: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.

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.

Espozo wrote: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.

rainwarrior wrote: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).

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.

rainwarrior wrote:LOD systems is something for new machines, not old ones.

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

Espozo wrote:

rainwarrior wrote: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).

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.

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

Espozo wrote:

rainwarrior wrote:LOD systems is something for new machines, not old ones.

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

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.

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

I mean, I thought it would be on everything.

rainwarrior wrote: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

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...

Espozo wrote: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

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?