 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was doing a render earlier today, and I got to wondering about
something... Suppose you write something like
#declare A = seed(...);
#declare J = rand(A);
#declare K = rand(A);
POV-Ray's rand() function returns random numbers in the (closed?)
invertal 0..1. But what is the minimum difference between J and K?
Presumably if you're really fluky they might just happen to have the
exact same value (improbable but not impossible). Assuming this is
not the case, what is the smallest amount they can differ by?
Specifically, I presume that POV-Ray does its calculations using some
finite level of precition. Is the minimum difference in random
answers equal to the minimum possible difference at this precition,
or is it larger? (If that makes sense!)
It's not earth-shatteringly important for me to find out the answer,
I'm just curiose ;-)
Andrew.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPZL+L7EpzUF0Y1JeEQJk9QCdHbkAT020LB8gUwh8tEkA1ozXSegAoP5A
lbC5fJdNcH7QKG49lTvBdRmg
=aG6m
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You can, of course, test against equality if you wanted to prevent that.
Simply by doing #if (J!=K) /* do whatever */ #end
I don't know the exact method used for a random number in POV without trying
to look it up but I'd guess its precision is the same as for any of the
math, meaning it is probably random down to the same decimal levels of other
numbers.
Just checked here using (no camera of light needed):
#declare S=seed(1234);
#declare R=rand(S);
#text {ttf "times.ttf",str(R,0,18),0.1,0
translate <-5,-0.25,10>
pigment {rgb 9}}
And this seems to get to 17 decimal places, rest are zeroes. If you use the
system specific way, -1 instead of 18 in the str(), you'll probably see it
to only 6 decimals. So it depends a lot on how you use it. 17 decimal places
leaves very little room for chance of getting two identical random numbers,
if it does indeed remain randomized over time.
This isn't the same reasoning for the seed(), it allows for the same
generation of a sequence of random numbers or else you wouldn't get
identical scenes each render.
--
Farewell,
Bob
"Andrew Coppin" <orp### [at] btinternet com> wrote in message
news:3d93103a@news.povray.org...
>
> #declare A = seed(...);
> #declare J = rand(A);
> #declare K = rand(A);
>
> POV-Ray's rand() function returns random numbers in the (closed?)
> invertal 0..1. But what is the minimum difference between J and K?
> Presumably if you're really fluky they might just happen to have the
> exact same value (improbable but not impossible). Assuming this is
> not the case, what is the smallest amount they can differ by?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d93103a@news.povray.org>,
"Andrew Coppin" <orp### [at] btinternetcom> wrote:
> It's not earth-shatteringly important for me to find out the answer,
> I'm just curiose ;-)
Hmm, that's a good question...true "random" numbers would have a minimum
difference of 0. Given the finite number of values of computer math, it
would have a small but finite probability of happening to consecutive
values. However, it might be impossible for the algorithm POV uses to
generate identical consecutive values...
As a wild guess, I'd say the minimum difference without being identical
between any two values (not just consecutive values) would be 1/(~2 or 4
billion), depending on whether POV uses a signed or unsigned long scaled
down to a double in the [0, 1] range. In other words, too small to worry
about if you are concerned about any kind of "stepping".
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks guys. Wasn't "worried" - just curiouse ;-)
Andrew.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> Hmm, that's a good question...true "random" numbers would have a minimum
> difference of 0. Given the finite number of values of computer math, it
> would have a small but finite probability of happening to consecutive
> values. However, it might be impossible for the algorithm POV uses to
> generate identical consecutive values...
> [...]
Hmm, i'm not sure. If it is possible that two consecutive occur in a
sequence of random numbers what is the probability of this event?
In fact i don't even know if mathematics deal with something like non
integer random numbers.
Of course this does not change anything about the POV-Ray random number
generator having it's limitations.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3D93329F.A5E1E5C4@gmx.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> Hmm, i'm not sure. If it is possible that two consecutive occur in a
> sequence of random numbers what is the probability of this event?
Ideally, just as likely as any other single combination. That is, not
very likely with this large of a large set of possible combinations.
Say you have 2 (identical) dice. Is the 1:1 combination less likely than
the 1:4 combination?
> In fact i don't even know if mathematics deal with something like non
> integer random numbers.
It does, it doesn't matter if it is integer or not, as long as it is a
set of specific values. There is a finite number of values that can be
represented with a double precision variable, with a perfect random
number generator any one of those values would be equally likely,
whether or not it had just come up the previous time. Assuming the
values are evenly spaced, that is...I think. It depends on how you look
at it and what exactly you want, I guess.
Ok, IANAM (I Am Not A Mathematician), and have never taken a statistics
or set theory course, but:
Picking a random value from a finite set, each value has an equal chance
of coming up, even if it was the previous value.
A perfect random number generator would produce a flat distribution, any
range of resulting values would on average be hit the same number of
times as any other range of equal length. You will get the same number
of values in the range [0, 0.1] as in [0.5, 0.6] and [0.9, 1]. (on
average of course)
I do not think all possible values a double can hold in the [0, 1] range
are evenly distributed...it is probably close enough though. If the
distribution is off, say there are twice as many values in the lower
half of the range then in the upper half, a specific value in the lower
half will have to be less likely than a specific value in the upper half
if you want to keep a flat distribution. However, POV creates a
pseudo-random integer value and scales it down to the right range, so
they are evenly spaced as well as a double value can approximate and the
generator can generate.
BTW, the algorithm POV uses to compute the next random number is:
next_rand[stream] = next_rand[stream] * 1812433253L + 12345L;
return((DBL)(next_rand[stream] & 0xFFFFFFFFUL) / 0xFFFFFFFFUL);
The seed() function sets the initial value of next_rand and returns the
stream index.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> > In fact i don't even know if mathematics deal with something like non
> > integer random numbers.
>
> It does, it doesn't matter if it is integer or not, as long as it is a
> set of specific values. There is a finite number of values that can be
> represented with a double precision variable, with a perfect random
> number generator any one of those values would be equally likely,
> whether or not it had just come up the previous time. Assuming the
> values are evenly spaced, that is...I think. It depends on how you look
> at it and what exactly you want, I guess.
>
> [...]
All right, but mathematics don't care about double precision so since
there is an infinite number of real numbers between 0 and 1...
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
>
> Ideally, just as likely as any other single combination. That is, not
> very likely with this large of a large set of possible combinations.
> Say you have 2 (identical) dice. Is the 1:1 combination less likely than
> the 1:4 combination?
>
Really one die thrown twice might be a better example. Otherwise 4:1 would
be considered along with 1:4.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote in message
news:3D93604D.4292E793@gmx.de...
>
> All right, but mathematics don't care about double precision so since
> there is an infinite number of real numbers between 0 and 1...
>
Would this matter? The second hand of a clock points in an infinite number
of directions, but also moves in infinitely small increments, so at some
point each minute the second hand is pointing exactly at the center of the
12 on the clock. It spends as much time in this position as in every other
(infinite) position on the clock.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
>
> > All right, but mathematics don't care about double precision so since
> > there is an infinite number of real numbers between 0 and 1...
> >
>
> Would this matter? [...]
Yes, this means the chance that two consecutive random numbers have
exactly the same value is infinitely small.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote in message
news:3D93663B.471DD47E@gmx.de...
>
> Yes, this means the chance that two consecutive random numbers have
> exactly the same value is infinitely small.
>
...and equal to any other sequence. I think that we are all agreeing with
each other.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 26 Sep 2002 14:56:13 -0400, Christopher James Huff
<chr### [at] maccom> wrote:
>Say you have 2 (identical) dice. Is the 1:1 combination less likely than
>the 1:4 combination?
Yes. Given that the two dice are identical you can't tell the
difference between 1:4 and 4:1, thus 4:1 is twice as likely to occur
as 1:1. If we change the premise so we only have one dice that we roll
twice 1:4 is as likely to occur as 1:1, now we've given value to the
order (1:4 <> 4:1). If you really want fun with permutations, try to
calculate the cumulative odds on a slot machine. I once attempted that
for a simulated slot machine I programmed, I ended up fiddling the
values until emparative testing showed the desired return rate (or
close enough) instead.
/Erkki
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3D93604D.4292E793@gmx.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> All right, but mathematics don't care about double precision
What branch of mathematics are you thinking of? Computer science is
largely mathematics, and definitely does care. Finite binary
representations of numeric values may not matter in the abstract
concepts of mathematics, but those concepts do deal with the same
situations.
> so since there is an infinite number of real numbers between 0 and
> 1...
A specific value still has the same chance of coming up. It doesn't
matter if it has already come up the previous time, or the previous 10
times. Um...I really don't know how to express this, I haven't taken any
classes in it or done much research on my own. The probability seems to
be 0 but is obviously not 0, and I thought things like the term
"infinitesimal" weren't used any more. How about: as the size of the set
(n) increases towards infinity, the probability of a specific value
being picked (1/n) decreases towards 0, with all values having an equal
possibility of being picked.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d93677c.99183057@news.povray.org>,
Erk### [at] povrayorg (Erkki S?ndergaard) wrote:
> Yes. Given that the two dice are identical you can't tell the
> difference between 1:4 and 4:1, thus 4:1 is twice as likely to occur
> as 1:1. If we change the premise so we only have one dice that we roll
> twice 1:4 is as likely to occur as 1:1, now we've given value to the
> order (1:4 <> 4:1). If you really want fun with permutations, try to
> calculate the cumulative odds on a slot machine. I once attempted that
> for a simulated slot machine I programmed, I ended up fiddling the
> values until emparative testing showed the desired return rate (or
> close enough) instead.
Gah, alright, I misstated the problem. You know what I meant... ;-)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> > All right, but mathematics don't care about double precision
>
> What branch of mathematics are you thinking of? Computer science is
> largely mathematics, and definitely does care. [...]
I'm talking about those parts of mathematics that consider there are an
infinite number of real numbers between 0 and 1.
I'm not sure about the precise english terms, but math distinguishes
between natural numbers (integers: 1, 2, 3, ...), rational numbers
(numbers that can be represented as a fraction of two natual numbers) and
real numbers (rational numbers and all other numbers like sqrt(2), pi,
etc.). The latter two categories are those where two consecutive random
numbers from a given range won't be identical (assuming there is a
mathematical definition of random numbers in that category, which i
doubt).
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3D937770.2863EBC7@gmx.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> I'm not sure about the precise english terms, but math distinguishes
> between natural numbers (integers: 1, 2, 3, ...), rational numbers
> (numbers that can be represented as a fraction of two natual numbers) and
> real numbers (rational numbers and all other numbers like sqrt(2), pi,
> etc.). The latter two categories are those where two consecutive random
> numbers from a given range won't be identical
If you can consider any two real numbers to be equal, it is possible for
two consecutive random real numbers to be equal (if you could find a
source of random reals...even analog circuitry would have a discrete
number of steps). Rationals can even be represented with a computer,
though you are practically limited by processing time and memory.
It *is* unlikely to happen in a finite range, and less likely the
smaller the range. In an infinite random stream of numbers, *every*
possible combination will occur, and the pattern of two consecutive
equal real numbers is no less likely than any other pattern of two real
numbers. 10 consecutive numbers being equal is no less likely than any
other specific sequence of 10 numbers.
There is definitely no reason for it to be impossible...if you forbade
these "runs", you wouldn't have a truely random sequence any more.
> (assuming there is a mathematical definition of random numbers in
> that category, which i doubt).
Why not?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 26 Sep 2002 08:31:46 -0400, Andrew Coppin quoth:
> I was doing a render earlier today, and I got to wondering about
> something... Suppose you write something like
>
> #declare A = seed(...);
> #declare J = rand(A);
> #declare K = rand(A);
>
> POV-Ray's rand() function returns random numbers in the (closed?)
> invertal 0..1. But what is the minimum difference between J and K?
> Presumably if you're really fluky they might just happen to have the
> exact same value (improbable but not impossible).
Because of the way that POV-Ray's random number generator works, it will
never produce the same number twice in a row (if it did, it would then
proceed to produce that number every single time).
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <pan### [at] gtenet>,
Mark Wagner <mar### [at] gtenet> wrote:
> Because of the way that POV-Ray's random number generator works, it will
> never produce the same number twice in a row (if it did, it would then
> proceed to produce that number every single time).
It will never produce the same integer value. I'm not sure rounding
error won't make some of those integer values equal the same double
value...I doubt it, but I'm not certain. It isn't something I'd worry
too much about.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 26 Sep 2002 20:08:30 GMT, Erk### [at] povrayorg (Erkki
Søndergaard) wrote:
>Yes. Given that the two dice are identical you can't tell the
>difference between 1:4 and 4:1, thus 4:1 is twice as likely to occur
>as 1:1.
I still remember that particular lesson in high school. My math
teacher in high-school, a very good backgammon player BTW, had the
same argument. I then asked whether that meant that playing with a
pair of white dice gave you a better chance of throwing double-6 than
if playing with a black and a white on. We had a good laugh :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
> Because of the way that POV-Ray's random number generator works, it will
> never produce the same number twice in a row (if it did, it would then
> proceed to produce that number every single time).
Then it's a rather poor random number generator, I must say.
In a good random number generator, any combination of two numbers (including
the same number twice) should be about equally probable.
Of course this is a very difficult issue.
I wonder if an approach like the drand48() function would be better.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d9434b1@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Then it's a rather poor random number generator, I must say.
> In a good random number generator, any combination of two numbers (including
> the same number twice) should be about equally probable.
> Of course this is a very difficult issue.
I don't think this alone makes it so bad, its other characteristics seem
fair. Not great, but not horrible. It is an extremely simple algorithm,
I posted the code earlier in this thread.
If you want a really good generator, the Mersene Twister might be
suitable...I've heard good things about it, and wrote an implementation
of it that seems to work fine.
> I wonder if an approach like the drand48() function would be better.
What approach would that be?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
>> I wonder if an approach like the drand48() function would be better.
> What approach would that be?
From the drand48 man page:
Functions drand48() and erand48() return non-negative
double-precision floating-point values uniformly distributed
over the interval [0.0, 1.0].
[snip]
All the routines work by generating a sequence of 48-bit
integer values, Xi , according to the linear congruential
formula
X n+1= (aX n+c) mod m n>=0.
The parameter m = 2**48; hence 48-bit integer arithmetic is
performed. Unless lcong48() has been invoked, the multiplier
value a and the addend value c are given by
a = 5DEECE66D16 = 2736731631558
c = B16 = 138 .
The value returned by any of the functions drand48(),
erand48(), lrand48(), nrand48(), mrand48(), or jrand48() is
computed by first generating the next 48-bit Xi in the
sequence. Then the appropriate number of bits, according to
the type of data item to be returned, are copied from the
high-order (leftmost) bits of Xi and transformed into the
returned value.
The functions drand48(), lrand48(), and mrand48() store the
last 48-bit Xi generated in an internal buffer. Xi must be
initialized prior to being invoked.
[snip]
The initializer function srand48() sets the high-order 32
bits of Xi to the 32 bits contained in its argument. The
low-order 16 bits of Xi are set to the arbitrary value
330E16 .
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> represented with a double precision variable, with a perfect random
> number generator any one of those values would be equally likely,
<g>
But then, for perfect random number generator, wouldn't we need to
plug a fresh cup of really hot tea into the USB port and use the
non-standard C function getbrownian() and somehow cast the
resulting vector as a double? Alas, I understand getbrownian()
isn't directly supported on all the platforms that POV-Ray is
compiled for, (or any of them, in fact) so this might somewhat
hurt portability.
</g>
--
@C[$F];
The Silver Tome :: http://www.silvertome.com
"You may sing to my cat if you like..."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 27 Sep 2002 20:11:30 -0400, Charles Fusner <cfu### [at] enternet>
wrote:
>But then, for perfect random number generator, wouldn't we need to
>plug a fresh cup of really hot tea into the USB port and use the
>non-standard C function getbrownian() and somehow cast the
>resulting vector as a double?
The problem with this approach is that the second law of
thermodynamics will kick in, which means that in animations, later
frames will have lower dispersion in their random sequences. This will
also result in pretty interesting vertical gradient patterns in
radiosity pictures due to the random number generator cooling down
during the long render.
<follow-ups set>
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27 Sep 2002 11:54:18 -0400, Warp <war### [at] tagpovrayorg> wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
>>> I wonder if an approach like the drand48() function would be better.
>
>> What approach would that be?
>
> From the drand48 man page:
>
> Functions drand48() and erand48() return non-negative
> double-precision floating-point values uniformly distributed
> over the interval [0.0, 1.0].
...
some time ago I played with PRNG's...
'worst-case' simulation or something.
25000 spheres were 'randomly' positioned.
'incr-seeds' means that for every sphere different initial seeds
were used (little bigger than for the previous sphere).
for every sphere position six (pseudo) random number generator
states (or seeds) were needed.
now, if spheres are not placed uniformly, it means that seed
values correlate with the output of the generator
(bad thing for a PRNG).
'one-seeding' means that for all of the 25000 sphere positions
only six seeds were used (and I mean six in TOTAL).
if spheres are not placed uniformly (in both -1 and -2 jpg),
it means that the PRNG plainly sucks.
I made patch for povray 3.5 which allows using GSL's RNG's
by defining env var POVRAY_USE_GSL and then wanted generator
in GSL_RNG_TYPE. if POVRAY_USE_GSL is not defined, SHA-512 is used.
of every PRNG in GSL v1.2, only mt19937 was 'okay' in my *humble*
opinion. YMMV.
(GSL+SHA-512 patch not available for public as for now)
scene file source
http://iki.fi/safari/prng/rnd_sphere2.pov
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-rand48-1.jpg
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-rand48-2.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-rand48-1.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-rand48-2.jpg
compare to a 'better' PRNG
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-sha-512-1.jpg
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-sha-512-2.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-sha-512-1.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-sha-512-2.jpg
and with povray 3.5's official PRNG
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-orig-1.jpg
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-orig-2.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-orig-1.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-orig-2.jpg
interesting, it's almost like rand48.
usually povray's PRNG is sufficient, but sometimes I get
artefacts in photon shooting (not evenly placed or something)...
and, of course, when using this kind of scene file :)
(yes, SHA1 would probably give same kind of results than SHA-512,
but that's another story)
--
Safari - y7p### [at] sneakemailcomgovinvalid
"Talk is cheap. Show me the code." - Linus Torvalds
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
