"Mael" <mae### [at] hotmailcom> ha scritto nel messaggio
news:3e9afa23$1@news.povray.org...
> Hello,
>
> I've tried to write a patch to do importance sampling of the phong brdf
(the
> modified phong brdf actually). The patch uses the phong and phong_size of
> finish{} to compute highlights even in radiosity lighted only parts of the
> image (If there are real light sources then the highlight is the phong
> contribution of those lights source + the contribution of the sampled
phong
> brdf)
>
> Some images : http://195.221.122.126/radphong/rad_phong.html
>
> M
>
Hi Mael,

it's wonderful !
Where is the new version?
I want to download.
Thanks.
Ceggi.

Post a reply to this message

Brilliant!

(Or should I say, "Phongey!")


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Mael, this is great! Thanks for all your ongoing contributions :)

George


"Mael" <mae### [at] hotmailcom> wrote in message
news:3e9afa23$1@news.povray.org...
> Hello,
>
> I've tried to write a patch to do importance sampling of the phong brdf
(the
> modified phong brdf actually). The patch uses the phong and phong_size of
> finish{} to compute highlights even in radiosity lighted only parts of the
> image (If there are real light sources then the highlight is the phong
> contribution of those lights source + the contribution of the sampled
phong
> brdf)
>
> Some images : http://195.221.122.126/radphong/rad_phong.html
>
> M
>
>

Post a reply to this message

Mael wrote:
> 
> > That looks very interesting, i have some troubles understanding how it
> > works though.  The phong model needs the light direction, how do you
> > determine it with radiosity lighting?
> 
> This sampling is independent of the radiosity inter-diffuse stuff. It occurs
> at each intersection point if there is a non zero phong in the finish. An
> adaptive number (calculated with phong_size and a global parameter rad_phong
> (a kind of density)) of rays are shooted near the direction = incident ray
> reflected (samples rays are choosed with an adequate probability density
> function -see the images- that's why it's called importance sampling) and
> light is gathered. Yes that sounds cpu consuming - and it is, but for high
> phong_size the number of samples can be low.

Very clever.

But i guess it is really quite awfully slow.  It could be worth
considering some caching function but that will probably be less helpful
than with diffuse radiosity since the result varies much stronger with
position and surface normal.

How does it look with very low sample counts? Does it look mostly noisy or
are there other artefacts?

Christoph

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

Post a reply to this message

> Very clever.

ehhm, to be honest this is really not rocket science and the patch is ~ 50
lines of C

> But i guess it is really quite awfully slow.

well as slow as blurred reflection, or things like this. I would say slow
but not awfully slow :)

> It could be worth
> considering some caching function but that will probably be less helpful
> than with diffuse radiosity since the result varies much stronger with
> position and surface normal.

I've not tried but i'm pretty sure caching is useless considering, as you
noted, the strong effect of normal and incident ray direction. A way to make
it faster would be to find another brdf which don't require a pow() call for
the distribution as it is quite cpu expensive (there are papers about such
brdf, see for example
http://dept-info.labri.u-bordeaux.fr/~schlick/DOC/eur2.html)

> How does it look with very low sample counts? Does it look mostly noisy or
> are there other artefacts?

in the current implementation the position of samples is fixed so low sample
counts may give artifacts. I think adding a random rotation of the samples
would result in noise.

M

Post a reply to this message

Mael wrote:
> 
> > Very clever.
> 
> ehhm, to be honest this is really not rocket science and the patch is ~ 50
> lines of C

Well, then it's even better...

> > It could be worth
> > considering some caching function but that will probably be less helpful
> > than with diffuse radiosity since the result varies much stronger with
> > position and surface normal.
> 
> I've not tried but i'm pretty sure caching is useless considering, as you
> noted, the strong effect of normal and incident ray direction. A way to make
> it faster would be to find another brdf which don't require a pow() call for
> the distribution as it is quite cpu expensive [...]

Is this based on actual measures?  I would assume the calculation of the
sampling directions is negligible on terms of computation time in
comparison to the actual shooting of rays.  Isn't it possible to calculate
the sampling directions and their weights in advance anyway?

> 
> > How does it look with very low sample counts? Does it look mostly noisy or
> > are there other artefacts?
> 
> in the current implementation the position of samples is fixed so low sample
> counts may give artifacts. I think adding a random rotation of the samples
> would result in noise.

I think it would be interesting to test.  One problem about blurred
reflection is that low sample counts tend to generate noise that makes the
result look very ugly.  Some 'slight' artefacts could be preferable in
some situations.

Christoph

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

Post a reply to this message

> Is this based on actual measures?  I would assume the calculation of the
> sampling directions is negligible on terms of computation time in
> comparison to the actual shooting of rays.  Isn't it possible to calculate
> the sampling directions and their weights in advance anyway?

Yes it would be possible (you need a set of samples for each different
phong_size). And you're right, calls to trace() are certainly what make it
slow

as i'm not planning to release more mlpov versions here is the code for
people interested (it still needs some work)
it uses a 2D halton sequence for random variables to compute the sampling
directions
the function have the finish metallic as i think it's possible to use it but
this not done

void do_phong_rad(VECTOR pt, VECTOR dir, VECTOR normal, VECTOR raw_normal,
                  DBL phong, DBL phong_size, SNGL metallic, COLOUR col, DBL
weight)
{
  unsigned long Save_Quality_Flags, Save_Options;
  int save_Max_Trace_Level;
  int nb_samples, i;
  static DBL cache_phong_size=0;
  static int cache_nb_samples=0;
  DBL ang;
  DBL depth;
  COLOUR tmp_col, sum_col;
  VECTOR in, in_s;
  DBL cosalpha, sinalpha, phi;
  DBL costheta;
  VECTOR ru,rv;
  RAY ray_s;

  // FIXME this could be computed at parse time and saved in the finish
  if (phong_size != cache_phong_size)
  {
    // Compute a number of samples with the rad_phong value and phong_size
    costheta=pow(.01,1/phong_size);
    cache_nb_samples=opts.Radiosity_Phong * (1-costheta);
  }
  nb_samples = cache_nb_samples;

  // Adjust the weight with phong
  weight *= phong;

  // Save and set tracing options
  save_Max_Trace_Level = Max_Trace_Level;
  Max_Trace_Level = Trace_Level + 2;
  if (Max_Trace_Level>save_Max_Trace_Level) Max_Trace_Level =
save_Max_Trace_Level;
  Save_Quality_Flags = opts.Quality_Flags;
  Save_Options = opts.Options;
  opts.Radiosity_Quality = 6;
  opts.Options &= ~USE_LIGHT_BUFFER;
  opts.Quality_Flags &= ~Q_AREA_LIGHT;
  if(!opts.Radiosity_Use_Media)
    opts.Quality_Flags &= ~Q_VOLUME;
  // FIXME do we consider it radiosity ??
  Radiosity_Trace_Level++;
  Trace_Level++;

  // Mirror the incoming ray, and build a local coord system
  // FIXME change for in ~= x
  VDot(ang, dir, normal);
  ang *= -2.0;
  VAddScaled(in, dir, ang, normal);
  VNormalizeEq(in);
  ru[X]=1-in[X]*in[X];
  ru[Y]=0-in[X]*in[Y];
  ru[Z]=0-in[X]*in[Z];
  VNormalizeEq(ru);
  VCross(rv, ru, in);

  // Samples the modified phong brdf, and save the sum in sum_col
  Make_Colour(sum_col, 0., 0., 0.);
  for (i=0;i<nb_samples;i++)
  {
    // Build a sampling direction in_s
    cosalpha = pow(halton_samples[i][X], 1. / (phong_size+1));
    sinalpha = sqrt(1 - cosalpha*cosalpha);
    phi = halton_samples[i][Y] * 2. * M_PI;
    in_s[X] = in[X] * cosalpha + sinalpha * (sin(phi) * ru[X] + cos(phi) *
rv[X]);
    in_s[Y] = in[Y] * cosalpha + sinalpha * (sin(phi) * ru[Y] + cos(phi) *
rv[Y]);
    in_s[Z] = in[Z] * cosalpha + sinalpha * (sin(phi) * ru[Z] + cos(phi) *
rv[Z]);

    // Test if not in the object
    VDot(ang, in_s, raw_normal)
    if ( ang > 0.)
    {
      // Trace a ray
      Initialize_Ray_Containers(&ray_s);
      Assign_Vector(ray_s.Direction, in_s);
      Assign_Vector(ray_s.Initial, pt);
      depth = Trace(&ray_s, tmp_col, weight);
      // for the modified phong divided by the pdf the integral only have
constant term (cf below), and costheta
      VDot(costheta, in_s, normal);
      VAddScaledEq(sum_col, costheta, tmp_col);
    }
  }
  // Scale and add in the returned col
  VScaleEq(sum_col, phong*(phong_size+2)/(nb_samples*(phong_size+1)));
  VAddEq(col, sum_col);

  // Back to previous values
  Radiosity_Trace_Level--;
  Trace_Level--;
  opts.Quality_Flags = Save_Quality_Flags;
  opts.Options = Save_Options;
  Max_Trace_Level = save_Max_Trace_Level;
}

Post a reply to this message

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

> I think it would be interesting to test.  One problem about blurred
> reflection is that low sample counts tend to generate noise that makes the
> result look very ugly.  Some 'slight' artefacts could be preferable in
> some situations.

If you look at the averaged texture method, the result of too few 
samples ends up as a blotchy, uneven blur instead of the severe 
grainyness of the old MegaPOV patch. I've been thinking about the 
possibilities of a patch that used precomputed sample directions 
smoothly perturbed by a pattern. This could avoid some of the extra 
computations of the averaged texture method and lower the number of 
samples required for a good result relative to the random sample method.

Another odd idea is adaptive sampling. For example, start off with a 
tetrahedron and subdivide each triangle into 4 triangles, sampling 
through the vertices and subdividing further when there's a significant 
difference between samples. Or have a minimum and maximum number of 
samples, split the minimum into two sets of samples and compare the 
results. If the results vary too much, take more samples and compare 
again. I did something like this in a development version of my 
proximity or curvature patterns (can't remembe exactly which, and didn't 
do much testing with it anyway).

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> well as slow as blurred reflection, or things like this. I would say
> slow but not awfully slow :)
I you'd only know..... :P

Post a reply to this message

Mael wrote:
> 
> > Is this based on actual measures?  I would assume the calculation of the
> > sampling directions is negligible on terms of computation time in
> > comparison to the actual shooting of rays.  Isn't it possible to calculate
> > the sampling directions and their weights in advance anyway?
> 
> Yes it would be possible (you need a set of samples for each different
> phong_size). And you're right, calls to trace() are certainly what make it
> slow

Yes, they could be stored as part of the finish when the new feature is
used in it.  

> as i'm not planning to release more mlpov versions here is the code for
> people interested (it still needs some work)
> it uses a 2D halton sequence for random variables to compute the sampling
> directions
> the function have the finish metallic as i think it's possible to use it but
> this not done
> 
> [...]

Thanks.  I assume it is called in 'compute_lighted_texture()' like
'Compute_Ambient()'.  You will probably also have to use some mechanism
like 'recursion_limit' to control recursion.  

Christoph

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

Post a reply to this message