|
|
Christoph Hormann wrote:
> The docs are wrong, f_rounded_box() should only be used with radius > 0.
> This is not a bug but simply a limitation (although it would of course
> make sense to add an efficient handling of the case radius=0).
>
> Note the current f_rounded_box() is not a very efficient solution anyway
> (you don't need an sqrt() for every evaluation).
Actually I tried the following expression.
return (PARAM_X * PARAM_X
+ PARAM_Y * PARAM_Y
+ PARAM_Z * PARAM_Z
- PARAM(0)*PARAM(0));
against
return (
sqrt(PARAM_X * PARAM_X
+ PARAM_Y * PARAM_Y
+ PARAM_Z * PARAM_Z)
- PARAM(0));
And found that the latter was always faster by about 30%.
I'm not exactly sure why it is that way but one problem
is that a the max_gradient needs higher values.
For the former version a max_gradient of 1.0 is always
suitable whereas for the latter one something
like
2.0*sqrt(3)*RADIUS
is neccessary.
There may be parameters for which the latter one is faster
but in the geral case the square root beats the square.
A least this is the result from the tests renders I did
on my pentium-m 1300MHz machine.
The most promissing solution I found looks like this.
DBL f_rounded_box(DBL *ptr, unsigned int) // 60
{
DBL x2, y2, z2, x3, y3, z3;
x2 = PARAM(1) - PARAM(0);
y2 = PARAM(2) - PARAM(0);
z2 = PARAM(3) - PARAM(0);
x3 = fabs(PARAM_X);
y3 = fabs(PARAM_Y);
z3 = fabs(PARAM_Z);
PARAM_X = (x3 < x2) ? 0 : (x3 - x2);
PARAM_Y = (y3 < y2) ? 0 : (y3 - y2);
PARAM_Z = (z3 < z2) ? 0 : (z3 - z2);
return (sqrt(PARAM_X * PARAM_X + PARAM_Y * PARAM_Y + PARAM_Z * PARAM_Z)
- PARAM(0));
}
Using fabs gave me approx. 2% speed increase in the test scene
(p.b.images).
>
> To me it seems this offset is specifically for handling the degenerate
> case. Choosing 1e-3 simply gets you beyond your accuracy limit.
This was my intention. And yes, this is very likely. I tried the
degenerated case without the offset and the render process stuck
on the first line until I aborted after some minutes.
Sebastian
Post a reply to this message
|
|