I'm in the process of fixing an animation of a hair as it swings back and forth into the back of the sim.

Problem is when I extract the TF and AF GDMC and try to import it into MS3D using unimesh, it gives me an err saying "Too many P1 sections for this implimentation".

But. . . .

The CF and PF import fine and they have the exact same amount of groups as the TF and AF.
21 groups each.

Also the TF has the exact same amount of faces and verts as the CF GDMC.
only thing I notice which is different is the name of the groups.
The TF alpha groups are called hairaplha5 and hairalpha3
The CF alpha groups are called bangs_l3 and bangs_l1

But I don't see how the name could cause an issue with the importation into SimPE.

Anyone have the answer to this mystery?

Update:-

Nevermind, figured out how to do it.

I followed bluRR's way of extracting the GDMC by importing the GDMC in two halves.
I couldn't figure it out the first time round because I didn't realize once you delete half the groups you must press commit, then extract the GDMC.

But still it leaves the mystery which I'm guessing lies with the unimesh plugins.

I think the amount of groups is either unlimited or not as limited for CF and PF as TF and AF.

Which is the reason why the GDMC has to be imported in halves for TF and AF meshes with alot of groups.

Each group has multiple "P1" parts (see the GMDC spec on the wiki for what that is). For each group there is at minimum three (vertices, normals, UVs), and for hair and body meshes more (bone assignment, skin weights, possibly several morph vertices, morph normals and a morph map) and perhaps a tangent normals.

So the range is from 3 to perhaps 15. I suspect the likely difference between your TF/AF and CF/PF versions is related to some having tangent normals (bumpmapping normals) and some don't.

But 21 groups on a hair mesh is, frankly, unnecessary and represents either laziness, ignorance or inattention to game performance on the part of the hair mesh creator. And whoever did these may not have intended that, but that is what happened. Each extra group, even while named the same, makes the mesh package larger, takes longer to load, requires more RAM, takes extra time to render and is just so unnecessary. Like higher poly counts, it just siphons off CPU/GPU horsepower and memory.

MAXIS meshes never have more than a handful of groups, generally one mesh group for each unique texture. That is the one real reason to have multiple groups, in order to have them be able to be textured in a different fashion. Having six copies of a hair layer with the same opacity and texture map is wasteful. Regroup them into one.

There is little excuse for releasing a hair mesh with more than one group per alpha layer, plus base. Maybe three or four. Failing to regroup all of the alpha3 or alpha5 groups together is the problem.

I know some creators keep the groups seperate as they develop them because it is more convenient to select each part that way. Releasing the mesh with so many groups, though, is not a very efficient way to do things.

If you want to make different parts of a group remain easily selectable, set each parts to a different smoothing group instead before regrouping them. There are 32 smoothing groups, and you could potentially multiply them by the number of groups you need by hiding groups before selecting.

So a hair with 32 base layers, 32 alpha1 layers, 32 alpha3 layers and 32 alpha5 layers (128 potential layers) can be made and managed with 4 groups. The smoothing group information will be retained in the MS3D file, but does not appear in teh exported GMDC.

This is not a new problem, it just keeps spiralling out of control. Twice before I increased the memory buffer size to hold more P1 items, and people just made bigger hair messes.

[/rant]

<* Wes *>

but do you have a idea how Louis made her hairmeshes then, 2 to 3 years ago?
Or wat has changed to unimesh that those hairmeshes with 20 to 30 meshgroups cant be imported/exported anymore.......

bLURR:

The exporter doesn't use the same method. It knows how many groups are there, and how many P1 items need to be generated.

For the importer, the file is laid out in part as a set of entries that look like "type, "count" and then "count" number of "type" items. There is a table with room for only so many entries (maybe 128 or 200 or so), so if "count" is more than that, it quits. I check every value read from a file and test it against limits to try to prevent crashes when a corrupt file (or a wrong file type) is being read.

Whatever the number for the P1 count is, I have raised it twice in the past in response to problems users reported importing custom hair meshes, not Maxis meshes nor custom body meshes or anything else. It's like the nuclear arms race in the 1960s... we need more missles to support our bombs, and more bombs to arm all the missles. The madness has to stop somewhere.

I have decided to dig my feet at this time and not raise the value for P1 because it only serves a bad purpose. There is nothing to be gained for the users by having 21 groups in a single hair mesh, and plenty of adverse performance issues. If I raise the count, someone will just make a hair mesh with even more groups.

Once you have the stubborn ones imported, you only need regroup some of the like named groups to be able to export a version that can be reimported. And by doing so, you are improving the mesh performance just as surely as you are by reducing the polygon count.

<* Wes *>

Wes H:

Just what I was thinking.
Why have so many mesh groups left instead of regrouping?
I can see how many of them can be regrouped into one alpha.

When I was dabbling in a bit of recoloring with one of Louis hairs I could see how a few texture files maybe needed if you wanted to make variable hair colours but still there are alot which don't need to be there.

But in saying that, louis released all his/her hairs is one colour on one identical texture map for each alpha unless it was done this way for recolouring.

The reason they are seperate is due the opacity, you get bleeding props when regrouping them.
Regrouping wont reduce the polygon count either.

But if peeps want more groups they just import/export with the smd import.

I didn't say, or mean, to combine groups with different opacity values together. Just put all the Opacity 3 parts into one group, all the Opacity 5 into another. No one needs a base mesh and 20 different layers to make a good hair mesh, any more than they would need 21 groups for a hula skirt.

You can export as many groups as you want with UniMesh, but I don't think I want to be any further an enabler for a practice that runs counter to good, sensible design for a low-poly, real-time-rendering game that will run on the average machines of the past few years (the older of which are equivalent to the bargain basement computer of today).

<* Wes *>

i understand.
And how about importing more morphs?
Can you increase that number?
The hottub for instance will give a error for to many morphs.
So when cloning and editing the tub you will lose the water animation...

For MilkShape, you are stuck. It can only manage four per group. The game can manage four per-vertex (per group), as long as the designers are careful to make sure that no more than four overlap at any one vertex. But in MilkShape I don't have a place to store the extra data.

The Cowplant and all the face templates are some more that cannot be edited, unless you intend to rework the morphs manually.

<* Wes *>

thank you!