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.
But I have a problem. Too smooth. I thought that the length of the normal vector
caused a gradation, but this is not the case, even if I reduce the length of the
vectors the smoothness level remains the same. What am I doing wrong?
Thanks in advanced!
Giovanni

Post a reply to this message

Attachments:
Download 'smoothstltest.png' (148 KB)

Preview of image 'smoothstltest.png'

"GioSeregni" <gms### [at] hotmailcom> wrote:
> Hi all, first I apologize for my bad english.

It's fine, and you probably speak better English than many people who speak it
natively.  ;)

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

Excellent.  Hopefully it was simple, can be invoked from SDL with a
pre_frame_command, and makes an .ini file with a built-in inside_vector
statement.

> But I have a problem. Too smooth. I thought that the length of the normal vector
> caused a gradation, but this is not the case, even if I reduce the length of the
> vectors the smoothness level remains the same. What am I doing wrong?

Not sure what "too smooth" means.

We would also need to see your exact code to make the smooth_triangle from the
stl triangle vertices.  That can get complicated, especially with a free-form
mesh like you're starting with.

For any given triangle, you're going to have neighboring triangles with
different face normals.  The normals of your smooth_triangle vertices should be
the average of all of the face normals that meet at that vertex.
So, you're going to have to find all of the neighboring triangles that share
common edges/vertices.

You're also going to have to have ways to handle missing triangles, edges, and
things like the edges of a cubic mesh - since on face of a cube should not
influence the normal of a separate face.

It's looking great, and anything is better than nothing!
I would suggest that you just search for calculating triangle normals, and you
ought to come up with articles and forum posts on scratchapixel.com,
gamedev.net, etc.  There's likely going to be instructional videos on YouTube
from people like Daniel Schiffman, Sebastian Lague, Martijn Steinrucken, Inigo
Quilez and a host of others.

Try rendering with a texture {} AND and interior_texture {} of contrasting color
to get a true idea of where your normals are facing.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > Hi all, first I apologize for my bad english.
>
> It's fine, and you probably speak better English than many people who speak it
> natively.  ;)
>
> > 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.
>
> Excellent.  Hopefully it was simple, can be invoked from SDL with a
> pre_frame_command, and makes an .ini file with a built-in inside_vector
> statement.
>
> > But I have a problem. Too smooth. I thought that the length of the normal vector
> > caused a gradation, but this is not the case, even if I reduce the length of the
> > vectors the smoothness level remains the same. What am I doing wrong?
>
> Not sure what "too smooth" means.
>
> We would also need to see your exact code to make the smooth_triangle from the
> stl triangle vertices.  That can get complicated, especially with a free-form
> mesh like you're starting with.
>
> For any given triangle, you're going to have neighboring triangles with
> different face normals.  The normals of your smooth_triangle vertices should be
> the average of all of the face normals that meet at that vertex.
> So, you're going to have to find all of the neighboring triangles that share
> common edges/vertices.
>
> You're also going to have to have ways to handle missing triangles, edges, and
> things like the edges of a cubic mesh - since on face of a cube should not
> influence the normal of a separate face.
>
> It's looking great, and anything is better than nothing!
> I would suggest that you just search for calculating triangle normals, and you
> ought to come up with articles and forum posts on scratchapixel.com,
> gamedev.net, etc.  There's likely going to be instructional videos on YouTube
> from people like Daniel Schiffman, Sebastian Lague, Martijn Steinrucken, Inigo
> Quilez and a host of others.
>
> Try rendering with a texture {} AND and interior_texture {} of contrasting color
> to get a true idea of where your normals are facing.
>
> - BW

Many Thanks!
My code is easy. I use all the vertices of the triangles to create an array of
points (xyz).
Another array, absolutely PARALLEL, contains the normal (xyz) for each vertex of
the first array, obtained from the normal of the corresponding triangles.
Then I scroll through all the points with a nested loop, step by step for each
point, and every time I find an identical point I go to point to its vector in
the second array. I add the vectors that I find for the equal points, then at
the end, I divide the value of the vector sum by the number of points that I
found equal. And I get the AVERAGE vector for each vertex.
It seems correct, PovRay does not give errors, but I would like the rounding of
the edges to be less, as per this diagram.
Thank you very much!
G.

Post a reply to this message

Attachments:
Download 'sm.png' (7 KB)

Preview of image 'sm.png'

I remember reading somewhere that the length of the normal vector determines the
smoothness. Shorter the vector, smaller the radius of the corner rounding, but
PovRay doesn't seem to think this way.
I was wondering if there are any options in the syntax...
Thank you again!
G.

Post a reply to this message

"GioSeregni" <gms### [at] hotmailcom> wrote:

Sounds good.

> It seems correct, PovRay does not give errors, but I would like the rounding of
> the edges to be less, as per this diagram.

So you want a sharper curvature.

Try this:

Take your starting triangle and find the area.  1/2 base times height, or
there's a matrix determinant way.

Use that as a multiplier - a weighting to that vertex normal.
Do that every time you find a matching triangle.  Weight the normal by the
triangle's area before adding it.
Never mind dividing / averaging - I think that would just ad an extra
unnecessary step - just use vnormalize ().

This way, the normal of the edge is influenced more by the bigger area than the
smaller transition area, and there should be a more sudden and pronounced change
of direction as you progress from one large face across the smaller face to the
other.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
necessary step - just use vnormalize ().
>
> This way, the normal of the edge is influenced more by the bigger area than the
> smaller transition area, and there should be a more sudden and pronounced change
> of direction as you progress from one large face across the smaller face to the
> other.
>
> - BW

Yes, really good idea, I understood the concept. Great concept.
I'm just worried about the times which are already very long lol

I have however noticed that short vectors, here X/10 y/10 z/10 seem to introduce
fewer artefacts!
Thanks again

Post a reply to this message

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

Preview of image 'clipboard01.png'

"GioSeregni" <gms### [at] hotmailcom> wrote:

> Yes, really good idea, I understood the concept. Great concept.
> I'm just worried about the times which are already very long lol

Indeed.  This is of course a common problem in dealing with large data sets in
computer graphics.

One thing you may want to consider is sorting your triangles so that you can
quickly use something like an octree to only search very nearby triangles for
matching vertices.

Do one BIG sort, then all of your very very many searches will be a LOT faster.

> I have however noticed that short vectors, here X/10 y/10 z/10 seem to introduce
> fewer artefacts!

When developing concepts like this, it is usually helpful to use very small test
scenes that parse and render very quickly, so that you can isolate and address
any problems quickly.  Then once you have everything worked out, you can try it
on a big mesh, like you are doing now.

Take a few single triangles, and just render them with different normal vector
lengths and see what happens.

First, all of your normal lengths should normalized as a starting point.
Then you add all of the weighted face normals with a common vertex,
and finally normalize the final result.

What language are you doing this in?   SDL?  :O

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
>
> > Yes, really good idea, I understood the concept. Great concept.
> > I'm just worried about the times which are already very long lol
>
> Indeed.  This is of course a common problem in dealing with large data sets in
> computer graphics.
>
> One thing you may want to consider is sorting your triangles so that you can
> quickly use something like an octree to only search very nearby triangles for
> matching vertices.
>
> Do one BIG sort, then all of your very very many searches will be a LOT faster.
>
> > I have however noticed that short vectors, here X/10 y/10 z/10 seem to introduce
> > fewer artefacts!
>
> When developing concepts like this, it is usually helpful to use very small test
> scenes that parse and render very quickly, so that you can isolate and address
> any problems quickly.  Then once you have everything worked out, you can try it
> on a big mesh, like you are doing now.
>
> Take a few single triangles, and just render them with different normal vector
> lengths and see what happens.
>
> First, all of your normal lengths should normalized as a starting point.
> Then you add all of the weighted face normals with a common vertex,
> and finally normalize the final result.
>
> What language are you doing this in?   SDL?  :O
>
> - BW

sure, last night I started with two faces, then three, then a cube (bad idea),
and then this.
I use the old RapidQ, it's slow but it's very versatile and it's the language I
know best, and the fastest to write. I also know XBLite, Ruby and AutoLisp, but
it would be much more complicated...

I was thinking, for your idea, instead of the area, which means many operations,
finding the center of the triangle, and comparing the size of the triangles
using the center- 1 vertex distance.
G.

Post a reply to this message

It's the first draft, raw and not optimized.
Be careful here, you are missing global variable declarations

Post a reply to this message

Attachments:
Download 'stlsmoothcode.zip' (1 KB)

"GioSeregni" <gms### [at] hotmailcom> wrote:
> It's the first draft, raw and not optimized.
> Be careful here, you are missing global variable declarations

GRIDf and NETf are memorystream, for points and normals...
so I have no limits of arrays to declare

Post a reply to this message