Note that many CSG-operations (difference, intersection,
merge) stacked onto (into?) each other slow down the
calculation process a lot, because a ray has to be tested
against all objects of the CSG.

So in order to quicken things up, you might want to break
the CSG into smaller parts.
Example:
A box with a cylinder cut out of it.
Suggestion:
Divide the box into several boxes, making on difference on
one small box which just about fits the cylinder, and leave the
others ontouched and set to fill the remaining space of the
original box.
Depending on your CSG, this might get quite complicated,
but its sometimes worth the effort. Also, only use merge{} if
actual need for transparent objects is there.
A friend of mine constructed a castle once using merge, thus,
the entire castle used one bounding box, and it seemed as if
POV-Ray tested every brick of the castle for every ray. Using
union speed up the tracing process by at least 60% (pending on
the amount of space the castle filled in the final image of course).

That general enough? :-)

Regards,
Tim


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> Is there some built-in POV feature that would help me diagnose which
> elements of a scene are hogging all the render time? I'm trying to
> temporarily focus the camera on a small corner of my scene, which as far
as
> I can tell, is composed only of CSG's that I didn't think were all that
> elaborate (after, _I_ coded them, and I don't know jack about macros yet).
> But the problem is that the render times seem disproportionately long.
>
> I've exchanged all the area_lights for simple, normal light statements,
and
> commented out the sky_sphere, but something still is really slowing down
> the works.  I would EXPECT a longer render if I was trying to do the whole
> scene, but GEEZ!
>
> I suppose this complaint is not too informative without my code, but I
don't
> think
> 1) anyone really wants to mess with THAT ;-)
> 2) I would care to reveal what an inefficient coder I really am... ;-)
>
> So let's keep it to generalities, shall we?
>

Post a reply to this message