Quote - Wings3D likes to load the groups as separate objects, as well, but one can prevent that by explicitly defining an object at the start of the .obj file, that is, by just adding a line that says something like 'o body'. I don't know if the same trick would work in Hexagon, but it might be worth a try.

Just to expand on this a bit... "o xxxxx" is an "object" record in a .obj file and is separate from a "g xxxxxx" - "group" record.

Group records tell the program groups/selections/sets of related polygons, whereas Object records are typically used to deliniate both sets of points/vertices as well as polygons.

Based on the fact that both exist, it makes sense to me that any "object" within a .obj file can have multiple "groups" defined as part of that object (and in fact, they are laid out that way, hierarchically within the file).  Unfortunately, many 3D apps make no distinction between Objects and Groups - they will just split either/both into multiple separate meshes.

With the above in mind, it sounds like what odf is saying is that if there IS an Object record in the .obj file, Wings (at least) starts making that distinction and leaves all the Groups in the same Object.  I have no idea if Hexagon does this though.

As for Cinema 4D, the default (built-in) .obj file - in addition to re-ordering the vertices - Import will split any Groups or Objects into separate meshes.  The default Export loses all Group information entirely.  Because of these (and many other) issues, I wrote my Riptide (and later Riptide Pro) plugins for Cinema 4D. 

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.