[Submitted: GSoC 2008] Different LoD strategies

[KamiKage]

Hello everyone, although I read the forums for some time now, it's actually my first time posting (just registered too^^).

I posted an application on GSoC 2008 and Tuan Kuranes though it would be better to stop by and ask for feedback. So I will share my application with you and I hope to receive some criticism that may make it evolve.
Thanks for your time.

==============

[Introduction]
OGRE currently uses a Discrete Level of Detail (DLoD) system in order to maximize the rendering process’ performance while sacrificing little details. Its LoD management is solely based on the distance of the Entity to the camera and, as such, has received some criticisms. Although it is a computationally efficient method, there exist some problems into not taking in consideration the viewport size and the field of view (FoV). Concretely, an Entity LoD doesn’t change automatically if a FoV change occurs (as in zooms). Furthermore, Entities close enough to the camera will be rendered at a higher LoD even into smalls viewports, which would result into Meshes that are just a few pixels big. Another issue with this technique is that would apply the same LoD for big and small Meshes given that they are at the same distance. Although some of those problems can be corrected by changing the camera bias factor and setting correct distance for each Entity’s LoD, it would be for the better if a more automatic way was available.

[Motivation]
Take for instance a racing game. The player would control a car from the inside and be able to see what is behind him through a rear mirror. One way to do this would be to set a camera looking backward and make it render into a small viewport which would represent the mirror.
This situation would, with no further tweaking from the programmer, render all the entities within the mirror with the same LoD as if they were seen from the front of the car. The problem is that the mirror itself is pretty small and the player wouldn’t be able to tell much of a difference if there is a bit more detail in the mesh or not.
Nevertheless, there are some others strategies that yield better results – while requiring no further tweaking. One of them is based on the actual size that a mesh has on screen. This particular technique would overcome all the weakness of the distance-based strategy [1].

[Proposal]
Our first step towards correcting those issues will consist into studying a possible way to extends OGRE LoD management framework so that it can support multiple strategies and others LoD-related enhancements: a LoD listener and a SubEntity visibility range.
Also, we will create a new strategy based on the Mesh’s approximate pixel size. The point is to fix flows existing in the distance strategy while keeping it fast.

[Implementation]
In order to calculate an approximate pixel size for each Entity we will use the viewport size, the camera FoV, the Entity’s distance and its bounding sphere. All of those are already available in the current LoD management used by Ogre (in Entity::_notifyCurrentCamera()).
Furthermore the whole management process will be redesigned to fit an extensible architecture. A good challenge for the first phase would be to think of a way to standardize the strategies results (squared distance is not compatible with a Mesh pixel size on screen) in order to retrieve the correct LoD. From here we will call the strategy result a LodValue.
Some other implementation details:
- we should be able to set a default strategy;
- we should be able to set the tuple <Camera, Viewport> to a specific strategy. What this means is that for a given camera, rendering into a given viewport, the chosen strategy would be used; *
- the actual API should stay the same. It would use the distance-based strategy as default;
Some new methods would be necessary:
- Entity::selectLodStrategy(Camera, Viewport, LodStrategy) – would do what was stated above;
- Mesh::createManualLodLevel(LodValue, …) – would be the same as it is now, but would accept generic LoD values;
- Mesh::generateLodLevels(LodValueList, …) – would still generate the mesh LoD in the same way but for generic LoD values;
- Would also imply rewrite more generic methods (get/set) for all involved classes (including material);
As for the LoD listener, when an Entity change its LoD a callback would be triggered:
- LodListener::lodChanged(Camera, ViewPort, Entity, …) – those three parameters should be essentials. More should be added to simplify (or avoid to repeat) some calculus;
SubEntity should be given a visibility range. That information would be stored in the Entity so that unnecessary calls might be avoided:
- Entity::setSubEntityVisibilityRange(SubEntity, LodValue start, End LodValue end, …) – more parameters should be needed. Position for a distance-based check and a radius (bounding sphere) for the pixel-size strategy;

[Benefits to OGRE]
OGRE is designed to be extensible. In pretty much every aspect this is true, yet we could say that OGRE’s LoD features could still improve toward this goal. What this proposal is aiming for is to give OGRE’s users more flexibility through its own design principles.

[Plan]
1) [Till May 26] Discussing actual ideas with the community and getting feedback. At the same time, study possible ways of:
i. Extending the actual LoD management framework
ii. Supporting multiple strategies
iii. Enabling a LoD listener
iv. Supporting SubEntities visibility range
2) [Till June 23] Extend the framework (1.i and 1.ii), implement the pixel size strategy with bounding spheres and reimplementation of the distance strategy into the new framework. Documentation and Testing.
3) [Till June 30] Comparison of the developed solution against the actual one in terms of performance. Check of the overhead introduced by the new solution. Evaluation of Pros and Cons. Discussion of obtained results with the community.

From here on the plan depends on the feedback and test results. “aâ€

[tuan kuranes]

I wonder if you could check the Lod listener question as well ?

[Assaf Raman]

It will be also useful for me is to define for each submesh of a given mesh – "a start seeing it distance", "an end seeing it distance" and "a point to check the distance to the camera". Very similar to the way it is done in openflight.

[KamiKage]

Tuan Kuranes: I did read thoroughly the link you provided and I will consider it when thinking about how to extend the actual LoD management.

Assaf Raman: I think that your idea might actually be linked with the LoD listener that Tuan suggested. I would just change your "distance" definition into a more generic one that would fit a more common way to check LoD. Maybe a "start LoD-level" and "end LoD-level" so that it could be updated depending on the current LoD-level given by the callback.

[Assaf Raman]

Is "LoD-level" an integer or a real value?

[KamiKage]

Is a real value needed for anything? Being a discrete LoD I think that a Lod-level would naturally be integer but I might forget (or not even think about) something.

[Assaf Raman]

If I want to use different LoD for different parts of the same mesh - depending on the distance (or size in pixels) of the part (submesh) - describe how do I do that with your idea?

[KamiKage]

You won't, I was thinking about it in the wrong way ^^ Just though about that too.

Edit: well not exactly about what you said, but what I was initially thinking would fail even for 2 distinct mesh as they both could set the meaning of a specific LoD-level to differents "distances" or "pixel sizes". So the callback really has to return a value that means something to the mesh. I will think a bit more about it.

[KamiKage]

Tuan, I have a small question about the behavior of the LoD listener you mentioned. Let's say that the same entity is rendered into two viewports but with a different LoD. How should it behave? simply inform the listeners of the two changes?
Camera could even be the same for different viewports, so the only distinction here is in which viewport an entity is rendered. Or am I missing something?

[tuan kuranes]

I think Lod bias is attached by camera rather than viewport.

Anyway, you have something to take account of that is similar, it's that as per camera multiple pass can be done with different perspectives (n shadow pass * m light).

So multiple camera and multiple pass has to be taken in account, callback giving user the camera and current render queue type.

Don't forget to post/edit any new planning and task list or update your application/first post, so that it gets more clear.

Have a look at addons like pagedgeometry to have real world 'use case'.

[KamiKage]

As the application deadline was extended I took a bit more time to review the third iteration. Any criticism continue to be welcomed
Thanks again for your time.

[yumok]

If I want to use different LoD for different parts of the same mesh - depending on the distance (or size in pixels) of the part (submesh) - describe how do I do that with your idea?

That's what I was thinking. If a mesh is soo big that you want to LoD it by parts, do you have to split it into many meshes?

My example would be a full planet with detailed geography. How do I make it to render a nice geography of the part of the planet the camera is close to, while using a low LoD on parts that are far from the camera.

Many thanks,

[Klaim]

If a mesh is soo big that you want to LoD it by parts, do you have to split it into many meshes?

How did they do in Shadow of the Colossus?

[Kencho]

I would suggest that to be enabled/disabled in a per-entity basis. That might be a nice feature in mecha- or golem-like meshes, where the joints are quite clear (they have loads of seams), but splitting a human body mesh (for instance) might present holes if for example the upper arm has a different LoD than the lower arm (I can visualize clearly the holes in the elbow area).

[Zeal]

How did they do in Shadow of the Colossus?

Best game I have played in years! To answer your question...

http://edusworld.org/ew/ficheros/2006/p ... _sotc.html

The colossus is staggeringly large, but we did not use a LOD system based on view distance like the landscape because there was no memory to spare. We use the high accuracy model even when it is far away.

*heh of course their reasoning was - 'we have no more memory'!