If object is made using CSG and boxes then is it true that avoiding
intersection and difference speeds up rendering?

Can I speed up rendering using meshes if object is constructed flat
surfaces?

Matti

Post a reply to this message

> If object is made using CSG and boxes then is it true that avoiding
> intersection and difference speeds up rendering?

Yes.

> Can I speed up rendering using meshes if object is constructed flat
> surfaces?

Yes.

Fabien.

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote in message
news:3e773099$1@news.povray.org...

>
> > If object is made using CSG and boxes then is it true that avoiding
> > intersection and difference speeds up rendering?
>
> Yes.
>
> > Can I speed up rendering using meshes if object is constructed flat
> > surfaces?
>
> Yes.
>
> Fabien.
>
>

Why?

Post a reply to this message

intersection & differences:
Needs to compute insides and outsides of objects, and
needs to determine in which order the objects appeared to
know which are subtracted.

meshes:
have low overhead and use optimization trees (AFAIK)


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

Post a reply to this message

On Tue, 18 Mar 2003 12:52:11 -0500, "Ross Litscher" <lit### [at] osuedu> wrote:
> > > If object is made using CSG and boxes then is it true that avoiding
> > > intersection and difference speeds up rendering?
> > Yes.
> > > Can I speed up rendering using meshes if object is constructed flat
> > > surfaces?
> > Yes.
> Why?

Because both solutions are internally optimized and more effective.
Union-only CSG is splitted into separated objects with vista buffer and other
goodies. Copied mesh use less memory and its intersection test is fast.

ABX

Post a reply to this message

Wasn't it Matti Karnaattu who wrote:
>If object is made using CSG and boxes then is it true that avoiding
>intersection and difference speeds up rendering?

Yes, but in many cases you can get most of the speed back if you can
apply tight manual bounding. POV can't work out, in advance, which parts
of the objects remain after some bits are removed, so it creates an
automatic bounding box that contains the union of the objects.

>Can I speed up rendering using meshes if object is constructed flat
>surfaces?

Rewriting the entire structure as a single mesh2 object will usually be
the fastest way to render complex structures

It's also worth considering breaking your structure into smaller boxes
and unioning them back together. The intersections and differences of a
set of boxes can always be described as the union of a set of smaller
boxes. Unless you've got thousands of boxes, the speed isn't going to be
much slower than a mesh2.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

ABX wrote:

> Copied mesh use less memory and its intersection test is fast.

Does copied CSG use more memory?

For example, if I have a macro that constructs a CSG object, which would use
less memory: to call the macro once, then use 20 copies of that object, or
to call the macro 20 times?

RG

Post a reply to this message

I guess it'd be 20 copies of the object. Thus, the macro-parsing is
saved. But CSG-Objects aren't saved like meshes, where the mesh
is loaded into the memory once, and then simply referenced. You
will have 20*CSG objects loaded into memory, no matter how you
do it (via macro or just copying), but macros create overhead.

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

>
> > Copied mesh use less memory and its intersection test is fast.
>
> Does copied CSG use more memory?
>
> For example, if I have a macro that constructs a CSG object, which would
use
> less memory: to call the macro once, then use 20 copies of that object, or
> to call the macro 20 times?
>
> RG
>

Post a reply to this message

On Tue, 18 Mar 2003 17:06:18 EST, "gonzo" <rgo### [at] lansetcom> wrote:
> Does copied CSG use more memory?

yes

> For example, if I have a macro that constructs a CSG object, which would use
> less memory: to call the macro once, then use 20 copies of that object, or
> to call the macro 20 times?

Considering there are no #declarations of objects inside macro then
one call + 20 copies of identifier will use in memory 21 objects
while macro called 20 times will use 20 objects in memory.

Considering that macro internally use #declarations of local objects then macro
will take more memory.

Macro is always less or more slower than assignment from predeclared identifier.

As long as you not make complicated CSGs like trees there should no problem with
hundreds of megabytes.

ABX

Post a reply to this message

"Mike Williams" <mik### [at] econymdemoncouk> wrote in message
news:JopK2DARl2d+Ewq### [at] econymdemoncouk...
> Wasn't it Matti Karnaattu who wrote:
> >If object is made using CSG and boxes then is it true that avoiding
> >intersection and difference speeds up rendering?
>
> Yes, but in many cases you can get most of the speed back if you can
> apply tight manual bounding. POV can't work out, in advance, which parts
> of the objects remain after some bits are removed, so it creates an
> automatic bounding box that contains the union of the objects.
>

Is this right?

Surely with:

difference{
    object{A}
    object{B}
}

and

intersection{
    object{A}
    object{B}
}

They could be bound by the object{A} bounding box, rather than the bounding box
of the union of A and B?

In the case of the intersection, you could also switch to the bounding box of B
if that was smaller than A's.

I thought that that was what happened (although I don't know if the final
paragraph is implemented).

Actually, what *DOES* happen with intersections? Does POV look for the smallest
bounding-box, or does it just use the box of the first object in the list? If
the latter, then it would presumably make sense to list your smallest object
first.

Post a reply to this message