Import - Mesh Splitting tab
The Mesh Splitting options tab can be found at the bottom of the .Obj Import dialog...
...when importing a .obj file into Cinema 4D, the file can be loaded into one or more C4D Polygonal Mesh Objects. The individual options are described below. Note that if any splitting takes place, a Null Object is added to the scene and the new Mesh Objects will be placed under the Null Object, to help keep things tidy.
With this option selected, the entire .obj file contents is loaded into a single polygonal Mesh Object, named after the .obj filename.
With this option selected, the .obj file is split into multiple Mesh Objects, on a per-object-record basis...
The .obj file format allows for 'object' records (ie. "o objectname"). These may or may not be present in the file, but Riptide Pro can split the file up into multiple meshes, based on them if they do exist.
With this option selected, the .obj file is split into multiple Mesh Objects, on a per-group-record basis...
The .obj file format allows for 'group' records (ie. "g groupname"). These may or may not be present in the file, but Riptide Pro can split the file up into multiple meshes, based on them if they do exist*. Also, unlike the free Riptide, Riptide Pro will preserve vertex ordering even with this option enabled, so it can be used to help create Poser morph files.
With the free Riptide, vertices
are re-ordered if you choose any of the "Split By xxx"
import options. This meant that if you wanted to create Poser
morphs for some body part, you either had to import the entire
figure, create your morph on that, then use some method of splitting
the mesh by group inside of Poser or start out by exporting only
some group from Poser, importing and morphing just that part
and then re-exporting.
The down-side to exporting individual groups from within Poser
is that you end up with what I have termed "rigging-induced
error" - the vertices are not 'exactly' where they are supposed
to be in an undeformed mesh, so this error is carried over into
the morph you create.
What this new feature allows you to do is import the entire base
mesh (from the Geometries folder, for example) and use the "Split
By Group" import option... this will create individual Polygon
Mesh objects in C4D (one for each group) and each one will have
it's internal vertex ordering preserved (and will not have any
rigging-induced error). You could then morph them and export
them separately as new morph files.
NOTE: ZBrush not only relies on vertex 'order', it also relies on the individual polygon->vertex indices remaining the same. If you're splitting a mesh file up into multiple mesh objects - and the mesh was not already split at the seams to start with - then new vertices will be generated at the seams and so those polygon->vertex indices WILL change (there's nothing that can be done about that).
So, these are two separate issues:
1. vertex "order"
2. vertex "index value"
...in Poser's case, relative to morph creation, it doesn't care if the actual index values change (in fact, a Poser morph .obj file doesn't need any polygons/faces in it at all - just the morphed vertices).
In ZBrush's case, (transfering a .obj file between it and C4D with the intent of re-loading your 'brush' in Zbrush), it looks at the polygon vertex index values, which must remain the same. If the vertex count changes, then the indices will change. If the mesh within the .obj file was already split into separate meshes (not welded at the seams), then you should still be good to go (as long as you don't re-arrange the order of the mesh objects within the Object Manager before exporting).
* Note that in the case of multi-grouped faces, a single mesh is created for those, with a compound name. In other words, if there was a multiple group record: "g head nose nostril" then faces that follow that in the file (up until the next group record) would belong to each of those groups (head, nose and nostril groups). Instead of duplicating the polygons in each mesh (remember, we're creating a separate mesh, for each group), a single "head nose nostril" mesh is created for those polygons and they only exist in that mesh (although the 3 groups would still be created on that mesh).
With this option selected, the .obj file is split into multiple Mesh Objects, on a per-region-record basis...
The .obj file format allows for 'region' records (...as a puedo-comment record - ie. "#r regionname"). These may or may not be present in the file, but Riptide Pro can split the file up into multiple meshes, based on them if they do exist.
With this option selected, the .obj file is split into multiple Mesh Objects, on a per-material-record basis...
The .obj file format allows for 'material' records (ie. "usemtl materialname"). These may or may not be present in the file, but Riptide Pro can split the file up into multiple meshes, based on them if they do exist.
Some .obj files contain "extra" / unused vertices that are not connected to any polygon - in some cases, these vertices are used for 'line' objects (Splines), but in some cases, they are just extra vertices where the polygons got deleted, but the mesh was not "Optimized" before exporting. In previous versions of Riptide Pro, these unused vertices were still loaded and became part of the resulting mesh object*.
[*NOTE: when any of the "Split by xxx" options are used, the resulting mesh objects ONLY had (and still do have) the vertices used by the polygons of the mesh(s), but if the "Don't Split" option was used, then the resulting (single) mesh contained any unused vertices as well.]
As of v2.6, these unused vertices are no longer retained in the resulting mesh - but there are now options to generate a separate, point-only mesh object made up of these vertices.