I don't know really remember anyone posting about using separate top/bottom meshing using Poser, and I have never tried that myself.

The .objx importer has a lot of checks built in to try to make sure that what is being imported is compatible with what was exported originally. This is very important, because you are trying to synchronize the contents of two different files.

If you need to make changes to something simple like the group name, the .objx format can be edited in Wordpad or Notepad, as can the .obj file. In the .obj file, the group name is on a line that starts with the letter g. In the .objx file, the groupname is a part of a line that starts with gnfv.

Unless the group count and names are the same, the .objx importer will think that you got confused and will not try to import the file.

You are right.

I don't want to throw cold water on your efforts, but doing things with body meshes is very different than all other objects. Virtually no objects have the same joint layout, but all body meshes share the same layout, and ofr good reason.

For body meshes and hair, the CRES you make the changes to is not the one used in the game. While you link the CRES, SHPE, GMND and GMDC all together in a package, the game takes the data from the GMDC and places it on the skeleton described in the CRES that is in the character file (in the neighborhood). It expects to match the head from the GMDC with the head in the CRES. This is why you can make a stretchskeleton cheat work on a standard clothing item.

To further complicate adding bones, the joint order is very important, in that the bone names are not in the GMDC, but rather the bones are matched in order.

So if you want the mesh to use all the standard things you think of for a Sim, the interchangeable clothing and hair, the facial animations and all of the standard Sims interactions, this is not very easy to do with a skeleton that is not standard, because the standard setup allows one hair to be added in place of another, one dress to work the same as another, because the joints are where everything is adjusted to fit.

Now, taking the basic body mesh skeleton, adding bones and making an object with it is very viable, although you really need to get the rotation on the root_trans out, as it makes everything alse so hard to work with. You should be able to apply body animations to it, such as waving the arms. Some body animations will never look good on the horse, such as walking. If you add the bones and make a custom animation, you could make it walk.

Not easy, but very possible.

<* Wes *>

You can't really relocate bones very effectively, as long as the game is allowed to dress and put a face and hair on the mesh.

But I don't know of any reason you can't assign the whole rear to head, or any other bone, if you want. The bones do not have to be INSIDE the mesh that is assigned to them. Assigning the rear to head will make it follow the front along, but whenever the head is nodded, the rear may rise up. A better choice might be one of the spine bones, as it will follow the body trunk better.

BTW, that is a nice piece of artwork.

It will require some detail work, because the faces have to be seperated also. One thing that may work is to duplicate the hand by selecting all that should be part of your seperately textured hand and use "duplicate selection". Unselect and hide that new group, then delete the hand off the mesh, leaving the vertices that will be at a shared location in place. Do this to both hands, and then regroup.

You should be able to more easily seperate the texture mapping when the hands are still in seperate groups (probably named Duplicate01 and Duplicate03).

You can use the smoothing groups as a sort of submesh selection tool. By this I mean the main group will be in smoothing group 1 by default. When you have the duplicated hands, select one and then assign it to smoothing group 2, and the other to three. Then, even after they are regrouped, you can select just one hand by unselecting everything else and selecting smoothing group 2.

<* Wes *>

The UniMesh exporter should support what you are doing. I cannot say whether there is an issue in the UV mapper.

Whenever you map something like your hand to a "divorced" area of the UV map, you need to make a seam, i.e. a row of duplicated vertices where the hand joins the arm. This is because of the way that Sims2 mesh elements are aligned. All elements (except the faces) are in sets that are aligned with the vertices. So a vertex may have one and only one UV coordinate. Where you want one set of faces to stop HERE on the UV map and the adjacent face to start THERE on the uv map, the shared vertices have to be converted into seperate vertices, colocated.

This is the way the original Maxis meshes are made (with seams). That is the reason I preached "no welding" because welding combines vertices at identical locations, removing the carefully placed seams.

Note that other games, and MilkShape, have a different layout, where the UV and normals associate with the faces. That is more common on OpenGL based graphics, while the vertex-aligned elements is more commonly used on DirectX based games.

From your description of the problem, I think that shared vertices is what is tripping up your effort.

<* Wes *>

You're welcome.
It has been quite an interesting adventure.
<* Wes *>

The UniMesh importer uses the values (.0, .1, etc.) that were used in the original file. The value needs only to be self-consistent with the morph name in the game files, so you will see .0 for fat in a lot of meshes starting with Nightlife, while a lot of .1 for the fat morph in meshes from the older games. But it is not a for sure, nor does it have to be.

In order to get it right, look at the comments in the groups. You do this by selecting a group (such as ~00MORPHMOD.1) in the groups panel and then clicking on the comment button.

A fat morph has the comment:

MorphNames: botmorphs fatbot

while pregnant is:

MorphNames: botmorphs pregbot

The game uses these names to locate the morph with, so it is entirely possible to swap fat and pregnant by swapping these two comments and exporting the mesh. Then in the game the fat state will use the pregnant shape and the pregnant state will use the fat shape. Not exactly useful, but it illustrates how the game works.

In order to match the morphs with the right base group, the comment for the base group (often "body") will contain a line like:

MorphRefNum: 0

The value in that line, in this case zero, needs to match the two digits near the name start (~00MORPHMOD.n for zero, ~01MORPHMOD.n for one, etc). This is just so that the exporter can properly match things up for meshes like the hula one, which has two base groups. As long as the values match, any numbers from zero to 99 could be used. But teh importer starts counting them from zero

<* Wes *>

I am guessing you worked very hard to make the arms into front legs and the legs into back legs.

It is likely that a horse will not animate very well in the game. But I have a suggestion that might yield something that may look good in game.

The Sims2 game engine does not really need to have the joints inside the mesh parts, and there is no reason I know of that says you cannot have both the left legs assigned to the same set of bones (l_thigh, l_calf, l_toe and l_foot), and similar for the right leg. The horse's back legs bend the wrong way to walk realistically with the human animations, and both legs on each side would move in synch, but standing poses could look correct.

Then you could use the arm bones for... arms.

Very creative idea.

<* Wes *>

The people that made the Maxis assignments are experienced professionals. And the animators designed the animation to work correctly with assignments that were used. You would need to think about changing both to do something special (such as Marvine's dancer).

<* Wes *>

In this specific case, there is a new SMD plugin for Blender that supports the SMD variety used in skankyboy's SimPE plugin. At present the author appears to be anxious for more testers.

But, as a general rule SMD and OBJ (amd 3DS and...) can be non-standard standards. Blender several releases ago changed their defaults and broke both SimPE and MilkShape OBJ importers by using an 'o' instead of a 'g'.

<* Wes *>

Oh, and MilkShape updated the SMD support to optional multibone skin weighting in version 1.8.0 or 1.8.1

The tutorial probably has a mistake, confusing export and extract.

The GMDC has an export button, that allows you to select a 3D format, such as ".OBJ" or ".SMD".

All objects, including GMDC and GMND, have available an interaction called extract. The difference is that extract saves an exact copy of a little part of your package file to a disk file. This allows you to move parts pieces from one package to another.

To make extract work, you RIGHT-click on the item in the resource list (the big list box in the center), and from the pop-up menu pick "extract" and then carefully navigate back to your working directory to save it.

<* Wes *>

I was going to type something here, but I just seemed to have lost my mind!

<* Wes *>

One thing that makes the Sims2 body mesh shading issues harder than they might need to be is the fact that, by default, there are no smoothing groups. This is mainly because the game files (GMDC) do not contain them (because they are not needed for runtime 3D rendering).

A smoothing group is a subset of a mesh that should not have any edges that are shared with a different smoothing group use averaged normals. My impression from looking at the Maxis meshes is that smoothing groups were used by the artists that made them originally.

One place that is easy to describe this is at the hem of a dress. At that edge, the faces that are on the outside of the dress should have normals that face outward (from the center of the body), while the faces on the inside of the dress should face inwards (towards the center of the body).

Maxis made these work by making sure that the "seam" there was not welded. Welding is where vertices that belong in more than one face are the same, versus unwelded, where there are two or more vertices at the same place. This is because in The Sims 2 mesh format, there is exactly one normal for every vertex (in some formats, the normal is associated with the face, but not here). Then, each set of faces needs to be placed in seperate smoothing groups (so, one for the inside, another for the outside). If those two steps are done, then the MilkShape function "Smooth All" will set the normals as I described they should be.

If you weld the seam there is only one vertex at each point along the edge, and so there can only be one normal. When you use smooth all, the result is the average of the two directions, which makes a normal that points downward. This give a dark shaded area at the dress hem.

You get a similar effect when you leave the seam unwelded, but have the two parts in the same smoothing group. In this case there are two normals, but they each point partly at the floor and partly the way they should, giving a shading issue, but not as intense.

As Bloom pointed out, there is also a UV mapping issue with welding seams where the UV map has seperated parts. The UniMesh exporter applies a partial fix for this by adding a new vertex in and then remapping the faces so that both UV coordinates are able to be exported (effectively unwelding them), but when this happens one of the normals can be lost.

If you cannot retain the original Maxis normals, which is what happens when you move the mesh to and from Poser, then you can cure this with smoothing groups. As an aide, I wrote a tool plugin that attempts to make new smoothing group assignments by combing through the model and splitting the parts that are UV mapped seperately into new smoothing group assignments. Since this is just a calculation, and there are only 32 smoothing groups, this process sometimes fails to get the entire mesh seperated on very complex meshes. But the latest releast of the UniMesh plugins had this plugin, named "Sims2 UniMesh Make Smoothing Groups V4.09", located in the Tools menu in MilkShape. Just make a backup of your work before you try it, please, in case you are not satisfied with the results.

<* Wes *>

Valve (Half-Life) has made a business out of open formats and modding. Heck, they give away a huge chunk of the game and game engine source code right on the game CD (installation optional). They just never had as good a game idea as Will Wright did.

<* Wes *>

In SimPE, find the GMDC for the endtable that has the group "groundshadow" (or a similar name). The Opacity value (somewhere in the groups in the SimPE plugin) should be a small number, like 0x00000007 or such. You probably have the value 0xFFFFFFFF, which makes it a solid.

Change the opacity value for just the groundshadow group to what was in the original object and resave.

<* Wes *>