If you haven't done so already, be sure to visit the Wiki Portal to read about how the wiki works. Especially the Ogre Wiki Overview page.
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
- Complete the DirectX 11 render system
- Terrain enhancements
- Texture streaming
- Animation frame callbacks
- Dual-quaternion skinning (covered by GSoC 2011)
- CHC/CHC++ Utility Framework
- Scene Manager: Hybrid tree
- Binary format support for scripts
- A unit testing framework (covered by GSoC 2011)
- Off-Screen Particles
- Consolidate Common OpenGL Functionality
- Network-streaming rendering system
Complete the DirectX 11 render system
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)
Animation frame callbacks
- 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)
Dual-quaternion skinning (covered by GSoC 2011)
- Implement dual quaternion skinning as an option for hardware skinning
- Expose support for this in vertex programs
- RTSS implementation for generating shaders
- 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
CHC/CHC++ Utility Framework
- 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)
Scene Manager: Hybrid tree
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.
Binary format support for scripts
Serializing materials, shaders, particle systems, compositor chains and such to a binary format. Meshs are a good example of what we aim to.
A unit testing framework (covered by GSoC 2011)
An infrastructure that will enable us to define tests for OGRE and run them one after the other so we will know that status of the version, because OGRE is mainly graphic - a part of the infrastructure will be to enable running the test in a "record" mode to record a positive state - and take a screen shot, this screen shot will be compared to the result of the same test running in "test" mode.
Implement "GPU gems 3. Chapter 23. High-Speed, Off-Screen Particles" - http://http.developer.nvidia.com/GPUGems3/gpugems3_ch23.html
Consolidate Common OpenGL Functionality
There is quite a bit of code that is duplicated between the OpenGL render systems(GL, GLES, GLES2). Keeping this common code in sync and up to date with new features is prone to errors and getting more difficult. It would be very helpful to pull any shared code(there is a lot) into its own library to be used as a base that all GL render systems descend from.
Network-streaming rendering system
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.
The content on this page is licensed under the terms of the Creative Commons Attribution-ShareAlike License.
As an exception, any source code contributed within the content is released into the Public Domain.