Re: Experimental additions I want feedback for...

[Kevin Harris]

On Fri, 29 Sep 2000, Angel Jimenez wrote:
>  First of all, thanks for asking about it before adding the code to the
> server.
Well.. I knew that there'd be questions posted here asking why everything
has slowed down a little bit.  Plus, it was a way to bring a little more
activity into the list (if anyone replied). :)

>  I don't understand what you mean with 'default at center'... That's useless
> for volume lights, isn't it?
Actually, yes.  I had to make some kind of initial garbage so that I could
test everything.  The defaulting to the center of the object should be the
same as (or close to) having the transparent pattern of the material being
set to whatever the emission pattern would have been, and then placing a
point light at the center (the emissive pattern would have a sphereical
projection onto the surrounding environment).

This was not intended to be permanent, just a first step, until something 
more complicated could have been done.
 
> >  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...
The random point on the surface was a virtual function in the TObject
class.  For those classes which I wanted to use (immediately), I provided
a working function, the others used the 'default at center' (again, only a
first step).  This would be faster for simple objects (sphere, box, etc.)
than randonly picking a point on the mesh.  That plan sounds good, as long
as the objects support surface meshes (I haven't checked to see how/if the
CSG handles them), and an alternate method is available for simple
objects (such as how I have implemented it).

<snip>
> > > (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?
It's a bug in my new code.  Basically, it came from me not looking close
enough at how the halo light code actually worked.

>  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.
I haven't looked much at those.

>  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...
Yes, but I was trying to look towards the future.  I guess it was a bad
idea, as everything will have to be changed when we actually move to
motion blur.  It is easy enough to eliminate the slowdown, just by
changing the lights position, instead of using a matrix multiply each
time.  I'll change this to my own code when I get a chance.

> > > 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'll remove the slowdowns incurred on standard lights (they'll be the
same speed as before). I've got too much trash to do this weekend, but I
could have it fixed by next thursday at the latest.

Any objections to me checking in my code if existing scenes have the same
performance as before, and using area lights is somewhat slow, yet
requires a ton of samples?

>  I wouldn't like losing an order of magnitude in rendering speed. In fact,
Neither would I.

> 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...
Hmm... I know of an easy way to speed up some of the vector operations, at
a cost of code uglification. I'll have to look at the code again to make
sure that they apply.  The problem is that some of the code uses the
x(),y(),and z() functions, where other code uses the subscript operator[].
It is possible to make it have no penalty for using either access method,
or a mixture of both by way of a union (only for primitive numerical
types).  This would at least save some compares and branches for the use
of the operator[] when using variable (not compile time constant)
subscripts.

>  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...

Well... Another potential speed increase would be to allow non-matrix
transforms (ie. quaternions).  These wouldn't allow scale and skew
(apparently not currently avaible in panorama), but could save some extra
multiplies and adds for simple transformations. 

I think that multiplies between vectors and matricies needs to be redone
anyways, as the multiply does NOT work if you are treating a TVector as a
vector.  It only works if you are treating it as a point.  Vectors do
not need to be translated - only the rotation portion applies (the first
3x3 submatrix).  This led to some weirdness in some of the stuff I was
trying to do.

Oh... Another bug that currently exists in panorama code is in
RandomVectorInSphere (llapi/vector_tools.h).  It generates a non-uniform
vector. See http://www.cs.utah.edu/~kpharris/panorama/non-uniform.html
(graphics intensive) for a simple page showing how it's currently working.

> > > 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...)
Hmm... One of the nfs servers went down this morning.  It should work now. 

-Kevin-