GSoC New rendering system: Difference between revisions
| Line 5: | Line 5: | ||
== Background == | == Background == | ||
The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible. | The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible. | ||
The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.) | The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.) | ||
Revision as of 23:13, 11 March 2010
GSoC idea: New Rendering System
Why
Rendering would be faster and more extensible, making it easier to bring in new features and players. It should help prevent Spring's visuals become 'dated' compared to commercial games running DX11 or OpenGL 3.1. It may eliminate some long-standing rendering bugs.
Background
The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible.
The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)
OpenGL ES 2.0 compatibility should be aimed at where possible.
Required skills
- Knowledge of C++
- Knowledge of OpenGL 2.0 API and GLSL
- Understanding Spring's sync system
Difficulty
Estimated: below medium
- Refactor C++ code and classes
- Create new GLSL shaders and integrate some from Lua scripts
- Add threading to renderer
- Remove all direct OpenGL calls from synced (sim) code.
- Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
- Reduce/refactor the amount of code paths used for rendering different world objects and model types.
- Use more class overriding for new rendering code (instead of branching)
