GSoC New rendering system: Difference between revisions

From Spring
Jump to navigationJump to search
New page: = GSoC idea: New Rendering System = == Why == Rendering will be faster and more extensible, making it easier to bring in new features and players. It should help prevent Spring's visuals ...
 
Jk (talk | contribs)
 
(17 intermediate revisions by 6 users not shown)
Line 2: Line 2:


== Why ==
== Why ==
Rendering will 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.
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.


== Background ==
== What ==
The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.
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.
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 trough direct load 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 ==
== Required skills ==
* Knowledge of C++
* Knowledge of C++
* Knowledge of OpenGL 2.0 API and GLSL
* Knowledge of OpenGL 2.0 API  
* Understanding Spring's sync system
* Knowledge of GLSL


== Difficulty ==
== Difficulty ==
Estimated: below medium
Estimated: high
 
== Technical details ==


* Refactor C++ code and classes
* Refactor C++ code and classes
Line 23: Line 22:
* Add threading to renderer
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs)
* 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.
* 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)
* Use more class overriding for new rendering code (instead of branching)
* Resolve some long-standing bugs, particularly for ATI cards
* OpenGL ES 2.0 compatibility should be aimed at where possible.
 
== Possible Mentor(s) ==
 
[http://www.example.com FORUMLINK]


[[Google_Summer_of_Code_2010]]
[[Category:GSoC]]

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.