"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

>
> > [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...
>
> 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.
>

Finally found it in MESHMIXER-- it takes two steps. Apps that have lots of
features have lots of menus to learn :-/

     PREFERENCES:  choose 'face normals'
     VIEW: choose 'wireframe'

BTW, I was wrong about the CURA app automatically smoothing an STL model prior
to 3-D-printing it; the fault is in the STL output of that complicated 3D SLICER
app that I've been testing. I have to find where to turn that off (as an
option.)

[more on-topic, hopefully...]

I downloaded a few STL files made by others, to take a look at their triangle
meshes in MESHMIXER. There can be some complicated triangle arrangements in such
files! Even on what look to be completely flat surfaces. I guess the many
vertices have meet up *somewhere*.

Post a reply to this message

Attachments:
Download 'example_stl_mesh.jpg' (97 KB)

Preview of image 'example_stl_mesh.jpg'

ok, after two days of going crazy I implemented a drastic and elementary
control. Then later I will see how to improve with the "weights" and the
individual vertices, but now I have chosen the simplest path.
I work with normalized normals. So, if two normals make an angle of about 90
degrees, their normalized distance is about 1.41
Around this value I abandon the smooth and use the simple triangle.
I still have a lot to work on, I will find many special cases along the way, but
in this rough way I get rid of the most conspicuous artefacts.

Post a reply to this message

Attachments:
Download 'smoothed.png' (16 KB)

Preview of image 'smoothed.png'

1024x768 AA
22 minutes on my old notebook with win 10. I think I'll get half that on win 11
with the new one. I'll try tomorrow.
The concept is this


.....
distance=SQR( ((xNS-NormX1)^2)+((yNS-NormY1)^2)+((zNS-NormZ1)^2))
if distance > 1.38 and distance < 1.45 then NoNorm=1
....
distance=SQR( ((xNS-NormX2)^2)+((yNS-NormY2)^2)+((zNS-NormZ2)^2))
if distance > 1.38 and distance < 1.45 then NoNorm=1
....
distance=SQR( ((xNS-NormX2)^2)+((yNS-NormY2)^2)+((zNS-NormZ2)^2))
if distance > 1.38 and distance < 1.45 then NoNorm=1
......

Post a reply to this message

Attachments:
Download 'clipboard01.png' (254 KB)

Preview of image 'clipboard01.png'

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> 1024x768 AA
> 22 minutes on my old notebook with win 10. I think I'll get half that on win 11
> with the new one. I'll try tomorrow.

is that a large pizza and sides ?!  </grin>


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > 1024x768 AA
> > 22 minutes on my old notebook with win 10. I think I'll get half that on win 11
> > with the new one. I'll try tomorrow.
>
> is that a large pizza and sides ?!  </grin>
>
>
> regards, jr.

no no, lol, ebay or amazon!
Today a new trouble (solved).
Some incorrect results by same points.
Same for me, but not for "single". the "doubles" does not have this problem, the
"single", after operations, can to became x.00000000 like x.99999999999999 or
something similar
In fact Autolisp, for example, in comparison for "=" or "equal", has the option
that you can to use to define the small irrilevant difference.
but which is very relevant when I look for identities in my points cloud
(vertices), and that I have to cut in the comparison, or the comparison does not
work.
I'll have to add a filter...
BR
G.

Post a reply to this message