Morphography tutorials
OBJ Fidelity Tests
• Index • Galleries • About • Downloads • Tutorials • Links • Contact
Introduction

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:

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:

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 the now-defunct WooYah. Of related interest to students of OBJ mangling might be Spanki's Kamikazi Kube Project, in which a battery of tests are carried out on a bunch of unsuspecting mesh files. These are mainly aimed at highlighting formatting differences in the OBJ files that are exported by a variety of modellers.

The test meshes

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:

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 procedure
Results

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.

  Vertices Vertex precision Texture coordinates Texture precision Normals Facets Groups Materials UV mapping Adds MTL? Morph Target? Notes
Original multi-group 16 8 16 8 0 9 3 3 - - -  
Original single group 16 8 16 8 0 9 1 1 - - -  
Amapi 7 Pro ver 7.16 P1 28 7 36 6 36 9 5 3* preserved yes 1 group Note 1
Anim8or 0.95 16 5 16 5 25 9 1 0 preserved no yes Note 2
Anim8or 0.98 16 5 16 5 25 9 1 3 preserved yes yes Note 18
Blender 2.6.7 24 6 24 6 0 9 0 3 preserved yes no Note 16
Blender 2.6.7 (1 group) 16 6 16 6 0 9 0 1 preserved yes no Note 17
Carrara 5 Pro 36 6 36 6 36 18 tris 9 3 preserved yes no Note 3
Carrara 6 Pro 16 6 16 6 16 9 4 3 preserved yes yes Note 7; Note 12
Cinema 4D via Riptide 1.7 16 8 16 8 0 9 3 3 preserved yes yes  
Compose 1.1 24 8 24 8 0 9 3 3 preserved no 1 group  
Hexagon 2.5.0.3 24 7 52 6 0 9 3 3* preserved yes 1 group Note 1; Note 4
Lightwave 8.5 16 7 36 6 0 9 3 3 preserved no yes Note 5
LithUnWrap 1.3 16 6 36 6 0 9 3 0 preserved no yes Note 15
Metasequoia 2.49 16 6 16 5 1 9 1 3 preserved yes yes  
Modo 301 16 7 16 6 0 9 4 3 preserved yes yes Note 6; Note 7
Pegasus 1.01 16 8 16 8 0 9 4 3 preserved no yes Note 7; Note 8
Poser 6 SR3 16 7 16 6 16 9 3 3 preserved yes yes Note 9
PoseRay 3.12.2.456 16 8 16 8 0 18 tris 3 3 preserved yes yes Note 3; Note 15
Roadkill 1.1 16 6 16 6 9 9 1 0 preserved no yes Note 2
Silo 2.2 36 6 36 6 36 9 3 1 preserved yes no  
Silo 2.2 (1 group) 16 6 16 6 16 9 1 1 preserved yes yes Note 17
STOMP 0.3.1b 16 8 16 8 0 9 3 3 preserved no yes Note 10
trueSpace 4.3 24 3   3   9 3 0 preserved     Note 13; Note 14
UVMapper Pro 3.5b 16 8 16 8 0 9 3 3 preserved no yes Note 11
Wings 0.98.36 36 8 36 8 36 9 9 3 preserved yes 1 group  
Notes
  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
  16. Groups are converted to 'o' lines and are not seen by most applications
  17. Materials are renamed
  18. Loses groups, materials preserved if imported file has a .mtl
Comments

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

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)

• Index • Galleries • About • Downloads • Tutorials • Links • Contact