It depends on the scene.

Merge takes care that surfaces inside the merged objects don't show up. In
effect, once it is inside an object, it will somehow discern if the next
surface it encounters should be calculated and used or not. For large
amounts of objects this can get pretty complicated, especially if they're
spaced widely apart. A friend of mine, DT, once built a castle, which you
can view on IRTC and his website (www.digitaltwilight.de), and used merge
first. The entire scene took forever to render. I replaced his merges with
unions (cause his objects aren't transparent), and then it rendered like
"PLOP-Finished".

I don't know HOW it actually checks for inside/outside surfaces though. It
seems that when the objects are stacked together nicely, it can sometimes do
better than when they are spread wide apart. Someone else might explain the
details. I just know that you should DEFINITELY use merge only when
necessary, never to an excess.

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: tim.nikias (@) gmx.de


> Out of curiosity: does anyone know the time complexity of merge?  Is it
O(n)
> or O(n^2)?  Because I was just rendering a scene with 20,000 spheres, and
it
> takes 13 seconds to parse with no merge (there's a bunch of other stuff
> going on), but when I tried putting them all in a merge object, well....
I
> cut it off after 17 minutes.  I don't know how long it would take to
finish,
> but since it is an animation, and that is only one frame, and the
animation
> will be much more complex soon, this time is simply not acceptable.  If
the
> time is O(n^2), would it be any faster to merge them in batches, and then
> merge the batches?  Or will I just have to deal with not being able to
merge
> them?
> Thanks!
>
> Barron Gillon
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 23.09.2003

Post a reply to this message