materials frontside - backside

[Devran]

hi all,

I found a ineressting bug... I hope not known ;D
when I asign V-Ray materials with Paint-Bucket the renderer distinguishes between frontside (white) and backside (purple)...

a catastrophy in architectural modelling... think about indoor outdoor renderings... . Lucky for us materials assigned with Material Editor don´t show this issue, glass material is just desaturated... interessting isn´t it.

bye devran

[dalomar_cg]

Re: materials frontside - backside

When using the paint bucket, we distinguish frontside and backside because SU makes that distinction. SU keeps both the material and texture coordinates for the front side and back side of the face separate, so unless you explicitly apply the material to both, then you'll only get it on one or the other.

Originally there was no acknowledgment of front/back faces in V-Ray, but with the first service release, this behavior was changed. There's been some requests to have some sort of middle ground between the way things are now and the way things behaved in the original release, but we haven't had much of a chance to give it any thought.

[thomthom]

Re: materials frontside - backside

Originally there was no acknowledgment of front/back faces in V-Ray, but with the first service release, this behavior was changed. There's been some requests to have some sort of middle ground between the way things are now and the way things behaved in the original release, but we haven't had much of a chance to give it any thought.

What would be nice if V-Ray did what SU did.
When you have a transparent material to one side, and the other is Default, both sides display as transparent.
And that V-Ray would recognize custom Default colours. More WYSIWYG.

[dalomar_cg]

Re: materials frontside - backside

What would be nice if V-Ray did what SU did.
When you have a transparent material to one side, and the other is Default, both sides display as transparent.
And that V-Ray would recognize custom Default colours. More WYSIWYG.

This is a problem. Perform the following steps.

1) create a material that is just a color...no transparency information

2) apply that material to a single face of a plane that has just been created (ie has no material applied to it)

At this point, the rendering is the same as the viewport...the front face and back face have different materials.

3) while looking at the back face, change the Opacity from 100 to 99. You will see the back face immediately change to the material of the front face.

At this point, the rendering is not the same as the viewport, since the backface has automatically applied the material onto the backface.

4) Set the Opacity of that material back to 100. The back face of the material now goes back to the default material. Now create another material that's just a color (preferably a different one) and no transparency information. Apply that to the back face.

At this point, the rendering goes back to matching what you see in the viewport.

5) Change the opacity on either one of the materials that are applied to that geometry. Now the opposite face does not change its material to coincide with the face that has the edited material.

Again, the rendering matches the viewport.

So this is a problematic situation, because in all cases but one wysiwyg. However the only spot where its not is the case where SU just "decides" that the material should be on the back side. There's obviously a rational for this, yet because SU does not process this event as a such (ie there's no way for us to look for "material changed opacity, but it only affected faces without a material specifically applied to the opposite face" event, it makes it very hard to support this behavior. As a note, I believe that the original version of VfSU would have only gotten the correct result 2 out of the 4 times.

Anyway, what I'm getting that is that in a number of situations SU has very little rational for how it goes about doing things. Why, for instance, is alpha the only setting that forces application to a backface? This makes it extremely hard to actually support some of this "eccentric" behavior. The best we can do is support what is performed EXPLICITLY. That's my take, but I don't know what your take on this is.

I actually do not know how to change the default material that is applied to geometry in SU. Can you point me to how to do this? As of right now, I'm not sure if there's a way for us to support this.

[thomthom]

Re: materials frontside - backside

Yea, SU do some things to be 'clever' which really annoys me. Like poping up the material window every time you activate the paint bucket tool. Or turn on textures when importing a model with textures. Or changing the line colour when it matches the face colours, etc etc. It makes too many assumptions.
This whole backface/frontface thing isn't too much of a concern of mine. I make sure to orient everything properly. But I've observed other users get confused when what they see in SU doesn't match the render.

I actually do not know how to change the default material that is applied to geometry in SU. Can you point me to how to do this? As of right now, I'm not sure if there's a way for us to support this.

In SU you set it under the Style window in the Face settings. You see the "Front color" and Back color" settings there.
In Ruby they are accessed from Sketchup.active_model.rendering_options

If you open the Ruby console and type in this: Sketchup.active_model.rendering_options.each_pair { |key,value| puts key.to_s + ' - ' + value.to_s }
You will get a list of all the data. The two keys "FaceFrontColor" and "FaceBackColor" contains the RGBA data for the default colours. And there's even an RenderingOptionsObserver which should notify you about changes here if that's needed for some reason.