If you make or modify Poser content, whether for yourself or others, you probably spend some time shifting OBJ format files back and forth between modellers and other utilities; probably hoping as you do so that the mesh isn't getting too mangled in the process.

I decided to see what existing applications were doing to a 3D model file that passed through their "hands". There are a lot of rules of thumb, almost superstitions, involved in most people's work flows - but I hadn't seen any objective measurement. So I did some.

Since this page delves into the workings of OBJ files, it will of necessity get fairly technical. If you're not comfortable with that level of detail, you may prefer to skip it. I won't be providing a cut-and-dried conclusion, at least not to begin with, since I hope to involve other people in testing applications that I don't own. In any case, it isn't my intention to identify heroes and villains, but to simply make the results available to the community. It wouldn't be fair to castigate a utility for poor performance in these tests, since most of them are not designed specifically with Poser use in mind.

The question that this page hopes to answer is "will application [x] be any good for use with Poser?" Exactly what constitutes "any good" is not a simple thing to pin down. My criterion was that the application should load a Poser mesh, and save it, without materially altering its performance. In particular:

• It should not change the vertex order, add or subtract vertices (which makes a morph target not work)
• It should not reduce the vertex coordinate precision (which makes switched geometry fail to weld)
• It should preserve grouping, material zones and UV mapping

Relaxations can be made on a case-by case basis. For example, a morph target needs no materials or UV mapping, and is usually built from a single group - so an application that failed in these areas may be acceptable for morph making. Similarly, loss of vertex coordinate precision would not be a problem if accurate welding was not required.

Other concerns which are annoyances rather than show-stoppers include:

• Does the application add a material (*.MTL) file where there wasn't one before?
• Does the application add normals to the output (Poser doesn't need them)?
• Does the application triangulate facets?
• Does the application add texture coordinates?

Most of the above make the file larger unnecessarily, and (apart from triangulation) can be fixed without much effort. Passing an OBJ file through STOMP or UVMapper is a good cure for most minor file formatting niggles.

I decided not to investigate areas which fall into the general category of malformed meshes which can be avoided by the modeller, such as the handling of n-gons. I assume that a competent Poser content creator knows how to build their mesh for best performance.

Thanks to all who helped with this, on the forums at Renderosity and WooYah. Of related interest to students of OBJ mangling might be Spanki's Kamikazi Kube Project, in which a whole series of tests are carried out on a series of unsuspecting mesh files. These are mainly aimed at highlighting formatting differences in the OBJ files that are exported by a variety of modellers.

I created a test mesh using UVMapper Pro. It probably isn't the most challenging one that could have been devised, but it will serve as a starting point at least. It has the following properties:

• A square plane having only positive X and Y coordinates
• Dimensions 0.1 OBJ units per side (the same as the Poser prop plane)
• UV mapped
• No normals
• No mtllib
• Vertex and texture coordinates to 8 decimal places
• 16 vertex (XYZ) coordinates
• 16 texture (UV) coordinates
• 9 facets
• 3 groups, each of which overlaps all 3 material zones, and vice versa

Maybe I should have included negative coordinates, but UVMapper built its plane entirely in the positive quadrant, and I stuck with it. The main thing is that it has most of the attributes that a Poser modeller would have to deal with, and hopefully preserve through its import / export process.

As the tests progressed, some utilities balked - especially at the overlapping groups and material zones. Essentially each facet in the plane has a unique combination of group and material, which while undoubtedly challenging, may be a little unfair for some uses (morph making for instance, where it is usual to deal with one group at a time). I therefore made a second version of the test model with only one group and one material. Where that was used, I've mentioned it in the test results.

You can download a copy of the test pieces below. They're free for any use. If you do use them to test an application that isn't in my list, I'd appreciate hearing how you fared. If you aren't sure how to interpret the output of your favourite modeller, then send me the resulting OBJ export and I'll do it for you. Let me know what application you used, what version it was, and what import and export options you chose (if there were any). In general, use the options that you would normally use in your Poser modelling workflow.

Test_OBJ.zip (1.4KB)

My contact details are here, and in the readme file in the download.

• The test mesh was imported into the application. If there were import options, they were chosen for the best results and the options chosen are noted.
• Without making any changes, the mesh was exported to Wavefront OBJ. Again, options were chosen for best results and these options noted.
• The exported mesh was examined using a text editor and UVMapper Professional 3.5b. It was also applied as a morph target to the original mesh in Poser 6 SR3.
• Changes to comment (#) lines are not noted. Most of the applications imposed their own comments, but this would have had no effect except to destroy UVMapper region information.

Except where stated (in the "Morph Target" column), these are the results obtained from the multi-grouped and multi-materialled mesh. If that failed to produce a usable morph target, then the single group mesh was tried.

Results that I've classified as "show-stoppers", after taking everything into account, are highlighted in red.

1. Materials mis-assigned
2. Loses all groups and materials
3. Triangulates facets
4. Import with all options unchecked; Export with only Export UVs checked
5. Attach the UV map in Surface editor to each material before export; UV mapping is lost if you don't
6. If there are multiple layers containing meshes, an exported .obj will have corrupted UVs
7. Adds empty default group
8. Facet order changed
9. Import with all options unchecked; Export with only "Include existing groups in polygon groups" checked
10. Save with all exports checked except material library; Face sorting as loaded
11. Save with "Don’t export material library" checked
12. Use Poser/Wavefront import/export options to avoid triangulation
13. Using LUUV import/export plug-in
14. Vertex count remains at 16 if the Option to preserve groups is off during import
15. Uncheck "export vertex normals" when saving

Some applications added vertices when faced with the multi-group file, making them useless for morph making. With the exception of Carrara 5, all these fell into line when processing a single group.

Some applications added groups of their own making, apparently because they were confused by the overlapping groups and materials. Although Carrara 6, Modo and Pegasus added a default group, it was empty and would not affect the usefulness of the mesh.

Amapi and Hexagon rearranged the material zones, presumably also due to confusion caused by the overlapping groups.

To put the vertex coordinate precision into perspective, 5 decimal places is a resolution of around a thousandth of an inch (0.025mm) at Poser scale, which is good enough for nearly everything. It only becomes a problem when Poser is expected to weld similar vertices. The precision can of course be improved by scaling up before import, and scaling down again on export.

Texture indices in the facet list exported by Lightwave are given in relative format which may upset some applications - this can be fixed by running the file through UVMapper.

I don't normally process multi-group meshes through Poser, so it's interesting to see that it preserves them. It's also vaguely interesting that, although some of the Poser props contain coordinates with up to 10 decimal places, Poser itself only exports 7 of them.

Poser compatibility is evidently becoming more important. Pegasus is designed from the outset as a modeller for Poser, while the latest versions of Carrara and Hexagon have corrected the disastrous morph-making performance of their predecessors. Since both applications are looked after by DAZ, that may not be a surprise. :)

Thanks are due to the following forumites who contributed test results and comments:

- Airflamesred at Renderosity (Metasequoia)
- Cage at Renderosity (LithUnWrap and Modo)
- CarlS at Wooyah (Amapi and Carrara 5)
- Khai at Renderosity (trueSpace)
- markschum at Renderosity (Lightwave)
- Miss Nancy at Renderosity (Carrara 6)
- Spanki at Renderosity (Cinema 4D)