@ unrealblue, last time I had a character morph come with an OBJ was probably Posette. Dawn 1 didn't have INJection channels and I'm betting Dawn 2 doesn't either, DS needs channels in the Poser figure otherwise you can't use INJ/REM PZ2's, and PMDs only load when called from a CR2, so if a DS user doesn't have a copy of at least P9 then they have a headache getting an OBJ of the morph to use on the DS version of Dawn 2.

It can still be done, but you need to know your way around the inside of a CR2, as you will need to create a "loader" CR2, one that loads the figure, any PMD's as well as add in every valueParm and targetGeom channel the morph has. All that just to get the morph into the Poser version in DS, just so you can export an OBJ to use on the DS version.

Now I've lost count how many "loaders" I've made since my Poser 4 days, so I have the knowledge and skills to do that, there aren't many that can say the same, especially not on the DS side of the fence.

Oh and btw I also explained how to do this over on the old Hivewire site (before they got hacked) for Dawn 1.

I'm not talking about a character morph *supplied* as an OBJ.  I'm talking about *making* one.   You don't need a morphed OBJ.

What's needed is:

- the original unimesh OBJ file.  This is referred to in the CR2.  It's in the geometries folder.  With few exceptions (none of the major figures) it is "unimesh".  That is, a single mesh with face groups named for the eventual actors.  But the mesh is not split; there are no co-located verts.

- a Poser (non welded) but zero'd OBJ export of the same figure.  This produces a Poser vert ordered OBJ, with the same face groups, *but* co-located verts (duplicated verts that are shared verts when Poser splits the mesh, effectively making a new one).

If you create a dict of verts (keyed on a tuple of xyz ) for each mesh, with an array of indexes at the vert, the keys of one mesh will == the keys of the other.  The only difference is, the Poser split mesh will have different indexes for each key, and some keys will have multiple indexes (the split verts: two or more  verts at the same xyz).  This is why I save the indexes as a list keyed on the vert XYZ.  To make it faster, the XYZ are converted to INTs (multiplied by 10^6, which in controlled with a precision slider).  a dict keyed on a tuple of INTs is very faster lookup.

This creates a map between indexes.  You can use the second (Poser vert dict) index, get the key, use that key for the first mesh (original vert dict) and grab it's index.  Set that vert in the original OBJ to the position of the vert in the second OBJ.  Do this for all the verts.  The result, the first OBJ (original) is now shaped like the second (Poser).  The mapping *and* setting of verts for meshes of "figure vert count" takes under a second.

Using this script, I can take a figure morphed in Poser, export that as a Poser OBJ, "convert" the Poser OBJ back to an original OBJ format (but shaped like the Poser morph).  Then use that in DS or Poser.

In it's simplest form, you apply a specific morph in Poser, take it through Blender into an OBJ you can use to load that same morph in DS.  No file editing.  Entire process takes under a minute (if you've setup the map and know the process).

The entire script is not very long.  It just iterates through the verts.  For a figure like Dawn 2 this is well under 50k verts.  Blender's python can do than in a small fraction of a second.

Anyway, I'm about to setup a pair of scripts to batch this.  Batch export the morphs from a figure, then Blender batch import them as shape keys, then Blender, batch export a dir of morph OBJs.  Which I think can be batch imported in DS.

More to come :)

I wrote this to make it easy to Blender-sculpt morphs for Poser.  But the same technique produces OBJs suitable for using to load a morph in DS.  And it also allows exporting a figure's morphs from Poser to DS without having to edit files or using anything other than FREE Blender and Add-on script.  That seems like something to *me* :D

Cheers!