Maya exporter - various comments

Before I start, let me say that I fully approve the Collada idea, and I hope it actually survive the initial hype to become a useful standard. Additionally, I found the Maya collada import/export implementation a good starting point for my personal needs, so I’d like to thank Alias for sharing the source code with us.

That said, as I implement import support for Collada in our engine, I bumped into a number of issues with the latest version (September 4th) of the Maya exporter. Note that some of these issues probably apply the collada spec itself.

In particular, consider a scene with a sphere (sphere1) which is assigned to a default material (lambert1) which has two color textures (file1 and file2) assigned respectively to its color and incandescence attributes.

I saw a number of problems with this simple scenario:

  1. Abusive name-mangling: the resulting textures get names like “#file1-DIFFUSE” or “#file2-GLOW”: it appears that the actual attribute where the texture is assigned has been appended to the original file texture node name. As far as I can tell this is unnecessarily ugly, considering that additional XML attributes could have been added to indicate the material channel in use. This also causes the next problem:
  2. No longer invariant: try to export the above scenario, then import it back. You’ll see that the resulting file texture nodes will be called “file1_DIFFUSE”. Export it back: the resulting texture will have a name like “file1_DIFFUSE-DIFFUSE”.
  3. The Lambert material node in Collada has the following type of param:
    “<param name=“DIFFUSE” type=“ColorRGB” flow=“IN”>0.000000 0.000000 0.000000</param>”. There’s no obvious relationship with the assigned texture, instead, a (wrong) black color has been assigned.

By now I hope you realize that this is a ugly hack. This could easily be avoided by keeping the texture name from the Maya texture placement node (that’s what the collada texture element means anyway), and avoiding the name mangling ugliness. Instead, indicate the channel assignment through the material param, eg:
“<param name=“DIFFUSE” type=“ColorRGB” flow=“IN”>#place2dTexture1</param>”, or add a new optional attribute to each Collada element (e.g. "dccName=“file1”). If you absolutely need to ensure unicity of collada textures by name mangling, at least choose some special separating character that is not typically in use by DCC apps (e.g. “#file1#name_mangled”) instead of ‘-’.

Finally, where does the name GLOW come from? I checked in the 1.0 collada spec and saw no mention of it. (BTW is there a more up-to-date, alpha spec circulating?) Why is the Maya exporter using GLOW instead of the regular Maya term (Incandescence)? Glow is a completely different property of a material in the Maya software renderers, so please avoid switching names for no good reasons. IMHO you should stick to the actual name used in the DCC package unless the Collada spec clearly dictates otherwise… doing otherwise will just cause unnecessary confusion.

One last thing: I’d be interested in beta-testing the next exporter release if this is a possibility.

Thanks for the input.
Yes, we are planning to separate name and id attributes. Ids will have to be unique in the XML file, but names could be the originals from the modeler (as long as they don’t have characters forbidden in XML).
As for the GLOW, I’m not sure where it came from. You should ask the Maya people.
We do have an EMISSION (color) and from your example, it sounds like that’s what they meant.
Glow is a different effect, also called “bloom” in photography. It’s a “spill-over” of light into neighbouring pixels.

What about the material texture assignment? The way it’s done right now (name-mangling the texture to indicate channel usage) is hard to parse and extend (and plain ugly). I’ve patched my local copy of the Maya exporter to generate params like this:

<param name=“AMBIENT” type=“ColorRGB” flow=“IN”>#file1_texture</param>

I also thought of defining a new type (e.g. “TextureRGB”), but my parsing code doesn’t need it. Any opinions?

What about the material texture assignment? The way it’s done right now (name-mangling the texture to indicate channel usage) is hard to parse and extend (and plain ugly). I’ve patched my local copy of the Maya exporter to generate params like this:

<param name=“AMBIENT” type=“Texture” flow=“IN”>#file1_texture</param>

Constant-colored channels can remain identical to what they are today:

<param name=“AMBIENT” type=“RGB” flow=“IN”>0.00000 0.00000 0.00000</param>

Ok, I hadn’t realized there was texture param with name=“DIFFUSE”. Still, that means that a texture shared across multiple material channels needs to be duplicated for every target material channel.

This is an old subject that we’ve kind of “beaten to death” in the secure forum, but you probably don’t have access to that.
:slight_smile:
In Collada, both the <shader> and the <texture> engines are programmable.
A <texture> element can manipulate multiple shader parameters, combine / blend multiple source images, or generate the output completely procedurally.

This separation lets you de-couple texturing from lighting to improve modularity.
For example: a procedural marble <texture> that modulates the Diffuse, Specular and Roughness <shader> parameters could be reused on both a Phong and a Ward’s anisotropic shader.

Basically, what you are describing is a degenerate case of the above: a simple one-to-one assignment. This is becoming less and less useful with the advancement of programmable shaders, where texturing can be a call to a complex subrutine (as opposed to just a tex2D() Cg call).

So, yes, you need a separate <texture> element if you want each image to modulate only one shader parameter, but you can reuse the <image> elements if needed.

This sounds interesting, but a few paragraphs is simply too short. I’d really like to read the private forums discussion so I can get a better understanding. Anyway, I’m curious on how you plan to solve more complex scenarios. In particular, I’d like to see how Collada would represent hierarchies of programmable textures (e.g. Material “skin” relies on textures “dermis” and “epidermis”, both of which rely on texture “perlin_noise” computed at different octaves).

In any case, it sounds like all of the important details are only accessible through the private forum. What is the procedure to get access to it?

You can learn more about being a partner or contributing member by reading the COLLADA welcome page HERE. We do welcome active contributions and so I look forward to your email.