20,741
edits
(→Status) |
m (→Use Cases: https://sourceforge.net/p/flightgear/mailman/message/36339959/) |
||
Line 98: | Line 98: | ||
* [[Procedural Texturing]] | * [[Procedural Texturing]] | ||
* [[Shuttle ADI ball]] | * [[Shuttle ADI ball]] | ||
== FAQs == | |||
I started the Compositor to hopefully unify rendering in FG in the most | |||
non-radical way. Instead of changing a large part of the codebase like | |||
Rembrandt, the Compositor aims to bring the same funcionality and slowly | |||
deprecate parts of the FG Viewer code. | |||
=== Shadows === | |||
It includes shadows indeed. The Compositor stacks several passes of | |||
different types on top of each other, and exchanges buffers between | |||
them. Nothing prevents someone from creating a new pass type that | |||
implements a shadow map pre-pass. I've already tried myself | |||
successfully, but the problem is telling the pass which light should be | |||
used, which brings me to spotlights. | |||
=== Light Sources === | |||
Allowing aircraft/scenery developers to include "real" lights is a whole | |||
different aspect of the scene graph that shouldn't be managed by the | |||
Compositor. Some kind of system that exposes OpenGL lights should be | |||
implemented and linked to the Compositor. Some decisions have to be made | |||
though. In a forward renderer lights aren't as cheap as in a deferred | |||
renderer, so if the aircraft developer says there has to be a light | |||
there, someone using a forward renderer might see a performance drop or | |||
not see them at all. | |||
== Elements == | == Elements == |