<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd">
<html>
<!-- Created by texi2html 1.76 -->
<!--
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
Karl Berry <karl@freefriends.org>
Olaf Bachmann <obachman@mathematik.uni-kl.de>
and many others.
Maintained by: Many creative people <dev@texi2html.cvshome.org>
Send bugs and suggestions to <users@texi2html.cvshome.org>
-->
<head>
<title>Crystal Space 1.2.1: 4.11.1 Lighting</title>
<meta name="description" content="Crystal Space 1.2.1: 4.11.1 Lighting">
<meta name="keywords" content="Crystal Space 1.2.1: 4.11.1 Lighting">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="texi2html 1.76">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
pre.display {font-family: serif}
pre.format {font-family: serif}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: serif; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: serif; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.sansserif {font-family:sans-serif; font-weight:normal;}
ul.toc {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Lighting"></a>
<a name="0"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="Lighting-System.html#0" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="HOWTO-Pseudo-DynLight.html#0" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="Using-Crystal-Space.html#0" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="Lighting-System.html#0" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="Working-with-Engine-Content.html#0" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="index.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="cs_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="cs_Index.html#0" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="cs_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<hr size="1">
<h3 class="subsection"> 4.11.1 Lighting </h3>
<p><em>Written by Jorrit Tyberghein,
<a href="mailto:jorrit.tyberghein@gmail.com">jorrit.tyberghein@gmail.com</a>.</em>
</p>
<p>Crystal Space supports three types of lighting: <em>static</em>,
<em>pseudo-dynamic</em> and <em>dynamic</em>. They are different in the ways you
can change their attributes while the engine is running. Static lights cannot
be changed at all, but produce best performance and least memory consumption.
Pseudo-dynamic lights can change their color and brightness, but not their
position. Dynamic lights can also change their position.
</p>
<p>In the interest of accuracy, it is actually possible to change the so-called
“unchangeable” attributes of static and pseudo-dynamic lights, but after
doing so, it is necessary to perform time-consuming recalculation of lightmaps
in order for the changes to be reflected in the rendered world.
</p>
<p>Every light has a position in world space coordinates and a current
<em>sector</em>. Every light also has a radius (expressed in squared distance).
This radius indicates where the light levels of the three light tables will
reach zero.
</p>
<a name="1"></a>
<h4 class="subsubheading"> Static Lights </h4>
<p>This section gives a very brief explanation of the static lighting system used
in Crystal Space. <strong>Warning</strong>: <em>Although the basic principle
described here is still valid, much more is going on now. This document needs
to be updated to reflect the current state of the engine.</em>
</p>
<p>Static lighting is based on <em>lightmaps</em>. These are like textures except
that every pixel defines the combined brightness of all lights at its
position. Before the rendering loop starts, these lightmaps are precalculated
so there is little performance loss at runtime, where we only need to blend
texture and lightmap of a polygon.
</p>
<p>Lightmaps are calculated as follows:
</p>
<ol>
<li>
First initialize all lightmaps to black (or the ambient color).
</li><li>
For every light in the world generate a view frustum as seen from the position
of that light. The frustum is defined as a set of 3D polygon or light
patches. Every light patch is clipped against the relevant portals until
nothing remains (light patch becomes empty). Every light patch in this
frustum is in fact a projection of the light on the normal polygons. It is in
that area that we need to update the lightmap for every polygon.
</li><li>
For every polygon that was hit, cast beams from the light to every lightmap
point on the polygon (lightmap points are often defined every 16 by 16 texels
although you can change this value if desired). We know that in principle the
beam of light should reach the polygon since the light patch gives the
boundary of where the light can reach the polygon. But the frustum was
generated ignoring Things. So it is possible that there is a Thing blocking a
specific beam of light. We need to test for that.
</li><li>
If there is a successful hit then calculate the distance between the light and
the point on the polygon and update the intensity there.
</li></ol>
<p>To create the three lightmaps for every polygon a 2D bounding box in texture
space is calculated. This defines a rectangle that overlaps with the texture
on the polygon and is correctly aligned with it (so that every 16 by 16 texel
grid has one lightmap position). A consequence of this is that rotated
textures can waste a lot of lightmap space. For example, see the following
polygon:
</p>
<p><img src="usingcs/lighting/light1.png" alt="usingcs/lighting/light1">
</p>
<p>And assume that the texture is aligned horizontally. Then we would need a
lightmap of the following size:
</p>
<p><img src="usingcs/lighting/light2.png" alt="usingcs/lighting/light2">
</p>
<p>Note also, that the texture in the texture cache will have that size.
</p>
<a name="2"></a>
<h4 class="subsubheading"> Pseudo-Dynamic Lights </h4>
<p>The pseudo-dynamic lighting system is an extension to the static lighting
system described above. Pseudo-dynamic lights can not move but you can change
the intensity or color. When some light is made pseudo-dynamic (a simple
flag) the processing is a bit different. The shadow-computation remains the
same but every polygon that is hit by the pseudo-dynamic light needs to have
separate lightmaps for every pseudo-dynamic light that hits the polygon. So
in the end all the polygons that are only hit by static lights have just one
lightmap (for the three tables) for all static lighting information. Every
polygon that is hit by one or more pseudo-dynamic lights will have one or more
extra lightmap tables for every pseudo-dynamic light and one extra for all
static lights. This information is then added together to result in the final
lightmap table that can then be used by the texture cache routine (as
explained earlier).
</p>
<p>The lightmaps for the pseudo-dynamic lights are stored without the strength of
the light. So where the light shines brightest the value in the lightmap will
be 255, and where it shines least bright the value will be 0. When combining
all pseudo-dynamic lightmaps and the static lightmap the strength of every
light will be multiplied with the distance value to result in the real
lightmap value. This also implies that there is only one extra lightmap for
every polygon/pseudo-dynamic light because the shadow information (which is
basically what is represented in pseudo-dynamic lightmaps) is the same for all
three light-tables.
</p>
<p>Here are some performance considerations for pseudo-dynamic lighting. There
is a memory penalty for every polygon that is hit by some pseudo-dynamic
lighting because extra lightmaps need to be created. So if you use no
pseudo-dynamic lighting you will suffer no penalty but if you use a very large
pseudo-dynamic light (with a large radius) it will probably hit a large number
of polygons and you will have a considerable increase in memory requirements.
</p>
<p>There is also a performance penalty whenever the intensity of a pseudo-dynamic
light changes. This is because all the textures for the polygons that are hit
by the pseudo-dynamic light need to be recalculated (they are removed from the
texture cache).
</p>
<p>If the intensity of a pseudo-dynamic light does not change there is no
performance hit at all.
</p>
<a name="3"></a>
<h4 class="subsubheading"> Dynamic Lights </h4>
<p>Crystal Space also supports true dynamic lights. These are rendered atop the
normal lightmaps as explained above and support colors and limited shadows.
</p>
<a name="4"></a>
<h4 class="subsubheading"> Shadow Calculation </h4>
<p>The algorithm to see if a given beam reaches a specific point on some polygon
works as follows. The beam is described as two vertices (<em>start</em> and
<em>end</em>):
</p>
<ol>
<li>
Start at the “sector” of the light.
</li><li>
If the current sector is equal to the sector of the polygon then there is a
hit, since all polygons of a sector are completely visible from anywhere in a
sector.
</li><li>
Otherwise, if the light is not in this sector, the beam could reach this
sector through a portal. Since the beam certainly ends at the polygon (this
is given, the start and end vertices define a beam that will—if not
blocked—reach the polygon) and the beam passed through portals to reach here
then the beam hits the polygon. So perform the following steps:
<ol>
<li>
Determine which polygon of the current sector intersects with the beam.
</li><li>
If the polygon is on the same plane as the destination polygon then there is a
hit. The reason this is true has to do with the fact that the lightmaps are
slightly bigger than what is really needed. Bilinear interpolation is used to
finally light the polygon and it has to be able to correctly interpolate at
the boundaries of the polygon as well.
</li><li>
If the polygon that is hit is a portal then recursively continue with the
following sector. If the recursive calls returns a hit then we have a hit.
</li><li>
If the polygon is not a portal there is no hit so return from the algorithm
(the beam of light does not reach the polygon).
</li></ol>
</li><li>
In all cases where a hit occurred according to the previous steps, arrive at
this step to check if there are no Things blocking the beam. For every Thing
in the current sector check if the beam intersects with one of the polygons of
the Thing. If so then there is no hit. Otherwise there is a hit.
</li></ol>
<p>A similar algorithm is used for Things.
</p>
<hr size="1">
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="Lighting-System.html#0" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="HOWTO-Pseudo-DynLight.html#0" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="Using-Crystal-Space.html#0" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="Lighting-System.html#0" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="Working-with-Engine-Content.html#0" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="index.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="cs_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="cs_Index.html#0" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="cs_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<p>
<font size="-1">
This document was generated using <a href="http://texi2html.cvshome.org/"><em>texi2html 1.76</em></a>.
</font>
<br>
</p>
</body>
</html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
bad97183153701b09df5fae1052b1c30
>
files
>
4202
