Thomas de Groot wrote:
> "stbenge" <myu### [at] hotmailcom> schreef in bericht 
> news:4c6c1d8d@news.povray.org...
>> I think that gaining some speed isn't worth the result. Like the other 
>> Halton sequences I have seen, the one you rendered shows a lot of 
>> repetition. And there are numerous instances in which the particles line 
>> up unnaturally. In fact, they are so numerous that they cannot be 
>> misconstrued as mere coincidences.
> 
> OK, yes, there are indeed repetitions, alignments and oriented gaps. I agree 
> with you that this is not perfectly random.

I'm probably just nitpicking :/

>> Have you tried placing ten times the number of particles that you used for 
>> that example? With smaller particle sizes? Is so, do the particles ever 
>> overlap? I suppose that if you can use more particles, then the 
>> periodicity may not be much of an issue, but the diagonal alignment 
>> problem will still be present.
> 
> See my third example in p.b.i. (red) compared to rand() in green.

They look a little better.

>> I've been thinking about just making some scripts to generate spaced point 
>> sets with min/max particle sizes, pigment-based distribution, and maybe 
>> even some macros for accessing the points.
> 
> That would be perfect, Sam :-)

I'm not sure that the time it takes to parse large sets is really worth 
it. See the image I posted in p.b.i.:
http://news.povray.org/povray.binaries.images/thread/%3C4c6d67d5%40news.povray.org%3E/

It took 23 minutes, 36 seconds to parse. Out of the 50,000 tests I gave 
it to perform, only a mere 3,065 succeeded. To me, this is unacceptable. 
If you were to populate a landscape with rocks or trees, you would need 
more points than that. To make matters worse, the parse time goes up 
with each new point added. I even used two optimizations. In one, a 
point stops trying to be placed after the first overlap. The other one 
bails out completely after failing to place a new random point n 
consecutive times. I didn't use the latter for that render. If I had, 
the parse time wouldn't have been as long, but there would have been 
fewer points. If, after all this you still want some code, I'll go ahead 
and finish the file-writing routines, which is the easy part.

Another method is to just code this in C++, using a bitmap-like array to 
test against. It's not as accurate, but it's much faster and you get to 
see the progress, and can bail out manually at any time, saving the 
successful points. I've already got a rough version, but I need to learn 
more about vector.h before I can finish it.

Post a reply to this message