 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Argh ... that hurts quite a bit ...
My new algorithm manages to place
32000 Spheres in ~6mins ... thats
"a bit" faster than my other try...
The "problem" with this one is, that
I can no guarantee any longer , that
it is without collisions, but the
probability is quite low ...
Post a reply to this message
Attachments:
Download 'simpleBackground2.jpg' (48 KB)
Preview of image 'simpleBackground2.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzer net> wrote in message
news:3cc0302b@news.povray.org...
>
> My new algorithm manages to place
> 32000 Spheres in ~6mins ... thats
> "a bit" faster than my other try...
>
That's about 1% of the former time, right? Now you can spend the time you
saved rendering all of the balls as glass with photons and radiosity.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> My new algorithm manages to place
> 32000 Spheres in ~6mins ... thats
> "a bit" faster than my other try...
>
> The "problem" with this one is, that
> I can no guarantee any longer , that
> it is without collisions, but the
> probability is quite low ...
What's the idea behind the new algorithm?
Bonsai
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jan Walzer" <jan### [at] lzernet> wrote in message
news:3cc0302b@news.povray.org...
> Argh ... that hurts quite a bit ...
>
> My new algorithm manages to place
> 32000 Spheres in ~6mins ... thats
> "a bit" faster than my other try...
>
> The "problem" with this one is, that
> I can no guarantee any longer , that
> it is without collisions, but the
> probability is quite low ...
>
>
just a thought...when i done this image, each smiley was random on the x and
y coordinates but was always translated a constant 1 unit on z. this
ensured no collisions. i also increased the x and y spread a tiny fraction
after each pass to make them look less cluttered as they go to the distance.
john
Post a reply to this message
Attachments:
Download 'smiley.jpg' (101 KB)
Preview of image 'smiley.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John Robinson wrote:
> just a thought...when i done this image, each smiley was random on the x and
> y coordinates but was always translated a constant 1 unit on z. this
> ensured no collisions. i also increased the x and y spread a tiny fraction
> after each pass to make them look less cluttered as they go to the distance.
That is one happy image! :-D
--
------------------------------------------------------------------------
+47 90 62 71 78 DoD#2101, DoDRT#017, NIC#015, PJ#006, OGM#007
azo### [at] dodno, Ducati M600, Clementine Ubesudlet: Aldri eid en J&%#PS.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bonsai" <bon### [at] b0n541net> asked:
> What's the idea behind the new algorithm?
If it were done on a recent gfx-card, it would be called
tile-based-rendering ...
I simply subdive the area, I want to fill in smaller
ones, and only do inside these ones the collisiontest.
But that means, there "can" be collisions when two sub-areas
collide, especially when I specify a high density.
But I can't simply make the subareas smaller, and leave
a border around, because this would also make the tiles
visible...
I need to do some more experiments with that ...
BTW: here are 408000 spheres, distributed over 20x51
patches with 400 spheres in each patch.
1:48:22 Parse, 0:02:39 Trace (2560x1024,AA0.2)
Post a reply to this message
Attachments:
Download 'simpleBackground2.jpg' (97 KB)
Preview of image 'simpleBackground2.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My include file does about 50,000/minute on a 133 MHz PI. However, I don't
include anything to prevent sphere overlap. Still, it can do random scaling
and rotation.
I use a separate loop for each combo of random location, size, and rotation.
Also, I take EVERYTHING I can out side of the main while loop.
Sam
news:3CC05370.8891DF27@dod.no...
> John Robinson wrote:
>
> > just a thought...when i done this image, each smiley was random on the x
and
> > y coordinates but was always translated a constant 1 unit on z. this
> > ensured no collisions. i also increased the x and y spread a tiny
fraction
> > after each pass to make them look less cluttered as they go to the
distance.
>
> That is one happy image! :-D
>
> --
> ------------------------------------------------------------------------
> +47 90 62 71 78 DoD#2101, DoDRT#017, NIC#015, PJ#006, OGM#007
> azo### [at] dodno, Ducati M600, Clementine Ubesudlet: Aldri eid en J&%#PS.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Would you mind releasing the code? I love the perspective in this scene.
D.
"Jan Walzer" <jan### [at] lzernet> wrote in message
news:3cc0302b@news.povray.org...
> Argh ... that hurts quite a bit ...
>
> My new algorithm manages to place
> 32000 Spheres in ~6mins ... thats
> "a bit" faster than my other try...
>
> The "problem" with this one is, that
> I can no guarantee any longer , that
> it is without collisions, but the
> probability is quite low ...
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Piece of cake... 6 mins is pretty slow. Are you using an array? That slows
things down a LOT. Nice img though.
I can send you code for a MUCH faster looped object (NOT JUST SPHERE)
placement include file, If you're interested. It too doesn't do collision
chk, but is lightning fast.
What speed computer are you using?
Jan Walzer wrote in message <3cc0302b@news.povray.org>...
>Argh ... that hurts quite a bit ...
>
>My new algorithm manages to place
>32000 Spheres in ~6mins ... thats
>"a bit" faster than my other try...
>
>The "problem" with this one is, that
>I can no guarantee any longer , that
>it is without collisions, but the
>probability is quite low ...
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Sam Van Oort" <sam### [at] yahoocom> wrote:
> Piece of cake... 6 mins is pretty slow. Are you using an array? That slows
> things down a LOT. Nice img though.
Thx...
> I can send you code for a MUCH faster looped object (NOT JUST SPHERE)
> placement include file, If you're interested. It too doesn't do collision
> chk, but is lightning fast.
That doesn't make sense here, as the collision chk was my priority ...
So I don't need your code, as without these collisionchecks I could
place them much faster, too.
BTW: I can also adapt this to evry obj. you like, but the bounding object
for collisions will still be a sphere ...
> What speed computer are you using?
I'm using an AThlon1.3 with 786MB SDR, but the file lies on a Network-server,
so probably this could be the bottleneck here ...
Now, thinking about it, my Macro (if it ever reaches the relase-state) is
able to do no-collision as well as 100% collision chk, as well as to
check with a special probability ...
the more you want to be sure, that objs don't touch, the slower it
will be ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
