 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doing some more work on tools for creating mesh2 objects, and I want to be sure
I am understanding the syntax of the mesh2 object correctly.
First, the ordering of the triangles in face_indices is irrelevant, correct?
Are there any optimizations in placing adjacent triangles near to each other in
the declaration?
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?
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?
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?
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.
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.
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcast net> 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
assumption.
> 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.
https://wiki.povray.org/content/Reference:Mesh2
"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
zero."
> 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?
Yes.
"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
way.
"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.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Surfed around a bit more.
Looks like some of the code out there has checks for degenerate objects, so a
degenerate triangle check / flag / excision might be a good feature.
Just going to plop these here as a historical record (some are looking quite
old) and perhaps to inspire some ideas.
A sphere-and-cylinder wireframe representation would be a great adaptation too.
I'm not sure how the mesh2 code works under the hood, but I'm wondering if a
vertex-order checking needs to be done to ensure the proper ordering of the
vertices so that the face normals are in the correct direction.
https://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
https://gist.github.com/monkstone/1639360
https://www.ks.uiuc.edu/Research/vmd/doxygen/POV3DisplayDevice_8C-source.html
http://jmsoler.free.fr/util/blenderfile/fr/povanim_Mesh2_en.htm
http://jgrimbert.free.fr/pov/patch/tessel/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Chris R" <car### [at] comcastnet> wrote:
> ...
> 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
the GTS library provides 'gts_surface_is_closed' to check for holes, and there
is a "repair" utility (part of download) for that case (though I have not used
that yet). there are 'stl2gts' utilities out there, complemented by 'gts2pov'
(link below).
re order of vertices, I think you're right, I seem to remember it matters when
the normal(s) need calculating.
regards, jr.
<https://drive.google.com/file/d/10WT-D3MP4qYxnP1BYu5f_ZN_xmOo1P5W/view?usp=sharing>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 8-12-2022 om 08:53 schreef jr:
> re order of vertices, I think you're right, I seem to remember it matters when
> the normal(s) need calculating.
>
iirc, righthand-winding or lefthand-winding of vertices determine if
normals face to the outside or the inside of the object...
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> the GTS library provides 'gts_surface_is_closed' to check for holes, and there
> is a "repair" utility (part of download) for that case (though I have not used
> that yet). there are 'stl2gts' utilities out there, complemented by 'gts2pov'
> (link below).
Interesting. I would love to know how _that_ all works. Undoubtedly some
vector black magic and maybe crossing tests.
> re order of vertices, I think you're right, I seem to remember it matters when
> the normal(s) need calculating.
re ordering of vertices, so if they're wrong then they'd need . . . reordering.
:D
I found this just now - I have yet to understand anything about it.
https://math.stackexchange.com/questions/689418/how-to-compute-surface-normal-pointing-out-of-the-object
> regards, jr.
re guards, it always seems like the sanity checks for thing like this
(degenerate, normal direction, dupes, missing) wind up overwhelming the actual
code for the object.
regards,
BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "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
> assumption.
>
> > 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.
> https://wiki.povray.org/content/Reference:Mesh2
> "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
> zero."
>
> > 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?
>
> Yes.
> "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
> way.
>
> "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.
>
> - BW
Thank you, as usual you are a wealth of information!
Just to be clear, I am writing java code for an external tool that will generate
text files containing the SDL for mesh2 objects, (the way Arbaro works). So
the meshes will definitely be written to disk and not need to be manually
recreated every time you render the scene.
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcastnet> wrote:
> Thank you, as usual you are a wealth of information!
Well, I've gotten sucked into doing a lot of projects, and biting deeply into
topics which were a LOT to chew on, and just about over my head at the time I
started on them. I just know things because I've done just about everything
wrong at some point and everyone here helped explain the problem and point me in
the right direction.
> Just to be clear, I am writing java code for an external tool that will generate
> text files containing the SDL for mesh2 objects, (the way Arbaro works). So
> the meshes will definitely be written to disk and not need to be manually
> recreated every time you render the scene.
I've tested my normal calculations with a tetrahedron, cube, octahedron, and
icosahedron. I have macros to check handedness of the triangle vertex order,
correct wrong ones, and calculate face normals that always point outward.
Works in all eight octants.
I have yet to make / test a concave mesh, and some code may be superfluous,
while other parts may need a bit of extra checking.
Definitely had a few bonehead mistakes and head-scratchers that I managed to
experiment my way out of along the way.
I'm sure there's still lots more to learn if I get around to testing any of this
on a more complicated mesh like the bunny, buddha, dragon, etc.
Unlike jr, I'm terrible with data structures, so I have no idea how to go about
efficiently checking for holes, duplicates, etc.
Post a reply to this message
Attachments:
Download 'surfacenormals.png' (58 KB)
Preview of image 'surfacenormals.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm sure there's still lots more to learn if I get around to testing any of this
> on a more complicated mesh like the bunny, buddha, dragon, etc.
So I fiddled with the bunny - I had forgotten what a small scale that thing is.
I basically made an array of the vertices, another array of the indexes, and
then a final array describing the actual triangles, pretty much undoing the
mesh2.
Only a few normals were pointing outward, which means that somehow almost all of
my normals are reversed. So one character later (-) I was able to render the
bunny with almost all of the normals facing outward.
I guess there's a way to do a breadth first search and correct the normals that
don't point in the same direction as all the others.
I might try adding an interior_texture to the triangles next to see what
happens.
But I'm super pleased that I made it this far, not fully understanding how
everything works with respect to calculating the determinant of the
cross-product vectors.
Enjoy.
Post a reply to this message
Attachments:
Download 'bunnynormals.png' (664 KB)
Preview of image 'bunnynormals.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > I'm sure there's still lots more to learn if I get around to testing any of this
> > on a more complicated mesh like the bunny, buddha, dragon, etc.
>
> So I fiddled with the bunny - I had forgotten what a small scale that thing is.
>
> I basically made an array of the vertices, another array of the indexes, and
> then a final array describing the actual triangles, pretty much undoing the
> mesh2.
>
> Only a few normals were pointing outward, which means that somehow almost all of
> my normals are reversed. So one character later (-) I was able to render the
> bunny with almost all of the normals facing outward.
>
> I guess there's a way to do a breadth first search and correct the normals that
> don't point in the same direction as all the others.
>
> I might try adding an interior_texture to the triangles next to see what
> happens.
>
> But I'm super pleased that I made it this far, not fully understanding how
> everything works with respect to calculating the determinant of the
> cross-product vectors.
>
> Enjoy.
When I was growing up there was a bath toy shaped like various animals, made of
some sort of soap that once it got wet and you let it dry, it would form a fuzzy
surface. Your bunny with all of his normals exposed like that reminded me of
it.
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
