"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

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

> sure, last night I started with two faces, then three, then a cube (bad idea),

Well, it was a good idea, because it shows you what can happen  ;)


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

Well, you can do whatever you like, but I'm not sure how much faster it will be,
or how much better it will be.

First you have to compute the center, and then you have to pick - what - the
maximum distance to 3 vertices?  What if you have 2 triangles that share the
only a single vertex?  |X|  Which of the 2 sides on the one triangle do you use
to scale the face normal by?

If you have vertices, A, B, and C, then you have vectors (A-B) and (C-B), and
the vector cross product of those will give you a vector perpendicular to the
surface (the face normal), AND it's length will be a scalar value proportional
to the surface area of the triangle, all in a single calculation.

What I usually do when experimenting with different methods, is either use a
#switch block to choose what method I'm using, or use macros with similar names
that do things a slightly different way.
#macro Method1 ()
#macro Method2 ()
#macro Method3 ()

and then I just change the name of what macro I'm calling to do the part of the
code where I'm doing the experimentation to see what will work best / fastest.


- BW

Post a reply to this message

"GioSeregni" <gms### [at] hotmailcom> 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.
> 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

Glassner, Andrew, Building Vertex Normals from an Unstructured Polygon List,
Graphics Gems IV, p. 60-73, code: p. 64-73, vert_norm/.
https://www.realtimerendering.com/resources/GraphicsGems/gemsiv/vert_norm/

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.
> > 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
>
> Glassner, Andrew, Building Vertex Normals from an Unstructured Polygon List,
> Graphics Gems IV, p. 60-73, code: p. 64-73, vert_norm/.
> https://www.realtimerendering.com/resources/GraphicsGems/gemsiv/vert_norm/

Thanks, but I my code with normals works fine, see my code and render pictures
above.
Furthermore, even if I am able to calculate the normals, in the binary STL files
to be converted, they are already present and available.
The question is about the level of the smooth.
I would like to get the effect of a smaller radius in the rounding illusion.
As Bald Eagle suggested I'm trying to work on the single "weight" of normals in
their average for each point  (which creates the smooth effect) , considering
the size of each triangle.
I hope I have explained myself, I have little command of English, and the
question is not very simple
Many Thanks!
G.

Post a reply to this message

I'm slowly clearing my head
For an excellent result the code must have at least 3 steps
1) (already done), calculation of the average of the normals affecting the
point.
2) Correcting the weight of the normals per point if they also come from
triangles with a large surface area
3) Corrective of the normals if the adjacent triangles have an inclination
between them that tends to approach 90 degrees

G.

Post a reply to this message

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> For an excellent result the code must have at least 3 steps
> 1) (already done), calculation of the average of the normals affecting the
> point.
> 2) Correcting the weight of the normals per point if they also come from
> triangles with a large surface area
> 3) Corrective of the normals if the adjacent triangles have an inclination
> between them that tends to approach 90 degrees

fwiw, my 'gts2pov' takes triangle area into account when calculating the
normals.  also just found mention of a 'stl2pov' software :
<https://news.povray.org/web.6156c51533af95845bd1b3ba6cde94f1%40news.povray.org>

<https://wiki.povray.org/content/User:Jr>


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > For an excellent result the code must have at least 3 steps
> > 1) (already done), calculation of the average of the normals affecting the
> > point.
> > 2) Correcting the weight of the normals per point if they also come from
> > triangles with a large surface area
> > 3) Corrective of the normals if the adjacent triangles have an inclination
> > between them that tends to approach 90 degrees
>
> fwiw, my 'gts2pov' takes triangle area into account when calculating the
> normals.  also just found mention of a 'stl2pov' software :
> <https://news.povray.org/web.6156c51533af95845bd1b3ba6cde94f1%40news.povray.org>
>
> <https://wiki.povray.org/content/User:Jr>
>
>
> regards, jr.

Tx JR!
My code is already working from STL to POV even with the color subset of STL.
In fact I have to add the surface calculation to the loops from triangle to
smooth_triangle, I'll take a look at your system. But first I also want to
translate the color, as I already do with the triangles, dividing groups of
differently colored meshes. This way my translator will also become faster
because the loops are compact and short on small meshes.
(between different colors I don't want smooth).
In the center STL, on the left the current smooth routine, on the right the
simple triangle mesh. Thank you!

Post a reply to this message

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

Preview of image 'clipboard01.png'