Less Noticable LOD Fading

[Epifire]

Really random thought out of sitting around all day when I was thinking about horribly obvious detail models when they change with distance. So I had this thought of, why do a lot of modern engines not have view model fading?

Even in Unreal and other engines, I notice very distinct points when detail models load lower or higher poly models depending on your distance and wondered why there was not any kind of fading from one model to another? Now I had thought of processing constraints like what the cost of it would be if there was such an undertaking in a engine but I just thought I would put this forward for the opinions sake.

Then level of detail changes would not be as distinct with large poly count differences since you could also mask it under blur/heat effects (which would work best in open exterior environments). So just kinda asking if this has been done, or if people see the use in it as I do?

[Gary]

We got prop-fading. Look at prop_statics. But it's more expensive, so detail-props probably can't use it.

If you are mapper for L4D or later versions of the engine, LODs become less important on low-poly props.

[Epifire]

We got prop-fading. Look at prop_statics. But it's more expensive, so detail-props probably can't use it.

If you are mapper for L4D or later versions of the engine, LODs become less important on low-poly props.

Yeah I think I know what you mean, but if it were more standardized in newer engine builds you would not need as many LOD models. This would mean better file sizes since you wouldn't have to worry as much about meeting a visual gradiant. So less model versions is what you would gain out of it.

Small props that need no LODs would not have any benifit from this anyway so this would mainly be for large props seen in more vast distances.

[kraid]

If there would be any blending between LoD models, it would cause the exact oposite effect on performance.
Because two LoDs would be active at the same time more polygons would be rendered instead of less for the time of transition.

The pure fade-to-nothing on the other hand is allready there because it helps performance.

The usage of LoD models has been reduced to a minimum because every model that uses LoDs needs more work beeing put into it. So instead of creating 3-4 models a day, the artist would possibly only create 2 models in the same time. Also polygons are very cheap to render these days, so that there are even cases where artists add in more polys then neccessary for the shape, e.g. to be able to cut down the required texture space by mirroring or tiling parts.

[Epifire]

Interesting point. To make mine a wee bit more clear about the process I saw in it is that I would have the fade time around a second or two. That would act as a buffer time for some larger props so that the LOD would not be near as noticable to the player when it reaches points of transition.

I can see where this would cause problems in Source due to too much fading all at once, so I would most likely limit it to fairly large props where it would be most effextive. This is of course my view on it and may show other problems if put to the test. Personally I wouldn't mind seeing LOD fading in action to test this theory a little more.

[marks]

Fading between LODs means that you are drawing/rendering 2 different LODs at the same time which is WAY more expensive than only drawing one of them. And rendering speed is a lot more important than disk size usually - the memory usage of LOD geometry is super low compared to, say, 1024 or 2048 textures.

[nub]

Wouldn't tessellation be able to accomplish something like this very effectively? Granted it wouldn't be possible in Source since it's a DX11 feature.

[stoopdapoop]

That might be a challenge. With tesselation you start off with control points (which are basically verticies in a regular model) and then you can add polygons with the hull and domain shaders.

So in order for that to work, you'd have to author your content at the lowest level of detail, and tessellate it up to normal detail as you got closer.

Maybe a better method would be to render the current model to a plane, then render the new lod model behind the plane, disolve/fade away the plane over time or distance or whatever. If you add them to the same batch then you can save a draw call too.

Now I don't know if that'll actually be faster in practice, but something to think about.

[Mr. Happy]

I remember discussing this with some people for something and actually seeing an example, I think there is a game that does this for an interesting effect where doorways elongate as you get closer (going from being flat to being holes).

Supposedly that method didn't cost any more since (begin non-coder explanation) everything was done in the vertex shader so the transformation costs the same as if it's not transformed at all.

Maybe I misunderstood but it seems as if you could use the vertex data of the higher lod to move (based on an interpolation between the two) the lod's of the lower poly lod without costing any extra since you are still only rendering fewer polygons so your fills are cheap.

(end possible nonsense)

[nub]

Now I'm getting interested in seeing this in effect.

[zombie@computer]

I remember discussing this with some people for something and actually seeing an example, I think there is a game that does this for an interesting effect where doorways elongate as you get closer (going from being flat to being holes).

Supposedly that method didn't cost any more since (begin non-coder explanation) everything was done in the vertex shader so the transformation costs the same as if it's not transformed at all.

Maybe I misunderstood but it seems as if you could use the vertex data of the higher lod to move (based on an interpolation between the two) the lod's of the lower poly lod without costing any extra since you are still only rendering fewer polygons so your fills are cheap.

(end possible nonsense)

kindof like a bumpmap with a dynamic depth? sounds interesting

[Epifire]

Makes me wonder what DX version may be in the new Source 2 (if there is to be any). Many possibilities that may be availiable for some moddifications like this.

[Gary]

OpenGL ftw. Then, when dx12 comes out, you won't have to buy a new 120usd+ operating system.

[Epifire]

Wait why would we be buying a new OS?

[Gary]

Wait why would we be buying a new OS?

Directx11 required Vista and better. They can force more people to "upgrade" in order to access newer graphical features. Regardless of hardware. OpenGL is not tied to a specific OS, and supports all DX11 features.

Going off topic now... Sorry about that. But I do wonder what Valve plans on doing with their engine's graphics API support. Though the current engine supports both APIs right now, Directx for Windows/x360 and OpenGL for OSX/Linux/PS3(?). But really, what Stoop said makes the most sense.