Well, I hope you figured it out, because I missed your 3 day window answering.

I apologize for the sparseness of the documentation. All that is required is to run the tool on your mesh. It modifies all vertices in all groups, except those with a 4th bone assignment (and also those vertices in MORPHMOD groups, which utilize the base group weightings), by adding the weights, subtracting them from 100, and adding that number (which could be negative) to the highest weight.

As Dr. Pixel pointed out, it just works and ends quietly, except it does unset any selected vertices. I will change that to leave all the changed vertices selected in a future release.

<* Wes *>

So far as I know, pending a better analysis, what the importer is doing now is correct. And that is, the first byte is for morph #1. If there is more than one morph, the digit indicates which data section, 1 or 2, to pull the morph deltas from. The second byte then is for morph #2, and the digit indicates which data section, 1 or 2, to pull the deltas from, and so on (up to 4).

During importing, the sections are recast such that the deltas for the first morph are isolated into section #1, and the deltas for morph #2 are isolated into section #2, and written out that way.

This change was made in V4.03. Prior versions, back to the BodyChop plugins, imported the model differently, relying on any row having a byte of 1 drawing the data from section 1, and any row containing a 2 drawing data from bucket #2. That was pointed out as wrong, and after inspection proved to be so. The reordering of the 1 and 2 should not change the rendering, because the data is also relocated into seperate data sections, instead of being merged into two mixed data areas.

I have tested meshes here, and have not to detected a difference between the size of the fat and pregnant meshes when exported and the originals. Reproducing the original format exactly has not proven necessary to generate an effective output mesh, and would severely limit the flexibility of the plugins, namely creating meshes that do not have to be limited to the mere movement of vertices, but able to be edited in any reasonable fashion, including the addition of unique parts, such as Dr. Pixel's classic Hook mesh.

The part 5 structure has eliminated the redundant zero padding. So far, that has not proven to be problematic with mesh rendering. Until I introduced multiple assignments and weighting adjustable per vertex, the heavy weighting given to the first assignment in the BodyChop plugins gave less flexibility to the mesh and also ensured that all vertices were 100% weighted. Now, some of that burden is placed on the user, although I posted a reweighting plugin a few days ago to arbitrarily reweight vertices to 100%.

So, given that the data that was present in bucket #2 for morph #1 has been moved to bucket #1, the output has the same delta values as the input mesh originally had. As long as the rendering software knows how to find the proper morph deltas for each morph and each vertex, then the output should be consistent with the performance of the original mesh.

If I am wrong in my assessment of how the format is built, then someone else here should be able to detect the error and point it out. So far, that hasn't happened, and there are some pretty sharp eyes looking at the work here. If it proves to be wrong, then I will change it... making the changes involve very few lines of code, but trying to decipher the format and the effects that it has on the rendering has been quite a bit more challenging.

<* Wes *>

Interesting.
I have to admit that I have spent more time trying to write the code for the plugins than I have spent creating new meshes to place in the game. You guys (and gals) have kept me pretty busy tweaking the small things until we get it right.
If you continue to have a problem, you can PM me & get my email address, and email the item in confidence, or post it here if you don't care, and I will attempt to analyze it, too.

<* Wes *>

[QUOTE=cevic
Nothing you need worried about the mesh, your mesh absolutely stunning. I just report a slight problem to Wes. I already made a few meshes of mine and they are have same problem. Since your mesh already uploaded here, if someone else want to look the problem might refer to your mesh.

You're absolute great, your works absolutely apreciated in the community.
[/QUOTE]

I have seen the color differences on several meshes, just like you noted. I directly cannot do anything about it, since the exporter relies on the normals that MilkShape has stored in memory. Since welding and smoothing alters the normals, what gets exported is not the same as what was originally imported.

Smoothing groups were invented to allow meshes to be seperated into various subsections for smoothing operations. My inspection of GMDCs has led me to believe that the original Maxis meshes had smoothing groups assigned when they were created. As evidence of this, look at the seams present in the original mesh.

But that information, while important to creating and modifying meshes, is of no use to the rendering software, and is not present in the GMDC, so what you have is each whole group in a single smoothing group (#1 by default). I tried several times to develop an algorithm for outlining various parts of the mesh and seperating them into different smoothing groups automatically, to be done by a plugin, but never hit on a reliable method of doing so.

Consequently, the user must generate the smoothing group assignments manually. I did develop a plugin that outlines the seams, which would be a good place to start for determining the boundaries of each subsection. I'm a big believer in automating everything possible, but so far have not been able to automate that.

As noted by several users and myself, there is a reason that the vertices in the original models have unwelded vertices in various locations. Some are there because the same point is the boundary between different parts of the UV map, and some are there because a hard transition with averaged normals makes shadows. You need only look back at Warlokk's postings of his work-in-process to see the adverse effects of indiscriminate welding.

You should also be aware that the exporter plugin now carefully examines the mesh, and any vertices that were welded but still have different UV coordinates are duplicated before exporting. However, the dupication is not transferred back to MilkShape, and since one of the two original normals has now been lost, the remaining one is duplicated (since the game expects the number of vertices, number of normals and number of UVs to match). This action is necessary to preserve the integrity of the exported mesh... without it, you get 'stripes' of flesh along the welded seams in the output mesh due to a gap in the UV mapping.

<* Wes *>

Well, I am mystified as to what the root problem with the bone tool and your setup is. But I am glad you found a workaround for now. All that went into 1.7.7a was that MilkShape now unloads the DLL between uses, while 1.7.7 and older kept them loaded until MilkShape was exited. This new behavior broke the bone tool in the first release, because it was leaving a window open when it exited, and when the code was unloaded there was no support for the window, and when it was supposed to act on a message the program crashed because it was leaping into empty space.

This is the first mention I have seen from you of a 'runtime error'. I have seen runtime errors from MSVC compiled programs before. I was writing one plugin and had problems with the floating point library being needed for stdio.lib and the linker had left the fp library out because it wasn't referenced in the main code module (optimized out of existance). The mere declaration of a float data type in the code is not sufficient, I actually had to insert a fp addition operation to force the linker to include the library with the program.

So please tell me exactly what the runtime error says.

Also, on the f_hair, etc. joints, I'm not sure that all of the older hair meshes have the problems, but the newer ones seem to have an additional operation that was done to the mesh that rearranged part of the GMDC to be different from the way it is used with body meshes. Since this special modification does not follow the way all the other meshes are built, and is not currently understood, the only suggestion I had was to not use the _hair joints in a mesh.

I will look for some of your hair meshes and see if I can find a pattern that more clearly indicates when _hair joints are usable and when they are not. But I suspect it has to do with the animation routines used and how they expect the model to be built.

<* Wes *>

Wes I have checked that mesh some more and I am pretty sure that it is just the bone assignments are not right yet.The mesh does actually move when the sim breathes just not the right amount.
I haven't been able to work on it in a few days so the assignments are still pretty off.I will post a copy here shortly if you want to take a look.

Okay let me know when you have it and I will take it back down.

Hi Wes--

I'm at the stage in my project where I need to create a full-body version of my hi-res meshes. Have you considered a tool to allow us to combine a top and bottom separate into one mesh? It seems like it would be possible using the objx files, for example if we took a top.obj and a bottom.obj, combined them into a body.obj, then merged the 2 objx's into one, and applied it to the mesh. I would think MS would simply add the vertex numbers on the 2nd mesh after the 1st, but I haven't investigated. Being able to easily combine top and bottom separates would be a very useful tool to have, I would think... I know it would be for me. I tried Merging the 2 ms3d files, but it lost all the bone assignment information for the 2nd part, which I think you knew. Of course if that can be fixed, this is a non-issue, and I think you mentioned Mete was working on it.

Anyway, just a thought before I go manually recreating my meshes in a full-body version :D

What will kill you is the bug in MilkShape 1.77 and 1.77a which loses the extra bone assignment data and all the weighting data on a file merge, regroup and duplicate selection operations. Were these to be fixed, you would most certainly be able to use a file merge and a regroup to easily put the two subsets together. All the result of an oversight when 1.7.7 was being made (the data is simply not copied over from the source to the new additions).

I have reported these problems directly to Mete. To date, I have seen no other MilkShape customers complain about the bugs on his site. By myself, I am but one voice in the wilderness. Additional reports may help speed resolution.

<* Wes *>

I have it. Thank you.
<* Wes *>

I thought so... I'm running over to the MS forums now... :D

I posted in the Bug Reports section, Wes maybe you or others could post some more detail? http://www.swissquake.ch/chumbalum-...&threadid=17854

I just went and posted in your thread - I would suggest to everybody else that you take a few moments to post there too.

Even if you don't make meshes at all, it wouldn't hurt to make a post - fixing these bugs will make it easier for all the mesh creators to make great new meshes for you to use.

Thanks.
Although you are helping yourselves.
I have put a lot of effort in getting us this far... and I hope it isn't too long before Mete gets these last items resolved.

<* Wes *>

Warlokk,I did get two body separates to work nicely... Just imported top and bottom meshes normaly with the plugins. The bone assignment data is included! You have the bones listed twice in the joits window, simply use delete key and delete the bottom joints. Let me know if that worked for you too.

And thank you all for your work in meshing the sims

Aha, never even thought of that... I'll give it a whirl tonight. Thanks! :D

Simboy-- How did you get the groups to merge? I imported by nude top & bottom, and I have 6 groups that need to become 3 for it to work properly. When I tried the Regroup function it loses the bone assignments.

Can you give a step-by-step of how you did this? I'm at a loss at the moment.

Warlokk, i'ts to late today to get in to it.. let me get back to you on Thursday.. Ok? Will do my best helping you, my master of MESHing...

No problem, I look forward to seeing how you managed this... it could help everyone, this is something we've all wanted to do for a long time.

I know it's not documented very well, but the .objx split file is a text document, and you could probably move the various vertex, face and bone assignment lines and renumber them to place the bone assignments from group 1 to group 0.

Of course this may be harder than remaking the assignments manually. I hate that Mete hasn't fixed the problems with the lost bone assignments yet, but I am at a loss for what to do to speed it up.

<* Wes *>

We'll see what Simboy has come up with, maybe he found something we've overlooked.

Any hope on the Bump/Normal map import/export? Currently Mesh Tool is the only way to modify a mesh and keep them, and we can only move the verts around with that, and it won't work with custom meshes at all. If we can get this working, Unimesh will become the only tool we need, with no limitations.

Warlokk, what I did is: I took your hi-res top and bottom, imported them both into the MS3D. Yeah, it nags about possible problems, ignore that.

Now you do have 6 groups in your groups list. Regrouping these and giving them the proper names, gets you back to 3 groups. Don’t forget to copy/paste the comment boxes too.
You might have to change the MorphRefNum: # according the one that you have with your morphs.

Now, about the joints… MS3D lists all the joints of both of the imported body parts, top and the bottom. So, you have double listing in the joints window. If you check the top of the list, all the vertices are connected to right bones/joints. Yet you have another list of same joints that are not connected to anything. What we do next, is that we delete the secondary list of joints, those that have no assings. Use your delete key after choosing the joint. Now we have only the assigned joints in the listing.

If we now export this as a UniMesh file, we can re-import it back to MS3D. So, it works properly.

Now I open the SimPE and make a new swimwear mesh, add the new GMDC to it and bind the mesh to a skin… Starting the game and waiting for what happens next….

Yes, we do have a new mesh in the game.. But we need the GMDC-tool to smooth it out.. I get sharp shoulders and some another problems.

I have managed to build new meshes with this method. Like Marvine´s new Alpha-skirt with Zenman’s top or Xenos’ Female muscle top

Cool, I'll check it out again tonight... when I tried last night, I just deleted all the joints in the second set, but I didn't check to see if they were assigned, I may have just deleted the wrong ones. When I was done all the verts were unassigned.

This may not be the right place to post about object related issues, but I got no replies to a separate post I made in The Sims 2 Tools forum about this a while ago, so I thought I'd give it a try here.

I used to be able to use the old plugins (I think version 216) and an older version of Milkshape before just fine. Now, when I recently tried to do the same with a toilet seat, there seemed to be a problem with no vertices being assigned to some of the joints. So, I updated to the latest Milkshape and the Unimesh plugins, and tried again with the same toilet. This time, I kept getting an error upon importing the GMDC to Milkshape about "Null bone assignment ptr". And when it was done importing, only the shadow meshes were there, not the actual object. I have now tried it also with a couple of other objects, too. With a barbeque, I get the same error message. With a fridge, I get an error message about "Null skin weight assignment ptr", and the same problem that the object mesh doesn't import. The only object I've been able to import without problems so far is an armoire. I'm wondering if I'm just simply doing something wrong and not realising it? Any idea what could cause this?

I don't always get to that forum... this thread is for the UniMesh plugins, whether used for Body or objects. Looks like the right place to me.



It looks like I have missed some 'regression' testing here. The objective was to have a 'universal' plugin for all mesh types, but in the combination of the 2.16 and the BodyChop plugin functions I have likely missed something. The checks for the errors you cited were implemented to ensure integrity for Body-type meshes. I must have left a control path for non-boned objects out.

Thanks for the report. I'll get on it.

<* Wes *>

If it didn't nag, someone would complain to me that it messed up their mesh because I didn't warn them. I chose the warning as opposed to blocking the action because there are some uses (as you have discovered) for importing a second mesh. But you gotta know what you're doing...



Square shoulders sound like the secondary bone assignments and skin weights were lost by MilkShape when you did the regrouping (a known problem with 1.7.7 and 1.7.7a). We have tried to get Mete to fix that bug in MilkShape, but so far no new release yet. When that gets fixed, you should be able to use your method with better results.

<* Wes *>

Thank you Wes, I figured that out by compairing two meshes one in 1.7.7 and another in 1.7.6.. "its not in our hands.. it's in the bigger hands..." Have done this for only a month now.. But getting really Hooked Up with meshing, thanks to you guys. You Rock!