"Warp" <war### [at] tagpovrayorg> wrote...
>   Is there a reason why copying a CSG object doesn't work like copying
> a mesh? I can't figure any reason why copying a mesh just by taking
> another "reference" to it but not copying the mesh data itself is ok,
> but doing it for a (big) CSG is not ok.
>   I think that many scenes would definitely take advantage of the memory
> saving, specially with very big CSG's.

It really could be done, but would require a re-write of a good chunk of
POV.

The issue has to do with how transformations are handled and how textures
are stored.

For some objects, such as meshes, transformations are stored in a
transformation matrix, leaving the base object untouched.  For a ray
intersection, the ray must be transformed (a rather time-consuming
calculation) into object space and then intersected with the base object.
Then, the intersection point and normal must be transformed back into world
space for the lighting calculation.

Other objects, such as boxes, spheres, and discs, are transformed by
modifying the object itself.  (e.g. If you translate a sphere, the center
point will be moved, and the transformation matrix will still be null.)
This means faster render times (no need to transform the ray, because object
space = world space).

A CSG object is just a collection of individual objects with special
intersection rules.  When a CSG is transformed, all of the child objects are
transformed at parse time.  To allow duplication of a CSG, a new
transformation stack would have to be created for the CSG, which would slow
things down.  Also, unions are often split apart before rendering.  This
will often greatly increase speed performance (due to bounding-box octree
storage and search).

Now, about textures:  As noted above, at the end of all intersection
routines, before lighting happens, the intersection and normal are in world
space.  They must be translated to texture space before texture calculations
can be done.  Each level of nested and layered textures can have their own
list of warps (including one or more linear transformation matrices).  When
a texture is applied to an object, a complete copy of the texture (along
with all of its warps) is made and attached to the object.  When the object
is transformed, all attached textures are transformed with it (just like the
transformation of child objects in a CSG).  This way the textures "go along
for the ride."  For speed reasons, these object transformations (which
affect the texture) are merged into the top-level warps for the texture.
(Two transformation matrices can be merged into a single one using matrix
multiplication.)

All of this means that textures are volatile.  After they are applied to an
object, they will change when the object is transformed.  That means that,
if two objects reference the same texture, and you move one object, the
texture on the other object would slide around.

Now, I'm not saying that it couldn't be done, but I am saying that it would
take a lot of very careful planning.  Personally, I'm going to wait until
POV 4 to try it.

-Nathan

Post a reply to this message