Mod The Sims - Morphmods: correcting the problems?

View Full Version : Morphmods: correcting the problems?

fireflies

9th May 2006, 07:16 AM

Working with the Food files i have discovered a problem with certain files and their Morphmods

We have a few questions about them and wondered if anyone might know a bit more about them?
so far we have only talked to Numenor and Exnem, thank you for the help and advice :)

In this first picture it shows the morphmods in the Gmdc Models Tab,
so far what we noticed is that it was missing the very first morphmod,
it should show three morphmods but does not,

http://img.photobucket.com/albums/v203/MrInvisableman/Food%20Creations1/original.jpg

Examle: they should look like this

:0 ,
1: eatberrypieblend berrypiesome
2: eatberrypieblend berrypienone

I then went ahead and pulled the mesh files,
using the gmcd file and of course the latest Simpe and all the latest updates for all other programs,
then re-imported them testing the same gmdc and i tried to import/export with wes,h's plugin into and out of milkshape to see what would happen.. same thing applied

this is what the file came up with although i did nothing to the mesh files.

http://img.photobucket.com/albums/v203/MrInvisableman/Food%20Creations1/re-meshed.jpg

notice it is correct but is missing the final morphing file?

the problem is not that SimPe is not exporting all the files
but rather the final two files are connected and is missing the final coding for the third morphmod

in this pic you can see the un-selected part of the pie and the two selected parts
but only one morphmod for those two files?

http://img.photobucket.com/albums/v203/MrInvisableman/Food%20Creations1/MissingMorphMod.jpg

I can re-build the mesh file so it is correct thats the easy part,
my problem lies in how to correct it in SimPe? can it be re-built in SimPe?
is their a way to re-import them and re-build the files so they work seperatly so i can remesh them to function normaly?

so far this seems to only happen with the foods beyond the base game,
Uni, Nightlife and OFB foods seem to all have this problem.

Thank you for any help you can give
if you need more information please let us know

Teresa and Rick.

pinhead

9th May 2006, 08:08 AM

wes plugin doesn't handle morphs that are stored with the line 0 of blending groups (name pairs).
Simpe has nothing to do with your problem.
When you change things in name pairs don't expect that will work fine.
I know a solution to the morphs with references pointing at line 0 at Name pairs, but is very advanced and all is edited manually... very painful also. Anyway, i have an idea that i didn't tried yet. Try export the mesh using skankyboy's SMD plugin, exporting the morphs as well, and import the morphs to your model in milkshape (just to see a visual reference of the morphs to edit the original model that you are working it). Then you can duplicate the main group of your model, set the name of duplicated group to "~00MORPHMOD.0" and change the comments to "eatberrypieblend berrypienone". The other morph you set the name as "~00MORPHMOD.1" and in the comments apply the other name "eatberrypieblend berrypiesome". You can edit those new groups to be like the morphs that you exported by skankyboy's plugin.

it's an idea.
just a quick note: the name ~00MORPHMOD.0 will use the name of the first blending name in the group comments. when is using MOD.1 will use the second name of blending groups in the group comments.

Numenor

9th May 2006, 09:11 AM

Pinhead, what do you mean with "the line 0 of blending groups (name pairs)"? The line 0 (usually empty) in the Model tab of the GMDC?

I thought that line 0 simply held the "main" mesh, and the following lines held the morphs...
Do you think that probably Maxis changed method? With the base game, the line 0 was just empty (and lines 1 and 2 were reserved for the blends), and in the EPs the line 0 and 1 are used for the blends, and there is no empty line...

As for the "Comments" associated to groups in Milkshape, and the blend names:
the first number in the name (e.g. 00~...) is the number of the "parent" group, the one to which the blends are connected to, and can be read from the Comment for the main group.
In foods, there is only one group (with morphs), so the parent group is number 00, and the blend names start with 00~...
But if you export for instance the GMDC from the crib, the animated part (crib gate) is the 6th group in the list. In Milkshape, you can see that the blends are named 06~... and the comment for the parent group is "MorphRefNum: 6".

fireflies

9th May 2006, 11:25 AM

wes plugin doesn't handle morphs that are stored with the line 0 of blending groups (name pairs).

but it does ;) i can pull the layered cake just fine using wes,h's plugins and it uses the 0 , file

also i can edit the mesh to work the same way as you are
just by cloning the mesh files and adding the coment lines
and changing the morphmod name

is something different to how skankyboys work
compared to my cloning and remeshing the file?

anyways once i imput the file back either way it still does not show the final morphing sequence
the last animation is missing even if i export in skankyboys method.

i am not sure if you mean i need to reimport the files after regrouping them in milkshape?
so they show up as only the two files?
and not the 0 , file? i can give it a try and see what happens?
will be a pain though .. seems as if the whole structure was changed since the base game? and if not then something is missing in the connection to the animation?

pinhead

9th May 2006, 01:16 PM

Pinhead, what do you mean with "the line 0 of blending groups (name pairs)"? The line 0 (usually empty) in the Model tab of the GMDC?
hi Numenor!
Yes. The first line (0), that usually is empty, is been used now. I saw a lot of meshes that have morph references in line 0 (since UNI).

@fireflies:
Well, you were saying that the first morph was not been imported in milkshape, and that is what i was saying that wes plugin can't import the morph that is referenced by line 0 of Name Pairs. And looking in the screenshot you only have 1 morph group imported, so one of the morphs (referenced in line 0) is not been imported by Wes Plugin. I had some problems with other meshes as well that use the line 0 to reference a morph and i fix manually to be imported by wes plugin. Anyway is so painful that i'm trying to find another method to it.

I don't know why you are missing the Name Pairs if you include the comments right and did what i suggested. Is suppose to be exported 2 working morph names (line 1 and 2) + a empty morph name as line 0 (wes plugin always add an empty 0 line there). Don't worry because wes plugin will correct the reference of morph adjustments to the correct Name Pairs lines.

A quick note:
"...MORPHMOD.0" isn't the 0 line of name pairs. Wes made that MOD.0 will be the line 1.

Jasana_BugBreeder

9th May 2006, 01:44 PM

Try export the mesh using skankyboy's SMD plugin, exporting the morphs as well By the way, smd plugin seems to have problems with object morphs :( I'm struggling with a cake piece right now. First and fairly easy to workaround is that morphs #1 and #2 are imported in reverted order. Second and painful is that no matter what I do with the vertices of supposed-to-be-none-morph, some weird faces appear :( I haven't give up on it yet, just warning.
anyways once i imput the file back either way it still does not show the final morphing sequence
the last animation is missing even if i export in skankyboys method. Hah, that's exactly what I've seen - morphs are imported in reverted order - if you'll watch carefully, you'll notice that the piece first disappears, then half of it appears. Try to swap the morphs.

fireflies, I haven't tried but seen a place in SimPe where you can probably correct the morph names.
When SimPe in Advanced Mode, there's additional tab for GMDCs, named Debug. On this tab, there's Model link (note that to see it, you might need to move splitter to increase Plugin View size). When you click on that link, to the right you'll see 3 fields, the one you need is BlendGroupDefinition. Click on the ... button, and dialog will open where names are editable.

pinhead

9th May 2006, 02:10 PM

well, the smd importer/exporter is first made for body meshes, but still has some problems.

When i said to export using it was just an idea, since i never tried with cake or food. I tried with a sofa (that wes plugin was not importing one morph) and was fine.

about correcting the morphs names you must know what you are doing since those names are referenced in the elements list (morphvertexmap). If you change something there you need to correct the references in this element list. That's why i was saying that is painful to fix, since editing each vertex reference of your morph data is a lot of work. :)

i'm with some free time now. i will try this one mesh to see if i catch something

EDIT:

I'm confused now. Not sure exactly were is the reference to that "none" blend. I get 2 different things when changing morphs references. One i got the same result showed by SMD plugin (that even showing just a point in the middle of the mesh) i think that is correct. One is a little different, but doesn't look right. What i'm thinking now is that "none" is not to be something visible, but i'm not sure anyway.
Sorry about the suggestion with smd exporter. didn't worked as i expected here also if the first morph isn't correct.

the attached file has 2 GMDCs.
cake.5gd is the one that i think isn't correct;
AC4F8687-AC4F8687-cake.5gd gave me the same result as SMD exporter. And i'm starting to think that is the right one.

exnem

9th May 2006, 03:56 PM

Hi folks :)

Numenor asked me to check this thread out as you were talking about morphs which I have some experience with.

I also noticed that the 0 blend is being used now (perhaps to be able to use 3 blends instead of 2?).

When you import one of these GMDCs into milkshape, the base mesh will be merged with whatever blend is occupying the 0 blend. I never use maxis meshes, I always use my own, but if you are to base your work off of maxis' mesh this could present a problem when trying to separte both (the base mesh and the 0 blend). I use max fortunately, and there's a way to grab entire elements inside a single object which makes the job much easier.

Anyway, fixing this (once you have your meshes right) is very simple (I think pinhead was trying to explaing this?).

All you have to do is recreate the missing blend, so suppose you have this setup (using the berry pie):

Original Berry Pie
frosting - Comment:ModelName: frosting
Opacity: -1
MorphRefNum: 0

~00MORPHMOD.0 - Comment:MorphNames: eatberrypieblend berrypiesome

Your mesh
myBaseMesh
myBlend0
myBlend1

Change your mesh like this:

myBaseMesh = frosting - Comment:ModelName: frosting
Opacity: -1
MorphRefNum: 0
myBlend0 = ~00MORPHMOD.0 - Comment:MorphNames: eatberrypieblend berrypienone
myBlend1 = ~00MORPHMOD.1 - Comment:MorphNames: eatberrypieblend berrypiesome

Notice that the "berrypiesome" blend has been moved to .1 instead of .0 as the .0 blend was really the one merged with the base mesh ;)

This method should fix any morph groups that have the blend 0 in use.

fireflies

10th May 2006, 01:01 AM

WesHowe

17th Jun 2006, 01:38 AM

Allright, I'm guilty.
I confess that I have had my own difficulties understanding which morphs should stay, and which should not.
The original game meshes were pretty standard (null 0, active 1 and maybe active 2), but the expansion pack meshes started showing up with many variants.
I believe the importer code can reliably read the morph data from all the models in. However, some morph data sections are not actually referenced, and some are simply null, that is, the morphs are all zeroes, which makes the morph the same as the base mesh (these are presently never passed to MilkShape). After all the data sections have been read in, the importer attempts to determine what kind of meshes to create in MilkShape.
Remember, the same code is attempting to organize not just body meshes, but objects (which also may contain joints and morphs, but might not).
I will follow this thread, looking to see if anyone can come up with a better rule to determine which morphs are real and what are not. Building a better importer will then be (relatively) easy with a good rule.
<* Wes *>

WesHowe

4th Dec 2006, 01:47 AM

I kind of forgot about this thread. I made an update for the UniMesh importer back in October that forces the empty morphs to load. They are still exported the old way with the release 4.06 exporter plugin (line 0 empty, and an operable mask), which works with the expansion and the non-expansion games.
Since then I have added a few extra fixes, and posted them as interim updates (only the new importer plugin was changed). The latest will load Pets mesh files, although it warns about the data it left out (which I think are Vertex ID and Region Mask). You can get the updated importer (includes all previous updates) at:
http://www.modthesims2.com/showthread.php?p=1458704#post1458704

<* Wes *>

Also, is there any reason for this thread to still be sticky? I always check the UniMesh thread first for any new posts, and may not always find posts about the plugins quickly if they are elsewhere.

Numenor

4th Dec 2006, 03:25 PM

I've "unstuck" this thread, I don't know why it has been sticky so long :P -
The "official" Unimesh thread is definitely the one where to post questions.

Numenor

17th Dec 2006, 11:27 AM

This Cow Plant is puzzling me...

1) The foods and the Buffet Table have this peculiarity: they have separate ANIM files that trigger the different blends; and in each ANIM file are referenced no more than three blends (in addition to the base mesh, i.e. the "full" one). This complies with the 4-slots limit pointed out by Wes.
These ANIM files seem to just "swap" between the different blends: no actual frames are created for them, and the overall duration of the animation is zero.

2) The Cow Plant, on the contrary, has several ANIM files, each referencing all the 16 blends (not counting the tongue, that is in a separate ANIM section). All the 16 blends are managed simultaneously: a set of frames is created for each blend (the number of frames may vary, but the overall duration of the different animations is the same for all the blends).

Are we facing two different phenomena? The apparent structure of the mesh may look similar in the two cases, but the usage of the blends made by the game is very different...

WesHowe

17th Dec 2006, 01:36 PM

I'm going to discuss the latest oddities about the morphs that I've found.
This message will use the cowplant mesh for the example.
You can follow along in SimPE for most of this, although I used a different disassembler.
The first thing after getting the GMDC into plugin view is to look at the Elements tab, items 8 through 26. These are TargetIndexes. Now, look in the Model tab, Model Section - Names with items 0 to 18. These name pairs appear to be a blend type and blend name, and you will note there are the same number as there were TargetIndices, so you can get a correspondence by using TargetIndex-1.
Next, let's go back to the Elements tab and look at items 46 through 49, these are the maximum four morph data buckets. Each is sized the same as and aligned with the vertex section (41) for this group.
Select the Morph Vertex Map and look at the values. The first line has 1118226 first... ignore that, this is used as four bytes, shown as (18 16 17 0).

It looks like the way the blend would be built from all this would be to start with the name, lets say "tongue3" which is found in the names section as index number 18.
We go to the morph map and go line by line through it, looking for instances of 18. We have a hit on the first line, and the position is the first of the four bytes.
So we would take the first vertex original XYZ and add the deltas found in the first vertex position in the first of the four Morph Deltas for shift one vertex from the original to tongue3 position. We would walk through all the rest of the morph map doing the same... note that on the third line, #18 is in the third position, so we draw our data from the third Morph Delta section.

UniMesh does not get this right.

When there are four or less targets, and the first target has a null name, what UniMesh is doing gets it right. When there are this many morphs, though, it only gets four of them picked out, and may get the wrong name pair associated with them.

There are only four data buckets (Morph Deltas) per group based on the way the DBPF is built; you have 1, 2 or 3 floats, or 1 longword for a section, so the morphmap can only reference four data elements. What Maxis has done appears to be very complex and quite clever. Each of the morphs covers only a little part of the mesh, so they are all packed together, providing that any one vertex in any group has no more than four morphs.

As of this morning, I don't know what I am going to do to rectify this. Revising the importer to make all 19 morphs into models, each matched to the proper names is not an overly ambitious challenge.

How to provide for packing them back up into four or less morph data sections and exporting them looks pretty challenging.

Edit:
I am working on an alternate importer that brings in all the blends. While that doesn't help the four buckets limit problem, it's a step toward a solution.
I think I m going to need to try to get some additional data items space (four bytes would work) on a per-vertex basis. This is a thorny issue, because each extra byte get multiplied by all the vertices in the mesh. Given the history of MilkShape, it was always lean and mean and ran on lower performance PCs that choked on the high-dollar 3D programs. But maybe there is a way to have the program designed to only use the extra space when requested by a plugin.

But perhaps suitable grovelling will help. It got me space to store additional bones and skin weights last year, which helped me solve a lot of the body meshing issues we had at that time.

<* Wes *>

exnem

17th Dec 2006, 04:49 PM

I believe what is happening with the cowplant is what we animators call "selective morphing" (at least at the studios I worked).

I imagine the way the cowplant works is by mixing in blends for different parts and using "selective morphing" to change only specific parts at specific times.

For example, there's a blend that controls the mouth (open/close), another set that controls head movement (up/down, right/left), and so on... then the animation mixes blends so that the cowplant can move it's head up, and at the same time, nod left and right and open it's mouth... There you have 4 or 5 blends all working at the same time but each affects only a portion of the mesh.

This is a technique that is very commonly used to animate and I'm certain the game does the same.

The food on the other hand needs no frames because there's no actual animation going on, just changing from one state to another instantly.

WesHowe

18th Dec 2006, 04:20 AM

While I don't have the practical experience you do, that makes a lot of sense to me (tweening). Even the normal/fat transition and different pregnancy stages appear to be done by using a fractional part of the morph delta.

BTW, I think the high-morph-count objects came, if not all, mainly in the EPs. I remember finding faces with a lot of morphs, but everything else seemed to have four or less active morphs.

Ah, but what have we without some progress. This one is just going to take a little more time and effort to put together.

<* Wes *>

Edit: It appears that getting the needed mods done to MilkShape will likely not be an issue. But testing and waiting for a new release (from both ends) is slow. The last time, I was able to get a lot of work done with beta versions, and had my package ready soon after the MilkShape version was released. Then, as now, there is no schedule to work from (best efforts only).

exnem

19th Dec 2006, 04:53 PM

I have been doing a lot of testing with morphs trying to figure out a way to transport animations from one object to another, but so far I haven't had any success.

I still believe the morphs are referenced by name from within the anim files, as changing the morph names to something else prevents them from playing... however if you change the names in the anim file and the names of the morphs in the GMDC the game crashes. So it seems that part is still bugged or non-functional. I haven't tried changing the names but keeping the same length as I know sometimes this helps (specially when hex editing, to help keep the same number of bytes (?))

Now, it's a fact that the mesh name (or subset names) have no importance, as I have changed the name of the mesh in many objects keeping the morph names intact and the animation still plays correctly, so the mesh name has no importance. However, there is an "object name" filed in the "Header" of the anim files that cannot be changed and is maybe what links the anims to an object (don't know if this references the "Practical" entry in the CRES). At the moment that field cannot be edited so maybe that has something to do with the problem.

Wes: The Alpha version of your export plugin seems to work perfectly now, thanks, the problem as you see now seems to lie somewhere else.

WesHowe

19th Dec 2006, 11:26 PM

The name is required for a morph to work, that has been known.
The linkage as I have it now involves:
1. The TargetIndex. If these have any data in them, it is a set of data that seems to be designed to allow the bounding-mesh to be changed.
2. Matching with each TargetIndex is a name pair. It seems like it is a family->member association, but you now know more than I do. If you are hex-editing the names, then the length is critical, because they are stored with a single-byte length value (always <128) and then that number of characters. The next thing after the last character is the first byte of the next item (which may not be a string), so if there is a gap of random garbage left at the end, the file becomes unparsable. Some hex editors will let you delete the extra bytes, and I think this would work.
3. So now there are, for each group, up to four 'bins' of morph delta values (and optionally morph normal values) plus a morph map that have an item count equal to the vertex count for the group. The morph map associates
the vertex delta from each bin to the vertex by the TargetIndex.

The present methodology works fine, as long as there are four or less morphs total. Items such as clothing have morphs that cover a lot of the mesh, so they may not be good candidates for packing.

The good news is that extending this to work with packed morph maps is going to be possible, as Mete has agreed to add what I need to have into MilkShape.
The bad news (why is this always so?) is that it will be cumbersome to work with these sets. I tried just unpacking them all into seperate morphmod-like groups, and the cowplant failed because, at 4,280-some vertices and 19 morphs I ended up with more than 65,535 vertices, which is too many for one file in MilkShape (the faces have 2-byte indices, there's the limit).

So I am working on importing them packed and using helper plugins to manipulate them with. However, synchronization when adding or deleting vertices will be critical.

<* Wes *>

WesHowe

19th Dec 2006, 11:50 PM

Now, it's a fact that the mesh name (or subset names) have no importance, as I have changed the name of the mesh in many objects keeping the morph names intact and the animation still plays correctly, so the mesh name has no importance. However, there is an "object name" filed in the "Header" of the anim files that cannot be changed and is maybe what links the anims to an object (don't know if this references the "Practical" entry in the CRES). At the moment that field cannot be edited so maybe that has something to do with the problem.

I wonder if your test was unflawed.... the subset name is used to link the texture(s) to the mesh, and with a changed name, it should have had a texturing issue (maybe you meant you changed both the GMDC and the SHPE). However, the morph linkage in the file, as I understand and describe above, would be independent of the group (subset) name, relying on the name position and the indexes held in the morph map and corresponding vertex delta values.

Thinking out loud and online here, you might try swapping two names of the same length with your trusty hex editor, and see if the animation plays differently. This would confirm the morph name link.

Wes: The Alpha version of your export plugin seems to work perfectly now, thanks, the problem as you see now seems to lie somewhere else.

Thank you for the feedback. I will work on adding something to detect and warn on morph overflow and then release it.

WesHowe

26th Dec 2006, 02:03 AM

so far this seems to only happen with the foods beyond the base game,
Uni, Nightlife and OFB foods seem to all have this problem.

Teresa and Rick.

[Also, thanks for the comments from exnem, pinhead and numenor].

The foods are just the most obvious examples.

UniMesh, through V4.06, does not handle importing morphs that are numbered (via the TargetIndex) zero. It does not handle those numbered above 4 properly, either. Nor does the exporter do a good job if the entire gmdc has more than four morphs, or different numbers of morphs per group.

As you noted, in the expansion packs the file format was expanded to allow for more active morphs, and, most problematically for UniMesh, some of these begin numbering at zero. UniMesh has a simpler minded view of the mesh world, and thinks that zero inside the morphmap means that vertex has no morph. I think at one time this was true.

I am working on this. I have written an importer that I believe addresses the ordering and some other intertwined issues. I am going to attach it here, for a public test.

Some caveats:

If generating a file with a lot of morphs drives the filesize beyond 65,000 vertices, as the cowplant does, the importer will quit (with a warning).

The exporter will not handle all of the imported files properly. Besides being confused if there are, for example, 2 morphs on one group and one on another.

The raw numbering used by the importer (e.g. ~04MORPHMOD.08) will be rejected by the exporter; the "08" in the above example is the TargetIndex in the original file.

This may not stay this way as I work on making sure the exporter and the importer view the Sims2 world harmoniously.

In any case, until some time in the future, you will only be able to have four morphs per group. While the importer will pull more than that from some files, there is no way to repack them without additional per-vertex storage space, which is not available in MilkShape 1.7.10 (and below).

That may be able to be changed to four-per-vertex, but not real soon.

I am looking for some testers and some example files that do not import properly. Since the exporter is not ready, the value here is that you can see the morphs, and toggling the 'hide' button shows how they relate to the base mesh.

I would like some knowledgable mesh modders to try this out and provide some feedback so I can be a little more confident that my changes to the exporter will stay stable, then I will release both for some tests.

<* Wes *>

Edit: Stale attached file removed.

exnem

27th Dec 2006, 05:54 PM

I'll start testing as soon as I get a chance and post my results here :)
Thanks for everything Wes

WesHowe

27th Dec 2006, 10:49 PM

The exporter likely will fail to produce some meshes correctly, even when renumbered.

I have the exporter parked in the garage here at Rancho Como, with all the wheels off, up on blocks, with the engine disassembled on the workbench.

We're taking off the carburetor, putting in fuel injection, new heads, new manifold and new pistons.

Other than that, no problems making the changes. :)

<* Wes *>

Edit: I got the exporter back together, but I have to charge the battery before it will start. :)

I have noticed another major difference in meshes from the original game and from the EPs that involves the morphs.

There is a section of the GMDC (called links in the wiki and SimPE) that tie the groups to the elements. The first three values are always the element index for the vertices, normals and UVs. On older meshes with morphs, these three are followed by the target(s). Usually the targets were numbered starting at 8, so this shows as a discontinuity, e.g. 19, 20, 21, 8, 9, 10, 22, 23...

In the expansion pack meshes, besides zero being a valid target reference value for a morph, these target references no longer appear in the links, e.g. 19, 20, 21, 22, 23...

The above examples are from body meshes, not objects. While the values change, objects with morphs are constructed the same way.

The release UniMesh V4.06 exporter only produces meshes using the first style, so it isn't apparent if the change was made to the package loader in the EPs, or if the base game could read them either way and the original meshes were just constructed the first way for production reasons. For all I know the change was made to prevent EP items from being used in the base game. Just supposition, though.

I have built a toggle in my exporter code so I can try to produce them either way. When I have a body mesh and an object built both ways, I will post them and ask someone to help me test them with and without EPs.

WesHowe

29th Dec 2006, 02:35 AM

I'll start testing as soon as I get a chance and post my results here :)

Here are some additional testing opportunities.

EDIT: Anyone following this thread that wants to help test these please read this post in the UniMesh thread: http://www.modthesims2.com/showthread.php?p=1532323#post1532323

<* Wes *>

exnem

8th Jan 2007, 05:00 AM

Hey Wes :)

Sorry for the late reply but a lot has been going on lately. I also recieved the messages you left me at my site, but I got them late because you sent them to an account we only use for special purposes, so I didn't see them until recently.

Ok, I have tested your plugins to re-make the buffet table and they work perfectly. I even added extra subsets and changed numbering and stuff and as long as I keep the 4 morph per group rule it works flawlessly.

The buffet table has 4 morph groups with 2 morphs each (+ base) they extract and import perfectly with your "4.07 test3" version.

Thanks for all the work you put into this. :up:

WesHowe

8th Jan 2007, 03:36 PM

Well, I thank you a lot for the help. I know with a young family that the recent weeks would have more to them than sims.

I have polished these some, also making changes that fix the hair-animation and bumpmap support issues. I am waiting for a few other testers to report back, but I think I will launch an update for UniMesh later this week which will have all that you've seen plus.

It should be posted in the same thread, to keep the same URL, although some archiving work needs done (there's a years worth of discussion there).

So I will end the discussion here in favor of resuming it, if needed, in the UniMesh thread, unless someone else has further questions here.

<* Wes *>