PolygonMesh behavior

tomasz

Do not count_points, count_polygons instead.
1 .. mesh.count_polygons
then

{
tri_indexes=mesh.polygon_at(i)
(0..2).each{|q| p mesh.normal_at(tri_indexes[q])}
}

EDIT.
use mesh 7 to ensure you get also normals. Doc doesn't say what is a default flag.

thomthom

But when you do 1 .. mesh.count_polygons you iterate over the polygons. And mesh.polygon_at(i) returns an array of point (vertex) indexes - which are the same indexes you get when you iterate mesh.count_points...

??

thomthom

@unknownuser said:

EDIT.
use mesh 7 to ensure you get also normals. Doc doesn't say what is a default flag.

Ah! Yes - of course. Now I get normals.

tomasz

Correct. They are same indexes, but now they define a triangle. In exporter you usually export triangles not a cloud of points...

Have you used mesh(7)? Maybe this is why it returns Vector3d(0,0,0) instead of Vector3d(0,-1,0)?

thomthom

@unknownuser said:

Have you used mesh(7)? Maybe this is why it returns Vector3d(0,0,0) instead of Vector3d(0,-1,0)?

Ja - it worked then. I'm guessing that was the same reason Soldatino got 0,0,0 normals as well.

soldatino

Thanks Tomasz and others!
Wow, I was away some time!
It seems it is possible, even if my english is terrible I think to understand something...
thomthom, exactly I had the same your results...

About the
x = mesh.point_at((vertices[eachvrtx]).abs).xRatioPov
Y = mesh.point_at((vertices[eachvrtx]).abs).yRatioPov
z = mesh.point_at((vertices[eachvrtx]).abs).z*RatioPov
instead of

pt = mesh.point_at((vertices[eachvrtx]).abs)

x = pt.x*RatioPov

y = pt.y*RatioPov

z = pt.z*RatioPov

I cannot confirm the better time of the second way... I understand that it seems impossible but my tests are different...
If I dont resolve I will send you my entire code of the plugin...

thomthom

@soldatino said:

I cannot confirm the better time of the second way.

It was just a general suggestion. When I was doing Vertex Tools I spend quite some time looking at performance - and when you do lots of iterations you can some times save some time by avoiding doing multiple lookups.
But overall gain will depend on what else your code is - there could be parts that offsets the performance gain too much.
If you want you can PM me the code and I can have a look at it.

soldatino

@thomthom said:

@soldatino said:

I cannot confirm the better time of the second way.

It was just a general suggestion. When I was doing Vertex Tools I spend quite some time looking at performance - and when you do lots of iterations you can some times save some time by avoiding doing multiple lookups.
But overall gain will depend on what else your code is - there could be parts that offsets the performance gain too much.
If you want you can PM me the code and I can have a look at it.

Yes I do!
HI, the normals are workin ! With flag 7 I got them !
The code is the output for POV-Ray (the normals are as // NOTE at this moment...)
triangle{<1.0,0.0,1.0><0.0,0.0,0.0><0.0,0.0,1.0>
// normal (0.0, 0.0, -1.0)
pigment{color rgb 1} finish{SkUpLight}}
triangle{<0.0,0.0,0.0><1.0,0.0,1.0><1.0,0.0,0.0>
// normal (0.0, 0.0, -1.0)
pigment{color rgb 1} finish{SkUpLight}}
triangle{<1.0,1.0,0.0><0.0,1.0,1.0><0.0,1.0,0.0>
// normal (0.0, 0.0, 1.0)
pigment{color rgb 1} finish{SkUpLight}}
triangle{<0.0,1.0,1.0><1.0,1.0,0.0><1.0,1.0,1.0>
// normal (0.0, 0.0, 1.0)
pigment{color rgb 1} finish{SkUpLight}}
triangle{<0.0,1.0,1.0><0.0,0.0,0.0><0.0,1.0,0.0>
// normal (-1.0, 0.0, 0.0)
pigment{color rgb 1} finish{SkUpLight}}
triangle{<0.0,0.0,0.0><0.0,1.0,1.0><0.0,0.0,1.0>
// normal (-1.0, 0.0, 0.0)
pigment{color rgb 1} finish{SkUpLight}}

soldatino

ok, I wrote a scanner that find the normals of the common vertexes and with the sum of the normal vectors it generates smoothed edges.
BUT, if I connect 2 planes it works, otherwise it does not work (strange results) if I attempt to connect 3 or + planes.
I used the sum of normalX, normalY, normalZ of the faces at each point + the x,y,z vertex offset of the same point.
But it seems to be bad.
Only where I erased the 3th plane the result is correct.
above, the POV-Ray renders

soldatino

question solved
POV-Ray help
Smooth triangle artifact

.....
*This assumes that the normal vector returned by the object is a true normal vector, and it works perfectly when this is so.

However, if the object returns an erroneous normal vector, ie. a vector which is not perpendicular to the surface, rendering errors can occur.

Smooth triangles and heightfields do this, and the price to pay are the artifacts in the lighting in certain situations.

The artifact is produced when the true normal vector would have an angle larger than 90 degrees with the ray, but the the actual vector returned by the object has an angle smaller than 90 degrees with the ray. In this case the rendering engine reverses the normal vector even though it should not. This is because it assumes that it is the true normal vector when in fact it is not.

This problem could be solved by making the decision of inverting the returned normal vector according to the true normal vector of the surface instead of the returned vector. However, due to the internal implementation of the rendering engine in the current POV-Ray 3.5, doing this is not trivial. It may be fixed in POV-Ray 4.0, where the rendering engine will be written again and this kind of things can be taken into account from the very beginning.*
see also
http://wiki.povray.org/content/Knowledgebase:Smooth_Triangle_Artifact

thomthom

@adamb said:

@thomthom said:

I did that for Vertex Tools, I take the average normal of the faces connected to the vertex.

You're missing a step with your averaging there. You need to weight by the contribution each face connected to the vertex makes - ie weight by the interior angle otherwise a cube constructed of triangles will end up with vertex normals not all pointing out exactly at 45 degrees.

How does one do that?