I've calculated 8000 radiosity samples (see p.b.i and p.b.s-f). As you can
see in the image the 255x255x255 resolution isn't fine enough for lots of
radiosity samples: the image already shows that the distribution has
rectangular artifacts due to rounding errors. Anyhow I'm posting an image
and a zipped set of files in p.b.s-f that you can use to insert the samples
into the POV-Ray source-code. I can't do that myself now, because I'll have
to install another compiler for that :-(

Post a reply to this message

Apache wrote:
> 
> I've calculated 8000 radiosity samples (see p.b.i and p.b.s-f). As you can
> see in the image the 255x255x255 resolution isn't fine enough for lots of
> radiosity samples: the image already shows that the distribution has
> rectangular artifacts due to rounding errors.

It is fairly obvious that using bytes to store the directions is just a
hack to save memory.  Apart from the accuracy problem it also costs some
computation time to unpack the directions for every radiosity sample
taken.  

> Anyhow I'm posting an image
> and a zipped set of files in p.b.s-f that you can use to insert the samples
> into the POV-Ray source-code. I can't do that myself now, because I'll have
> to install another compiler for that :-(

Without any information on how the samples were generated this suffers
from the same problem as the original set of sample directions.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

> It is fairly obvious that using bytes to store the directions is just a
> hack to save memory.  Apart from the accuracy problem it also costs some
> computation time to unpack the directions for every radiosity sample
> taken.
No need to save memory with this, because we're having more and more RAM
every year :-) And IIRC computers nowadays work as fast with integers
(16bits) as with bytes (8bits).

> Without any information on how the samples were generated this suffers
> from the same problem as the original set of sample directions.

It's a bit like this:

save first sample, offset = 0 (this one is on the exact center of the disk)
samplescalculated = 1
minimumtrials = 1000
repeat until (samplescalculated equals 8000) {
    trialcounter = 0
    besttrialdistance = 10   (doesn't really matter, must be > 2)
    repeat until (trialcounter equals samplecount \
      and trialcounter is greater or equals minimumtrials) {
        create random sample on disk
        if (distance from random sample to nearest sample saved <
besttrialdistance) {
            besttrialdistance = distance random sample to nearest sample
saved
            save random sample, offset = samplescalculated
            trialcounter = 0
        }
    }
    samplescalculated ++
}

save all samples saved to disk

done


Anyhow. The first test with this test set really sucks :-(    Extreme
artifacts!



Here's the source code of the monster:

#include <stdlib.h>
#include <stdio.h>
#include <math.h>


#define SAMPLESAMOUNT       (12000)
#define MINRETRIES          (1000)
#define DISTRIBUTEROUNDS    (200)
#define DISTRIBUTESTEPSIZE  (0.01)
#define PI                  (3.141592653589793238)
#define XMEAN               (127.5)
#define YMEAN               (127.5)
#define XSCALE              (127.5)
#define YSCALE              (127.5)
#define ZSCALE              (127.5)
#define RANDOMVALUE         ((double)rand() / (double)(RAND_MAX))

int main(void) {
  FILE*     filehandle1;
  double*   x              = (double*) malloc(SAMPLESAMOUNT *
sizeof(double));
  double*   y              = (double*) malloc(SAMPLESAMOUNT *
sizeof(double));
  int       i              = 0;


  /******* CREATE DISTRIBUTION *******/

  x[0] = 0.0;
  y[0] = 0.0;

  for (i = 1; i < SAMPLESAMOUNT; i++) {
    int    i2;
    double xnew;
    double ynew;
    double olddist = 0.0;
    int    retry   = 0;

    printf("\rSETUP DISTRIBUTION   : %d of %d", i, SAMPLESAMOUNT);

    for (retry = 0; (retry < i) || (retry < MINRETRIES); retry++) {
      int    j       = 0;
      double mindist = 1001.0;
      double phi     = 2*PI*RANDOMVALUE;
      double sqrtr   = sqrt(RANDOMVALUE);
      xnew           = cos(phi)*sqrtr;
      ynew           = sin(phi)*sqrtr;

      /** determine distance of new sample to nearest existing sample **/
      for (j = 0; j < i; j++) {
        double dx = xnew - x[j];
        double dy = ynew - y[j];
        double d2 = dx*dx + dy*dy;
        if (d2 < mindist) {
          mindist = d2;
        }
      }

      /** if new sample is farther away than the previous one, save it **/
      if (mindist > olddist) {
        x[i]    = xnew;
        y[i]    = ynew;
        olddist = mindist;
        retry   = 0;
      }
    }

  }
  printf("\rsetup distribution   : done                 \r\n");

  /******* WRITE SAMPLES TO DISK *******/

  printf("SAVE SAMPLES TO DISK...");
  filehandle1 = fopen("newraddata.inc", "w");

  fprintf(filehandle1, "#declare Thing1 = union {\r\n");
  for (i = 0; i < SAMPLESAMOUNT; i++) {
    double z = sqrt(1-x[i]*x[i]-y[i]*y[i]);
    fprintf(filehandle1, "  sphere {<%d, %d, %d>, 1.0} //count %d\r\n",
(int)(.5+XMEAN+XSCALE*x[i]), (int)(.5+YMEAN+YSCALE*y[i]),
(int)(.5+ZSCALE*z), i+1);
  }
  fprintf(filehandle1, "}\r\n");

  fclose(filehandle1);
  printf("\rsave samples to disk : done                \r\n\007");

  free(x);
  free(y);

  return (0);
}

Post a reply to this message

> Anyhow. The first test with this test set really sucks :-(    Extreme
> artifacts!
Oh, lucky me. The artifacts are even worse with the original set. I'm
rendering a bunch of tests now which I'll post later on when they're
finished.

Post a reply to this message

And I'm calculating a 12000 samples set. This time I'll get rid of the
255x255x255 problem. Maybe I'll try integers: 65535x65535x65535.

Post a reply to this message

Apache wrote:
> And I'm calculating a 12000 samples set. This time I'll get rid of the
> 255x255x255 problem. Maybe I'll try integers: 65535x65535x65535.

You could use two shorts instead of three, and compute the third with z =
sqrt(1 - x^2 - y^2). Then the memory use would only go up by 33% per sample.
(Besides, it would probably be faster than vnormalizing the whole vector
every time.)

If you get this working, by the way, you could reuse the same table for
focal blur samples, since it is after all a uniform distribution on the
disc.

Anders

--
#macro E(D)(#if(D<2)D#else#declare I=I+1;mod(pow(.5mod(I 6))*asc(substr(
"X0(1X([\\&Q@TV'YDGU`3F(-V[6Y4aL4XFUTD#N#F8\\A+F1BFO4`#bJN61EM8PFSbFA?C"
I/6 1))2)<1#end)#end#macro R(D,I,T,X,Y)#if(E(D))R(D-1I,T,Y/2X)R(D-1I,T+Y
/2Y/2X)#else box{T T+X+Y pigment{rgb E(2)*9}}#end#end R(10,5z*3-1v*2u*2)

Post a reply to this message

In article <3e1b35b0@news.povray.org> , "Anders K." <and### [at] kaseorgcom> 
wrote:

> You could use two shorts instead of three, and compute the third with z =
> sqrt(1 - x^2 - y^2). Then the memory use would only go up by 33% per sample.
> (Besides, it would probably be faster than vnormalizing the whole vector
> every time.)

I never looked at the radiosity code, but it does not use VNormalize insde
the radiosity calculations, does it???

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3e1b35b0@news.povray.org> , "Anders K." <and### [at] kaseorgcom> 
wrote:

> You could use two shorts instead of three, and compute the third with z =
> sqrt(1 - x^2 - y^2). Then the memory use would only go up by 33% per sample.
> (Besides, it would probably be faster than vnormalizing the whole vector
> every time.)

Never mind, I checked and it really does.  This has to be fixed.  A fix will
be in POV-Ray 3.51.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> > You could use two shorts instead of three, and compute the third with z =
> > sqrt(1 - x^2 - y^2). Then the memory use would only go up by 33% per sample.
> > (Besides, it would probably be faster than vnormalizing the whole vector
> > every time.)
> 
> Never mind, I checked and it really does.  This has to be fixed.  A fix will
> be in POV-Ray 3.51.

Be careful, this could possibly 'break' old radiosity scenes because the
directions will slightly differ (although the differences will not be
large of course).  Calculating the direction vectors at the beginning and
not during every ra_gather() call would be a good idea IMO.  I already
made this modification for Megapov in case you want it.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3E1B3FDE.4F8CC9FA@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Be careful, this could possibly 'break' old radiosity scenes because the
> directions will slightly differ (although the differences will not be
> large of course).  Calculating the direction vectors at the beginning and
> not during every ra_gather() call would be a good idea IMO.  I already
> made this modification for Megapov in case you want it.

Already in 3.51, too.  The speed gain does not seem to be too much, though
:-(

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message