Lod strategies

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4077
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 231
Contact:

Lod strategies

Post by dark_sylinc » Sat Nov 30, 2013 4:37 am

I'm close to finishing the 2.0 LOD branch and merging it back to 2.0
The only loose end I'm wrapping up are lod strategies.

This post is more "I'm informing you" rather than "I'm opening a discussion for this", so I apologize for this.

Ogre 1.9 allows for different LOD strategies to be used by meshes and materials (Distance based, absolute and relative pixel-count based, etc)

Initially, I just wanted to drop them all and just use distance, but deep in my heart I knew that was a bad idea and a step backwards; so I supported them all.
With one caveat: In Ogre 2.0; strategies are used globally. You can't have a mesh using a distance based strategy, a mesh using pixel count strategy, and a material using a pixel count one. All of them must use the same strategy.

This is because we parse them all together for performance reasons: There are no more needs to call the virtual function getValueImpl per object; and pixel based strategies gained tremendous optimizations:
Out of the following formula:

Code: Select all

(objRadius * objRadius * PI * viewport->getActualWidth() * viewport->getActualHeight() * projectionMatrix[0][0] * projectionMatrix[1][1] * bias) / distanceSquared
The following elements remain the same for all objects:

Code: Select all

PiDotVpAreaDotProjMat00dot11 = PI * viewport->getActualWidth() * viewport->getActualHeight() * projectionMatrix[0][0] * projectionMatrix[1][1] * bias;

//Per object
(objRadius * objRadius * PiDotVpAreaDotProjMat00dot11) / distanceSquared;
Not to mention we can check if the camera is ortho or perspective just once, and not once per object (which involves a branch!).

That's 5 less muls, but most importantly, much less pointer indirections (retrieving Viewport pointers, projection matrix, Math::PI); and looking at both code and assembly, there's practically no difference between distance and pixel count strategies, so I haven't benchmarked yet, but I expect them to have near equal performance (making the choice of Lod strategy a matter of taste or need, without worrying about performance).

But also very importantly: I believe consistency is also a serious matter; mixing multiple assets all with different Lod strategies is asking for trouble. It's hard to calibrate them to multiple monitor resolutions and aspect ratio if they're all inconsistent.
Forcing to choose one strategy allows having a consistent workflow through the development of a game or 3D project; and the team to implement good Lod practices.

Of course, there's always some people who will complain, and to them: I'm sorry.

There are also some minor changes. For example I consider making virtual both getValueImpl, transformUserValue and sort is overkill.
Pixel-count based strategies override sort because resolution areas should be in descending order (while distance based should be in ascending order). However if you can overload how to transform and calculate the value; you can just multiply them by -1 and keep negative values in ascending order (which is what I did).

Finally, perhaps the biggest change is that the Mesh serializer used to save the lod strategy method's name (since lod values are only usable by one strategy; and rarely can they be converted to a different one).
So on loading, it will just warn when the current global lod strategy set doesn't match the Mesh lod value data.

Any thoughts?
0 x

TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin

Re: Lod strategies

Post by TheSHEEEP » Sat Nov 30, 2013 12:16 pm

I'm always for simplifying things and making them more consistent, even if it means losing some minor flexibility (usability & performance > flexibility, IMO). Especially if the performance wins are that big.

As long as we can still have different distance values for each object (so one object might switch LoDs sooner than another), all is fine.
0 x
My site! - Have a look :)
Also on Twitter - extra fluffy

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 2

Re: Lod strategies

Post by syedhs » Tue Dec 03, 2013 7:43 am

I think pixel count strategy is always superior to distance strategy - because what really matters is the effective mesh size on the screen. Is there any reason why use distance instead of pixel count?
0 x
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me

al2950
OGRE Expert User
OGRE Expert User
Posts: 1200
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 76

Re: Lod strategies

Post by al2950 » Tue Dec 03, 2013 6:48 pm

syedhs wrote:I think pixel count strategy is always superior to distance strategy - because what really matters is the effective mesh size on the screen. Is there any reason why use distance instead of pixel count?
I have wondered this as well, as a result I see no problem with the changes dark_sylinc has made.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4077
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 231
Contact:

Re: Lod strategies

Post by dark_sylinc » Tue Dec 03, 2013 7:10 pm

al2950 wrote:
syedhs wrote:I think pixel count strategy is always superior to distance strategy - because what really matters is the effective mesh size on the screen. Is there any reason why use distance instead of pixel count?
I have wondered this as well, as a result I see no problem with the changes dark_sylinc has made.
I believe the same.
Without proper care, pixel count strategies can have issues when the object is partially visible by the camera (i.e. half the object visible, half the pixels); but AFAIK our implementation doesn't have this particular issue (i.e. like a 360° fov camera)
Another issue can be that when the object rotates, less pixels may be visible, which again our implementation assumes the shape of the object is a sphere, so we shouldn't see this artifact either.

Since both distance and pixel count strategies assume the shape is a sphere, it should be theoretically possible to convert Lod values between one system and the other and make them work exactly the same. However it's far more intuitive to work with pixel coverage than with distance to viewer.
It's like kg vs liters. One measures weight or rather mass, the other volume; but if given that gravity, pressure and surface's density are known; it should be possible to convert between kg & liters (in this case the unknowns are aspect ratio, FOV, near & far plane and resolution)

However if we were to lift the "shape of a sphere" assumption, other issues start popping out (like rotating the object: Different amount of pixels shown)
0 x

jonim8or
Goblin
Posts: 287
Joined: Mon Dec 08, 2008 4:49 pm

Re: Lod strategies

Post by jonim8or » Thu Feb 20, 2014 10:29 am

Interesting discussion on the LOD strategies and their applicability. However there is one strategy that would seem useful to me, that I haven't seen yet: bounding-sphere-size-on-screen-based
it differs from the pixel-count-based strategy, in that it does not take into consideration which part of the object is actually visible/drawn. So rotation or partial hiding don't cause sudden LOD switching.
it differs from the distance-based strategy in that objects can be scaled. So if a big and a small version of the same object are in view at the same distance, the big one will be shown detailed, the small one will be shown simple.
This also means that when you are drawing on a small window, you automatically draw the lower LODs, and on a bigger window you draw the detailed ones.

Optionally, one could have an ogre-wide "detail" setting, which is just a simple factor applied to the bounding-sphere-size-on-screen values, and which can be used to render lower quality meshes on lower-end systems.

Sorry that i am hijacking this thread a bit by coining an idea, it's just that I saw some experienced LOD users here...
0 x

Post Reply