Re: Experimental additions I want feedback for...

[Angel Jimenez]

Kevin Harris escribió:

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

 Maybe faster, but it does not have any use, other than a quick first
test for this code... We will eventually need this method anyway (for
lights in photon tracing)...

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

 Obviously, I would not use that for sphere, cylinder or some other
simple objects, but it is a generic (and valid) default implementation
(as long as the mesh is working and every object has a method to return
it).

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

 Much better.

> 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 see you put too much emphasis in the number of samples... Why? I
mean, there is a tradeoff between noise level and the number of samples,
but it is usually not that huge as you are saying...

 On the other side, I see the need for the interface (i.e. a way to
sample a non-poing light), but, how are you using that in current code?
There are means for reducing the number of samples needed for a given
noise level (adaptive sampling, importance sampling, quasi-Monte Carlo
methods, etc.). Are you using any of them? And, if so, how is that code
related to the light? (Be careful, as every renderer will treat the
light in its own way...)

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

 I've just done that in my current work :) I've been studying the
assembler code generated by VC++, and I found that, for example,
operating component-by-component (first x, then y, then z) instead of
using a vector, can give you a big improvement in speed sometimes... Now
I know why PovRay does everything this way... I have also found that you
have to be careful with inlines, and make sure they end up inlined and
not used as as normal functions (you probably know 'inline' is not an
order, but a suggestion for the compiler...).

 Cleaning up the vector code was one of the things I wanted to do...
Although losing code cleanliness for a little speed improvement is a bad
idea in my opinion (I wouldn't use a component-by-component operation
unless in a very critical place).

> 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 don't know much about quaternions, so I can't tell about it... But,
I'm sure they would be useful, if only to give some better handling to
the camera...

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

 I already knew that, but I thought there was a special function for
that somewhere... (I am looking but I can't find it). In fact, I think I
solved TRay::applyTransform() in the quick-and-dirty way just to avoid
that...

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

 Thanks. It is funny, as Carlos has just discovered that himself too (he
told me about that yesterday). He has a fix, but he needs to check it
before commiting, as he is not sure how it works... And I still don't
know what's the problem in current code...

-- 
Angel Jimenez
address@hidden