Ken wrote:
> 
>  One question John - Will your macros read in a file containing a
> triangle mesh or is it currently resticted to meshes that are
> generated internaly using functions for their creation ? If it is the
> latter would it be possible to extend its capabilities to include
> reading existing meshes?

One of the issues I had to deal with is the inability of macro code to
erase and re-declare arrays that are passed to it as arguments.  The
array can be accessed, and its elements altered, but the dimensions, and
the size of each dimension, cannot be altered within the macro.

For instance, consider the following macro:

#macro ResizeArray(MyArray)
  #local Size=dimension_size(MyArray,1)
  #undef MyArray
  #declare MyArray=array[Size*2]
#end

An array that is passed to this macro will not be affected by the macro
whatsoever; what appears to happen is that POV-Ray forgets that MyArray
was an argument passed to the macro, and consequently a global array
with the name "MyArray" is created.  I haven't fully tested this out,
but one thing is for certain:  If you pass an array to a macro, that
macro cannot resize the array.

This is a problem because the divider code (which is the whole reason I
wrote the SSS to begin with) has to resize the arrays for each
iteration, for the simple reason that the number of triangles quadruples
with each execution of the division process.

For this reason, the SSS uses three globally-declared arrays, and the
names of these arrays must be Points, Edges, and Triangles; so if you
are going to use the SSS, you have to treat these labels as reserved
keywords, for all intents and purposes.

Another issue that has to be dealt with involves the vertices in the
mesh.  Consider the following mesh:

mesh {
  triangle { <1,0,0>,<1,2,0>,<1,1,2> }
  triangle { <1,1,0>,<1,2,0>,<2,2,0> }

...

}

These two triangles each have a corner at <1,2,0>.  Are the two
triangles supposed to be connected (ie, form a surface together), or
not?  In order to resolve this ambiguity, the code would have to know
what the user wanted, and in this case, there's not enough info to make
the call; the user needs to be more specific.

In order to get something subdivided, all you have to do is to define
two arrays:

  Points[PointCount] is an array of vectors representing the vertices of
the mesh.
  Triangles[TriangleCount][3] is an array of indices to the vertices of
the mesh.  Points[Triangle[n][0]] is the first vertex of triangle n,
Points[Triangle[n][1]] is the second vertex of triangle n, and
Points[Triangle[n][2]] is the third vertex of triangle n.

  In this way the ambiguity is resolved; if the point shared by two
triangles is meant to link them together, then both indices can refer to
the exact same member of Points[].  If they are supposed to go their
separate ways, then the indices should point to different elements,
which will have the same starting value.

  Now the subidivider needs a lot more info that I have specified here,
but there is a macro in the SSS that will generate this info, making it
unnecessary for the user to do so.

  So basically, your only real problem is to get the mesh data into the
two arrays Points[] and Triangles[][].  Anything that accomplishes that
will work just fine.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message