news:3fb30aa5$1@news.povray.org...
> Oh boy, what a long thread ...

> Because the usage of such a macro should not depend on its inner
> workings, I think it is bad (or at least questionable) programming
> style to rely on the specific algorithm used for the implementation.
> (Remember: the macro is supposed to deliver *random* points, so
> even a truly random hardware generator that never repeats the same
> (long) sequence should be accepted!)

<snip>

I think you're missing the point - when using rand in a scene I will often throw
various seeds at it until I get a distribution I like. This distrib will be
random - I'm not aiming for a particular numeric sequence - but in the interests
of a nice image some random sequences will produce better results.

Take a look at:

http://www.tomandlu.co.uk/webres/raytracing/gallery/pics/tmsummer.jpg
and
http://www.tomandlu.co.uk/webres/raytracing/gallery/pics/tmwinter.jpg

the branch distrib is undeniably random, but a different sequence will not
produce the same aesthetic effect. Now in this case I'm using plain rand + my
own algorithms, but if the supplied macros are to be taken seriously, then they
have to produce consistent results. Bug fixing is one thing, but (fairly)
arbitary changes every time a speed-increase is found is another. Much better
IMHO to provide improved macros with different names (or some sort of version
directive as suggested by others).

Post a reply to this message