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