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
Code: Select all
PiDotVpAreaDotProjMat00dot11 = PI * viewport->getActualWidth() * viewport->getActualHeight() * projectionMatrix[0][0] * projectionMatrix[1][1] * bias;
//Per object
(objRadius * objRadius * PiDotVpAreaDotProjMat00dot11) / distanceSquared;
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?