SoC2008 LOD         Different LOD Strategies - GSoC 2008

Summer of Code 2008: Different LOD Strategies

Student: Christopher Bowen (Lostera)

Mentor: Andres Carrera (Lioric)

Location: TBD

Status: In Progress


More Information: Ogre Forums Topic


In determining what level of complexity to use in representing 3D objects, OGRE currently implements only one approach, a level of detail strategy based on entity distance from the camera. In this implementation, each level of detail for a mesh has an associated reference distance. However, there are several drawbacks to this approach. It does not account for changes in camera field of view (for instance, when zooming) or viewport size. Multiple methods have been proposed to solve these issues. Of these, the simplest and fastest is to estimate the pixel count by projecting the bounding sphere, replacing the reference distance for each level of detail with a reference pixel count.


  • Extend the level of detail system to allow for multiple strategies while continuing support for assets using the current strategy. This would provide a flexible framework for implementing alternative strategies.
  • Within this new system, implement a pixel count approximation strategy which provides more appropriate level of detail selection for a variety of viewing conditions. This strategy would estimate an entity’s pixel count by projecting the bounding sphere; each level of detail for a mesh would have an associated reference pixel count.
  • Change the automatic level of detail generation to utilize the new strategy.
  • If the community concurs, I would also like to provide a means to address the drawbacks for assets using the old system by allowing the user to set the assumed field of view and viewport size upon which the reference distances were based. From this information, an appropriate correction bias would be calculated to automatically correct for other field of view angles and viewport sizes.

Tentative Schedule

Discuss with community the desired mechanism for allowing multiple strategies. In particular, decide if an abstract LOD strategy class is desirable even if it is associated with a performance penalty. The primary benefit of this method would be the ability to add additional strategies from plug-ins through the use of factories. The simpler and faster implementation would be a basic conditional in the LOD calculation. This step will be completed before coding begins.
Modify the mesh and entity subsystems in the current LOD system to allow for multiple strategies. The precise timeline for this step depends on the design chosen by the community and will be supplied before coding begins. This will be the longest individual step in the process as a lot of existing code relies heavily on the current implementation. Upon completion of this phase, I will make the first release available for testing and design evaluation.
Develop and implement a test plan for the completed changes and make corrections for any identified problems.
After testing on new system is complete, I will implement the new strategy. Unless precision issues arise, this will be a fairly simple operation and a working release should quickly be made available for testing.
Once the new strategy is in place and functional, existing parts of the engine can be made to utilize it. In particular, the automatic LOD generation should be modified to use the improved strategy.
Develop and implement additional testing for the added features and make corrections for any identified problems.
With these modifications in place, new assets are no longer subject to the drawbacks of the previous system, but older assets, while usable, retain the problems. This can be remedied by implementing a method to automatically bias the LOD based on the reference field of view angle and viewport size used when determining reference distances.
Develop and implement final testing, make corrections, clean up code, and finalize documentation.


Added LodStrategy class and corresponding functionality for mesh level of detail. Implemented old (distance based) strategy. Initial work begun on new mesh serializer.
Incorporated LodStrategy into Material and modified both serializers to handle this information. LodStrategy is now utilized for material LOD.
Merged in LodListener work and modified to function with new system.
Added some additional LodListener functionality and extended LodStrategy usage to instanced geometry.
Extended LodStrategy usage to static geometry (with a few changes to instanced geometry).
Added handling for new and changed fields in XMLConverter.
Better support for lod strategies in XMLConverter and a few other bugfixes.
Implemented pixel count approximation strategy.
Added default strategy to strategy manager as suggested on the forums.
Added reference view functionality for distance lod strategy.
Additional testing performed.
Added user value transformation functionality, so squared distances are no longer required in many places.
Added support for separate lod camera (mostly just merging in Sinbad's work).
Cleaned up code and improved documentation.

Porting Notes

Unfortunately, this project makes fairly large changes to the way Ogre handles LOD, and while I've tried to maintain backwards compatibility where practical, there are a number of changes to keep in mind when porting to the new system.

  • Removed Mesh::getLodIndexSquaredDepth.
  • Mesh::getLodIndex now requires a squared distances when using DistanceLodStrategy.
  • Renamed MeshLodUsage::fromDepthSquared to value.
  • Renamed LodDistanceList to LodValueList and LodDistanceIterator to LodValueIterator.
  • Material::getLodIndex now requires squared distances when using DistanceLodStrategy.
  • Renamed Material::mLodDistances to mLodValues.
  • Renamed Material::getLodDistanceIterator to getLodValueIterator
  • Removed Material::getLodIndexSquaredDepth as it no longer applies.
  • Renamed Entity::_getMeshLodFactorInverse to Entity::_getMeshLodFactorTransformed as this method does not neccessarily return the inverse anymore (but will when using DistanceLodStrategy).
  • Renamed InstancedGeometry::BatchInstance::mCamDistanceSquared to mLodValue.
  • Renamed InstancedGeometry::LODBucket::mSquaredDistance to mLodValue.
  • Renamed InstancedGeomety::LODBucket::getSquaredDistance to getLodValue.
  • Renamed StaticGeometry::Region::mCamDistanceSquared to mLodValue.
  • Renamed StaticGeomety::LODBucket::mSquaredDistance to mLodValue.
  • Renamed StaticGeomety::LODBucket::getSquaredDistance to getLodValue.
  • Added LodStrategy argument to MeshSerializerImpl::writeLodSummary.

Possible Additions

While the scope of this project was initially limited to improving the accuracy of lod calculation, there have been other lod related features suggested. Time permitting, these features may be implemented once the requirements outlined in the initial proposal are fulfilled.

  • Lod listeners: This has already been completed, but was not part of the original proposal. This listener interface allows notification and some measure of control for lod changes.
  • Lod relative camera specification: This has also now been completed by Sinbad and merged in. Allow lod calculations to be performed relative to a camera other than the current one. This would be useful primarily for shadowing to ensure that entities in the shadow map are rendered at the same lod as in the viewport. For anyone interested in pursuing this feature now, the implementation would probably involve the addition of a MovableObject::_notifyCurrentLodCamera or similar method parallel to MovableObject::_notifyCurrentCamera. Any reference to _notifyCurrentCamera would probably require an additional call to _notifyCurrentLodCamera, particularly in SceneNode::_findVisibleObjects. SceneManager::_renderScene, SceneManager::_findVisibleObjects, and SceneNode::_findVisibleObjects would probably all require an additional camera parameter. Current calls to SceneManager::_renderScene would need to be supplemented with an lod camera, usually the same camera as is currently being passed to it except when rendering a shadow map. I'm sure other modifications would be necessary, but this should get anyone interested started.