 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"GioSeregni" <gms### [at] hotmail com> wrote:
> Hi all, first I apologize for my bad english.
> I finished now developing (basic version no color at this moment) a small
> transformation tool from STL mesh, in the center, to mesh with smooth_triangles.
Hello Giovanni!
Your results are already looking very good! :-) Congratulations for figuring out
this kind of translation. (I have been busy working on the 'opposite'
translation-- POV-ray objects to STL.)
A little utility called 'stl2pov' was mentioned. I remember it from years ago.
It is still available here, although it apparently runs in Python(?). It might
give you some ideas and suggestions about your problem.
https://github.com/rsmith-nl/stltools
By the way, 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.
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. (?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
*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. (?)
or maybe... MORE smooth? So perhaps the normals on LARGER triangles could be
*duplicated* in your summing process instead, to make their contribution have
more weight, resulting in a *less*-smooth result. Based on the size or computed
area of each triangle.
I apologize for just guessing about this, because I don't fully understand all
of the details of your idea.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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".
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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".
>
> - BW
tx Bw
I am working around this concept. The bad angle is 90 degrees. The vectors are
ever long 1 (red color), so the distance (green) it's approximately 1,4142
(Pitagora).
Around this value I have to eliminate the smoothing. It involves graduating on
the size of the angles. Unfortunately I don't have much training in
trigonometry... it takes me a long time and I don't know the shortcuts in the
formulas, I need time...
TX Again
G.
Post a reply to this message
Attachments:
Download 'clipboard01.jpg' (476 KB)
Preview of image 'clipboard01.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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!
Post a reply to this message
Attachments:
Download 'clip.jpg' (399 KB)
Preview of image 'clip.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
