Alpha transparency in back face

soldatino

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.

slbaumgartner

The piece of the puzzle that you may still be missing is that Faces in SketchUp also have an associated normal Vector3d that defines "front" or "outside". On the entity info window, the material painted on the "front" shows in the left panel, and the material painted on the "back" shows on the right panel. From your SketchUp picture it is evident that what one would logically call the "inside" of the window is actually the "outside" in terms of SketchUp Faces. That is, the brown-red color shows where the inner surface is visible and the transparent color where it is not. Your Face normals are pointed inward. You need to reverse all of the Faces of your window by means of the right-click context menu in SketchUp.

soldatino

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

slbaumgartner

@soldatino said:

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

As you draw a Face, the ordering of the vertices ordinarily determines the orientation of the normal vector, hence the directions of "front" and "back". However, SketchUp sometimes flips the normal during its cleanup operations. For example, it will determinedly force the normal to point downward if you draw something on the z=0 plane. It will also flip normals to match where two Faces intersect. It will usually cause the normals to all point outward when you create a "solid". So, it always pays to check what you got and fix up any reversals, especially before doing things like applying translucent materials that can confuse the issue!

In ruby code it is not uncommon to have to test whether a normal came out the way you assumed. For example, a positive push-pull value goes in the direction of the normal vector. If SU set it opposite to what you assumed, your operation will also go opposite.

In the case of your converter, it seems to me that you can't make assumptions about what the creator of the original model intended. If they modeled a particular way, maybe that is what they meant!

soldatino

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

TIG

Now you are feeding us more information in tiny morsels.
In most renderers you only get the front face rendered in its color/texture, any back face is usually shown in white/black/default/transparent material depending on the rendering-application used.
It is therefore important that 'visible' faces are front faces.
If you are making glass that will be view from both sides it should have a real thickness, like in the real world, with both of its faces looking outwards.
If you have any single face then its back view in a render may well look different from how it renders in SketchUp.
If you view the model in Monochrome mode using a Style with a distinctively colored default back-face material, you can more readily see what faces are incorrectly oriented.
There are several tools to reverse such poorly modeled faces.

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 !

In code you can also paint the same material on every face's back as it is front.
So for example iterating all faces to make sure any ones using a transparent material, then have the same material on both sides...
faces.each{|face| face.back_material=face.material if face.material && face.material.alpha < 1.0 **&& !face.back_material** }
The part at the end - && !face.back_material - only paints the back of a face if it is in already in the default material, BUT omitting it forces every face which has a transparent material to have that material on its front AND its back sides.

You can of course do much more, but that's just one idea......

soldatino

@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

AdamB

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

AdamB

@tig said:

In code you can also paint the same material on every face's back as it is front.
So for example iterating all faces to make sure any ones using a transparent material, then have the same material on both sides...
faces.each{|face| face.back_material=face.material if face.material && face.material.alpha < 1.0 **&& !face.back_material** }
The part at the end - && !face.back_material - only paints the back of a face if it is in already in the default material, BUT omitting it forces every face which has a transparent material to have that material on its front AND its back sides.

And of course this ignores Group materials that override any face with the Default material. So you can't just check when face#[back_]material is nil

TIG

You are right about the angle check.
I threw it out as a way of approaching something - NOT a fully fledged working tool/method...

However, this could be further improved by not using the camera direction vector, but getting the vector between the eye and parts of the face [like bounds.center or vertices] AND the angle_between each of those and the face.normal ?***

Didier Bur's 'Automatic Face Reverser' in the PluginStore works by using a pickray within a Tool t and inspects the visibility of every vertex in a face, casting the ray from the eye, until one is visible AND the normal is looking away from the camera [>=180.degrees], then you are looking at a visible bare back...
Didier's file's code is 'packed' as a low level encryption, but by making a copy and changing the file suffix to .txt so it doesn't load, and editing the initial 'eval' to a 'puts', will then 'unpack' its contents and print it out in the Ruby Console when you use 'load' on it later...
Note his tool only works on the active_entities or selected faces, and also has an option for multiple eye-point checking etc...

soldatino

@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

AdamB

I've made a simple model to help understanding.

Open it and you'll see a single face, but its actually rhomboid with the "sides" facing toward the camera direction.

You can't do a worldspace test to determine visibility in a non-orthonal projected space.

EDIT: well thats not entirely true, but you need more than camera.direction.

backface culling.skp

soldatino

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!

soldatino

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

soldatino

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

TIG

So you have finally realized that sloppy modeling leads to back-face issues.

That is why I developed http://sketchucation.com/pluginstore?pln=FixReversedFaceMaterials
View the model in Monochrome mode, so that you can see visible 'back-faces' in a distinctive color set in the Style.
There are several tools to flip [reverse] the face so its 'back' is then facing the correct way.
BUT these faces will then take their material with them, perhaps leaving a default [or other unexpected material] front face visible.
My tool reverses any [selected] face with a material on its 'back', AND then reuses its back-material onto its front, keeping any UV-mapping, and it then defaults the back material of the face too.
There are other tools which reverse faces, and swap the materials between the face's sides too [thomthom has one...]

soldatino

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

soldatino

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