Maya Lambert Shader Export

Hey,

I have a question about transparency in materials. In Collada, transparency is defined by a transp.color and a transp.key.

But when I export from maya, the key is always 1.0 (not transparanent) and the resulting transp. color contains the amount of transparency as well. (so a white color is full transparent).

In my opinion, transparency is defined by a color and a key. The color does not affect the amount of transparency at all. This is only defined by the key.

Does anybody have some insight?

  • Pieter

Hey Pieter,

The transparency factor is usually in the range [0,1]. Maya does always export a transparency factor of 1.0, which implies full transparency. As defined in the COLLADA specifications: you multiply the transparency factor with the transparent color: so the transparency factor is basically unused. In our viewer, I believe we average the three color components and factor in the transparency factor. Then, we do alpha-blending with that value. In truth: you should blend each color-component channel independently.

Maya supports a color (or textures) for the transparency without any extra factor: so it makes sense to rid ourselves of the transparency factor by always forcing its value to 1.0. In 3dsMax, you can use either an opacity factor or an opacity color, so the transparency factor does have some use there.

Hope this helps some,
Sincerely,

Hey Guillaume,

Thanks for your help. That makes sense. I’m developing the Collada 1.4 plugin for Blender. A lot of values from collada do not match the settings in Blender, so it’s a big puzzle ;).

I’m still unclear (I’m writing a Collada to X3D converter). I see some files with transparency 0 and some with transparency 1. Should I ignore this thing completely, as it seems to have dual meaning? Or should I use the transparent color all the time?

Take a look at the COLLADA 1.4.1 Release Notes revision A. It has a section explaining how to use transparency.
I suggest you implement it according to the spec and not based on the other implementations. They often get this wrong and we will definately be bugging them to get it fixed.

COLLADA Release Notes Rev. A

-Andy

Hi,

I’am created an COLLADA importer, and I’ve tested with several DCCs (3DSMax, Maya, Blender, …)… and my conclusion is that no one exports the transparency in the same way.

According to the 1.4.1 release notes, we have those two equations :


In A_ONE opaque mode:
result.r = fb.r * (1.0f - transparent.a * transparency) + mat.r *
(transparent.a * transparency)
result.g = fb.g * (1.0f - transparent.a * transparency) + mat.g *
(transparent.a * transparency)
result.b = fb.b * (1.0f - transparent.a * transparency) + mat.b *
(transparent.a * transparency)
result.a = fb.a * (1.0f - transparent.a * transparency) + mat.a *
(transparent.a * transparency)

In RGB_ZERO opaque mode:
result.r = fb.r * (transparent.r * transparency) + mat.r *
(1.0f -transparent.r * transparency)
result.g = fb.g * (transparent.g * transparency) + mat.g *
(1.0f -transparent.g * transparency)
result.b = fb.b * (transparent.b * transparency) + mat.b *
(1.0f -transparent.b * transparency)
result.a = fb.a * (luminance(transparent.rgb) * transparency) + mat.a *
(1.0f - luminance(transparent.rgb) * transparency)

From that two equation, I conclude that :
[ul]

  • In A_ONE, <transparency> == 1 means fully opaque

  • In RGB_ZERO, <transparency> == 0 means fully opaque
    [/ul]

But earlier in the release notes, it is specified that :

Your application can get these results by assuming the following if <transparent> or <transparency> is
not specified:
transparent = <color> 0.0 0.0 0.0 1.0 </color>
transparency = <float> 1.0 <float>

It is not clear to me : it means that if <transparency> is not specified, and transparent is in RGB_ZERO mode, the material will always be fully transparent… There must be a mistake in the release notes, isn’t it ?

Can some infirm or confirm what i’m saying, so that all COLLADA developpers can go further, and follow a strict rule for handling <transparent> and <transparency> tags ?

Regards,
Thomas

The release notes say that transparency is not part of the calculation if it is not specified:

If <transparent> exists but <transparency> does not then transparency is assumed to have no effect on the percentage of opacity or transparency defined in <transparent>.

If you look at the equations you will see that the assumption given in the text is based on the fact that the transparency value of one is the multiplicative identity i.e. it’s not going to have an effect on the result.

Does that help?

Hi Marcus, thank you for the quick answer.

In fact I gave my conclusion according to the equations.

In A_ONE mode, we have :


result.r = fb.r * (1.0f - transparent.a * transparency) + mat.r *
(transparent.a * transparency)

Let’s set transparency to 0 :


result.r = fb.r * (1.0f - transparent.a * 0) + mat.r * (transparent.a * 0)
           = fb.r * (1.0f - 0) + mat.r * (0)
           = fb.r

==> in A_ONE mode, transparency = 0 make the material fully transparent, thus here 1 is the neutral value.

In RGB_ZERO mode, we have :


result.r = fb.r * (transparent.r * transparency) + mat.r *
(1.0f -transparent.r * transparency)

Let’s set transparency to 1, and transparent values to 1 (fully transparent):


result.r = fb.r * (1) + mat.r * (1.0f -1) 
           = fb.r + mat.r * (0) 
           = fb.r

Let’s try with transparency = 0, and transparent values to 1 (fully transparent):


result.r = fb.r * (1 * 0) + mat.r * (1.0f -1 * 0) 
           = fb.r * 0+ mat.r * 1
           = mat.r

==> in RGB_ZERO mode, transparency = 1 means fully transparent… a value of 0 make the material opaque, whatever the transparent color is.

Moreover, according to the equations, in A_ONE mode the transparency value modulate the transparency material (the less transparency value is, the less transparent is the material), whereas in RGB_ONE mode the transparency modulates the opacity of the material (the less transparency value is, the mode opaque is the material). As in both mode the transparency has not the same even, it cannot have the same default value for both modes.

Maybe I’m totally wrong, but in that case I don’t see my mistake.

I see what you’re saying and I agree that the relnotes are not crystal clear on this topic. First please note that there are no default values for these elements. The relnotes talk about assumptions, not defaults, in order to explain the difference based on the opaque attribute values. The relnotes say:

Your application can get these results by assuming the following if <transparent> or <transparency> is not specified:

transparent = <color> 0.0 0.0 0.0 1.0 </color>
transparency = <float> 1.0 <float>

Perhaps the example given is not as clear as the language preceeding it asserts.

Can you submit a bug in Bugzilla for this issue to be addressed?

Thanks

I’ve posted to issue here :
http://khronos.org/bugzilla/show_bug.cgi?id=39

Regards,
Thomas

I’ve read the new release-notes, 1.4.1rev-B, and they are indeed much clearer. Thank you for this. I fail to understand though, why the choice has been made to change the meaning of transparency depending on the value of the optional OPAQUE-attribute. Shouldn’t transparency always mean 1=transparent, 0=opaque? A “high” value of transparency should equal transparent… highly transparent.

This may be nitpicking but I feel it’s currently a source for confusion.