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.

thank you but I still absolutely do not understand.
Who made this object used a grey color with 100% opacity on the front face, and a white color with a transparency value on the back. Following this the face has become transparent.
Maybe I never understood the difference between material and color .... I'll have to start studying that ... thanks

but perhaps it is possible that the opacity of the gray does not matter because the grey is inherited from the block...

Now I am confused again. In my example above the front is grey... coloured, and 100% opaque, but the glass get the transparency from the back.
The grey is "default"? It is painted.
What is the concept of default in SU?

ok, thanks I think you're right, I try to run tests based on OR between external and internal, to understand if different values between outside and inside which is adopted. I thought at first that this was such a strange coincidence, and the possibility of difference in value as a general principle was implemented to allow view points from inside the objects. Thanks!
sorry my English is poor and wrong reasoning a bit complex....

I am unable to figure out how SU decides the transparency of a face.
It seems that "if" there is transparency in the back face SU chooses to use it.
It 's true?
This is a model in which the transparency is declared only on the back of the glass, but it is applied to the right view.
https://3dwarehouse.sketchup.com/model.html?id=607f2b88312dd468bb5c0bf5eec83fc
thanks in advance!

@driven said:

are you updating su2pov3.rb or starting again?
john

No, it's an old version, I'm working on a new one, but unfortunately I'm trying to understand how to use SketchUp Alpha declared a value on one side, and a different value in the same back_face simultaneously. All this is complicated by the same concept in the statements of the parent block. A problem that for now I can not find answer .....

This is a version a bit less old, but I hope to improve soon
http://imitidicthulhu2.blogspot.it/2010/12/skup2ray-v006.html

@adamb said:

The reason you really want zero-area, non-degenerate triangles is for this case:
[attachment=0:1fn6aq9s]<!-- ia0 -->KeynoteScreenSnapz018.png<!-- ia0 -->[/attachment:1fn6aq9s]

The triangle ABC has zero-area - BUT is critical to retaining a continuous surface. If you remove ABC, what happens is you get tiny cracks in the rendering because computers use a finite precision floating point representation - cracks in your render are entirely unavoidable without these 'stitching triangles'.

Anyway, best of luck with your solution.

Of course, but I have no plans to remove the false triangles in SU, the filter of mine is working in output to other engines, which do not like the fake triangle. But the problem is present in SU, that does not accept them as input, SU uses only three decimals and does not import certain triangles with a small side ... but it's only a problem conceptually. These faces are so thin that do not get "cracks" visible.

Thank indication but I already know something about the triangles.
Here we are talking about special triangles.
The false (type 1), and the triangles of the topic in the title (type 2). I had a very good answer on SketchUp behavior, which in extreme cases consider them in the same way.

@slbaumgartner said:

To avoid issues with floating point arithmetic, SketchUp has an internal tolerance of about .001". This was chosen based on its original use in architecture. In various operations, it tests values (especially vertices) for match to within tolerance. Depending on the operation, it may merge nearby vertices into one (basically, making the assumption they differ only due to numeric error) or may do things like you observed and proclaim two lines parallel when they are "close enough"...

If you read the start of the topic you will see what the problem was.
Anyway, thank you, there is always more to learn each other, I made a drawing to explain better the concepts already discussed.

Lol PovRay does not want triangles because they are redundant information. They are simple edges of something that it does not exist, the edges are not rendered. A triangle of these would be in any case invisible. Some graphics engine uses them but for their own reasons computational graphics. For example sculpties in Second LIfe absolutely needs the mesh is continuing to wrap objects, and I used these invisible triangles to have two detached objects but part of the same mesh ....

This is a PovRay example !

Yes, this is a opinion, but I need to export to PovRay, one of the best rendering engines, which does not recognize a triangle which is a straight line with the apex of the triangle placed at an intermediate point. And I can not manually delete step by step all the lines of code that stop and report.