Re: Experimental additions I want feedback for...

[Kevin Harris]

On Thu, 28 Sep 2000, Carlos Jimenez Moreno wrote:
> On Wed, 27 Sep 2000, you wrote:
> > I've added area lights by means of an 'emission' pattern for every
<snip>
> 
> emission pattern ?? I am working in a MonteCarlo render and I have
> area light without that:
>  -With the emission parameter in TMaterial (class parameter tSelfEmission)
>    we can control the material emission intensity.
>  -A random point over the object surface for next event estimation and you 
> have
>    area lights.
> What functionality is added with the emission patters?
Currently, there is a pattern for color, opacity, ambient reflection,
diffuse reflection, specular reflection, and caustics.  Having a single
number to represent the light emission of an object would only allow a
light to emit some scalar multiple of what was intended only for
reflection. 

What if an object is to emit some amount of light that varies,
yet reflect different light that hits the surface (both diffuse and
specular)?  An example of an object like that would be one of those flat,
rectangular night lights that glow a 'cool blue'.  They emit light, yet
when it is brighter in the surrounding environment, you can see specular
and diffuse reflections on the surface (along with the emission).  The
ability to emit a different pattern than that being reflected from
external light sources would allow such effects.

Some may say that this sould be done with ambience, yet the light may well
be causing some pattern of light to fall (visibly) on a nearby object.
Making it a light source would allow the light to be shown.

This is my idea of what should be in the material class (at this point):
class TMaterial : public TProcedural
{
  protected:
    TPattern*       ptColor;
    TPattern*       ptEmission;
    TPattern*       ptOpacity;
    TPattern*       ptAmbientReflection;
    TPattern*       ptDiffuseReflection;
    TPattern*       ptSpecularReflection;
    TPattern*       ptIor;
    TPattern*       ptCaustics;
    TPerturbation*  ptPerturbation;
    TBsdf*          ptBsdf;
...
};

The only difference is the removal of the 'self emission' scalar (never
used in any existing panorama code), and the addition of the emission
pattern.

> > Lights need not be included explicitly in the scene section of the rt
> > format.  They can be detected automatically and added.  As a bennefit
<snip>
> > transformed 'externally', by inclusion in another object (such as an
> > aggregate, or union) that is being transformed.  
> > 
> If the point light is inside an object, it will not be visible from
> outside for shadow rays.??
That depends.  The current code allows shadow rays to pass through
semi-transparent materials and to filter out some of the light emitted
from the light source.  The light would not be visible if it was within a
non-transparent object.

My goal in making a change such as this is that you could define an object
like a lamp, and place the light inside of it.  Whenever you move this
lamp, the light should move with it (as with my change), and not stay in
place.  

> > A side effect of this involved a slowdown whenever sending a ray to a
<snip>
> > dislike, as it could slow down the rendering by a HUGE amount.
> > 
> > So... The slowdowns involved by these changes are a few extra matrix
> > multiplies for pure light sources, and a requirement of a large number of
> > samples for area lights.
> I don't understand. For area lights we only need a random surface point and
> trace a shadow ray from camera. It is not slower that a normal
> findFirstIntersection()??
Sorry, I should have been more clear here.  The addition of an area light
to a scene requires a larger number of samples to be taken for each pixel
in a resulting image.  This is to get the nice soft shadow effects.
Without taking a large number of samples per pixel, the any visible point
in space that the light is hitting will be from either one point or
possibly all points on the light source.  With area lights being able to
emit different patterns of light, one sample on the light is not enough.
Multiple samples per pixel is the only way to go here, as multiple shadow
rays would be very time consuming for an object that is at the sub pixel
level, and may end up being averaged out anyways.


> For point lights the render can save its 3D locations or it can be in the
> object so where is the matrix operation?
This is so that lights can be instanced.  Going back to my lamp example,
say that I want to create 30 of these lamps for some room.  I just
instance the object and transform them into their correct position.  This
transform is then applied to the light by means of a matrix multiply.  The
current light interface allows a light source to calculate its own emitted 
light on a distant point (given as a point, not a distance).  To retain
these effects, a transform matrix multiply was needed to transform the
point into the space that the light thought it was in.

One approach to this would be to create a new light identical to the
first, except for the position.  This would be faster than what I am
doing.  However, when we add the capibility for motion blur, an object
(possibly one containing a light) could be moved, and the light would need
to be moved along with it.  This is the reason that I included the extra
matrix multiplies, instead of just duplicating the light.

If anyone has any better ideas, let me know.

Sorry for all of the verbage, but I was trying to be more clear this time.

-Kevin-