LOD blending

[Ian]

This is the only thing currently missing from the rendering engine. And I never implemented it because I could never figure out how it worked exactly.
The real3d pro-1000 has 4 possible level of detail models, and a table of values where these models fade in/out. It's supposed to be a distance table, or possible angle table, but I could never get the values to work exactly. They were always off by some factor. Currently we always render the highest poly models. But some games are using this table to do blending effects we currently don't support.

Anyway I had some sort of epiphany whilst thinking about other stuff. I did note before the blending seemed to change with the FOV of the camera, which kinda makes sense. If the FOV is narrowed you zoom in.
Anyway with a 45degree field of view, the ratio between the distance and the horizontal is the same. But if you narrow the FOV this ratio changes .. anyway there must be some formula to calculate distances for this.

And googling around I found this
https://digitalrune.github.io/DigitalRu ... 4cb032.htm

distancenormalized = distance * tan(fovY / 2)

where fovY is the camera's vertical field-of-view.

In other words, the view-normalized distance is the camera distance times a camera correction factor. The correction factor accounts for the camera field-of-view. The resulting value is inversely proportional to the screen size of the object and independent of the current field-of-view. It can be used to specify LOD distances or similar metrics.

Note that tan(fovY/2) is 1 if the fovY = 90°. This means that distance and view-normalized distance are identical for a camera with a vertical field-of-view of 90°. (This 90° FOV camera is the "reference camera".)

The view-normalized distance is only defined for cameras with perspective projections. The result is undefined for orthographic projections!

Anyway I might give this a go to see if it works

[Bart]

Cool! Two questions:

1. Do we know of any games using the LOD mechanism for something other than LOD? That is, using this feature to display completely different models as part of some other effect. This could help validate your results.

2. How does modern LOD blending work? At the transition point between LODs n and n-1, what happens? One strategy would be to have a hard threshold where either one or the other is rendered. The Real3D specs seem to suggest some sort of smooth blending. Is there a region where both models are rendered with alpha? That would make things more taxing for the hardware.

[Ian]

1. Do we know of any games using the LOD mechanism for something other than LOD?

Yes ocean hunter and emergency call ambulance are abusing the LOD table to add transparency to rom models.

That is, using this feature to display completely different models as part of some other effect.

In the example code there is something like this. It blends between 4 completely different models. But it's just for a test really, I don't think (or know of) any games that are doing this.

2. How does modern LOD blending work?

I don't really know, maybe they don't blend between models at all. To do transparency for models means you have to do a depth pass first, otherwise parts of the model will overlap. The model3 doesn't need a depth pass because transparent polys are rendered to a separate frame buffer layer, which automatically overwrites lower depth values.

[Ian]

Just documenting this here ..

[Bart]

I did some quick Googling. Modern LOD blending is typically implemented with stipple transparency and, yes, it does increase rendering load during the transition phase because two models are being rendered. Modern games may choose to dynamically disable blending and suffer the consequences of sudden pop-in during performance-intensive scenes. Modern implementations will have a shader that implements some sort of a stipple pattern (not necessarily a uniform one but some dithered pattern) that gradually passes through more of the next LOD's pixels.

If you do some Googling you can find images of this technique being used in modern games like Assassin's Creed 3:



There is also fancier geometric blending which involves pushing vertices into the equivalent points in the lower LOD mesh and then smoothly interpolating them to their actual positions but this is difficult to set up and in practice only done for terrain LOD.

I'd bet that some sort of stipple system is used on Real3D. They probably have some hard-wired set of patterns that they select based on how far within the blend they are.

[Ian]

It could be using stipple alpha
But I think it's much more likely it's doing the model transparency and rendering to the alpha layer. I mean the hardware can already do this ...



Doing at at least 8 levels of transparency there with the different ambulances. In supermodel currently they all look opaque.

[Ian]

Star wars is making heavy use of different LOD models
I am pretty sure there is no actual blending going on between the different levels themselves. Although the last level definitely fades out.

Level 3?


Level 2?


Look at the dome thing towards the right. This is about 1 frame apart.

[Ian]

FOV calculations

A useful rule of thumb: an object will appear twice as tall and twice as wide if the camera-to-object distance is halved. This is true for any FOV. This may be helpful when working with LOD distances such as making LOD Models, MIP Mapping textures, and setting Fade Distances.

To calculate actual screen pixels is usually unnecessary, but quite straight forward:
The trick is to bisect the "FOV" and use simple trigonometry to convert the Angle to a ratio of : FrameWidth / Distance = 2 (tan (FOV/2). So for the Player's 75° FOV, the FrameWidth = Distance * 1.535.
This represents how much the Frame's dimension increases with distance - which is very useful in itself. But we want to know how an object "shrinks" (relative to the frame) over distance, so our ObjectScale is the inverse of the FrameScale, ie : 1/ (2(tan (FOV/2))). For the Player's 75° Angle of View, the ObjectScale is 1/1.535 == 0.652.
An object which is 8 units wide and 512 units away from the Player covers ObjectScale * ObjectWidth / Distance == 0.652 * 8 / 512 = 1% of the horizontal FOV, which is 1% of the horizontal screen resolution.
Now, if you half the distance or double the size of the object, it will cover 2% of the width of your screen.
If your horizontal screen resolution is 1600 pixels, 1% of 1600 = 16 pixels, 2% = 32 pixels, etc.

If the ObjectWidth is the same as the Distance, then (for Player's 75°) 0.652 * 1/1 = 65%, which is close enough to remember : 64 unit wide object viewed at 64 units distance covers 64% of the screenwidth.
For 90° Angle of View the ObjectScale = 0.5.
If you want it all in one formula (which is much less handy) : ObjectScreenWidth = ScreenResolution * ObjectWidth / (ObjectDistance * (2 tan (FOV/2)))

from https://developer.valvesoftware.com/wiki/Field_of_View

might prove useful to solve this problem

[Bart]

Nice If I can find time toward the end of summer to rig up a way to easily transfer code to the Model 3 there is a chance we could test this sort of stuff.