D|S .mtl file oddness / bugs

typhoon_aedac96c99

Hey guys,

I'm hoping one of the D|S developer/tech guys can answer a few questions related to the .mtl files being output when exporting .obj files.

First off, there seems to be several 'issues' with the format/specification interpretation - I'll refrain from flat-out calling them bugs (in most cases), but they certainly seem "at odds" with the specification (I've seen a few around the web, but will reference this one as seemingly fairly 'official': http://www.fileformat.info/format/material/ ).

With the above in mind, it's also understood that in many cases, a relatively ancient (in computer terms) file format is being (re)interpreted for modern-day use.

1. (partial) paths in texture file names.

I'm not sure if it's hard-coded or just circumstantial, but I typically see "/Maps/" tacked on to the front of the file name...

map_Kd /Maps/kd_filename.jpg

...the linked spec may not specifically state that there should be no path, but none of the examples have any path and having (modern) path info (which could include spaces) would certainly complicate things and therefore any/all path info should be left out. The individual 3D application will have it's own mechanism for specifying texture search paths (current folder, listed preferences folders, etc).

2. map_Bump

While I've seen other apps (mistakenly) use this keyword, it does not exist in the spec. The proper keyword is simply "bump".

3. map_D

Note that the proper 'case' of this keyword is: map_d ...this might seem like a nit-pick, but just as you shouldn't use "NewMaterial" or "NEWMATERIAL" or "MAP_KD", you should use the proper case for "map_d".

4. Dissolve/Transparency value - "d 1"

This is just a suggestion, but the .mtl file format is a 'sparse' format. In other words, records/values can be missing if not needed and a Dissolve value of 1.0 (no transparency) is a fairly well accepted/understood 'default' value... if the material has no transparency and/or no map_d value, I'd recommend leaving it out.

5. Ni 0

From the linked spec:

"[Ni] Specifies the optical density for the surface. This is also known as index of refraction.

"optical_density" is the value for the optical density. The values can range from 0.001 to 10. A value of 1.0 means that light does not bend as it passes through an object. Increasing the optical_density increases the amount of bending. Glass has an index of refraction of about 1.5. Values of less than 1.0 produce bizarre results and are not recommended. "

...D|S is writing "Ni 0" in many/all (?) cases, which is a) not needed at all if there is no Dissolve (transparency) value and b) is probably way too low of a value when/if it should be used.

6. Ka (ambient) values

This is one value where there seems to be some general confusion/interpretation differences... Poser (and I believe D|S) basically/effectively use Ambient for a material to produce it's own light/color. My plugin for Cinema 4D uses a similar interpretation and maps this to the "Luminance" value, however other applications use a different interpretation and often write 1.0 values for this. I like/agree with the idea that D|S is (now) writing 0.0 values, but I'd recommend leaving it (the Ka record) out entirely unless you specifically need the material to produce it's own light/color.

7. Km

Wassat? :). This is obviously an invented record/keyword (I've never seen it listed in any spec or files from any other app before)... my plugin ignores it, but I'm just curious what it's used for.

NOTE: All of the above are meant as constructive suggestions, based solely on my own personal opinions and experience with .obj/.mtl file coding over the past dozen or so years - no offense intended.

Cheers,

Keith

ReDave

1. That's because you select "Collect Maps". Unsurprisingly this option collects all textures and places them all in a subfolder named "Maps". If I select "No Maps", you'll get the absolute path, saving me from having to browse to the texture folder(s).
2. I don't think that file you linked is quite complete. But I don't know if the keyword is correct or not.
3. Good point
4. Hmm, DS seems to skip doing some stuff when values are at the default, which may lead to unexpected behavior in some cases. Better to leave values in general, IMHO.
5. Good point. However it saves whichever value you have in the surfaces tab, simplest fix is to actually have a 1 in your IOR channel. It's surprising how many characters have 0. I'd file a feature request for this.
7. Appears to be (Maxbump-minBump)*BumpStrength. It would be completely obnoxious on DAZ's part to invent an mtl keyword. The Alias brand still exists, bought by Autodesk, those specs are from 1995 and as already said they may not even be complete. In fact I'm reasonably confident DAZ got some more recent/complete specs.

typhoon_aedac96c99

ReDave said:

1. That's because you select "Collect Maps". Unsurprisingly this option collects all textures and places them all in a subfolder named "Maps". If I select "No Maps", you'll get the absolute path, saving me from having to browse to the texture folder(s).

Yikes - absolute paths would be even worse. ie. I'm pretty sure that your machine doesn't contain a path that might be on my machine:

map_Kd k:\keith's awesome textures\filename.jpg

ReDave said:

4. Hmm, DS seems to skip doing some stuff when values are at the default, which may lead to unexpected behavior in some cases. Better to leave values in general, IMHO.

The idea that D|S may be broke in some other way (if simple default values are missing) is not a good reason to include them :). For some of these values, the existence (or not) can help tell the reading app whether that feature is needed. In other words, if my plugin doesn't see a value for transparency ("Dissolve" in .mtl file terms), then it doesn't bother enabling the Transparency Channel of that material. Having a value for it - when it's not needed - can cause confusion ("why is the Transparency Channel enabled, but set to no transparency?").

7. Appears to be (Maxbump-minBump)*BumpStrength. It would be completely obnoxious on DAZ's part to invent an mtl keyword. The Alias brand still exists, bought by Autodesk, those specs are from 1995 and as already said they may not even be complete. In fact I'm reasonably confident DAZ got some more recent/complete specs.

I'm personally not too opposed to extending the format (for example, the .mtl format never had any provision for a "Normal map"), but I would probably recommend doing what Steve Cox did with the .obj format when he added "Region" records - he made them a modified "comment" record (ie. "# r region_name" which most apps would just see as a comment and ignore).

Just to clarify, I don't personally use D|S often/recently... my perspective is from writing .obj file enabled programs and various plugins for Cinema 4D, including my "Riptide Pro" enhanced wavefront .obj Import/Export plugin - and so I have to "deal with" these non-standard .mtl file issues in code and/or from a customer-support position (I have more "special-case" code in my .mtl file reading routines for D|S produced files than any other .mtl file generating application).

X3D

I often wondered why when exporting a figure in .obj format from DAZ|Studio then importing into C4D the material transparency map options always need to be setup manually.. also the only way to actually get the textures to transfer correctly with UV maps intact is to use Figure Names unlike Daz 3 where you could use Surface Names to export, resulting in a full list of the character mesh instead of one collective file for the figure mesh.

@ Spanki A friend of mine uses your Riptide importer which does enable the mesh to come in split... which is handy :)