Believe it or not, I have been thinking in the same way.

Indeed, assume a tetraeder object, defined by the four corners, that can be
CSG'ed. From this a body with 5 cornerpoints can be defined as the union of
two tetraeders: the first one defined with the first 4 vertices, and the
second one with the first three and the fifth
vertex. This pattern can easily be extended to form objects with 6 7, 8, and
so on corners.
The only difficulty will be the numbering of the vertices, but I am sure
there is some nice mathematical rule for this, and for the obvious case of
the octaeder a macro wrapper can be written.
The advantage is that the space described by the object can be concave (not
possible using a union of planes), and that the object can be of any
complexity.

But, so thinking further, what is the actual reason that a mesh can not be
used for CSG? I assume this is because :
1 - there is no guarantee that a mesh describes a closed surface, so no
'real' inside or outside
2 - there is no guarantee that all triangles are consistently defined with
their corner vertices arranged such that a normal vector defined by the
right hand rule points outward. (or was it the left hand rule?  with POV you
never know).
3 - there is no guarantee that the surface does not intersect itself,
exposing the inside surface to the outside, and having the normals pointing
inward. (hard to tell this in words, but no time to render an image)
But, what if we would allow meshes that are closed, consistently defined,
and not self-intersecting to engage in CSG?

A practical solution would be to add a keyword 'CSG' to the definition of
the mesh, like:

#macro flat_metabox (FP1, FP2, FP3, FP4, BP1, BP2, BP3, BP4)
   mesh {
      CSG       // I, user, herewith declare and confirm that the follwing
mesh definition complies with the THREE RULES
      triangle {FP1, FP2, FP3} triangle {FP1, FP3, FP4}  // Front
      triangle {FP1, BP1, BP2} triangle {FP1, BP2, FP2}  // Top
      triangle {FP1, FP4, BP4} triangle {FP1, BP4, BP1}  // Left
      triangle {BP1, BP4, BP3} triangle {BP1, BP3, BP2}  // Back
      triangle {FP4, FP3, BP3} triangle {FP4, BP3, BP4}  // Bottom
      triangle {FP2, BP2, BP3} triangle {FP2, BP3, FP3}  // Right
      }
#end          // with many thanks to Chris Colefax !!

In adding the CSG keyword the USER would assure that the above conditions
are fulfilled, and POV can just do its work.  If the mesh is not compliant,
the user may end up with errors in his picture, and probably some warnings
or messages from POV. Too bad for him. This approach would minimize the task
of the highly praised and overworked POV team.

An algorithm to check a mesh for the above conditions is not so difficult.
It comes down to checking that:
Condition 1 - a ray fired at the object from far away hits the surface on
what we want to be the outside, typically this can be judged by checking the
sign of the scalar product of the ray vector and the normal. When the object
appears to be 'reversed', the checker may be of use to 'flip' it (i.e.
reverse the two first vertices in each triangle)
Condition 2 - all edges are used exactly two times, in opposite directions,
so in the above example: side FP1, FP2 must have a counterpart FP2,FP1. This
means that there are no free edges, and the edges are used to bound two
triangles defined in the same direction.
Condition 3 - no edge of any triangle passes trough another triangle. This
check is not difficult, but just a load of work,that needs to be done only
once. One more reason to have a separate mesh-checker.

By the way, meshes converted from say Autocad or 3DS files, do they normally
comply with these Rules?

And: a mesh usually renders more quickly than a complex union of solids.

Frans

Post a reply to this message