This page lists a selection of tasks that are ‘nice but not essential’; things that would be useful but are not likely to be developed by the core team. If you’re interested in helping out and you don’t have anything specific in mind, pick something off this list and make a note that you’re working on it. Don’t add things to this list, these tasks are approved by the team. You can of course tackle your own choice of feature too, but we’re not guaranteed to support it unless you clear it with us conceptually in the forums first.
GSoC: There also is a dedicated page listing ideas for potential Google Summer of Code projects.
Table of contents
There is a fledgling DirectX 11 render system in trunk right now, but it needs plenty more work doing to it in terms of implementing recommended performance characteristics for D3D11 and some other gaps.
You’ll need a Vista\Windows 7-capable machine for this one. All new features must be exposed in such a way that they are options, with detection and fallback for non-Dx11 machines.
Per polygon material ID is now supported in DirectX11 which means exporters, importers and resource system and index buffers should support this.
Some other gaps are described in the current version roadmap.
OGRE has a new terrain system in 1.7 which is much better than previous versions. However there are features we’d like to add, such as:
- More material generators. Fallbacks for different cards, detail texturing, rayleigh scattering
- Vertex compression
- Optimization of the processed terrain page data file (covered by GSoC 2011)
Right now OGRE either loads a texture, or it doesn’t. The loading can be done in the background, but the entire texture with all mipmaps is always loaded. It would be nice to support a kind of internal LOD for textures, where smaller textures can be loaded in the distance and replaced automatically by higher detail textures closer up.
This feature should support:
- Loading just the lowest N precalculated mipmaps from a DDS file as a low LOD texture, then loading the upper mips into a new texture (copying the lower mips into it)
- Alternatively, loading the LODs from 2 different textures, or loading from one high detail texture and shrinking during load for the low LOD (the least favourable option)
- Background thread processing of the above
- Material / texture unit enhancements to support configuring the above
- Shaders for fading between low/high detail (RTSS)
- Enhance the .skeleton format to include frame events in animations
- Allow listeners to be registered on AnimationState to receive event notifications
- Events raised must be aware of interpolation (skipping over the event, time distances)
- Automating the process of creating imposters, ie rendering a sub-scene to a texture to use on a billboard to reduce rendering complexity. Should include detecting when the view needs updating due to the camera changing position, camera mirroring and multiple cameras.
- Impostor Geometry with Relief Textures
- Create an implementation of CHC/CHC++ that is usable with any hierarchical scene structure (ie not SceneManager specific, but usable from any hierarchical scene structure)
Hybrid tree implementation allowing for spatial partionning to be composed of various subtree part (octree, kdtree, aabbtree, quadtree) optimizing static geometry using best partionning possible.
Serializing materials, shaders, particle systems, compositor chains and such to a binary format. Meshs are a good example of what we aim to.
Implement “GPU gems 3. Chapter 23. High-Speed, Off-Screen Particles” - http://http.developer.nvidia.com/GPUGems3/gpugems3_ch23.html
Use case: Many monitors joined toghether to form one huge screen, where each monitor has its own PC/CPU. The different PCs now need to update the scene via the network...so stream the scene state. An example could be many screens forming a circle where the user stands in the middle and his/her movements/gestures should e.g. move the scene displayed on the screens around him.