Just a quick mention, I have posted V4.02 a few minutes ago. Mainly, what 4.02 does is confined to the exporter carefully checking each triangle point that shares a point, and if the UVs don't match, then it "splits" them by adding a new point. Pretty much it is an automatic unweld on parts that should never have been welded.
This won't fix welding on parts that were MAXIS seams intentionally made, such as those at the dress hems and other clothing overlap areas, where an inside and outside are adjacent. Those will end up with the shadows back.
I recommend welding not be used on modifying objects except for where you are adding new parts, and, of course, welding custom new made-from-scratch objects is needed.
But indiscriminate welding seems to do little to improve the model from the MAXIS original.
Unless someone finds a big boo-boo, there probably won't be any new updates coming soon, as the code seems to be pretty stable, and I see people getting some good results out of the tools now. Remember, meshing is complicated, and the clothing and hair meshes are really tough projects to take on.
But now we have a few more capabilities than we had before. MilkShape is not in the same league as some of the big name tools, but I think that some of you have proven that it is a lot more powerful than the big boys imagine.

<* Wes *>

p.s. I am always open to suggestions for improvements and features, but these last two updates were to repair what I felt were major impairments.

I have downloaded it. And compare it with the original MAXIS mesh. I have some tools here that I made when everyone was trying to figure out what all the parts that weren't the triangles and vertices and normals were for.

Some of the models, particularly the expansion pack ones, have "morphs" that are not referenced by the body model, have no name, and, when left in if they were triggered would make no change. I go ahead and import them, but pop up that warning. By hiding/unhiding the groups, you can see the morph is the same as the base model. Removing the morph data will make the model smaller.
I have taken models that originally had morphs, deleted the morphs, and exported them into the game. BodyShop will still allow you to select fat/thin body types, but all you see is the hands move away from the hips a little.
I wish I knew more about how morphs are triggered, because I think that they could be used for other kinds of effects besides thin/fat, if we knew where in the game the "state" gets changed at.
<* Wes *>

Well about my last post, like I said I was away from a computer for a while so when I came back I just read Dr pixels way and didn't even read fully Wes's note so then now iv gone ahead and tried with all the new stuff and I’m still getting weird things but its a lot better I can see my mesh beginning to shape up.


It seems that the body is acting like one of the alpha layers. Its pretty weird, but when I change the color in the alpha it works like the normal body would. You can see in the picture the first two models show really how things are "bleeding" I guess you can say right through. And then the third model shows the feet which are doing some funny stuff and then the fact that the back of the dress isn't showing up and I don’t have the slightest idea because its part of the body not the alpha.

Excuse the picture quality its just so I could fit it in the attachment.

You are right about the appearance being different between the morph states between your replacement mesh and the original game for the af mesh in the fat state.

The names are in the right order in both files, but I am not sure the morph models are being built correctly on import. It seems that in the original "morph map" section, some vertices are flagged 02 01 00 00 and other places 01 02 00 00, while mine always has 01 02 00 00 in those locations. If so, then I may be drawing the delta data from the wrong places part of the time. I have to recheck, but I don't think my import placed any significance on the order between 01 02 and 02 01, but rather whether there was an 01 or an 02 at each vertex point. That is likely the difference.
So I think maybe I am drawing the fat and pregnant parts both incorrectly when the import occurs, mixing the data up, some fat in the pregnant and some pregnant in the fat. Of course, when there is only morph, there is nothing to confuse... just fat and thin.
The names are in the same order between the original and your remake, so that's not where the difference lays.
I will research this... not bragging, but I was the one that deciphered how the morph sections and the map pieces all fit together in the first place. Maxis didn't supply us with any book on how the data is laid out.
However, this confusion has been there since the "BodyChop" models first appeared, which was Sim ages ago. It has to be in the mapping order on import.
Thanks for the good example. I always have enjoyed a challenge, and you have sharper eyes than I have. I have done replacements tests like that, and never noticed that fat was too fat on my replacements.
I'm not sure that this can be changed in a way that will not require the af model to be redone from scratch, because I think that is where the mixing up happens at.
<* Wes *>

Hi Wes,

I don't care if I have to redo the model I'm more concerned about my pregnant sims looking pregnant when they change into their pjs.

You totally amaze me with these tools. I am very picky when it comes to my skins & I have tried & tried - everything - for the past year but I could never get anything quite right in a reasonable amount of time. These changes you & Mete made are awesome! I managed to make the changes in a short time & they came out perfect (except for the fat/pregnant thing). The shadows were right, they weren't too choppy - they just look great & it really wasn't hard to do! I am officially impressed

I'm sorry to say you will.
But I like the rest of what you said! My ego is going to get as big as some of my cow's butts, if you keep that up.

Remember all the way back to yesterday, when I said I probably wouldn't be doing any more releases soon unless someone found a big boo-boo? Well, I considered this a big enough defect to warrant a prompt repair.
So you will find version 4.03 posted in message #1 of this thread. I'm afraid that an update for the manual will not happen soon, because the basic way to use the plugins is the same, just a few visits from the terminix guy to kill some bugs.

This problem is as old as the first edition of BodyChop.
What was really wrong wasn't that the morphs were switched when there was more than one, but that parts of each were lumped together, and the way it happened, a lot more pregnant bits ended up in fat. Essentially, there is a part of the file that has a "map" of whether the vertices should be moved, and there are data sections that contain the amount to move the morph by.
I was reading the map in the importer as if it was a spreadsheet, and I was looking at each row as if it was organized by columns. A zero means no change. But a 1 or a 2 in the first column means pull the data from section 1 or 2. For the next morph, you read down the second column, and pull from pile 1 or 2. I was reading the column to see if it had a 1 or 2 in it, and was pulling all the data from the same section, morph by morph. There is room for up to 4 morphs, but the only files I have seen use more than the two you are accustomed to are the face files, and they have some other oddities about them, too. It's too easy to make a new face in the game, so I never played with editing any face GMDCs in SavedSims.
I tested your package, and now the fat silk af pajamas are the same body shape as the other nighty-type ones. But I didn't lengthen the legs. You'll have to redo the af one starting with a fresh import from the game directory. The meshes with only a single fat morph will not need to be redone, because this was only a problem of mixing more than one morph in a file.

So, thanks again for the kind words, and I'm sorry for making evertone download so often. However, it is good practice to replace the whole set, rather than having to manage portions with different version numbers, not being sure what is current and what is old. Importing with one version and then exporting with another that maybe didn't get updated too is bad practice.

<* Wes *>

Wes, there is also an issue with missing information when using MilkShape's "Merge" option - you might want to mention this to Mete too.

If people are unfamilar with "Merge", it allows you to combine a saved .ms3d file into your existing project in MilkShape, and would be a very handy feature to have available if possible.

========================================================

And now, an "if this is practical" type of request

It would be great, in some cases, to be able to export and import from MilkShape all the comments, and bone/vertex assignment/weights information into a separate file.

This would allow meshers to export the file as an .obj (or other format) for uv_mapping in an outside editor without losing this critical information.

I second that request, uv-mapping in milkshape is a nightmare compared to using Ultimate Unwrap.

Thank you Wes for the quick updates!

I second Dr Pixel's request too, this is a great idea and I hope it's doable without too much pain.
Milkshape's uv-coordinate editor is a good and convenient tool, but it doesn't offer the same possibilities as other editors; and even trying to stick to Dr Pixel's method (mapping parts before importing them and assigning them), I often have afterthoughts when it comes to elaborate meshes...

Yes, as marvine says, thank-you for the speed of updates. It is much appreciated. Just last night I was bemoaning the bodymod problem and voilà! You are the greatest

I will report that for you.



The milkshape ascii text exporter/importer does not save the extra assignments, at least not yet. It does save all the comments, since V1.7.3.
Model comments were added in 1.7.4, but those have never been utilized by BodyChop or UniMesh except for a special experimental version I posted in the Research & Development thread.

Now, I can write a special text version exporter/importer that could be done using the .obj style general layout, with, of course, extensions. That would lend itself to cut-and-paste operations to/from .obj format files.
The critical component here is vertex count and order. If vertex #501 is in point #2 of triangle #770, and the bone/skin data is ordered as #501, you can't use tools that reorder the mesh in any way. If it changes the UV data values without reordering, it would work. Not throwing stones here, but one of the things I remember about Wings was it rearranged the triangles and vertice order... one reason I never did anything resembling a Wings file format converter for TS2.

So, having said that, what is your experience with UV remappers using .obj files?
1. Do they maintain the triangle/vertex/normal order?
2. If so, who does and who doesn't support .obj format?
3. Would cutting the end off an exported extended format .obj file, saving it (as a text file), feeding the head of it into your UV mapper, then pasting the extra data back on the end after remapping be of enough value to be worth the effort of me writing a special exporter/importer plugin pair?
4. Is there a better textual mesh file format other than .obj we should think about?

<* Wes *>

I use Ultimate Unwrap 3d (lithunwraps pro version)
1) The vertices look correct. I'm not sure about the rest. I'll attach before and after obj's for you to dissect. The out version, I selected include texture coords, vertex normals and unselected smoothing groups.
2) I know lith and uu3d do.
3) I would have no problem using this method, to be able to use my uvmapping program.

Aloha Wes

We have a winner! I redid my adult pjs & they are now working correctly. Fat is fat & pregnant is well......pregnant.

Excellent! Thank you - I really didn't expect this fix SO fast, but I do really appreciate it. Having this tool makes such a huge difference - it's unbelievable.

Morague

Hi Dr Pixel!

You where right! The necks on teen and above look perfect now!
But, the kid neck still has the hole in it when she looks to the side, like this:


It is a adapted version of a teen mesh, since there was no ponytail mesh for children. Maybe there's too many verticles and it just doesn't fit. Couls you take a look at it and tell me what you think?

Thank you very much for your tips! It's helping me out a great deal!

Greetz from Nouk

The files you sent appear to have the same face/vertex ordering maintained.
The normals were changed by the uvmapper, as were the UVs, which is what you wanted done.

I was thinking, perhaps instead of cutting and pasting, I could text export everything BUT the faces, normals, vertices and UVs.
So to uvwrap, you do two exports, one the .obj exporter already in MilkShape, and another "XtraData" export.
To reassemble, you would do a file/new, then file/import/.obj from the UV mapper output, then an "XtraData" import.
This "XtraData" importer would complain if the face/vertice count was different from what was exported, and quit. Otherwise, it would attach the missing data to the Faces/Normals/Vertice/UVs that are already there.
The "XtraData" (just a working title for the moment) would be all the bones, bone comments, group comments/bone assignments/skin weights... everything that the UniMesh exporter needs to make a complete file ready to export.
So two export operations, and two imports, and the user would have to keep the names straight or the data wouldn't align. Then the UniMesh exporter would be able to squirt a GMDC out to go into the game via SimPE.

I know this can be done. Rather than file surgery (cut and paste), maybe just two seperate operations. The import "XtraData" would have to come after the .obj import, the export order wouldn't matter, so long as the working file isn't changed inbetween. And sticking to the already well tested .obj exporter/importer in MilkShape would cut development time and debugging considerably.

From a design standpoint, synchronization of external events being dependent on a user is not a good choice, but whether cut-and-paste or click and name, if the tool isn't used correctly, all you get is a spoiled file. And writing a program like MilkShape just for the Sims2 from scratch would be such a Herculean effort that I'd have to make it a business to justify it, as I wouldn't have any time to go feed my cattle and mend my fences.

I'm sort of thinking out loud here, in public. I will think some more off line. I would like some more opinions from everyone interested, maybe even a sample before/after .obj from someone with a different UV mapper. As long as the triangle/vertice ordering relationship is maintained, it would work.

<* Wes *>

Wes can you make it so we can type in the numbers for weight and joint index on the bone weight editor?

You did such a good jobe with getting Milkshape updated should try to work with the guy who writes fragMotion to update his milkshape support. Doing bone weights is ALOT easier in it as you can see the affect right away.

Nouk, I have put the bodyshop child's face mesh into MilkShape along with your hair mesh.

In the picture the face is highlited in red, your hair is in white. As you can see, the vertices at the back of the neck are not aligned exactly with those of the face mesh. I think this is what is causing the problem you are having.

I have attached the child face mesh for you to use to align these vertices.

Import your mesh first, then import this. Use it to make the adjustments, but make sure to delete it before you export your mesh.

I will rework the bone editor in a future release. The edit boxes were supposed to be typable the first time around, but I had trouble with the "Windows" part of the code, and I believe the reason was the same problem that made the bone tool crash MilkShape 1.7.7A. I had the window improperly defined, and wasn't getting the messages that new data had been typed in. Making a user interface work right is sometimes as hard as writing the code to do the real work.

I have no idea about fragMotion. I've never even seen the name mentioned before. What does it do? Is it a shareware/freeware or is it something you can order at Amazon.com?

<* Wes *>

It's here, Wes:

http://www.fragmosoft.com/

I hadn't heard of it before either, but it looks pretty good - it's low cost ($20) and says it supports up to 4 vertex weights/assignments

i hate to seem like a nusence, but iv tried and tried to fix this problem with my mesh from 2 days ago that i posted the problem here and it seems like its only on my computer that it went through. all id like to know is if this is a simple problem of mine or if the problem is deeper.

I purchased fragMotion for another project about a month ago. It's a very nice program, you can do alot in it, modeling, rigging, animating, uvmapping, texture painting. I found it very easy to get started with and use. The rigging part is great because you can see which bone is associated with which vertices in real time, and see how the weighting affects it.

Hi Dr Pixel!

I tried your method, but the hole still appears sometimes as the child turns her head... I even took parts of the model that connect to the face, but it's still there every now and then.

I have a second question... i found out that when I look at the meshes from different angles, part of the hair groups shows through the face. I had opacity set to -1 still. Wich opacity would work too?

Kisses from Nouk

I see it has an SDK for custom interfaces.
So I am downloading the SDK and will research this... no promises other than I'll research and think about it.
<* Wes *>

It is likely from your description of the problem that you have vertices in the hair mesh that are attached to, at least in part, one of the 5 joints that end in "_hair". Leaving bone assignments in a hair mesh to these bones has proven to be a problem, as the animation routines use these in ways that are not yet fully understood. They are not really "bones" but rather "animation targets", and when you leave some of these bone assignments in there, unless you get the model exactly like the original, the animation routines will rearrange things in unexpected ways.
Check all the secondary assignments and remove any *_hair references.
Also, some of your problems you describe are indicative of underweighted bones. Any set of assignments significantly under 100% will leave unintended artifacts when the model is animated. The underweighted parts will not move in synchronization with the properly weighted joints, creating little bits of mesh where they shouldn't be.
<* Wes *>

The opacity settings should be like this:

Group "hair" is always -1

All other groups should be the same as their name -

For example "hair_alpha7" should have opacity set to 7, "hairalpha_11" should have opacity 11, etc.

Also, I would check the mesh of a child's hair and see what Maxis has set for those vertices on the back of the neck in the area where you see the problem. The child's hair may have a different setting than the adult and teen do.