Help please:Why perform lighting in WC?????

what do you think(or know)??

Markus
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Markus Pfau
Aachen-Germany

Marku...@post.rwth-aachen.de

Kind regards, Henning Semler

You can do lighting like this, and it is much faster.

You need to transform your light by the inverse of "object-to-eye",
then you can use the object normals without transforming them.

--

<\___/>
/ O O \
\_____/ FTB.

Those who do not understand Unix are condemned to
reinvent it, poorly. - Henry Spencer

In other words, you are asking if you can transform a light from WC
to VC, that is, replace a light defined in WC with a light defined
in VC giving exactly the same lighting results. The answer is yes,
as long as you limit your rendering to simple transformations and
simple lights. In the case of the transformations, there are no
problems with pure translations, pure rotations, and isotropic
scale transformations, but difficulties can arise with anisotropic
scale transformations and arbitrary 4x4 transformations.

Appropriate treatment of normal vectors must also be observed. The
transformed normal vectors will not necessarily be orthogonal to the
transformed surface. This is not difficult.

In the case of lights, there are no problems with "infinite" lights
(Iris GL), "directional" lights (PHIGS), "distant" lights (RenderMan),
or the equivalent in any other renderer. In this case, all light
rays are parallel and there is no attenuation. This type of light
can easily be transformed.

In the case of "finite" lights (Iris GL), "positional" lights (PHIGS),
"local" lights (RenderMan), or the equivalent in any other renderer, the
light source is located at a finite, possibly small, distance from the
objects being rendered. The light source may appear within the scene.

The effects of such lights typically include an attenuation factor
based on the distance from the light source to vertices. Anisotropic
scale transformations make it impossible (in VC) to calculate the
distance value (defined in WC) required to obtain the attenuation
factor, unless one transforms all coordinates back to WC, thereby
eliminating any advantage to pretending to do the lighting calculations
in VC.

In the case of "spot lights", problems become more severe. Such lights
may have attenuation and cut-off functions defined by circular cones
in WC. These cones are circular because the pattern of intensities
in any plane perpendicular to the direction of the light always has
circular symmetry (not square or elliptical, etc.). An anisotropic
scale transformation can squash this circular pattern (in WC) into
an elliptical pattern in VC. Unless one extends the definition of a
spotlight to allow elliptical intensity distributions, there will be
no (circular) cone in VC to produce the elliptical pattern implied
by the circular pattern in WC. In many cases, the added cost of the
extra generality needed to imitate a light in VC makes it easier to
just do the calculation in WC, as it is supposed to be done.

If you are writing your own personal renderer for your own personal
use, you could simply decide to disallow any of the things that cause
problems. If you are trying to implement or create an alternative
to an existing renderer, you would be in trouble because most rendering
libraries already permit the sorts of things you would need to forbid.
If you want to sell or distribute a new rendering library to others,
you may soon find users wanting to do the things you had forbidden.
In these cases, it is simply easier to stick with doing the lighting
in WC, like it is supposed to be done.

The cost of the view transformation tends to be pretty cheap anyway.
Most modern floating point processors are pretty good at this. They
are likely to be optimized for this. They love it like candy. The
performance killers are things like conditional branches, especially
floating point conditional branches (if the dot product comes out
negative, make it zero, ...), divides, float to integer conversions,
and exponentials (x to the power y, needed for specular highlights and
spotlight attenuation factors). Don't worry about the floating point
multiply and accumulate operations that take care of view and modelling
transformations.

I hope you find this explanation to be helpful.

Regards,

W. Luken

Hm... scale? How would you exactly go about xforming the light's WC
coordinates into object space, when the object transform has scaling
on it? You can't just use the inverse scale (1/scale) like you do with
the translation (-translation) and rotation (transpose of rotation).
I'm thinking about point lights, light located closer than inifite.

Example: a cube of vertices -1 and 1 in all axes, scaled by 1/2, and a
light at coordinate 2. The actual distance from the light to the
cube's closest face is 1.5, so the position of light in object space
would be at coordinate 2.5... But then there's the problem with the
angles between object's normals and ray coming from the light, which
to be right would have to be calculated with light transformed by the
inverse of the scale, that is, light at coordinate 4 in object space.

How is this done? Do I simply transform by inverse of scale, and scale
down all my lighting distances by the original scale (because the
light attenuation is calculated in world coordinates). Maybe I have to
transform the attenuation factors into object space too.

Yes, this is probably it. Explaining your problem can help in solving
it. ;-)

You got it. OTOH, if the scaling is anisotropic (for example, 2 for
x and 1/2 for y), you are stuck and the attenuation factors cannot be
transformed.