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

Well I've got 15 seconds for the 0.2 diameter spheres, but I'm currently up 
at 3 minutes 53 seconds for  the 0.23 diameter ones (on a 1.8GHz machine).

Regards,
Chris B.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
>    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.

Running 3.6 on a 1.8GHz laptop with 512MB RAM:

0.2  = 0:08
0.23 = 1:26

(note: this is with the centers constrained to <-10,0,-10><10,0,10>)

-tgq

Post a reply to this message

Trevor G Quayle wrote:
> Running 3.6 on a 1.8GHz laptop with 512MB RAM:
> 
> 0.2  = 0:08
> 0.23 = 1:26

   I guess we use the same technique but you optimized the SDL more
to be faster. Or perhaps you use something really innovative?

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Trevor G Quayle wrote:
> > Running 3.6 on a 1.8GHz laptop with 512MB RAM:
> >
> > 0.2  = 0:08
> > 0.23 = 1:26
>
>    I guess we use the same technique but you optimized the SDL more
> to be faster. Or perhaps you use something really innovative?

Depends, I haven't seen yours yet... but based on the times, I would assume
they are similar.  I don't think I did anything really innovative, just
tweaked my algorithm to try to minimize the calcs required as much as
possible.  Actually I started with a bit higher times for the 0.23, but
made some algorithm optimizations to speed it up, then made some SDL
optimizations for further speeding.

-tgq

Post a reply to this message

Greetings, and thanks for your answer.

Yes, I would be interested to see how the code for the object distribution 
would be. I tried on my own, a few successless times before, but had not 
even the right beginning idea.

And to be honest, if you could show me how to trace the surface(s) of an 
object on which the objects should be distributed, I would appreciate it a 
lot! I am asking, because I also have no idea how to do that.

Thanks,

Sven



"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag 
news:4469e328$1@news.povray.org...
> 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

94 seconds on an Athlon Xp-1700.  The first iteration gave me about 3 
minutes, the second got me to that.  Once I figured what it was, the 
only thing I could say was "Doh!"

...Chambers

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > Trevor G Quayle wrote:
> > > Running 3.6 on a 1.8GHz laptop with 512MB RAM:
> > >
> > > 0.2  = 0:08
> > > 0.23 = 1:26
> >
> >    I guess we use the same technique but you optimized the SDL more
> > to be faster. Or perhaps you use something really innovative?
>
> Depends, I haven't seen yours yet... but based on the times, I would assume
> they are similar.  I don't think I did anything really innovative, just
> tweaked my algorithm to try to minimize the calcs required as much as
> possible.  Actually I started with a bit higher times for the 0.23, but
> made some algorithm optimizations to speed it up, then made some SDL
> optimizations for further speeding.
>
> -tgq

One further refinement in the algorithm

0.2  = 0:08 (no significant change)
0.23 = 1:11

-tgq

Post a reply to this message

Interestingly if you constrain the entire sphere volume to the given area
(20x20) rather than the center positions, the parse time triples...

-tgq

Post a reply to this message

Warp wrote:

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

Do you have problems with it turning into an O(n^2) problem, or is there 
some kind of shortcut to make things go faster?

Regards,
John

Post a reply to this message

John VanSickle wrote:
> Do you have problems with it turning into an O(n^2) problem, or is there 
> some kind of shortcut to make things go faster?

   AFAIK the method I use is faster than O(n^2), although it might not
be immediately obvious from the code.
   (Although don't quote me on that. Trying to prove that claim is
actually quite difficult... :P )

Post a reply to this message