Steve wrote:
> 
> What could we call POVs technique?  Namewise I mean.  Radiosity is not a good
> word.  Is it "distributive ray tracing" ?
> 

Yes.  Pov's radiosity is a modified type of distributive (monte-carlo) ray
tracing.  Some distributive ray tracers shoot the sample rays at every point
(to do blury reflections, for instance), but this is really slow.  Also,
the samples are usually chosen using the surface's BRDF... POV uses the
same lambertian-only pdf for all of its samples (so even shiny surfaces
tend to get a diffuse-surface look).

POV averages those samples and stores the color that it gets.  Then, instead
of always sampling, it sometimes interpolates between points already in its
cache.

> 
> It's a matter of sample-and-replace.  Solving this problem by storing a bigger
> database is redundant.  If an angle of emmition is homogeneous around itself,
> replace all these similar samples with a single sample that is an average,
> both in importance and in direction.   If you have directions giving you
> near-zero importance, remove them, and recast them in a more "important"
> direction.  Your database size should remain the same in the end.  You will
> have a _better_ not a _bigger_ database.  To set this process in motion, don't
> shoot rays from the light sources randomly, but in a rectangular lattice.
> Subdivision is now possible. This is sampling after all.  (Maybe I should be
> emailing this to you privately! )

I like the idea of replacing similar samples with a single sample.  This,
of course, requires you finding similar samples in the database, but that
might not be too time consuming.  And the savings in database size could be
very considerable!

> There is an elegant way to get rid of this splochiness.  It's called a
> "contributing point network."  I'll email details later when I get the time.

I'm very interested.  I look forward to hearing about it.  :-)

> Also, consider the output of a ray-tracer.  For true-color it's 8bits per
> color channel.  Giving  you a maximum 256  shades of color.  For a scene
> containing a single light source with channels not exceeding 1.0 in
> brightness, there is an upper theoretical limit on the number of points
> averaged.  Is this limit the average of 256 points?  Will more points in your
> average change the image?  Think about it.

If the points are not very uniform, the first 256 points you gather could be
very dim... then points 257-350 could be twice as bright as the others. This
would change the average.  Of course, If this were the case I would try a
better sampling technique to avoid such problems.

> Yes.  But you will find out that the user has to enter a "brightness factor."
> There is no way to get around this using nothing but sampling.   Consider
> averaging the samples.  This is not so bad, I think. Just something to keep in
> mind.  You should definitely investigate.

I think the 'brightness_factor' can be removed and a better averaging of
samples than the current technique could be used.  I'm not sure if it will
actually work the way I want it to, though.

> Well... yes,, that.  How slower is the database stuff anyway?  It seems it
> could be potentially staggering.

For a reasonable-sized photon map in a balanced kd-tree and only averaging
50-100 points per intersection, it's not too bad.  The search time, like
any other binary tree, is approximately on the order of log(n), so that
is good (n=number of photons in tree).

> Not so fast. :)   You may be considering bounces on the same photon.  I am
> talking about something totally different.  Such as the fact that all
> intersection points in the path of a multipley-reflected photon potentially
> illuminate every intersection point on all the paths of all the other photons
> traced.   The recursive nature of this boggles the mind.  But I assure you
> this is attainable, and elegantly at that.  I will elaborate only over email.

I look forward to hearing more.

> fascinating results.   20 megs?  I think the randomness of light out the light
> source is introducing the noise. Honestly.  Try an even distribution. Let me
> know what happens.

I did use an even distribution from the light source.  (My initial attempts
did use random sampling, which I quickly abandoned.) But once I hit an
object, I had to use random sampling, which brought the noise back.  I agree
that with such a large database, the results should have been much better.
Maybe there's a bug in my code (now that's unthinkable!!!).

-Nathan

Post a reply to this message