Anthony D'Agostino wrote:
> Would it be much more difficult to put them on the surface of a 
> sphere rather than a plane?

   Not really. It would even be as fast to calculate (well, approximately
at least).

> And what if you want to make sure that they are 
> as equally spaced as possible -- that they sort of repel each other.

   That would be a bit more complicated and naturally will take longer.

Post a reply to this message

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.

When faced with this problem, I usually take the easy way out and put 
them into rows and columns, with jitter to make it look random.

Regards,
John

Post a reply to this message

Oops, I had an error in my description: It was the *diameter*, not
the radius of the spheres which were 0.2 and 0.23.

   Anyways, with a small change I got the time for the spheres of
diamater 0.2 reduced to 15 seconds and the time for the ones of
diamater 0.23 to 1:50.

Post a reply to this message

John VanSickle wrote:
> When faced with this problem, I usually take the easy way out and put 
> them into rows and columns, with jitter to make it look random.

   But as I said, I don't use any fakery. The location of every single
sphere is calculated randomly accross the entire area. :)

Post a reply to this message

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'

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:446997bb$1@news.povray.org...
>    Oops, I had an error in my description: It was the *diameter*, not
> the radius of the spheres which were 0.2 and 0.23.
> 
>    Anyways, with a small change I got the time for the spheres of
> diamater 0.2 reduced to 15 seconds and the time for the ones of
> diamater 0.23 to 1:50.

quite a difference :)

best I could come up with, is more or less the naive way, where I, in a 
way, let POV-Ray itself check the intersections, instead of doing the 
checks in POV-SDL:

-- begin code --
camera {
 location <1,8,4>*2
 look_at 0
}
light_source {<75,180,500> rgb 1}
#declare Seed=seed(354);
#declare MinCoords=<-10,0,-10>;
#declare MaxCoords=<10,0,10>;
#macro Location()
 #local R=MinCoords+(MaxCoords-MinCoords)*<rand(Seed), 0, rand(Seed)>;
 R
#end
#declare TestTexture=sphere {MaxCoords*10,.01}

#declare Count=5000;
#declare Radius=.1;

#while (Count>0)
 #local Loc=Location();
 #if (inside(TestTexture,Loc)=0)
  sphere {Loc,Radius pigment {rgb <rand(Seed),rand(Seed),rand(Seed)>} 
finish {ambient .25 specular 1}}
  #declare TestTexture=union {object{TestTexture} sphere 
{Loc,Radius*2}}
  #declare Count=Count-1;
  //#debug concat(str(Count, 0, 0)," to go\n")
 #end
#end
-- end code --

takes 1'30" for a diameter of .2 and 6'51" for a diameter of .23

(but I only have an athlon xp 2500+ :))

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen wrote:

> 
> takes 1'30" for a diameter of .2 and 6'51" for a diameter of .23
> 
> (but I only have an athlon xp 2500+ :))
> 
Ran it on an Athlon dualcore 3800 (64bit Linux)
33 sec for 0.2 diameter
230 sec for 0.23 diameter
-- 
Ger

Post a reply to this message

"Ger" <No.### [at] ThankYou> wrote in message 
news:4469c92d@news.povray.org...
> Zeger Knaepen wrote:
> 
> > 
> > takes 1'30" for a diameter of .2 and 6'51" for a diameter of .23
> > 
> > (but I only have an athlon xp 2500+ :))
> > 
> Ran it on an Athlon dualcore 3800 (64bit Linux)
> 33 sec for 0.2 diameter
> 230 sec for 0.23 diameter

hmm, huge difference, I think it's time for a new pc :)

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Hi Warp,

I like your smart programming.

But here is my question:

Let's say, I intend to place a ramdom-generated pattern of spheres (such as 
yours) on an unequal surface (maybe a heightfield or a union of objects). 
How, then, would the code look alike? Can you help me?

Greetings,

Sven

Post a reply to this message

Sven Littkowski wrote:
> Let's say, I intend to place a ramdom-generated pattern of spheres (such as 
> yours) on an unequal surface (maybe a heightfield or a union of objects). 

   My method can actually be used for any distributions of spheres,
not just a plane. You only have to come up with a formula which
calculates a random placement for the spheres in whatever shape
you want (eg. the surface of an object). Of course with certain
shapes calculating an even distribution may not be as trivial
as a simple <rand(S), rand(S), rand(S)> (for example distributing
points about evenly on the surface of a sphere requires a function
slightly more complicated).
   If you want to place spheres on the surface of an object you'll
have to use trace to get points on that object and figure out a
way to distribute these points approximately equally on the surface
of the whole object (with a spherical surface it's rather easy but
with other more irregular surfaces it can be more difficult).

> How, then, would the code look alike? Can you help me?

   The naive approach is to simply store the locations of the spheres
already created in an array and then when a new sphere is created,
check it against each coordinate in this array (iow. check if the
center of the sphere you just created is closer than the diameter
of the sphere to any of the coordinates in the array; if it is closer
to any of the points, then it's not ok and you have to create another
location for the new sphere; after you successfully create it, add
its center coordinates to the array).

   My optimized method uses this basic approach but I figured out a
rather simple way of speeding up the check a *lot*.
   The good thing about this approach is that you can have *any*
distribution for the spheres you like (eg. on the surface of any
object or whatever), and this algorithm will never produce spheres
which are intersecting.

   I can post a description of my simple method in povray.general if
people are interested. (It's probably nothing new and other people
have probably already thought of it, but perhaps my specific approach
is more resource-friendly than most other attempts.)

Post a reply to this message