User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
mapping:cawe:lighting [2007-10-22 22:18] Carsten Augmented the text |
mapping:cawe:lighting [2007-10-28 23:36] Carsten Augmented the text |
||
|---|---|---|---|
| Line 24: | Line 24: | ||
| Good news about Radiosity-based lighting is that once the preprocessing step it complete, it is //fast//. Independently of the number of light sources or complexity of the scene, Radiosity-based lighting provides very good performance at run-time during the game. It is therefore a natural choice for large-scale base lighting of any level. | Good news about Radiosity-based lighting is that once the preprocessing step it complete, it is //fast//. Independently of the number of light sources or complexity of the scene, Radiosity-based lighting provides very good performance at run-time during the game. It is therefore a natural choice for large-scale base lighting of any level. | ||
| - | Even better, Radiosity lighting results looks stunningly good. No matter what hardware vendors tell you about their latest products, no matter what game developers tell you about dynamic lighting (as I too do, see below), none of these techniques can beat the realism of lighting generated by Radiosity methods. Based on an accurate physical model, the natural appearance of lights and shadows is unique to Radiosity methods. [Screenshots!, link to my thesis in See Also section] | + | Even better, Radiosity lighting results looks stunningly good. No matter what hardware vendors tell you about their latest products, no matter what game developers tell you about dynamic lighting (as I too do, see below), none of these techniques can beat the realism of lighting generated by Radiosity methods. Based on an accurate physical model, the natural propagation and appearance of lights and shadows is unique to Radiosity methods. |
| + | |||
| + | The Radiosity method also handles //area light sources// without special measures, but as a natural part of the algorithm. Area light sources are an important key feature, because they are the main contributors to a realistic lights and shadows distribution with diffuse reflections and soft shadows. | ||
| + | This is contrary to dynamic lighting, where lights are only points in space, soft shadows are always the result of some kind of trick, diffuse reflections are not possible at all, and a physical model is never involved. | ||
| For these reasons, Radiosity was the first lighting technique implemented in Ca3DE. | For these reasons, Radiosity was the first lighting technique implemented in Ca3DE. | ||
| - | * Radiosity lights are **area** light sources. | + | Here is an overview of the available Radiosity light sources and how they are created in a map: |
| - | * (whose irradiance is defined with the material), | + | |
| - | * radiosity point light source entities, | + | ==== Area Light Sources ==== |
| - | * sky light. | + | Any primitive (brush or Bezier patch) surface that you place in a Ca3DE map can be turned into an //area light source//. The key point here is that a surfaces characteristic of being an area light source is //not// :!: directly set in the Ca3DE World Editor CaWE. Rather, being an area light source is a //material// property. |
| + | |||
| + | That means that a surface becomes an area light source when it has a material applied to it which in turn is defined to emit Radiosity light. | ||
| + | |||
| + | As a mapper, if you want to find out if a material emits area light, its intensity and color, FIXME | ||
| + | |||
| + | ==== Point light sources ==== | ||
| + | Radiosity light can also be emitted from point light sources. | ||
| + | |||
| + | ==== Sky Light ==== | ||
| + | [ FIXME TODO: Screenshots!, link to my thesis in See Also section, link to DK project] | ||
| ===== Dynamic Lighting ===== | ===== Dynamic Lighting ===== | ||
| + | |||
| + | Dynamic lighting has become popular with the advent of hardware-acceleration for 3D graphics in the recent years. | ||
| + | Its main properties/characteristics are that its computational steps occur //per-pixel// and //per-frame//. | ||
| + | |||
| + | //Per-pixel// means that.. FIXME | ||
| + | |||
| + | //Per-frame// refers to the fact that all lighting computations occur only at runtime, and in fact, they are performed for each rendered frame anew. This allows both light sources and lit objects to move arbitrarily through the scene, with the lights and shadows being updated correctly and instantaneously. | ||
| * hardware accelerated. | * hardware accelerated. | ||
| * dynamic light+shadow entities | * dynamic light+shadow entities | ||
| + | |||
| + | ===== Spherical Harmonics Lighting ===== | ||
| + | |||
| + | Lighting with [[wp>Spherical_harmonics|Spherical Harmonics]] ("SHL") is an area of active research in computer science. Its goal is to combine the merits of Radiosity-based lighting with light sources that can move, especially when the light sources are very far away from the scene, like for example the sun or the moon. | ||
| + | |||
| + | SHL has been implemented in the scope of my diploma thesis in the Ca3D-Engine, but is currently not supported by the public releases. You may refer to the thesis linked below for more information. | ||
| + | |||
| + | |||
| + | ===== See Also ===== | ||
| + | |||
| + | * [[http://www.ca3d-engine.de/download.php?view.5|Methods for Real-Time Lighting]] -- Diploma Thesis by Carsten Fuchs. | ||
mapping/cawe/lighting.txt · Last modified: 2013-01-07 12:07 (external edit)