Re: Experimental additions I want feedback for...

[Angel Jimenez]

> ----- Original Message -----
> From: "Kevin Harris" <address@hidden>
> To: "Panorama Developer List" <address@hidden>
> Sent: Wednesday, September 27, 2000 7:29 PM
> Subject: Experimental additions I want feedback for...
>
> > I've made quite a few changes to panorama, and I would like some input
> > before (if at all) I check them in.  I'm not sure that everyone will
> > appreciate what I've changed, or the slowdown incurred by the changes.

 First of all, thanks for asking about it before adding the code to the
server.

> > I've added area lights by means of an 'emission' pattern for every
> > material.  This required that every object be given a function to return
a
> > random point on the surface (easier than a 2d-3d mapping), with a
default
> > provided at the 'center' of the object.  One problem arising from
> > adding the area light sources is that a HUGE number of samples must be
> > taken for each pixel to get a decent image.

 I don't understand what you mean with 'default at center'... That's useless
for volume lights, isn't it?

 How did you solve the 'random point at surface' problem? It is not
trivial... My plan was doing it by getting the object's mesh and choosing a
random triangle, and a random point in that triangle...

> > Lights need not be included explicitly in the scene section of the rt
> > format.  They can be detected automatically and added.  As a bennefit
> > here, I've allowed pure light sources (point lights, etc. are all
> > subclasses of 'TObject') to be included in aggregates, csg (intersection
> > or difference doesn't make too much sense), or whatever.  This allows
> > objects to be defined with light sources in them, and they can be
multiply
> > instantiated, transformed, translated, etc, and have the light stay with
> > the object.  This does not currently work for all pure lights or with
halo
> > (I don't know why yet).  These bugs only apply to lights that have been
> > transformed 'externally', by inclusion in another object (such as an
> > aggregate, or union) that is being transformed.

 Sorry, I'm lost. Are you saying there is a bug in current code, or in your
new code?

> > A side effect of this involved a slowdown whenever sending a ray to a
> > light -- a matrix multiply is used to transform the lights position, and
> > to transform the relative world coordinates into it's local system (for
> > falloff, etc.).  This is the part that I would assume most people would
> > 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 think there should be a way to have both models and choose between them.
Something like I did with 'halo' lights and atmospheric objects code. The
second is much better and more general, but the first can be used to get a
fast atmosphere effect.

 Couldn't we have both normal lights and 'object' lights? I mean, there
should be a way to add the second without affecting the first...

> > I would like to hear if anyone actually would like these changes I've
been
> > making.  If I get a positive response, I'll merge my stuff (not
completely
> > bug free yet -- I will probably need help with that) back into the tree.

 This is a very sensible decision... I understand you have worked some time
on this, and I would like to respect your work, but I also would like to
respect other people's opinion on this. My own one is we should try to find
a way to have both your new features and keep current speed. What's your
opinion on this? (I assume you have probably tried it...)

 I wouldn't like losing an order of magnitude in rendering speed. In fact,
one of my short term plans for the code, after making it work in VC++, is
profiling and making it run faster. I have learned some things at work (real
time graphics programming) that I think would make the code much faster than
it is now... Starting with a complete revision of data structures (both STL
and own made) and going to a (probable) rewrite of the scene tree and the
intersection algorithms and data structures (current map is probably a *big*
bottleneck). I think I could make the code about 2 times faster with that...

 About the scene tree... maybe this is the key to this problem. It is far
too simple and we need a better structure. We would need to support
instancing, so maybe a DAG, or DCG is a better choice. We could also
preprocess it before rendering and save some matrix operations...

> > A couple of example images of area lights can be found at:
> > http://www.eng.utah.edu/~kpharris/panorama/panorama.html

 I'm getting 'socket error', but it is probably a local problem (ADSL at
work is giving a lot of trouble...)

 Cheers.
 Angel.