http://www.povray.org/documentation/view/3.6.1/68/

1) I'm trying to wrap my head around the concept of a UV mesh.  Could
someone help me by explaining what they mean when they wrote things like,
"/*as 8*/ /*as 0*/  /*as 2*/" in the doc?


2) I've got a macro where I sweep my own mesh2.  I have a strategy question
about computing power.  Right now the macro does not compute normals, but
the macro allows one to set any triangle size.  Which of the two options
would be the best overall approach, as far providing pretty, smooth-looking
meshes as a function of rendering time with long-term use of a macro?

i) Going to the trouble of calculating the normal for every triangle?
ii) Just using a sub-pixel triangle size?

tia.

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> http://www.povray.org/documentation/view/3.6.1/68/
>
> 1) I'm trying to wrap my head around the concept of a UV mesh.  Could
> someone help me by explaining what they mean when they wrote things like,
> "/*as 8*/ /*as 0*/  /*as 2*/" in the doc?

These are just comment blocks for notation here.  ("/*" opens a comment,
"*/" closes the comment, and POV ignores it in parsing).

In this particular case, the documnetation is just showing the layout for
each individual triangle, but since normals can be repeated several times
in the mesh, they only need to be put in once, normal indices are used to
pick the right one (in mesh1 format, you would need to layout each vertex
and vertex normal of each triangle, this i part of the optimization of
mesh2).  The comments are simply indicating "the normal that should be used
here is the same as normal n".  The same is true for vertex vectors and
uv_vectors.


> 2) I've got a macro where I sweep my own mesh2.  I have a strategy question
> about computing power.  Right now the macro does not compute normals, but
> the macro allows one to set any triangle size.  Which of the two options
> would be the best overall approach, as far providing pretty, smooth-looking
> meshes as a function of rendering time with long-term use of a macro?
>
> i) Going to the trouble of calculating the normal for every triangle?
> ii) Just using a sub-pixel triangle size?

For what it's worth, I would use normals.  You'll get a smoother looking
result with less visible artifacts a lot sooner than with subdivided meshes
alone giving a much smaller mesh size.  The only problem is figuring out how
to calculate the normals.

-tgq

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> http://www.povray.org/documentation/view/3.6.1/68/
>
> 1) I'm trying to wrap my head around the concept of a UV mesh.  Could
> someone help me by explaining what they mean when they wrote things like,
> "/*as 8*/ /*as 0*/  /*as 2*/" in the doc?

I found that documentation a bit confusing, but what it's getting at is that
adjacent triangles in mesh2 can share vertices. On that page the example is
a mesh2 having 8 triangles. If you list every vertex as if the triangles
are separate objects you'll have 8*3 = 24 vertices. Compare the mesh2 of 24
vertices listed after the line "The complete mesh:", with the mesh2
containing 9 vertices that follows it. The duplicate vertices have been
removed and replaced with the /* as n */ (means "this has been removed
because it's a duplicate of vertex n").

In the example, all 8 triangles share the central vertex; we can record it
once and avoid 7 duplicates. Each pair of triangles also share a vertex on
the outer boundary of the shape, so instead of recording 16 vertices in the
vertex_vectors list to make up the outer boundary we only need to store 8
unique vertices. With the central vertex that's 9.

To still have a valid mesh you then use the face_indices list to build the
triangles - in the example you can see the advantage of the /* as n */
comments if you were building this mesh by hand, since if you read it line
by line, converting each line into a triangle index vector, you get your
face_indices list.

> 2) I've got a macro where I sweep my own mesh2.  I have a strategy question
> about computing power.

I would calculate the normals. It will allow smoother-looking meshes for
fewer triangles even if you have still have to use quite a few to beat the
shadow line artefact, and fewer triangles to parse and render => more
speed. In my experience increasing numbers of triangles don't slow down
rendering as much as they do parsing (not really surprising). With large
numbers of triangles the parse time can become as significant as the
rendering time if the materials and lighting used are simple.

Tom

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> Which of the two options would be the best overall approach...
> i) Going to the trouble of calculating the normal for every triangle?
> ii) Just using a sub-pixel triangle size?
>

The results are in:

With a mesh2 macro, and the same figure:

i) Not calculating normals, but using 130 rings & 130 segments:
6 secs parse, 6 secs render

ii) Calculating normals, using 30 rings & 30 segments:
"0" secs parse, 5 secs render.

Image quality: Case ii) is segmentally lumpy but much "smoother", of course.

Post a reply to this message