Ack! that was stupid of me for not considering other monitor resolutions. Knowing what resolution you are using would be really helpful to me for making a fix.

The body models issue is sort of complex with Sims3; First, the face, scalp, body top, and body bottom are split into several different files; so it will take some time to compile these into .obj. Next, is that Sims3 uses a format called GEOM that has its UVmap interlaced (someone should correct me if I'm wrong, since I try to avoid messing with the UVmaps), so the uvmap would also be in separate pieces. Lastly, (and it should't be an issue for you, since you would only be using the .ojbs for textures) is that the GEOM files carry an extra data table used for morphs that sometimes gets lost when saving as .obj.

The bu, pu, and cu thing can be easily understood with some background info on the naming convention for sims3 files. For any file dealing with the mesh of the sim itself, it uses a 5-part name system. The first letter indicates what age group it belongs to-- b for baby, p for toddler, c for child, t for teem, y for young adult, a for adult, and e for elder. The second letter indicates what gender uses the file-- f = female, m = male, u = unisex. The third part indicates what part of the mesh (Body, Face, Scalp are seen here but there are others including Top, Bottom, Shoes, etc) The fourth part of the name usually gives a specific name, but for these files it is omitted. The fifth part of the name is always preceded by an underscore, and indicates a subtype (subtypes for the skins files are: a = ambient, d = diffuse, m = mask, n = normal, o = overlay, s = specular; however a/d files are not used.)

Because both male and female children use the same skin files, it is inappropriate for genital details. Others that have done skins for child sims usually just try for better physiological looks (i.e. details on the collar bones, better knee-caps, etc).

While on the subject of anatomically correct sims, it may be beneficial to your effort to go over to the adult site (link at top right, separate registration required) and look for the DBCAB recolorable male anatomy. These have an additional UVmapping for the parts, and DBCAB has given a map file in one of his posts showing where.

Your understanding is correct, sims teen through elder all use the same skin files for the body. Elder sims get an extra layer added to their skin (called weathering) that is separate from the skin files. As it is now, making body skins specifically for teen or elder would not be of any use. Face skins is different though; Teens use the y faces and elders use their own faces.

Just an observation. I recall you talking about how the mannequin skin might refer to the ghosts? I believe it does, it seems no matter which skin defaults i use, my ghosts all look like the default skin. So i believe thats some proof that youre right.

Now that I think about it I think your right too, since white on the ramp gradient represents transparency and the mannequin ramp is ALL white.......
Stop those ghosts from getting un-ghostly nasty flesh colour's.

Agreed. But doesnt a default skin affect all tone ramps? Forgive me if im wrong, but shouldnt it also affect the ghosts??

There is probably a flag in the programing for the state change into ghost that will change it. I can't really say though it's just my speculation.

Oops Guys. Nother Observation. Although you probably already know this one.



The smaller image that i believe you are referring to is the thumbnail. For example, If you look at the Alien Tone Ramps in file format, you'll notice that it is actually darker than its actual tone ramp. I guess EA wanted us to believe something else

Here's my take on the structure of the tone files. Incomplete, of course.

dword version (4)
dword offset to TGI
dword ?? (close to TGI size)
dword repetion count (5)
--count:
----dword universal age/gender mask
----3 bytes flags?
----dword ?? unknown (255)
----6 bytes unknown (FF 00 00 80 40 00)
dword 0
dword 1
dword repetition count (19)
--count:
----dword age/gender flags
----dword type (2=scalp, 4=face, 8=body)
----repeat 5 dword index into TGI list (zero-based)
(Baby face and body refer to the same TGIs. TGI #6, which is blank, appears to be used as a filler.
Child face and body have separate entries for female and male but both point to the same TGIs. (Interesting possibility of separate male/female child skins!)
Ages teen-elder use the mask value 0x78 in the age/gender flags; teen & YA mask to 0x18.)
byte 0
dword TGI count (74)
--repeat count:
----TGI

Skininator is making progress. Tomorrow I'll finish the code to write packages and start testing.

I am no coder, so most of that post didnt make any sense to me. Hah!
As I said before, if you are looking for other people to begin testing, I am very willing Cmar!!

Most of the default replacement skins that have been release so far have only changed the _m files. The mannequin tone doesnt have any _m and only uses the specular; so that would be why you havent seen any changes on ghosts.

From my understanding, the third dword should always be the TGI size; if it appears smaller than you think it should, its probably not counting the empty TGI, if its larger it may be counting the size for the non-existing cm/cf.
For the three flags, I think I can account for two of them; one should be for 'usable in CAS' (can be checked by comparing to mannequin), and the other would be 'valid for random' (check against blue/alien/red)
The 255 value might be a float; there should be at least one float value since the game sorts the tones in an order that doesn't match the instance values of the tone files.
The unknown byte looks familiar to me, 0x00408000 seems like I should know it from somewhere...
Which tone did you pull the info from?

EDIT: I checked the TGI size and offset, it's correct. The offset places the size start at adr:286 (the start of the TGI count). So the count given in the third dword is 1188, so we get:
[74(#of TGI)x16(size of each tgi)]+4(the size of the TGI count) = 1188

I see what you mean about the ghosts, Rez. Suprisingly, it actually made sense! So technically, someone could make a ghost default replacement, just by a different way of going about it?

I cant wait for more updates! This is coming along great.

You're right - for some reason my hex editor wasn't showing the last line of 11 bytes in the file. Yep, TGI size.



For what it's worth, normal, redtone, and yellowtone all have the same set of flags, while red, blue, alien, and mannequin all have the same set of (different) flags. So I don't know about 'usable in CAS' but 'valid for random' makes sense. Possibly there's values for inheritance?



I doubt the 255 is a float since the value (3.57331e-043) doesn't seem meaningful, but I think the 00 00 40 80 (which seemed familiar to me too, and there's a similar float of 1.0 in the blend files) is your float:

dword repetion count (5)
--count:
----dword universal age/gender mask
----3 bytes flags?
----dword unknown (255)
----byte unknown (255)
----float amount (4.0)
----byte (0)

Certainly worth seeing if changing that 4.0 does anything.

I got this from the normal tone, but except for the flags the others seem identical. Even for the mannequin the headers look the same. On the other hand I'm looking at this early in the morning on about six hours sleep.

The thought occured while I was trying to avoid getting out of bed, that by writing out a different set of age/gender flags and TGI indexes it may be possible also to have separate skins for teens and elders. Something to try at some point, anyway.

Fawkes: I hope to take advantage of your offer by tomorrow, soon as I have code that writes a usable package!

Thats great Cmar! Im reading through this and things are making *slight* sense. And Im so happy that this will be soo soon!! Kep up the good work!

Rez, Thanks so much for answering my questions about the body files....Unfortunately I guess that's not quite enough (it's NEVER simple lol). I spent all night last night searching out af top and bottom geoms and figuring out how to convert them to .obj - but alas - I find no UVmapping in those files.

I have a couple more guesses I'm going to try at today. It seems there is no meshing tutorial involving the actual sim bodies - which are far different than objects you can just clone and remap. BUT people have edited them (I've seen bigger boobs downloads) so it is possible.

Anyway this doesn't really stop me, it just limits me from using a better program for making the textures, and MUCH FASTER. I had the desire to actually make this set very high quality, but after today if I haven't gotten anywhere on getting these UVmapped meshes out of the game then I am going to have to do the plain ol generic edit in photoshop on the M map.

I guess anymore this only relates to this thread in that I do plan to make the entire set and link it to this utility somehow. After this unless it is directly related I will probably create a new thread.
Again thanks for all the help - and if anyone does come across the info I need or knows someone who may have the info I need PLEASE let me know

The best advice I can give you is to get Milkshape. It's not free, but it's cheap, and I believe it'll convert to obj format. Don't know if that process preserves the mapping, though. Possibly more important, it'll show you and let you edit the UV map, and will texture the mesh. Milkshape is what the majority of Sims meshers use so more people would be able to help you, too. On the downside, you may not want to learn a whole new meshing program.

BTW, the bigger boobs isn't a mesh change per se, it's a bone delta morph. There are plenty of people working with meshes, though. Unfortunately the excellent tutorial Wes wrote for beginner body meshing for Sims 3 seems to not be available anymore.

Actually converting to .obj wasn't the problem. The utility "Postal" does that for the .geom files. I use a program much better for these purposes than "Milkshape". I am familiar with Milkshape but I use C4D and Bodypaint. The reason I was wanting to find the Uvmapped .obj files is because in C4D+Bodypaint I can paint right on the 3d figure which works out excellently for body textures because it removes the problem of seams. If Milkshape is able to load the .obj and uvmap of the original items than the programs I use should be doing the same. I can get the .obj to load, but it loads in unmapped. From what I understand from Wes tutorial is another type of file modl contains the mapping information. I just need to find those files now and see what I can get. Right now I do have the .obj files for both aftopnude and afbottomnude. I just need that dang ol uvmap.



I did read through all of the tutorials for sims meshing that I could find. Including Wes's but they all seem to deal with object meshing and exports and then what they do is create a new UVMAP for the object (or it appears this way) and then import it into the game. The problem I have with that is that I am not wanting to create a new UVMAP - I want to work with the current ones. I need the sim body so that I can see the changes I make to the texture in real time, instead of having to reload the sims each time I make a change to see if that looks good. I WILL eventually figure this out - just a matter of finding the right people to ask lol.

And thank you so much for taking your time to try to help me with my problem. I really appreciate the effort.

One of the few things I do know about Sims 3 meshing is that the UV coordinates are definitely included in the geom files. (This depends on the exact format of the file - morph meshes have no mapping; I imagine a few others don't also.) If UV is missing from Postal's obj exports, presumably the program doesn't convert all the data. I think it's worth a try to convert them using Milkshape. In fact, when I get home tonight I'll grab the afnude top and bottom, convert them with Milkshape, and post them here for you.

Wow that is a REALLY nice gesture on your part - but another kind person did offer me the files already Hystericalparoxysm was very helpful and zipped up all of the files for me that she/he already had. One thing I am still missing though is the feet file. EA has it listed as shoenude, which can kinda throw you for a loop. So if you happen to have that file I do still need it.

Yeah the file export process was obviously messing up somehow because the files that I got from Hysterical had UV attached just fine. I don't understand what was going on with the others. Very frustrating process to say the least. As least I can rest easy knowing once it is done once than it never has to be repeated Halleluia!!!

**and now for a nap my 8 hour workday was officially over 2 hours ago** I'll be back at it again this evening though.

velocity, the files I uploaded that had the bodies included the feet - the parts are considered separate mesh-wise but there's no difference, skintone-wise, putting the mesh together or splitting it apart since the uv map is seamless between the parts. I actually exported those originally for skintone making - I use Milkshape to preview rather than wotsitthingie you use - it's not as good since you can't paint right on, but it does allow me to see near-enough-instant updates in 3D.

I see in the tutorial screenshot that you've made the slider represent hue rather than brightness. You also mentioned that the color ramp is just an overlay over the skin texture. Does this mean one can make the slider represent something other than color? For example, what if I wanted to make the slider change the muscle tone of the sim. Could I put a regular EA texture on the left end of the slider and a muscular texture on the right?

Okay, here's the first test version of the Skininator. Unzip both files in the same folder and run Skininator.exe. The help and the project open and save aren't done yet, so those choices do nothing.

To use: Fill in a name for your skintone and use the buttons along the left side to pull up screens to let you import the different kinds of texture files. Use the top button in the list to load the ramp files. If you load a new ramp you have to also load the png ramp thumbnail. Then click the button to create a package, stick the package in your game, and if you've also installed Rez's CAS skin tone expander you should get a new skintone button.

The order of files in each screen needs work, and I need testing to see if I got all the files in the right places. The skintones don't seem to be in any particular order - we need to experiment with that and with making the thumbnails more recognizable. Oh, and the checkbox for 'non-standard' will make a tone file with the flags used for the red, blue, alien, and mannequin skins - presumably there's some difference. Maybe those skins don't show up on townies and NPCs.

You see my quickie test in the pics below - a new skin and by contrast HP's skin which is my default replacement. And now I'm totally pooped and off to get some rest. Let me know your results/problems/bugs you find!

** Edit to add: Only import the textures you want changed in your new skin. Anything you don't supply a new texture for will use the default.

** Edit again: I've had a little luck making the new skin identifiable. By printing my name across the gradient from top to bottom and stretching the text to cover the 64x64 png image, it shows up sort of legibly in the slider bar.

** Yet another edit: Skininator is updated; please get it from reply 106 on the next page.

You could definatly do that since there are texture files for light and dark keep the light end for normal and dark end for muscle, if you were to do that and you also wanted to keep light dark variations then it would probably be best to do something simirar to my duo tones but with added textures. It might be a bit odd if only dark sims were toned.

Only just tried your stress test Rez and it was fine in my game, my resolution is up full though.

Excellent! Skininator is out so fast for an alpha test; its amazing how fast you've worked Cmar. Now I just have to make some skins so I can try it out.

Anyways, I got a new version of the UI mod. I think everyone will like this better. Instead of just expanding it, I completely moved it instead. This one is 5x10 and expandable with a scroll-bar and, has been relocated to the immediate right of the CASBasics window and up about 250 pixels up from its previous location. Resolutions of 1024x768 or smaller will have a slight issue with the box overlapping the sim, but the box closes, so.... meh.

I'm gonna be updating the old 5x5 mod in the morning so it will have a nice scroll-bar, in case anyone has any serious complaints about the relocated one.

Also, if anyone has any ideas on how to make the UI mod even better, I'm open to ideas. The more stuff I try in the UI modding the better I get at it, so I'm willing to consider trying anything.

Again, the same rules apply for this file--testing only, no distributing, not a core mod, won't crash your game, remove any old one before putting this one in, and you know what mods conflict with it.

Have fun making new NDST's everyone!

Edit: Welcome anyone coming here from Fawke's skins DL. To clarify, (as was mentioned in an earlier post) This is a testing file; please do not distribute. The final versions will be uploaded to the moderator queue later this evening; at which time when they are available on the DL page, please re-download (or at the very least, post a thanks). These are default replacement layout mods. They specifically contain the CASBasics.layo (0x97DB9E9DDA2D2671) file. It is not a core mod. Layout mods will not cause your game to crash.

Known Compatibility: Awesomemod and EGC both work with this mod.

Known Conflicts: Drakah's Slider limit increase mod; Rick & Delphy's Slider Hack(depreciated).

Version Info: these mods are known to be compatible with 1.7/2.2 and have been tested and confirmed to run with 1.8/2.3

If anyone does run into additional conflicts, please let me know by sending me a PM.

Edit2: The UI mod has been removed from this thread. It is now available in the downloads section here. Thanks everyone for testing.

I'm kind of surprised myself! Didn't expect my first skin attempt to actually work. Anyway, all the really hard stuff was already written for MorphMaker. Now comes the tedious part - testing that every one of those 74 TGIs is being written correctly.

I also had the issue of the tones box being too big, so can't wait to try out your new version.

Wow things are really moving along here. I'm still trying to sort out how to do things, but if I'm understanding it right, Cmar's tool should really help.

The stress test worked in my game, I have the highest possible resolution.

I'll continue to be a happy guinea pig while all you clever people figure out the hard stuff.