I submitted this proposal to gSOC and would appreciate feedback and suggestions.
I'm quite new to the OGRE community. I have created several games in the past. Flash games, and then moved on to C/C++ and openGL.
I need some time to learn more about the OGRE source code, so if anyone has suggestions/improvements to how LOD in OGRE can be improved, and any details about implementations, -please post!
The aim of the proposal is to research and implement a more robust LOD solution than what is already in OGRE.
The current LOD system of Ogre only conciders distance from the camera and does not take into account the size of objects on the screen.
This proposal aims to improve the LOD system, so that zooming the camera or shrinking the viewport will have an effect on the level of detail of objects.
The implementation suggested is using the screen space of the bounding sphere to determine how big the objects are on screen. This would be a very fast and efficient method.
Another improvement is to add a generalized way of adding different LOD routines. A suggestion how this can be done is by adding a lod listener to the mesh objects, which will notify whenever there is a change to the LOD, allowing the user to create custom LOD routines.
One idea that I had for the LOD problem is to have a sizebias factor, which when set to a non-zero value, takes into account the bounding sphere screen size of the objects. The value of the sizebias (from 0 to 1) would then determine how much to take into account the size of the object.
This could also possibly introduce the new functionality without breaking the old.
(LOD could be a function of both screensize and distance)
LOD = (size*sizebias) + (distance*(1-sizebias))
LOD = distance
By taking the bounding sphere through the projection matrix, the screen space that the object occupies can be determined.
Currently it is possible to set the level of detail through "lod_distances" followed by a series of distances which will be assigned to a different "lod_index".
In addition to the idea above, I have also been playing with the idea of abondoning distance, for a mesh "LodSizeList" vector instead. The user would then set screen size thresholds for changing the LOD.
For the generalization and extended handing of LOD, the idea is to add an addLodListener() function to MoveableObject. A callback function will be called on the event of a LOD change, with the current properties (e.g. distance, camera, lodlevel) provided to the function. The user can then implement his own routines for dealing with LOD.
This is useful for example for turning off visibility of meshes, replacing with other meshes or billboards, or dealing with cases where the generic LOD behaviour must be extended, etc.
Suggested schedule: (dates are deadlines. university exams in early june, but can work out september).
1. Get familiar with OGRE, the source code and community. (1. June)
2. Research implementation solution to LOD problem. Provide definite plans. Cannot commit to any finished code, but should be able to make a modification to OGRE source code. Psedo code and a good plan for how the LOD strategies will actually be implemented. (1. July)
3. Streamlined contribution workflow. Done changing to the source code. Rudimentary LOD code. (15. July)
4. Having implemented plans from 1. July. Added working LOD improvement. e.g. at least LOD based on screen sized bounding sphere should be fully functional at this stage. (30. July)
5. Adjustments/improvements to previous code. Fully implemented solution. (15. August)
6. Testing and implementing response to feedback. Work on other features if done. (31. August)
7. Further contributions possible. (1. October).
I'd love to contribute to OGRE during gSOC, and I'd like my contribution to be appreciated by the community, so I'm happy to receive suggestions. Any additional features you'd like implemented that are realistic to do during gSOC?
Threads related to Google Summer of Code
1 post • Page 1 of 1
- Posts: 1
- Joined: Wed Mar 28, 2007 4:21 pm