I've run into an interesting and totally unexpected situation in v3.6.1 while
animating, trying to produce some random values from frame to frame. I'm seeing
repeating patterns in the values; nothing that I try eliminates them.

The problem arose by using seed(clock) or seed(frame_number) in my SDL scene to
generate different random seed streams for each frame (a standard method?) then
pulling only one rand() value from that per frame--which made the patterns very
apparent. I *thought* that by simply throwing some multiplier value 'M'
at seed(M*clock) or seed(M*frame_number)--just one time in my POV scene, to use
for the entire animation--would give me 'obvious' random numbers from frame to
frame. Unfortunately, not so. There are, to my great surprise, clear
*almost*-repeating rand() patterns, no matter what seed values I use. And it
shows up quite quickly in animation--usually over 5 to 10 frames. I've included
some small test code. A few newsgroup posts mention that the current
random-number-generator in POV may need to be improved; my animation indicates
that as well.

The near-repetition of rand() is more apparent with certain seed values than
with others, but there are--in my limited experimentation--always patterns, if
you're patient enough to discern them.  It's especially obvious when using
strict integer multiples for M--3,6,9,12, for example. Actually, any multiple
of any integer. So simply using clock or frame_number to change the seed value
from frame to frame presents a problem, as they both count up linearly.

I had always thought (perhaps wrongly) that any particular value for seed would
produce a totally different rand() sequence...different enough to 'appear'
random, in any case, with no discernible pattern. Instead, it's as if a great
many seed() values are falling across or interacting with some kind of built-in
seed 'frequency.' My own analogy is light waves interfering--two waves of
different frequencies (one of them non-varying), interacting to form crests and
troughs. Or pure sine-wave sound tones causing 'beats.'

So, practically speaking: How do I get *obviously* random values in animation,
across frames? I'm stuck. Trying different schemes to vary seed hasn't worked so
far (although I haven't exhausted the idea yet.) Perhaps this:

#declare temp_seed = seed(frame_number);
#declare real_seed = seed(M*frame_number*sqrt(rand(temp_seed)));

Or this..
#declare temp_seed = seed(frame_number);
#declare real_seed = M*sqrt(clock)*rand(temp_seed);

Haven't tried these yet. (Such ideas have endless permutations!) Of course, they
could simply be substituting one pattern for another.

Here's the test code, to show the situation. Run a 100-frame animation, with
clock 0 to 1. It gives seed() a different integer for each frame, counting up
in integer multiples. The resulting visual pattern becomes apparent quite
quickly. (For fun, set multiplier M to 1000 to see an extreme situation; or 12,
for yet another clear pattern):

#declare M = 1; // or any integer--or *any* value >= 1
#declare P = seed(M*frame_number)
sphere{0,1
 texture{
  pigment{rgb 1}
  finish{
   ambient 1
   diffuse 0
   }
  }
 translate 20*rand(P)*y
 }

Post a reply to this message

Not that I have any idea about the inner working of POV's rand() generator - but
did you also try *dividing* clock or frame_number?

Maybe the integer part of the seed() argument is thrown away and only the
fraction is used?

Post a reply to this message

Kenneth wrote:
> I've run into an interesting and totally unexpected situation in v3.6.1 while
> animating, trying to produce some random values from frame to frame. I'm seeing
> repeating patterns in the values; nothing that I try eliminates them.

No, because so is the nature of a simple random number generator.

	Thorsten

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.497a1e5215dcf5ebf50167bc0@news.povray.org...
> I've run into an interesting and totally unexpected situation in v3.6.1 
> while
> animating, trying to produce some random values from frame to frame. I'm 
> seeing
> repeating patterns in the values; nothing that I try eliminates them.
> ... snip ...
> So, practically speaking: How do I get *obviously* random values in 
> animation,
> across frames? I'm stuck. Trying different schemes to vary seed hasn't 
> worked so
> far (although I haven't exhausted the idea yet.)

You could try using the same seed in each frame, using the frame_number or a 
multiple of it to step through to a fresh part of the pseudo random sequence 
. The following example throws away one for each frame that's gone before. 
If you use 10 in a frame you could loop 10 times as far through the stream.

#declare P = seed(1);
#local I = 0;
#while (I<frame_number)
  #local ThrowAway = rand(P);
#end

Post a reply to this message

clipka wrote:
> Maybe the integer part of the seed() argument is thrown away and only the
> fraction is used?

Other way around, as far as I know. The seed value is truncated.

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> I've run into an interesting and totally unexpected situation in v3.6.1 while
> animating, trying to produce some random values from frame to frame. I'm seeing
> repeating patterns in the values; nothing that I try eliminates them.

  POV-Ray uses a linear congruential generator as RNG, and those tend to
produce patterns in certain situations.

  What you can do to get a more random sequence is this:

1) On the first frame seed the RNG with whatever value (eg. 0).
2) Then pull a value with rand(), multiply it by a large value and
   #write it to a file. Then use the value in your scene in any way
   you want.
3) In subsequent frames #read that value from the file and give it to seed()
4) Repeat the steps 2 and 3.

-- 
                                                          - Warp

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Not that I have any idea about the inner working of POV's rand() generator - but
> did you also try *dividing* clock or frame_number?
>
> Maybe the integer part of the seed() argument is thrown away and only the
> fraction is used?

My own experience is that seed() values less than 1 result in *almost*
NON-varying rand()values--in my animation test, anyway, when extracting only
one rand() number per frame--so I'm guessing that POV rounds the seed value up
or down to an integer before pulling a rand()sequence. Using something like
seed(pi*frame_number) produces a pattern as well.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Kenneth wrote:
> > I've run into an interesting and totally unexpected situation in v3.6.1 while
> > animating, trying to produce some random values from frame to frame. I'm seeing
> > repeating patterns in the values; nothing that I try eliminates them.
>
> No, because so is the nature of a simple random number generator.
>

Alas, so it seems. It's interesting that, when using only one seed() value--as
in a still image--rand() has no problem producing endlessly varying values from
it. (I've never *noticed* a pattern.)  So rand() itself isn't the problem,
AFAIK.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:

>
> You could try using the same seed in each frame, using the frame_number or a
> multiple of it to step through to a fresh part of the pseudo random sequence...
>
> #declare P = seed(1);
> #local I = 0;
> #while (I<frame_number)
> #local ThrowAway = rand(P);
> #declare I = I + 1; // added by Kenneth  ;-)
> #end

That's quite interesting, and it makes great sense--it pulls a nice random value
for each frame. I'll try it!  It's one of those solutions where I smack my
forehead and say, "Of course!" I had a funny feeling that some kind of #while
loop might be a solution, though how and where had me baffled. I'll report back
with the results.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > I've run into an interesting and totally unexpected situation in v3.6.1 while
> > animating, trying to produce some random values from frame to frame. I'm seeing
> > repeating patterns in the values; nothing that I try eliminates them.
>
>   POV-Ray uses a linear congruential generator as RNG, and those tend to
> produce patterns in certain situations.
>
>   What you can do to get a more random sequence is this:
>
> 1) On the first frame seed the RNG with whatever value (eg. 0).
> 2) Then pull a value with rand(), multiply it by a large value and
>    #write it to a file. Then use the value in your scene in any way
>    you want.
> 3) In subsequent frames #read that value from the file and give it to seed()
> 4) Repeat the steps 2 and 3.
>
> --
>                                                           - Warp

Another interesting idea; thanks. I see that it would produce what's needed:
Each subsequent frame's seed is using the rand() value from the previous frame
for ITS value; so even though there are patterns, each new frame sees what
amounts to a different pattern (if I'm thinking correctly.)  Nice.

Post a reply to this message

Kenneth nous illumina en ce 2009-01-23 14:45 -->
> I've run into an interesting and totally unexpected situation in v3.6.1 while
> animating, trying to produce some random values from frame to frame. I'm seeing
> repeating patterns in the values; nothing that I try eliminates them.
> 
> The problem arose by using seed(clock) or seed(frame_number) in my SDL scene to
> generate different random seed streams for each frame (a standard method?) then
> pulling only one rand() value from that per frame--which made the patterns very
> apparent. I *thought* that by simply throwing some multiplier value 'M'
> at seed(M*clock) or seed(M*frame_number)--just one time in my POV scene, to use
> for the entire animation--would give me 'obvious' random numbers from frame to
> frame. Unfortunately, not so. There are, to my great surprise, clear
> *almost*-repeating rand() patterns, no matter what seed values I use. And it
> shows up quite quickly in animation--usually over 5 to 10 frames. I've included
> some small test code. A few newsgroup posts mention that the current
> random-number-generator in POV may need to be improved; my animation indicates
> that as well.
> 
> The near-repetition of rand() is more apparent with certain seed values than
> with others, but there are--in my limited experimentation--always patterns, if
> you're patient enough to discern them.  It's especially obvious when using
> strict integer multiples for M--3,6,9,12, for example. Actually, any multiple
> of any integer. So simply using clock or frame_number to change the seed value
> from frame to frame presents a problem, as they both count up linearly.
> 
> I had always thought (perhaps wrongly) that any particular value for seed would
> produce a totally different rand() sequence...different enough to 'appear'
> random, in any case, with no discernible pattern. Instead, it's as if a great
> many seed() values are falling across or interacting with some kind of built-in
> seed 'frequency.' My own analogy is light waves interfering--two waves of
> different frequencies (one of them non-varying), interacting to form crests and
> troughs. Or pure sine-wave sound tones causing 'beats.'
>
You can look at it this way: the seed can be taken as an offset in a constant 
pseudo random stream.

You can try moving some large, non-constant, distance between your seed values.
Something like:

seed(pow(31*pi*clock,frame_number)}



-- 
Alain
-------------------------------------------------
If you choke a Smurf, what colour does he go!

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Alas, so it seems. It's interesting that, when using only one seed() value--as
> in a still image--rand() has no problem producing endlessly varying values from
> it. (I've never *noticed* a pattern.)  So rand() itself isn't the problem,
> AFAIK.

So how about, at the end of any animation, pull one more rand() value to seed()
the next run?

Post a reply to this message

"Kenneth"  wrote in message
<web.497b219ab528db0df50167bc0@news.povray.org>:
> Alas, so it seems. It's interesting that, when using only one seed()
> value--as in a still image--rand() has no problem producing endlessly
> varying values from it. (I've never *noticed* a pattern.)  So rand()
> itself isn't the problem,

You are asking two different kinds of problems here: the randomness of one
sequence versus the randomness of the mapping seed -> first term. The first
one is guaranteed (it would not be called rand() otherwise), not the first.
For all you know, the first term could be the seed itself.

Solutions have been given to pull yourself back into the first case.

It would be a nice feature, though, to have access to a strong random
function.

Post a reply to this message

Kenneth wrote:
> I've run into an interesting and totally unexpected situation in v3.6.1 while
> animating, trying to produce some random values from frame to frame. I'm seeing
> repeating patterns in the values; nothing that I try eliminates them.
> 
> The problem arose by using seed(clock) or seed(frame_number) in my SDL scene to
> generate different random seed streams for each frame (a standard method?) then
> pulling only one rand() value from that per frame--which made the patterns very
> apparent. I *thought* that by simply throwing some multiplier value 'M'
> at seed(M*clock) or seed(M*frame_number)--just one time in my POV scene, to use
> for the entire animation--would give me 'obvious' random numbers from frame to
> frame. Unfortunately, not so. There are, to my great surprise, clear
> *almost*-repeating rand() patterns, no matter what seed values I use. And it
> shows up quite quickly in animation--usually over 5 to 10 frames. I've included
> some small test code. A few newsgroup posts mention that the current
> random-number-generator in POV may need to be improved; my animation indicates
> that as well.

I think I got this kinda solved by using this:

#local rsA=seed(frame_number);
#local rsB=seed(floor(rand(rsA)*270000));
#local rsC=seed(floor(rand(rsB)*270000));

and use rsC as your seed.

Hope this helps,
John

Post a reply to this message

"clipka" <nomail@nomail> wrote:

> So how about, at the end of any animation, pull one more rand() value to seed()
> the next run?

Another good solution--if only there was a way to 'save' that rand value to load
into my SDL scene for the next frame.  Of course, Warp's idea of
#writing/#reading would easily solve that--which I didn't think of when I was
grappling with the problem. :-(  I'm *hoping* to keep all the bits and pieces
within my SDL file, though. I think the #while loop idea seems the most
straightforward for that purpose.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> "Chris B" <nom### [at] nomailcom> wrote:
> >
> > #declare P = seed(1);
> > #local I = 0;
> > #while (I<frame_number)
> > #local ThrowAway = rand(P);
> > #declare I = I + 1; // added by Kenneth  ;-)
> > #end
>
> That's quite interesting, and it makes great sense--it pulls a nice random value
> for each frame. I'll try it!

Yes indeed, it works as advertised. Wonderful! Who cares if it wastes some rand
values; that's what computers are FOR! :-P

In thinking the idea through, I decided to make a subtle change:
With the #while loop as-is, say that instead of pulling only one rand() value
for use in my animated scene, I want to use three different ones from the same
seed, for various things. So for frame_number 1, all is well--each created
rand() value is actually used, and I'll call them rand #1, rand #2 and rand #3.
But here's what happens on frame number 2: The first rand value, #1, is wasted,
then #2, #3 and #4 are actually used. But two of those are the same values that
were used for frame_number 1. And so on.

To get around that duplication, I added a multiplier within the #while
statement:

#while(I<3*frame_number)

The multiplier represents the number of times that rand() is called in my scene.
(That number may perhaps be a bit difficult to keep track of in a complex scene,
but it works.) So for frame_number 1, rands #1 and #2 are wasted, then #3,#4 and
#5 are used; for frame_number 2, rands #1-#5 are wasted, then #6,#7 and #8 are
used; for frame_number 3, rands #1-#8 are wasted, then #9,#10,and #11 are used.
 Etc., etc. Never any repetition!

Hmm. With the added complexity, I'm not so sure now that this method would be
'easier' than the #writing/#reading one mentioned by warp (and clipka).  Must
think on it awhile...

Ken

Post a reply to this message

While we're on this subject:
I made a small .INI file called 'animation settings', where I've put stuff like
Final_Frame=100, Cyclic_Animation=on, etc. It is then called by my main .INI
file. (It's easy to change settings that way). Prior to posting this seed
problem, I had the (vague) idea that I could stick a #while loop into
'animation settings', to change some values there as the animation proceeded.
But what I found was that SDL syntax doesn't work--or isn't recognized--in an
..INI file. Looking at the docs, section "3.1.2.5.1  Constant" says that
something like a simple Declare=myvalue=1 does work. No mention of any other
syntax, though. So I assume that nothing like a loop or more complex syntax can
go there, nor any 'changing' values. Am I correct?

Continuing with that question: Is an .INI file parsed *each* time, per frame? Or
just once for the entire animation? I'm curious.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> But what I found was that SDL syntax doesn't work--or isn't recognized--in an
> ..INI file. Looking at the docs, section "3.1.2.5.1  Constant" says that
> something like a simple Declare=myvalue=1 does work. No mention of any other
> syntax, though. So I assume that nothing like a loop or more complex syntax can
> go there, nor any 'changing' values. Am I correct?

Unfortunately, yes.

> Continuing with that question: Is an .INI file parsed *each* time, per frame? Or
> just once for the entire animation? I'm curious.

Just once, unless I'm totally mistaken.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:

> You are asking two different kinds of problems here: the randomness of one
> sequence versus the randomness of the mapping seed -> first term. The first
> one is guaranteed (it would not be called rand() otherwise), not the first.
> For all you know, the first term could be the seed itself.
>

I'm not sure I really understand that whole concept. (Long ago, Warp helped me
out with a detailed discussion of the finer points of rand and seed; I need to
revisit that post for a 'refresher course'.)

Ken W.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:

> You can try moving some large, non-constant, distance between your seed values.
> Something like:
>
> seed(pow(31*pi*clock,frame_number)}
>

I had to think about this one for a little while; but rather than over-strain my
brain, I decided to simply run it, to see what would happen.  The result is very
odd: In my 100-frame test animation (pulling only one rand() value per frame),
my moving sphere STOPS moving at about frame 10. I'll try and dissect the
problem here.

Let's see: Since the clock is going 0 to 1, that would put the clock at .10
Then pow(31*pi*.10,10) = 4.2844 X 10^23

(I had to #debug the scene to find that.)

A whoppingly high value, probably over the limit of what seed (or even POV) can
process. The same thing happened during my own trial-and-error phase as well,
several times. Some seed equations just make POV go bonkers.

KW

Post a reply to this message

"Kenneth"  wrote in message
<web.497c1bf0b528db0df50167bc0@news.povray.org>:
> I'm not sure I really understand that whole concept. (Long ago, Warp helped me
> out with a detailed discussion of the finer points of rand and seed; I need to
> revisit that post for a 'refresher course'.)

Pseudo-random generators work with a sequence (in the mathematical sense, in
practice, they only keep one term in memory) of state values defined like
this:

	s_0 = seed
	s_(n+1) = m( s_n )

where m is a function that blends and mixes the input. The resulting random
numbers are:

	r_n = e( s_n )

The e function extracts the random value from the state. For example, the
s_n sequence could be a 128-bits number (or a 16-octets array), m would do
various binary and arithmetic permutations, and e would extract the middle
16-bits of the number.

The strength of a PRNG is in the s function. If you use only the first term,
then you get only the e function:

	r_0 = e( s_0 ) = e(seed)

and the e function is not designed to create pseudo-randomness.

The standard solution to this problem is to drop the recursive sequence
scheme and go for a random function. For example:

	r_n = lower_16_bits( SHA1( concat(seed, n) ) )

Post a reply to this message

Alain  wrote in message <497b6419$1@news.povray.org>:
> seed(pow(31*pi*clock,frame_number)}

What you are doing here is try to invent a brand new random function. There
are two problems with this method:

- Designing a random function is hard, and unexpected patterns often happen.
  Experts in cryptography around the world work very hard to create new
  ones, and they often fail.

- This particular function uses huge floating-point numbers, and quickly
  overflows.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> In thinking the idea through, I decided to make a subtle change...
> ...So for frame_number 1, all is well--each created rand() value is actually
> used, and I'll call them rand #1, rand #2 and rand #3...

I made a slight mistake there (I forgot that the #while loop counter was
starting at 0, not 1--which is how I usually start my own counters.) It doesn't
affect the logic of the example in any way, but allow me to re-word that
paragraph, for clarity's sake:

"With the #while loop as-is, say that instead of pulling only one rand() value
for use in my animated scene, I want to use three different ones from the same
seed, for various things. So for frame_number 1, all is well--the first rand
value is discarded, but the next three are used, and I'll call them rand #2,
rand #3 and rand #4. But here's what happens in frame_number 2: The first and
second rand values are discarded, then #3, #4 and #5 are actually used. But two
of those are the same values that were used in frame_number 1. And so on."

Ken

Post a reply to this message

"Kenneth"  wrote in message
<web.497c4cb0b528db0df50167bc0@news.povray.org>:
> I made a slight mistake there (I forgot that the #while loop counter was
> starting at 0, not 1--which is how I usually start my own counters.)

I think you made two opposite mistakes:

while(i < n * 3)

is perfectly correct if i starts at 0, but would be wrong if i started at 1.

That is the reason why you should take the habit to start your loops at 0:
it makes most of the boundaries computations easier. (Although in this
particular case, changing < into <= would be enough).

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
> > "Chris B" <nom### [at] nomailcom> wrote:
> > >
> > > #declare P = seed(1);
> > > #local I = 0;
> > > #while (I<frame_number)
> > > #local ThrowAway = rand(P);
> > > #declare I = I + 1; // added by Kenneth  ;-)
> > > #end
> >
> > That's quite interesting, and it makes great sense--it pulls a nice random value
> > for each frame. I'll try it!

> Yes indeed, it works as advertised. Wonderful! Who cares if it wastes some rand
> values; that's what computers are FOR! :-P

  Actually it doesn't waste any values. In fact, the end result is very
similar to the #write/#read solution, but without having to use the temporary
file.

  Or it is, if you only want one random value per frame. If you want several
random values per frame, then you have to "read away" all the random values
from the RNG stream that have been used in previous frames.

  If the number of random numbers generated per frame varies from frame
to frame, then it can become difficult to achieve the desired effect
without #write/#read.

-- 
                                                          - Warp

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> I think I got this kinda solved by using this:

> #local rsA=seed(frame_number);
> #local rsB=seed(floor(rand(rsA)*270000));
> #local rsC=seed(floor(rand(rsB)*270000));

> and use rsC as your seed.

  As a side note, technically speaking what you are trying to achieve is
to create a (good) hashing function which takes frame_number as parameter
and returns a value which is as "random" as possible from it.

  Researching high-quality hashing functions from online material might be
one way to go.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
>> "Kenneth" <kdw### [at] earthlinknet> wrote:
>>> "Chris B" <nom### [at] nomailcom> wrote:
>>>> #declare P = seed(1);
>>>> #local I = 0;
>>>> #while (I<frame_number)
>>>> #local ThrowAway = rand(P);
>>>> #declare I = I + 1; // added by Kenneth  ;-)
>>>> #end
>>> That's quite interesting, and it makes great sense--it pulls a nice random value
>>> for each frame. I'll try it!
> 
>> Yes indeed, it works as advertised. Wonderful! Who cares if it wastes some rand
>> values; that's what computers are FOR! :-P
> 
>   Actually it doesn't waste any values. In fact, the end result is very
> similar to the #write/#read solution, but without having to use the temporary
> file.
> 
>   Or it is, if you only want one random value per frame. If you want several
> random values per frame, then you have to "read away" all the random values
> from the RNG stream that have been used in previous frames.
> 
>   If the number of random numbers generated per frame varies from frame
> to frame, then it can become difficult to achieve the desired effect
> without #write/#read.
> 
	One way to work around this issue is to use two random streams: the
first is seeded by a constant and read in the while loop with one
iteration per frame, and the second is seeded from the first:
#declare P = seed(1);
#local I = 0;
#while (I<frame_number)
   #local ThrowAway = rand(P);
   #declare I = I + 1;
#end
#declare P = seed (P)

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Jérôme M. Berger wrote:
> Warp wrote:
>> Kenneth <kdw### [at] earthlinknet> wrote:
>>> "Kenneth" <kdw### [at] earthlinknet> wrote:
>>>> "Chris B" <nom### [at] nomailcom> wrote:
>>>>> #declare P = seed(1);
>>>>> #local I = 0;
>>>>> #while (I<frame_number)
>>>>> #local ThrowAway = rand(P);
>>>>> #declare I = I + 1; // added by Kenneth  ;-)
>>>>> #end
>>>> That's quite interesting, and it makes great sense--it pulls a nice random value
>>>> for each frame. I'll try it!
>>> Yes indeed, it works as advertised. Wonderful! Who cares if it wastes some rand
>>> values; that's what computers are FOR! :-P
>>   Actually it doesn't waste any values. In fact, the end result is very
>> similar to the #write/#read solution, but without having to use the temporary
>> file.
>>
>>   Or it is, if you only want one random value per frame. If you want several
>> random values per frame, then you have to "read away" all the random values
>> from the RNG stream that have been used in previous frames.
>>
>>   If the number of random numbers generated per frame varies from frame
>> to frame, then it can become difficult to achieve the desired effect
>> without #write/#read.
>>
> 	One way to work around this issue is to use two random streams: the
> first is seeded by a constant and read in the while loop with one
> iteration per frame, and the second is seeded from the first:
> #declare P = seed(1);
> #local I = 0;
> #while (I<frame_number)
>    #local ThrowAway = rand(P);
>    #declare I = I + 1;
> #end
> #declare P = seed (P)

	Sorry, the last line should be:
#declare P = seed (rand (P))

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

"Jérôme M. Berger" <jeb### [at] freefr> wrote:
>         One way to work around this issue is to use two random streams: the
> first is seeded by a constant and read in the while loop with one
> iteration per frame, and the second is seeded from the first

  That would work if you used two *different* linear congruential generators.
However, since you are using the one and the same, I'm not sure it would
help anything.

  It is, in fact, possible to completely replicate POV-Ray's rand() in SDL:

#declare SeedValue = 0;
#macro GetRand()
  #declare SeedValue =
    mod(Int32Mul(SeedValue, 1812433253) + 12345, 4294967296);
  (SeedValue / 4294967295)
#end

#declare Int32Mul = function(v1, v2)
{
  mod(v1, 65536) * mod(v2, 65536) +
  mod(v1, 65536) * mod(int(v2/65536), 65536) * 65536 +
  mod(int(v1/65536), 65536) * mod(v2, 65536) * 65536
};

//--------------------------------------------------------------------
#declare POV_seed = seed(0);
#declare Ind = 0;
#while(Ind < 20)
  #declare SDL_rand = GetRand();
  #declare POV_rand = rand(POV_seed);

  #debug concat("SDL: ", str(SDL_rand, 0, 10),
                ", POV: ", str(POV_rand, 0, 10), "\n")

  #declare Ind = Ind + 1;
#end

Post a reply to this message

Kenneth wrote:
> Nicolas George <nicolas$george@salle-s.org> wrote:
> 
> 
>>You are asking two different kinds of problems here: the randomness of one
>>sequence versus the randomness of the mapping seed -> first term. The first
>>one is guaranteed (it would not be called rand() otherwise), not the first.
>>For all you know, the first term could be the seed itself.
>>
> 
> 
> I'm not sure I really understand that whole concept. (Long ago, Warp helped me
> out with a detailed discussion of the finer points of rand and seed; I need to
> revisit that post for a 'refresher course'.)
> 
> Ken W.
> 
I'm going to intrude here...  This isn't anything new to this 
discussion, but it's described a bit differently and might give you 
another way to think about it.

The key is that the rand() function _should_ be seeded once and only 
once.  Then the _sequence_ of numbers it produces from that seed is 
statistically random.  (Pseudo random of course, but statistically 
truely random.)

Your original approach continually re-seeded the rand() function which 
would effectively override the normal random sequence.  The patterns you 
were seeing were due to the non-random selection of the seed values. 
The techniques suggested to overcome this are ways of being able to 
continue using the sequence produced by the rand() function from it's 
one and only seed.

Make sense?

      -=- Larry -=-

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > "Kenneth" <kdw### [at] earthlinknet> wrote:
> > > "Chris B" <nom### [at] nomailcom> wrote:
> > > >
> > > > #declare P = seed(1);
> > > > #local I = 0;
> > > > #while (I<frame_number)
> > > > #local ThrowAway = rand(P);
> > > > #declare I = I + 1; // added by Kenneth  ;-)
> > > > #end
> > >
> > > That's quite interesting, and it makes great sense--it pulls a nice
> > > random value for each frame. I'll try it!
>
> > Yes indeed, it works as advertised. Wonderful! Who cares if it wastes
> > some rand values; that's what computers are FOR! :-P
>
>   Actually it doesn't waste any values. In fact, the end result is very
> similar to the #write/#read solution, but without having to use the temporary
> file.
>
>   Or it is, if you only want one random value per frame. If you want several
> random values per frame, then you have to "read away" all the random values
> from the RNG stream that have been used in previous frames.
>
But isn't that what happens when needing just one real rand value per frame?
Given Chris B's #while loop, each new animation frame discards all the previous
frames' rand values, in order to come up with a fresh new one. (That's what I
meant by 'wasting values.') So by frame 100, the previous 99 generated values
have been discarded, as a necessity. Please clue me in if I'm not understanding
your argument clearly.

KW

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> "Kenneth"  wrote in message
> <web.497c4cb0b528db0df50167bc0@news.povray.org>:
> > I made a slight mistake there (I forgot that the #while loop counter was
> > starting at 0, not 1--which is how I usually start my own counters.)
>
> I think you made two opposite mistakes:
>
> while(i < n * 3)
>
> is perfectly correct if i starts at 0, but would be wrong if i started at 1.
>

Yes, you're right. I should have re-written my 2nd paragraph as well.

KW

Post a reply to this message

Warp wrote:
> John VanSickle <evi### [at] hotmailcom> wrote:
>> I think I got this kinda solved by using this:
> 
>> #local rsA=seed(frame_number);
>> #local rsB=seed(floor(rand(rsA)*270000));
>> #local rsC=seed(floor(rand(rsB)*270000));
> 
>> and use rsC as your seed.
> 
>   As a side note, technically speaking what you are trying to achieve is
> to create a (good) hashing function which takes frame_number as parameter
> and returns a value which is as "random" as possible from it.
> 
>   Researching high-quality hashing functions from online material might be
> one way to go.

I tested the results, and if there was a pattern, it wasn't painfully 
obvious.

Regards,
John

Post a reply to this message

"Kenneth"  wrote in message
<web.497d0d60b528db0df50167bc0@news.povray.org>:
> But isn't that what happens when needing just one real rand value per
> frame? Given Chris B's #while loop, each new animation frame discards all
> the previous frames' rand values, in order to come up with a fresh new
> one. (That's what I meant by 'wasting values.') So by frame 100, the
> previous 99 generated values have been discarded, as a necessity.

They have not been wasted, they have been used in the previous frames.

There is something that was wasted, though: CPU time: in frame 100, CPU time
is used to compute the random values #1 ... #99 in order to get to the #100
although they have already been computed for frame 99.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:

> There is something that was wasted, though: CPU time: in frame 100, CPU time
> is used to compute the random values #1 ... #99 in order to get to the #100
> although they have already been computed for frame 99.

I suppose that a more 'strictly logical' approach (in the sense of first
generating one large set of rand values to use, and not wasting any) would be
something like this, done only once during the first frame of animation:

#if(frame_number = 1)
#declare P = seed(1);
#local I = 0;
#while (I<frame_number)
#local my_rand = rand(P);
#write ***my_rand to a separate file***
#declare I = I + 1;
#end
#else
#end

Then, where I use my_rand in the scene...
#read ***a particular my_rand value from the pre-#written list***

I've left out the code details (and the 'details' may well quash the whole
scheme!), but the idea is to generate a complete list of random numbers (only
once), #write them all to a file, then #read back one rand value at a time for
use in the scene, as the animation progresses.

An interesting idea (probably the same as or similar to Warp's original
#write/#read scheme, now that I think of it.) I have no idea of its
'efficiency', though, compared to Chris B's original #while loop.

KW

Post a reply to this message

Larry Hudson <org### [at] yahoocom> wrote:

>
> Your original approach continually re-seeded the rand() function which
> would effectively override the normal random sequence.  The patterns you
> were seeing were due to the non-random selection of the seed values.
> The techniques suggested to overcome this are ways of being able to
> continue using the sequence produced by the rand() function from it's
> one and only seed.
>
> Make sense?
>
Yes (and thanks.)  In my trial_and-error phase, I very quickly 'zero-ed in' on
seed as being the culprit, but spent most of my efforts on simply trying to
vary IT from frame to frame...when that wasn't the proper approach, as I've
come to realize (thanks to the great contributions here.)

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> I suppose that a more 'strictly logical' approach (in the sense of first
> generating one large set of rand values to use, and not wasting any) would be
> something like this, done only once during the first frame of animation:
>
> ...
> Then, where I use my_rand in the scene...
> #read ***a particular my_rand value from the pre-#written list***
> ...

> An interesting idea (probably the same as or similar to Warp's original
> #write/#read scheme, now that I think of it.) I have no idea of its
> 'efficiency', though, compared to Chris B's original #while loop.

I guess it can be summed up into one word: "Desastrous" ;)

First thing to note is that it isn't any better than the original #while loop
approach: With POV SDL, unfortunately you can't just read "a particular" value
from a file. All you can do is read the file sequentially - so again you need
to pull the first numbers and discard them, until you reach the number you
want. So same problem as with Chris B's original approach.

Worse yet: Instead of a few computational steps required to pull a single random
value, you now have disk reads instead, *plus* some computational steps to parse
the plain-text numbers back to float values.

So all in all, it's quite a creative idea, but gives you more pain than gain :)

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:

> I think I got this kinda solved by using this:
>
> #local rsA=seed(frame_number);
> #local rsB=seed(floor(rand(rsA)*270000));
> #local rsC=seed(floor(rand(rsB)*270000));
>
> and use rsC as your seed.

I finally got around to running this (sorry for the delay in responding.)  It
does seem to produce nicely random values. I don't *see* any obvious patterns.
Good job, and thanks! This may, in the end, be *the* technique to use. I'll
have to play with it awhile to see.

KW

Post a reply to this message

"clipka" <nomail@nomail> wrote:
 'efficiency', though, compared to Chris B's original #while loop.
>
> I guess it can be summed up into one word: "Desastrous" ;)
>
> First thing to note is that it isn't any better than the original #while loop
> approach: With POV SDL, unfortunately you can't just read "a particular" value
> from a file. All you can do is read the file sequentially - so again you need
> to pull the first numbers and discard them, until you reach the number you
> want. So same problem as with Chris B's original approach.
>
> Worse yet: Instead of a few computational steps required to pull a single random
> value, you now have disk reads instead, *plus* some computational steps to parse
> the plain-text numbers back to float values.
>
> So all in all, it's quite a creative idea, but gives you more pain than gain :)

Ooh!  Bad idea! As Rosanne Rosanadana used to say on 'Saturday Night Live',
"Never mind." ;-)

KW

Post a reply to this message

I've come up with another permutation of Chris B's #while loop idea, this one
using an array.

For a 200-frame animation, I create a 205-element array, then fill it with rand
values. (The extra values are for 'overhead', the reason for which will become
clear.) Each time the SDL scene is run, for each frame, those same rand values
are loaded into the array. (They're always the same from frame to frame
--that's the key to how the scheme works.)

---code---
#declare R = seed(72);
#delare rand_array = array[205];
#declare I = 0; // array[0] is a valid location
#while (I < 205)
#declare rand_array[I] = rand (R);
#declare I = I + 1;
#end

Then, to use them during animation, I do something like this:

#declare frame_number = F; // starts at 1, of course
object{my_object
 rotate 360*<rand_array[F - 1], rand_array[F], rand_array[F + 1]>
 translate <rand_array[F + 2], rand_array[F + 3], rand_array[F + 4]>
      }

(It uses six rand values from the array. For frame 200, rand_array[F + 4] is at
array location 204. Remember that the array itself starts at location 0, so
that's 205 total elements needed.)

You'll probably notice that, during each new frame of animation (and an
incrementing F), five of the six rand values are used again. But they are
applied to different axes (thanks to the ever-advancing F value), so the visual
result still *looks* random enough.

Of course, this scheme is somewhat wasteful of CPU time and memory, but it has
some nice advantages:
1) The rand values are always there (in the array), waiting to be used.
2) It's possible, through some SDL coding, to create short 'repeating
animations' WITHIN the overall animation. I'm using that idea now, to generate
some 4-frame 'explosions' that show up every now and then in different random
locations. Without the pre-made array, that would be more difficult to code.
It's complex to explain, and probably a bit off-topic, but the general idea is
to create *another* 205-element array, look at rand_array's rand values, then
(with a #while loop) stick four 'ones' or 'ONs' into the second array wherever
rand_array has a value >= some value you choose. Those resulting sequential
'ones'--always there for each frame of animation, always the same--are used to
trigger one of four 'events' (by using some version of the incrementing F
value) that all show up in the *same* random location (again chosen from
rand_array--so it now serves two purposes!) My own 'events' are four image_maps
applied to thin boxes. Pulling the 'ones' out of the second array--in the proper
sequence--is somewhat complex, and so is picking the proper rand values from
rand_array to translate the four image_maps, so they all show up in the same
place. But both simply use various sequences of the changing F, as in the
example above. I do think the scheme could benefit from a #macro, though, to
make it easier to implement and change.

(This particular idea could probably be done in a simpler way, by initially
#write-ing the four image_maps to a different file, which is only #read when I
want to use one of the four events; but my present scheme is all contained in
the SDL file, no #writing or #reading required.)

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
>
> Then, to use them during animation, I do something like this:
>
> #declare frame_number = F; // starts at 1, of course

Oops--that should be reversed-- #declare F = frame_number;

Sorry!

KW

Post a reply to this message