normal map in material

Does collada support normal maps from 3dsmax?

I tried to export a mesh that has a normal map placed in the bumpmap slot of 3dsmax, and it doesn’t export it…

I’ve had no problems exporting normal maps. You should get <bump> elments under <library_effects>.

yoshi

The Max export of <bump> elements is done within the MAX3D profile for COLLADA 1.4. You can read more about that by clicking the link.

It would seem this way for the Maya exporter as well - any bump map is handled in the Maya extra section for the effect. I can see why this approach would be taken for some implementation details that may not be common - I could argue that bump mapping is fairly basic, but that’s not all that important a point.

The slightly larger issue is that, because these “extra” sections aren’t part of the base standard, they appear to not be part of the DOM generated code, and therefore require hand generated code to process. Granted, in this case, my cColladaMeshReader::GetMayaBumpTextureElement() function is only about 50 lines of code (and could surely be less if it followed a stricter interpretation of the section), but that’s definitely less convenient than phong->getDiffuse() (or the analog for whatever material variant I’m reading).

Has there been any thought towards building the DOM off of a slightly extended schema? Or, am I misunderstanding the situation?

The DOM has mechanisms for extensibility. And it would be almost as easy to use, except all the data is stored as string data so you would have to convert it yourself.
A domAny object is created for elements inside of the technique=“MAYA” section that aren’t global scoped COLLADA elements (the global COLLADA elements will have the appropriate strongly typed class). They can be accessed by iterating through the contents array. You can find the element you are looking for, in this case “bump”, by calling getElementName() on each of the domAny objects. From there you can get its children or its value or any attributes, I don’t really know how MAYA profile defines the bump element but if it is in the .dae document then it will be accessible somewhere in domAny.

The whole process of getting what you need should be approximately 20 lines of code. It shouldn’t be difficult at all.

-Andy

I agree that using the domAny interface isn’t difficult - in this case (for Maya) it’s just a matter of following technique->extra->technique profile=“MAYA”->bump.

The 0.90 Maya exporter then outputs somethat that’s a domCommon_color_or_texture_type (with some additional internal extra nodes). It’s not difficult to interpret the contents of one of those by iterating elements and attributes, it’s just not quite as convenient as having it accessable as the strongly typed class.

I looked through the docs, but didn’t see anything along these lines (which, of course, doesn’t mean it wasn’t there): Is there a way to “cast” a given node to a dom strongly typed class? As in, here, the contents of this node really maps to domCommon_color_or_texture_type - if I’m right, please return me a reference to the object, if I’m wrong, feel free to puke in whatever fashion you’d prefer?

No there isn’t any way to do that. But it is an interesting idea and something I will look into for the future.

-Andy

The desired approach is to define the schema for the Maya extensions and include that schema in the instance document so that the missing meta data is available to make the safe type cast. For example:


<technique profile="MAYA" xmlns="ColladaMayaSchemaExtensions">
  <bump>height_map</bump>
</technique>

Tools that support the xmlns attribute on the <technique> element would then have all the information for the extensions available to them at run-time.

[quote=“marcus”]

The desired approach is to define the schema for the Maya extensions and include that schema in the instance document so that the missing meta data is available to make the safe type cast. For example:
(snip)

Tools that support the xmlns attribute on the <technique> element would then have all the information for the extensions available to them at run-time.[/quote]

Ok, I think I understand what you’re saying - explicitly citing the schema extensions in the instance document would allow whatever code was processing the document to understand the extensions.

That seems to make sense, but I’m not sure it’ll help me in the short run. :slight_smile:

Specifically, the Collada DOM code is statically generated by a tool I don’t have access to, and that code is what I’m currently using. My (admittedly somewhat shallow) understanding of the generated code is that it provides meta-data descriptions that tell the traversal code how to bind the data in the XML to parts of the strongly typed C++ structures - any schema extensions wouldn’t be useable for consideration at run-time.

It would appear that I could generate code for the extensions I’m interested in by hand (that is, code that’s similar to the machine generated code, but to provide meta-data descriptions of the extensions), but that wouldn’t seem to put me very far ahead of just writing code (like I did) to use xsAny to hand-walk the sub-tree of the XML that I need to (given that it’s not very complicated).

My XML/DOM fu is definitely yellow-belt level, so any corrections or additional insight is most welcome. :slight_smile:

Your XML/DOM fu is stronger than you may think.

I agree with you completely that it would be more difficult to hand write the COLLADA DOM classes and meta descriptions than it is to just use the domAny interfaces.

But for people who might be using C# or Java which have their own code generation tools, having a maya extensions schema could be very helpful.

-Andy