|
 |
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] gmx de> 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
|
|
|
|
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
|
|
