Hi Warp,

Here's the result from a file I set up a while ago, using your radii.

On a P3, 933MHz the parsing for the 0.1 radius was 41s, for the 0.115 
radius it was 10m20s (620s).

I wonder if we're using the same technique ...

Mike.

Warp wrote:
>   Inspired by a post I made to another group, I thought if I could find
> a fast way to create a large amount of randomly-placed spheres on a plane
> so that they don't intersect each other.
> 
>   In these images I created 5000 spheres randomly placed inside an area
> between <-10, 0, -10> and <10, 0, 10>. The locations of each sphere is
> individually calculated with just a honest
> MinCoords+(MaxCoords-MinCoords)*<rand(Seed), 0, rand(Seed)>
> ie. no cheating by creating repeating patterns which just look random
> or anything. The location of each sphere is honestly calculated by
> with that line.
> 
>   In the first image the radius of the spheres is 0.2 and it took
> 17 seconds to parse in my P4 3.4GHz. In the second image the radius
> is 0.23 and it took a lot longer because the space fills faster and
> it's harder to find places for new spheres: 2 minutes 44 seconds.
> 
>   The naive way of doing this (which I posted in that another group)
> took more than 7 minutes to place the spheres of radius 0.2 (compared
> to the 17 seconds of my optimized method). I don't know how much longer
> than 7 minutes it is because I got bored of waiting and stopped it.
> 
>   The scene which created these images is 76 lines long (written in
> a nice, indented way, no obfuscation nor artificial shortening, and
> it even prints its progress during the calculations).
> 
>   If you want a small challenge, try replicating this result.
> 
>

Post a reply to this message

Attachments:
Download 'array_fill1.jpg' (69 KB) Download 'array_fill2.jpg' (67 KB)

Preview of image 'array_fill1.jpg'

Preview of image 'array_fill2.jpg'