GSoC New rendering system: Difference between revisions
From Spring
Jump to navigationJump to search
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
== What == | == What == | ||
Under this proposal, the rendering code should get a complete overhaul | Under this proposal, the rendering code should get a complete overhaul and moved into a Scene Graph. | ||
Allowing to replace the old code optionally with shader based approaches, including techniques as normal/relief mapping or 100% GPU based rendering of particles. | |||
== Required skills == | == Required skills == | ||
| Line 13: | Line 14: | ||
== Difficulty == | == Difficulty == | ||
Estimated: | Estimated: high | ||
== Technical details == | == Technical details == | ||
Latest revision as of 09:26, 8 March 2012
GSoC idea: New Rendering System
Why
Spring rendering engine includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.
What
Under this proposal, the rendering code should get a complete overhaul and moved into a Scene Graph. Allowing to replace the old code optionally with shader based approaches, including techniques as normal/relief mapping or 100% GPU based rendering of particles.
Required skills
- Knowledge of C++
- Knowledge of OpenGL 2.0 API
- Knowledge of GLSL
Difficulty
Estimated: high
Technical details
- 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)
- OpenGL ES 2.0 compatibility should be aimed at where possible.
