Many thanks for the quick response, I suspected but now I am sure I did not make mistakes, so I'll keep the filter. The problem is theoretic and practically it shows in "wrong" , or better "bad", drawings , and also the import plugin is already very slow and an operation of this kind, much much more slow. Indeed I thought in the practice of what is necessary to enlarge the incoming data so as to insert acceptable values, and then reduce the modified product after extracted again from SU.
I now have a very clear idea then! Thanks again!

First, Excuse my bad English
In some plugin of mine I have a filter working of the faces that I import or export in SU.
This is the code for a 3 points face:

if (pts[0].vector_to(pts[1]).parallel? pts[1].vector_to(pts[2]))==false
     if (pts[1].vector_to(pts[2]).parallel? pts[2].vector_to(pts[0]))==false
           nu=ent.add_face pts[0..2]
           nu.material=matf
           nu.back_material=matf
     end
end

It is my workaround because I need to filter for example a false triangle, where all the 3 points are filled in the same segment, and the face has not really area.
Well, luckily this code traps also captures TRUE faces that have 2 long sides and one side very small.
EXAMPLE:
-42.711087, 3.524699, 0.0 (vertex 1)
-42.711084, 3.524691, 0.0 (vertex 2)
1705.049441, 820.900776, 0.0 (vertex 3)
This is a valid triangle but, if I attempt to import it, without the filter I wrote, SU fails and the plugin exit out.
The concept is : SU allows floating points, these points are really imported, I debug using
UI.messagebox( (pts[0]).to_s)
UI.messagebox( (pts[1]).to_s)
UI.messagebox( (pts[2]).to_s)
but the sides ARE NOT parallel, even if the API say YES!
And also if I attempt to create a triangle!
What a kind of floating values does SU use?

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

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

@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}}

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

17/11/2010 10:03:00
//Ending at 17/11/2010 10:03:18

17/11/2010 10:09:00
//Ending at 17/11/2010 10:09:18

28935 faces
Later I will check on largest files...

This is a part of my exporter to POV-Ray. Yes, now I apply your suggestion !

@thomthom said:

@soldatino said:

note: Vertex.used_by? in a loop of all connected faces ? waiting for the eternity...

I am worried because I think that with large model the time required will be huge.
Addictionally I would not repeat the calculation for the same point when the loop scans the already involved faces, but if I do not want to repeat I have to save an array for all the entities, containing normals already calculated, and to scan it also, which could be worse...

thomthom, TIG, thanks. I will attempt to write this in Ruby, even if I dont know much of this language, to do it with a post editor would be very easy, storing the array of all the normals of every face as comments within the ouput of the points ...

note: Vertex.used_by? in a loop of all connected faces ? waiting for the eternity...

yes, thanks, pointing at the face I get the float values of the vector.
Now if it is a offset valid for all the points of each face, I have to find the common points of adjacent faces, and interpolate their offsets to get the vector for the points. A lot of work... do yo think it is right?

http://code.google.com/intl/it/apis/sketchup/docs/ourdoc/polygonmesh.html#normal_at

but this is about points "particular index in the mesh."
Or it is for each face? In this case I have to calculate each angle between vertexes of adjacent faces?
Anyway the vector that I get is 0,0,0, but the faces have smooting in SU.
http://sketchup.google.com/support/bin/answer.py?hl=it&answer=114941
the procedure is explained in the yellow window..

I am sorry but I use this topic because it seems to be about my question.
I make a solid using the help example for smooth surfaces (6 sides), then I push for the elevation, then I select all the object, then I apply Soften edges angle 79,0 degrees, and the edge appear soft.
But if I get the normals at each point I read always (0, 0, 0), that is not a valid vector.
Sorry, where I am wrong?

 
for np in 1..numpol do
  vertices=mesh.polygon_at np
  numvrtx=vertices.length - 1
  for eachvrtx in 0..numvrtx do
    x = mesh.point_at((vertices[eachvrtx]).abs).x*RatioPov
    y = mesh.point_at((vertices[eachvrtx]).abs).y*RatioPov
    z = mesh.point_at((vertices[eachvrtx]).abs).z*RatioPov


    nx = mesh.normal_at (eachvrtx+1) #index is base 1
    UI.messagebox(nx.to_s)

thanks , I now see that about it there are topics in the forum...

@thomthom said:

You can use Win32 API...
http://ruby-doc.org/docs/ProgrammingRuby/html/lib_windows.html

thanks but the meaning of the error vs
require 'Win32API'
is that the build-in Ruby in SU does not have this extension? Does the user need to install ruby runtime components?

Well I need win API in SU's Ruby because I want write a rb plugin with the same code I use in T-Magnifier, but it seems that I cannot without complicated extensions !
All the languages can access to the win API...

@thomthom said:

@soldatino said:

I did not attempt to sniff the jpg size because the compress header has particularity different of other picture formats, it is not a true header, and I dont have enough knowledge about it.

What header are you referring to?

I'm not sure if we are referring to the same thing - maybe this screenshot will help.
[attachment=0:3ag13v96]<!-- ia0 -->SUMaterialStart.png<!-- ia0 -->[/attachment:3ag13v96]

exactly I was talking of the header of the jpg file itself

updated 0.0.9
faster, filename's search uses only ("jpg" or "IEND" strings) + &FF&FE&FF pointer

Yes I downloaded it but I did not found jpg blocks and I thought that the markers was the signature only for the structures of objects and the jpgs were an unexplored different attachment.
Addictionally I thought that SU maintained an area of overwriting for the jpg images in the file, because I find garbage (jpg started and not ended, but it is possible that I was wrong) and I got the idea of a single physical space of storage...

I did not attempt to sniff the jpg size because the compress header has particularity different of other picture formats, it is not a true header, and I dont have enough knowledge about it.
But your screeen shot is very good. I only knew the FF+FE recurrence. Your confirmation is important for me, with your addictionally info also.
Thanks!
ps I now can improve the exact png filename also, that at this moment I did not still search...

yes, this is now the way that I use to find the pointer of the jpg end.

DefStr endj
DefStr endjH
endj="."+chr$(0)+"j"+chr$(0)+"p"+chr$(0)+"g"+chr$(0)
endjH="."+chr$(0)+"J"+chr$(0)+"P"+chr$(0)+"G"+chr$(0)
DefStr slash1$ ; slash1$=chr$(0)+"/"+chr$(0)
DefStr slash2$ ; slash2$=chr$(0)+"\"+chr$(0)
DefStr slash3$ ; slash3$=chr$(&hFF)+chr$(&hFE)

then, looping block of 200 bytes, then, if the block has endj or endjH then, looping in the block

    hh$=File.ReadBinStr(1) ; rd=rd+1
    File1.WriteBinStr(hh$,1)
    if hh$="." then
      DoEvents
      npo=File.position
      hh$=File.ReadBinStr(6) ; File.Seek(File.Position-6,0)
      chh=REPLACESUBSTR$(hh$,CHR$(0),"")
      chh=LCASE$(chh)
      DoEvents
      IF chh="jpg" then
        File.Seek(File.Position-128,0)
        name$=File.ReadBinStr(134)
        slash1=INSTR(name$,slash1$)
        slash2=INSTR(name$,slash2$)
        slash3=INSTR(name$,slash3$)
        IF (slash1 + slash2 + slash3)<>0 THEN
           >>>  FOUND! Then I start the detailed search of the pointer...
 

and now I am waiting for the next file that will fail