Tig, I checked, but AdamB is right ...

@adamb said:

@tig said:

In code you can ensure a face's normal is towards the camera [get angles between the view direction and the face.normal], if >180 you are looking at the front !

TIG, strictly this is only true for a parallel projection. Its broadly correct for perspective projection, but not for all cases.

The search for the "internal" and "external" of the object, this is the only way to evaluate the order of the vertices of the faces.
Instead, this code seems to be a solution.
It is a raw code ... it investigates only the skin of a compact object, devoid of undercuts ... but I will write the recursive routine. the ray must to come and to go in the solid, each IN must find his OUT in the space, and to end this way in the open space, switching the on - off ... otherwise the beam was started by a face looking at the inside of the object, and the normal of that face watch inside (what I have to correct) ...

  
  if face.material==nil        #and face.back_material!=nil
      model = Sketchup.active_model
      vertx=mesh.polygon_at 1
      ray = [mesh.point_at(1), face.normal]
      item = model.raytest(ray, false)
      if item.to_s.length!=0  then
            # UI.messagebox(item.to_s.length.to_s)
            face.reverse!
            #  face.material=face.back_material
            # else
            #  UI.messagebox("ok")
      end
  end

PS: at this moment in the code the point is one random of the face vertexes, it would be better to define an interior point on the plane of the face, which is not disturbed by any adjacent faces at 90 degrees that can confuse

really, more than I have to figure out how to draw, I have the opposite problem, I certainly do not model these objects so sloppy, (and redundant, but that's another matter) because I'm used to working on a real CAD for a lifetime . It took me a long time to realize that SU uses safely the back face as a front face, pulling on the front his color back ..... so I will have to develop a filter that normalize the entire model. My problem is not learning how to draw, but how import those models that do not have a decent description of the points .... thanks

I will check your code !
tar=cam.target
vec=eye.vector_to(tar)
if vec.angle_between(face.normal)>90.degrees .....

My conclusions.

Generally the principle of OR between the two sides of a face works for transparency, because it is always quite reasonable that the apparent transparency is equal between the views from inside OR outside.
Instead, the problem is more serious for the color.
SU does not differentiate inside and ouside of each face and objects does not apply evenly the principle of the right hand.
Faces and back faces are not always oriented toward the outside the first and the second inward.
For this reason, when exporting is important to check the normal to choose the right color (if the colors are two) for export to the face.
The methods exist, it is only a matter of working on it, even if it is not simple.
http://en.wikipedia.org/wiki/Back-face_culling
In the image, the example, part of the truck (sketchup object found in the web) with the door designed with the order of the clock and also with the reverse order. (image of MeshLab after I imported some faces of the truck converted in STL format)
sorry for the bad English, I hope it is at least understandable

The simple to apply an OR between the sides seems to work well. Note that the windows of the truck were opaque even on SU, but now the lights are transparent, the same of SU.
I have to test it on various models, because my old version of the plugin to import in PovRay exchanged opacity values and I have to fix the little problem. SU uses the opacity value, and instead using PovRay I usually write the transparency. So I have to make complementary to 1. I did not realize at that time because with 50% of transparency (more or less) the results seem to be equal .... Then the next day I will update the plugin .... thanks

maybe I did not understand, but if I could see the faces covered and their normals (which geometrically can do), normals vectors should be away and not to my point of view. Which would mean that I would be looking at the back of the faces .... but maybe I did not understand what you mean, later will study better, thanks!

@adamb said:

@tig said:

In code you can ensure a face's normal is towards the camera [get angles between the view direction and the face.normal], if >180 you are looking at the front !

TIG, strictly this is only true for a parallel projection. Its broadly correct for perspective projection, but not for all cases.

Yes, but the summ of the perspective projections draw step by step the outer visible skin of each object, only if you are "into" the object the entire skin is reversed.
I think that it is the right method to identify if the face is drawn properly...
Thus, in case of doubt with transparency valued only on the back of the face, checking if the face was drawn wrong then I can understand why transparency is over just that way.
And this is precisely the case of the glass of the truck that was giving me uncertainties.

PS. inherited attributes are one other thing to consider, but if you take a look at my code you see that I have a map levels that store the parent attribute, and only if the face need it, I load that value

@tig said:

In code you can ensure a face's normal is towards the camera [get angles between the view direction and the face.normal], if >180 you are looking at the front !

yes, I think that this is really a good idea.
I thought for a control vector from the center of the object, but it is not a general rule, if the object has undercuts ...
instead your idea can not fail

No, I do not assume anything, I follow what APIs tell me, but it is not ok, because a face drawn as transparent from the inside OF THE TRUCK, SU shows transparent from outside OF THE TRUCK.
This makes it a bit difficult to make the correct view on other platforms.
Don't care of the code in surplus, I just need to relate to integer (part of 100) for my needs ....

thanks, this is not a model of mine, who did it drew partly in one way and partly in another. I was looking for a test of my format converters, but I think that if I wont to do a perfect job I also need to search the SU API that gives me information about the "normals" of the faces drawn that I must translate...

The confusion starts from the fact that I see contradictions, it is not easy to explain.
I isolated the glass and I'm sure.

• face.back_material.alpha - declare a value of low opacity for the "back" of the face, and it is exact because the face is designed relatively to this side, and has vertices in reverse order if we look at the truck from the outside.

But the same face on the window of colors of SU is shown with the back color on the left, as if it were the primary side of the face, that instead is completely opaque.
I conclude that to test the proper operation of my parser does not have to look at the order used by the window that I showed above.
http://sketchucation.com/forums/download/file.php?id=125617

Ok, thank you for patience and useful general explanation.
Now even though I understood the mystery of the face "internal".
Who had designed the glass had done it in reverse ....
I turned the object into STL format and I checked the normal in MeshLab.
On MeshLab the glass appears "broken", as all faces reversed, MeshLab does not reflect light for it. For this reason, the transparency on SU is active, in fact transparency appears on the right, but the faces are reversed.
(in the small image, I reversed the normals)

In SU (second upload) this concept is obvious if I try to change color, the color in the palette is at left side (first), I thought was the main (front face) but the face that paints is the (false back) inside.