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