Re: Experimental additions I want feedback for...

[Kevin Harris]

On Mon, 2 Oct 2000, Angel Jimenez wrote:
> Kevin Harris escribi?:
> > > >  How did you solve the 'random point at surface' problem? It is not
<snip>

>  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)...
Yes.  I just didn't want to have to write something complicated, or have
to add a function for each object type before I could test 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
<snip>
> > time.  I'll change this to my own code when I get a chance.
>  Much better.
I've changed my code already, but it developed worse bugs.  I'll try to
debug it by Thursday.

>  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...
It depends on the scene.  I have done some with only 16spp (aa_depth 4),
and they look great.  Others, I have done at 256spp (aa_depth 16), and
they still look terrible.  One thing that makes the image look bad is if
the soft-shaded region is much larger than the light source creating it.  

I was trying to emphasize the huge time required to get a picture with
almost equiv shading using point lights.

>  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?
Ok.. I don't completely understand your question.  If you are asking how I
am doing the area lights, I'm just adding another function for the shadow
rays, direct lighting, and changing the main directLight function to
get light from area lights as well (it will require more than this to
work correctly, though -- for reflections of lights).

> 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...)
Nope.  The sampling was done in the same way that the raytracer did it.

> > > 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
<snip>
> > 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
<snip>
>  I've just done that in my current work :) I've been studying the
<snip>
> not used as as normal functions (you probably know 'inline' is not an
> order, but a suggestion for the compiler...).
Yes, but one of the real slowdowns in the current vectors is when they
*do* get inlined with all of the code to test the bounds for the
operator[] gets inserted.  Those could be avoided with a simple union.  

GCC typically does inline when you request it (unless it is on a virtual
function that it can't tell the type for at compile time). 

Here's a snippet of what I've used in my own code (in the past):
-----------------------------------------------------------------
/* class that has 3 doubles stored directly */
struct coord3_direct { double x; double y; double z; };

/* class that has 3 doubles stored in an array */
struct coord3_array { double coords[3]; };

/* union to allow accesses to both indirectly through an array, and
   directly through a name, without adding any extra processing time or
   space requirements */ 
union  coord3_union
{
  coord3_union() {}
  coord3_union(double x, double y, double z) 
  { direct.x = x; direct.y = y; direct.z = z; }
  inline double& operator[](int index)       
  { return(array.coords[index]); }
  inline double  operator[](int index) const 
  { return(array.coords[index]); }
  coord3_direct direct;
  coord3_array  array;
};

class vector
{
public:
  /* The internal coordinates of this class */
  coord3_union coords;
  inline double X() const  { return coords.direct.x; }
  inline double operator[](int index) const { return coords[index]; }
...
};

...
-----------------------------------------------------------------

This has no extra overhead for using either of the two methods (if
inlining is done).

It could even be templated, so long as there is always a primitive type
used in it.

>  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).
It isn't a huge loss in readability, as most of it would just be defining
the types that would be stored in the vector class.  From the outside
world, they would look and act the same (although the [] would be faster).

> > Well... Another potential speed increase would be to allow non-matrix
> > transforms (ie. quaternions).  These wouldn't allow scale and skew
<snip>
>  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...
Well... After I finish with my lighting stuff (at least enough to get it
checked in) tomorrow, I'll start working on faster vectors and
quaternions.  I'll try to explain how to use them before (or at the time) 
I check them in.


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

>  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...
The problem with the current code is that the trig functions are warping
the PDF too much to remain anywhere near uniform.  

Hmm... I began this the other day (yesterday?), and forgot to send it
until today... I hope it makes sense, as I haven't re-read it.

-Kevin-