"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > I am looking forward to seeing how you solve your too-smooth problem; I wish
> > that I could offer some suggestions. Some of this triangle stuff is outside my
> > knowledge.  *If* the triangle normals are all unit length, perhaps your summing
> > operation could be made to eliminate some of the identical normals on large flat
> > areas, which might reduce their contribution-- and make the smoothness less
> > smooth. (?)
>
> Triangles typically have a sinlge normal - a vector that is perpendicular to
> it's face (in either direction).
>
> The normal can be of any length.
>
> Typically, for lighting purposes, since the normal vector is used to calculate
> how light interacts with the surface, you want them of unit length.
>
> For smooth, or perturbed-surfaces, you will specify the normals of the vertices,
> and then POV-Ray will interpolate the normals across the surface, (and perhaps
> adding/multiplying by some pattern) to yield a smoothly changing surface.
>
> When dealing with a mesh of triangles that share common vertices and edges, one
> typically averages all of the normals that meet at a common vertex so that
> there's no sudden discontinuity in the way light reflects from the surface,
> appearing as lump, depressions, or creases.
>
> If you have two triangles oriented in different directions, if you multiply the
> length of the normal of one triangle, its contribution to how the triangles
> behave at that vertex will be greater.
>
> I think in order to accomplish what he's looking to do, the way that the
> triangles get interpolated would have to change, other wise I don't see how to
> maintain a common normal direction on one end, and non-linearly change apparent
> curvature at the other.
>
> It's not something I've played with in detail, but it sure seems like something
> that ought to be explored with test renders, diagrams, normal directions and
> lengths explicitly labeled, etc.
>
> Good instructional articles are what draw computer graphics students and
> hobbyists to any given site for the quality content.
>
> We should have that.
> Right on the home page.  Perhaps directing to a specific (new) sub-group titled
> "Articles".

Hi Bill

Here's two relevant articles:

"Weighted Vertex Normals"
http://www.bytehazard.com/articles/vertnorm.html

"On the computation of vertex normals"
http://meshlabstuff.blogspot.com/2009/04/on-computation-of-vertex-normals.html

- And then there's this paper, which delves deep into the topic:

"A comparison of algorithms for vertex normal computation"
Shuangshuang Jin, Robert R. Lewis, David West
The Visual Computer, 2005 - Springer

Vertex normal algorithms investigated in that article:

    Mean edge weighted by cotangents of subtended angles
    Mean weighted by angle
    Mean weighted by areas of adjacent triangles
    Mean weighted equally
    Mean weighted by edge length reciprocals
    Mean weighted by square root of edge length reciprocals
    Mean weighted by sine and edge length reciprocals

From the article's "Conclusions and future work":

Relatively speaking, except for trigonometrically parameterized surfaces,
"Mean weighted by angle" is most frequently a good choice. If speed is a
concern, however, "Mean weighted equally" holds up well in most cases.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"GioSeregni" <gms### [at] hotmailcom> wrote:
> There was an interesting comment with a utility to download, but now I don't see
> it anymore. Has it been cancelled? I took the obj and converted it to STL then
> applied my code to it, but without refinements in the environment. I tested his
> example with my program, because I had downloaded it, my render is poor.. it has
> no texture, it has no lights... I put the linked example but rendered with my
> version 3.7 (the file was 3.8 ) Strange, I can no longer find who posted and the
> content, thanks anyway!
NOW I understand! it hasn't disappeared, it's on another topic. Obj to POV...
Now I understand why I had artifacts. By transforming the obj into STL I already
had the normals with smooth, on which I intervened with a new smooth, mine, that
is, sorry, I made a mess :)

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Hi Bill
>
> Here's two relevant articles:

Hi Tor,

Thank you as always for sharing some of (what I'm sure is a very extensive)
reference library.

Luckily, I had written a fully chamfered box macro not too long ago, so I could
just piggyback off of that and get right to trying to calculate the normals and
replicate the work in that first paper.

I normalize all of my cross-product vectors before summing to get the "wrong
way" and then just use the direct cross-product result to try to get the
right/improved way - but it still doesn't look very smooth.  So I must have some
aspect of this that I didn't code right in that second macro.
(and even seeing the flaws is very lighting and camera angle dependent...)

However, aside from that, what I did find disturbing is that I have an
interior_texture defined for my smooth_triangles, and that's showing up, even
though my normals are facing the proper way.

So it seems like we're back to having some triangle mesh rendering errors in the
source, even after clipka hunted down and fixed the faux-mesh union-of-triangles
problem that I uncovered when making subdivided spheres.

See attached.

Maybe someone else can confirm.


- BW

Post a reply to this message

Attachments:
Download 'weightedvertexnormals.png' (68 KB)

Preview of image 'weightedvertexnormals.png'

"- And then there's this paper, which delves deep into the topic:

"A comparison of algorithms for vertex normal computation"
Shuangshuang Jin, Robert R. Lewis, David West
The Visual Computer, 2005 - Springer"

Can't seem to find that one, even though my tax dollars probably funded the
research.  ;)

Is that a journal article, or part of _3D Imaging, Analysis and Applications
(Pears, Liu, Bunting) ?



- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "- And then there's this paper, which delves deep into the topic:
>
> "A comparison of algorithms for vertex normal computation"
> Shuangshuang Jin, Robert R. Lewis, David West
> The Visual Computer, 2005 - Springer"
>
> Can't seem to find that one, even though my tax dollars probably funded the
> research.  ;)
>
> Is that a journal article, or part of _3D Imaging, Analysis and Applications
> (Pears, Liu, Bunting) ?

It's here:

https://link.springer.com/article/10.1007/s00371-004-0271-1

Springer seems to have some kind of sharing feature for this.
So let's see of you can read it if you follow this link:

https://rdcu.be/drMhc

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> > Hi Bill
> >
> > Here's two relevant articles:
>
> Hi Tor,
>
> Thank you as always for sharing some of (what I'm sure is a very extensive)
> reference library.

Yes, I have saved a lot of articles related to computer graphics (and
mathematics, photography, electronics and much more) on a lot of hard
drives during the years, but unfortunately I'm not able to keep track
of them.

So this time I googled a bit and then posted the ones that looked most
relevant and informative. (But I did remember that I had read somewhere
that there are more than one way of weighting the normal vectors of
triangles surrounding a vertex in a mesh, before summing them. And that
there's no single way to choose those weights so that one gets good
results in all cases.)


> Luckily, I had written a fully chamfered box macro not too long ago, so I could
> just piggyback off of that and get right to trying to calculate the normals and
> replicate the work in that first paper.
>
> I normalize all of my cross-product vectors before summing to get the "wrong
> way" and then just use the direct cross-product result to try to get the
> right/improved way - but it still doesn't look very smooth.  So I must have some
> aspect of this that I didn't code right in that second macro.
> (and even seeing the flaws is very lighting and camera angle dependent...)
>
> However, aside from that, what I did find disturbing is that I have an
> interior_texture defined for my smooth_triangles, and that's showing up, even
> though my normals are facing the proper way.
>
> So it seems like we're back to having some triangle mesh rendering errors in the
> source, even after clipka hunted down and fixed the faux-mesh union-of-triangles
> problem that I uncovered when making subdivided spheres.
>
> See attached.
>
> Maybe someone else can confirm.

As you know:
It will be easier for us look at your problems if you show your code.

    ;-)

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> I also thought that the normals of triangles are direction vectors of 'unit
> length' by default, not smaller or larger, but I could be wrong.
[and...]
> *If* the triangle normals are all unit length, perhaps your summing
> operation could be made to... [clip]

[Bald Eagle:]
>
> Triangles typically have a single normal - a vector that is perpendicular to
> its face (in either direction).
>
> The normal can be of any length.
>
> Typically, for lighting purposes, since the normal vector is used to calculate
> how light interacts with the surface, you want them of unit length.
>

Sorry for the confusion, I was actually thinking-- in a muddled way-- of the
original 'source' triangles from Giovanni's STL file.

Honestly, I did not know *what* length such normals there could be-- so I took
one of my 'slice-created' STL binary files made by the 3D SLICER app (mentioned
elsewhere), brought that into MESHMIXER, and converted it to an asci-text STL
file. The triangles-- or each vertex?-- are of this typical form (not
'smooth triangles', as far as I know)...

facet normal -0.107895597816 -0.696702897549 0.709199249744
    outer loop
      vertex 21.3610057831 0.39481022954 -0.11346334219
      vertex 22.4441795349 0.273843616247 -0.158073753119
      vertex 22.0666675568 -0.210549205542 0.393470913172
    endloop

In POV-ray, I took the 'facet normal' data/vector and ran it with vlength(...)
and #debug. It turns out that ALL of the triangles have a unit-length normal:
<1.000,0.000,0.000>, as vlength reports it.

-----
[off-topic here but interesting}: The MESHMIXER app (also my CURA 3-D-printing
app) shows the STL object to have smooth edges-- even though the triangle
data appears to be 'un-smooth'. I have no idea why. Perhaps those apps are
automatically creating smooth triangles from the data. (Or maybe interpolating
the data from the individual vertices?)

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> As you know:
> It will be easier for us look at your problems if you show your code.
>
>     ;-)


Yes, yes yes - I was on my way out the door to shovel snow and get out to The
Circus.

Link to shared article worked great.  Thank you.

Post a reply to this message

Attachments:
Download 'weightedvertexnormals.pov.txt' (19 KB)

"Kenneth" <kdw### [at] gmailcom> wrote:

> converted it to an asci-text STL
> file. The triangles-- or each vertex?-- are of this typical form (not
> 'smooth triangles', as far as I know)...
>
> facet normal -0.107895597816 -0.696702897549 0.709199249744
>     outer loop
>       vertex 21.3610057831 0.39481022954 -0.11346334219
>       vertex 22.4441795349 0.273843616247 -0.158073753119
>       vertex 22.0666675568 -0.210549205542 0.393470913172
>     endloop

And as you can see, that's about as close to SDL's triangle {} statement as
anything.

> In POV-ray, I took the 'facet normal' data/vector and ran it with vlength(...)
> and #debug. It turns out that ALL of the triangles have a unit-length normal:
> <1.000,0.000,0.000>, as vlength reports it.

Well yes.  Those are going to be the final surface normals, and ought to all be
1.0.   The intermediate computations for calculating what the vertex normals of
smooth_triangles are can be anything.  The final normals, however, are almost
always going to get normalized, and so end up as length 1.0.   It's really the
direction of those normals that's going to influence how the light bounces off
of the surface from the light_source to the camera, and show up as either a flat
facet, a smoothly curving surface, or a normal {} pattern.

> [off-topic here but interesting}: The MESHMIXER app (also my CURA 3-D-printing
> app) shows the STL object to have smooth edges-- even though the triangle
> data appears to be 'un-smooth'. I have no idea why. Perhaps those apps are
> automatically creating smooth triangles from the data. (Or maybe interpolating
> the data from the individual vertices?)

Yeah, I think that's just the way they get rendered.  There's likely a setting
that you can turn off, so you can see the raw stl mesh.

- BW

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> ..and converted it to an asci-text STL file. The triangles-- or each
> vertex?-- are of this typical form (not 'smooth triangles', as far as I know)...
>
>  facet normal -0.107895597816 -0.696702897549 0.709199249744
>     outer loop
>       vertex 21.3610057831 0.39481022954 -0.11346334219
>       vertex 22.4441795349 0.273843616247 -0.158073753119
>       vertex 22.0666675568 -0.210549205542 0.393470913172
>     endloop
>

Just to follow up, after a little more research:
FACET means the entire triangle, not an individual vertex. STL files are
composed of flat triangles, not smooth ones. Giovanni's STL image show this too.

-------------------
I am not very happy that MESHMIXER (and CURA) show 'smooth triangle' versions of
the file; I would rather see the raw-triangle representation there. And it seems
that CURA also *outputs* its .stl-to-.gcode 3-D-printing file as a
smooth-triangle version, according to tests that I have made. I have mixed
feelings about that...

Post a reply to this message