I've been busy with the noise function this last weekend (the one in
texture.c, not the isosurface function) and I got some interresting
results I thought I'd share my progress:

* I found a slight optimization that allows it to compute faster;
* I rewrote it from scratch and got a new version that's even faster for
very similar results (but the results are different, so if you spent a
lot of tim placing your building just right in your ridged mf landscape
you won't want to use this one). The drawback is that it uses more
memory (Not so much of a problem with modern computers as it was when
the original was written);
* then I lost all the speed I had gained and then some by fixing the
range problem (very big or very negative numbers give bad result) that
occurs both with the original and my  implementation.

	Here are some numbers. I computed the minimum, maximum, mean and
standard deviation in a 64 units wide cube sampling every 0.1 unit and
got the following durations (in seconds):

                original     range fixed
megapov          505.56        628.10
improved MP      439.49        608.75
mine             421.29        606.45

	Next order of business for me (next we) is to look into DNoise and see
if the same kind of optimizations are possible. Then I intend to add
keywords in global settings to allow people to choose between improved
mp and mine, and between range fixed or not. What kind of keywords would
you prefer?



PS: I just noticed that there's a bug in the "range fixed" version. It
should be slightly faster than the numbers I just gave, but not much...

-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

> Then I intend to add
> keywords in global settings to allow people to choose between improved
> mp and mine, and between range fixed or not. What kind of keywords would
> you prefer?

First, off, thank you for trying to improve something even though everyone
else thinks it's working fine already. This kind of experimentation brings
new and better things.

The synxtax I see is this: noise {method 0/1/2 fixed_range/range on/off}

If you don't use fixed_range, then you don't have to go about adding more
keywords.

Post a reply to this message

"Tony[B]" <ben### [at] panamac-comnet> wrote...
>
> First, off, thank you for trying to improve something even though everyone
> else thinks it's working fine already. This kind of experimentation brings
> new and better things.

Actually, not everyone thinks it's working.  Check out these posts in
povray.bugreports:
"Bug in noise function" dated 8/28/99 by Margus Ramst (this may have been
fixed already)
"Bozo "saturation" problem" dated 5/20/99 by Ron Parker (this is "fixed" in
MegaPov)
"Spotted normal bug (Jerome M. Berger)" dated 11/22/99 by Peter Popov

> The synxtax I see is this: noise {method 0/1/2 fixed_range/range on/off}

Because this sort of thing affects bozo, spotted, wrinkles, turbulence, and
a variety of other aspects of POV, the exact way it should be implemented
may not be this simple.

-Nathan

Post a reply to this message

> Actually, not everyone thinks it's working.  Check out these posts in
> povray.bugreports:

I don't check out .bugreports very often. Point taken, nonetheless.

> Because this sort of thing affects bozo, spotted, wrinkles, turbulence,
and
> a variety of other aspects of POV, the exact way it should be implemented
> may not be this simple.

Ah, OK. What would you suggest?

Post a reply to this message

Nathan Kopp wrote:
> 
> "Tony[B]" <ben### [at] panamac-comnet> wrote...
> >
> > First, off, thank you for trying to improve something even though everyone
> > else thinks it's working fine already. This kind of experimentation brings
> > new and better things.
> 
> Actually, not everyone thinks it's working.  Check out these posts in
> povray.bugreports:
> "Bug in noise function" dated 8/28/99 by Margus Ramst (this may have been
> fixed already)
	This is the problem I'm addressing... The point is that in most cases,
if this problem manifests itself, you're probably not using noise
correctly. Most of the times it occurs when people translate a noise
pattern to get several different "noises". But noise is actually a
periodic function (it has a period of 4096 in the current
implementations) so you don't need to translate it as much. The problem
should only manifest itself if you zoom out a lot (but then the noise
pattern is not visible anymore). However this is only true for
"straight" noise (as in the bozo pattern) and thing might be different
in other patterns or in turbulence...

> "Bozo "saturation" problem" dated 5/20/99 by Ron Parker (this is "fixed" in
> MegaPov)
> "Spotted normal bug (Jerome M. Berger)" dated 11/22/99 by Peter Popov
> 
	The grid that appears is unfortunately an unavoidable side effect of
the way noise is computed. I don't think this one can be fixed except by
completely replacing the algorithm and I have no idea what could be used
instead :-(

> > The synxtax I see is this: noise {method 0/1/2 fixed_range/range on/off}
> 
> Because this sort of thing affects bozo, spotted, wrinkles, turbulence, and
> a variety of other aspects of POV, the exact way it should be implemented
> may not be this simple.
> 
	True enough. Unfortunately, I have neither the time, nor the overall
knowledge of pov necessary to do it "the right way". Moreover the speed
versus memory parameter should indeed be global anyway. So I think I'll
do it that way (and Tony's keywords look good to me) and let others with
more time/knowledge adapt it if they really think it's necessary (after
all, the problem doesn't occur that often, and people make do very well
with the present limitations)


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

"Tony[B]" wrote:
> The synxtax I see is this: noise {method 0/1/2 fixed_range/range on/off}
> 
> If you don't use fixed_range, then you don't have to go about adding more
> keywords.
	Thanks, I think I'll do it that way.


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

> 
>         I've been busy with the noise function this last weekend (the one in
> texture.c, not the isosurface function) and I got some interresting
> results I thought I'd share my progress:
> 
> * I found a slight optimization that allows it to compute faster;
> * I rewrote it from scratch and got a new version that's even faster for
> very similar results (but the results are different, so if you spent a
> lot of tim placing your building just right in your ridged mf landscape
> you won't want to use this one). The drawback is that it uses more
> memory (Not so much of a problem with modern computers as it was when
> the original was written);
> * then I lost all the speed I had gained and then some by fixing the
> range problem (very big or very negative numbers give bad result) that
> occurs both with the original and my  implementation.
> 
Speeding up noise is Good Thing(TM). Lots of textures use it and its
speedup will make scene rendering faster as well. I've thought about
trying this myself, but I haven't had time or good profiler to do it.
What is this range problem, which loses this speed-up? Can't you avoid
it? 
Very big numbers? Very negative numbers? Do You mean input vector
values? Can't you subtract some negative value to push it on positive
side as it is in POV-Ray code? And then take module from this? Does this
really slow down Noise function? Or do You mean something else?

Post a reply to this message

Vahur Krouverk wrote:
> 
> Speeding up noise is Good Thing(TM). Lots of textures use it and its
> speedup will make scene rendering faster as well. I've thought about
> trying this myself, but I haven't had time or good profiler to do it.
> What is this range problem, which loses this speed-up? Can't you avoid
> it?
> Very big numbers? Very negative numbers? Do You mean input vector
> values? Can't you subtract some negative value to push it on positive
> side as it is in POV-Ray code? And then take module from this? Does this
> really slow down Noise function? Or do You mean something else?
	Very very positive (as in more than what a long can contain) and very
negative (as in less than -10000) numbers. Of course I can do it the
same way it's done in pov now (in fact that's what I do). But I was just
suggesting that I could add an option that would allow people to get the
whole range at the cost of speed if they need it (of course I intend to
use the fast noise as the default).


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

>         Very very positive (as in more than what a long can contain) and very
> negative (as in less than -10000) numbers. Of course I can do it the
> same way it's done in pov now (in fact that's what I do). But I was just
> suggesting that I could add an option that would allow people to get the
> whole range at the cost of speed if they need it (of course I intend to
> use the fast noise as the default).
> 
I wonder, why this clamping reduces performance in such degree (almost
50 %)? Noise calculation does much more and requires only twice as much
time? This seems really strange.

Post a reply to this message

Vahur Krouverk wrote:
> 
> I wonder, why this clamping reduces performance in such degree (almost
> 50 %)? Noise calculation does much more and requires only twice as much
> time? This seems really strange.
	I guess it's because it requires computing three modulus on doubles
which is very slow (a division + a floor + a difference)*3 whereas noise
itself mostly requires some additions and substractions (all right plus
a few multiplications, but not that many and no division)


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message