> 
>         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

: 	I guess it's because it requires computing three modulus on doubles
: which is very slow (a division + a floor + a difference)*3

  Why not just:

if(val>1) val=1;
else if(val<0) val=0;

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39d1d67f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Why not just:
> 
> if(val>1) val=1;
> else if(val<0) val=0;

That makes the plateaus, which are what started this whole thing.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: That makes the plateaus, which are what started this whole thing.

  I was responding to someone who explained why clamping is so slow (or
at least I think so).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : That makes the plateaus, which are what started this whole thing.
> 
>   I was responding to someone who explained why clamping is so slow (or
> at least I think so).
> 
	No, but I think I see where the confusion comes from. You were thinking
of the values returned by the Noise function (which are something like
-0.01 to 1.01 and are truncated in the way you said) and the values
where Noise can be computed (must be bigger than -10000, and I don't
know the upper limit but there's one). In this case the only solution is
to take advantage of the periodicity of Noise and to bring the values
inside the acceptable range using a modulus (or something similar).


-- 

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

Post a reply to this message

> No, but I think I see where the confusion comes from. You were thinking
> of the values returned by the Noise function (which are something like
> -0.01 to 1.01 and are truncated in the way you said)

Actually, the plateaus were much worse than that.  Clamping (as Warp
described) still happens, but it used to be something like [-0.5, 1.5]
clamped down to [0,1].

> and the values
> where Noise can be computed (must be bigger than -10000, and I don't
> know the upper limit but there's one). In this case the only solution is
> to take advantage of the periodicity of Noise and to bring the values
> inside the acceptable range using a modulus (or something similar).

Could this be done using shift operators (is the period a multiple of 2)?

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> Could this be done using shift operators (is the period a multiple of 2)?
> 
	That only works once the double has been changed into a long, but there
might be something I can do there... I'll have to look at it in more
detail.


-- 

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

Post a reply to this message