"Chris R" <car### [at] comcastnet> wrote:
> First, the ordering of the triangles in face_indices is irrelevant, correct?
As the documentation doesn't mention it, I would assume that is a safe
> Are there any optimizations in placing adjacent triangles near to each other in
> the declaration?
That's something that likely someone on the development team would have to look
into. (But if you're writing code to do all of this, then you could have SDL
spit out system elapsed time along the way, and compare final parse & render
times, if you have a way of changing or randomizing an existing data set. Then
the question could be answered empirically.)
> Second, if using uv_indices then it must contain the same number of entries as
> face_indices, and each uv_indices entry references the same triangle as the
> corresponding face_indices entry, correct?
That's how I'm reading it.
"Note: The numbers of uv_indices must equal number of faces."
> Third, if using normal_indices it does not have to contain the same number or
> fewer entries than face_indices, and the entries that are present in
> normal_indices reference the same triangle as the corresponding face_indices
> entry, correct?
If I'me reading your question correctly, then that seems right also.
"The indexes are zero based, so the first item in each list has an index of
> Fourth, if uv_vectors is specified and has the same number of entries as
> vertex_vectors, (and you have not bizarrely decided to list the uv_vectors in a
> different order than the vertex_vectors), then there is no need to specify
> uv_indices, as POVRay will simply use the same entry numbers for uv_vectors as
> it does for vertex_vectors from the face_indices. If you do specify uv_vectors,
> then it must contain the same number of entries, in the same order as
> face_indices. Correct?
"The normal_vectors, uv_vectors, and texture_list sections are optional. If the
number of normals equals the number of vertices then the normal_indices section
is optional and the indexes from the face_indices section are used instead.
Likewise for the uv_indices section."
> Fifth, if normal_vectors is specified and has the same number of entries as
> vertex_vectors, (and same caveat about ordering the normals), and you want all
> triangles to be smooth, then there is no need to specify normal_indices, as
> POVRay will simply use the same entry numbers for normal_vectors as it does for
> vertex_vectors from the face_indices. If normal_vectors has fewer entries than
> vertex_vectors, or you wish to specify that some triangles are not smooth, then
> you must declare normal_indices. The entries in normal_indices must be in the
> same order as the triangles in face_indices.
That sounds like it should be right, given you do any prerequisites the right
"Smooth and Flat triangles in the same mesh
You can specify both flat and smooth triangles in the same mesh. To do this,
specify the smooth triangles first in the face_indices section, followed by the
flat triangles. Then, specify normal indices (in the normal_indices section) for
only the smooth triangles. Any remaining triangles that do not have normal
indices associated with them will be assumed to be flat triangles."
> I am writing code that will take a collection of Faces (triangles), create the
> set of unique vertex points to optimize the declaration of vertex_vectors, and
> then determine whether it is cheaper to declare uv_vectors and normal_vectors to
> match vertex_vectors and thus reuse the face_indices for all three, (as long as
> everything is either smooth or not-smooth), or to make the uv_vectors and
> normal_vectors only contain unique values and pay the cost of declaring
> uv_indices and normal_indices.
Well that seems to be a huge undertaking, and I hope you start with a few simple
test data sets to make writing and debugging easier.
Not that you don't have enough to do, but you might consider the option of
writing the centers of the triangles and the normals of those faces to disk, in
case anyone would find that data to be useful. (I'm thinking of Voronoi over
the surface of the mesh, and/or using your utility to display normal directions
for debugging or educational/illustrative/debugging purposes.
I'm not sure how anyone would go about finding and filling "holes" (missing
triangle faces), but maybe put any idea you have as comments in the code in case
someone decides to work on something like that.
Also make sure you have the utility write an "inside vector" so that the mesh
can be used in CSG.
Jeff Houck wrote and "stl2pov" utility, and (doing a search for "stl2pov")
apparently several other people have as well. Just in case you wanted to look
over what other people have done, in case they decided to go the mesh2 route.
jr has pointed out that there exists the GNU Triangulated Surface library
and apparently Chris Young had cooked up some STL / triangle / mesh code in the
distant past - not sure where / if that still exists.
Since the STL file format / syntax is almost identical to POV-Ray's mesh object,
maybe you could author a mesh to mesh2 and stl 2 mesh utility - something that,
given the number of 3D printing files out there, would surely find a LOT of use.
I hope this all works out, and you manage to write a nice utility that finds a
lot of use, over and above anything presently extant.
Post a reply to this message