"stbenge" <myu### [at] hotmailcom> schreef in bericht 
news:4c6d6f17@news.povray.org...
>> 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 :/

No, I think you are quite right in putting the problem foreward. It forces 
us to rethink and being more critical. That said, and me being also lazy, I 
can live with the halton code because its weakness is not going to be too 
obvious in most of my scenes and it is an easy way out to mix different 
objects without too much overlapping problems. Obviously, the weakness is 
less visible to the observer in a 3D situation.

> 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/
>

Ideally, that is what we all should want of course :-)  It is the *perfect* 
result.

> 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.

That seems indeed to be the trade-off of this method.  :-(

Thomas

Post a reply to this message