Replies: 24 (Who?), Viewed: 5401 times.
Ms. Byte
Original Poster
#1 Old 19th Sep 2009 at 1:53 AM
Default Tool to create files for modified/new morphs
BGEO files appear to be what the game uses as morph data, at least for CAS body parts. This is a standalone command-line executable which will take modified morph meshes (GEOM morph files) and generate a new BGEO file which the game will recognize as a modified or added morph. It runs only on Windows (sorry) and in a command prompt window. You can cut and paste filenames or just drag the files into the window. All three lods are required to make a complete BGEO file, along with any sub-lods or whatever you call them - lod1-1, lod2-1, etc.

There are two versions: MakeBGEO makes a new BGEO file; MakeMorph also creates a new VPXY file with links to the morph mesh GEOM files. So far I've seen no indication that the game uses the morph VPXY or GEOM files, but who knows? I'm including them in my packages just in case.

The source is included, written in Fortran. If anyone would be interested in making a more user-friendly wrapper or translation for the code, just let me know. At this point I haven't the skills to do a nice GUI.
Download - please read all instructions before downloading any files!
File Type: zip Morphs.zip (446.6 KB, 235 downloads) - View custom content
Description: Morph creation programs
Advertisement
Sockpuppet
#2 Old 19th Sep 2009 at 1:34 PM
Can you clear up a few things?
I am trying to test this out with one of my meshes, the Aftopbra_strapless.
The first thing it askes is the instance ID but looking at my bgeo files in Postal i have 4 diffrent ones.
One for the aftopbra_strapless_fat
One for the aftopbra_strapless_fit
One for the aftopbra_strapless_thin
and one for the special/pregnant version, wich one i fill in?
0xace5423f395c751a fat
0xace53a3f395c67a2 fit
0xe7d3372537bf419a special
0xab2b726e32135278 thin


Acording to the VPXY files there is one bgeo file for every morph.
Like the Fat state contains Lod1_fat/Lod2_fat and Lod3_fat.

When i have add the 4 necesarry files(i think, because i can not add all 12 as there is not enough space) how it find its path to the files?

If it doesn't need links to the files then i must install your proggy in the same folder as were the geom files are located?
How does it find its path to the files?

I am prolly a noob to all this but can you plz make it a bit more clear?
Ms. Byte
Original Poster
#3 Old 19th Sep 2009 at 2:16 PM
Okay - first, this program is intended to modify one morph. (At a time. ) You're talking about the 4 morphs that come with every CAS clothing part - fat, fit, thin, and pregnant. (Pregnant is not actually present in most of them, but the 'empty' files for the morph are there.) In order to use my program, you should be modifying ONE of those morphs, and therefore would give it the instance and your modified meshes for the one you're working on. It will generate a new BGEO file to replace the one from the game.

What are you trying to do with the afTopBra_strapless? You should be working on one of the morphs, and by the time you use my program you should have used Milkshape or Blender to make changes in the morph meshes. There are three lod meshes for each morph, and there may be 'sub-lods' (lod1-1, etc.) so you feed the program those 3, 6, or possibly 9 files. For example if you're modifying the fat morph for the strapless bra:

Instance: ace5423f395c751a (don't include the 0x)
Morph meshes:
afTopBra_strapless_fat_lod1
afTopBra_strapless_fat_lod2
afTopBra_strapless_fat_lod3

If there's more than one file for each lod:
afTopBra_strapless_fat_lod1
afTopBra_strapless_fat_lod1_1
afTopBra_strapless_fat_lod2
afTopBra_strapless_fat_lod2_1
afTopBra_strapless_fat_lod3
afTopBra_strapless_fat_lod3_1

The lods are Level Of Detail - lod1 is the nice, detailed closeup view, lod2 is from a distance starting roughly close to but outside the house, and lod3 is from about as far away as you can get. (This may vary on different computers - I don't know.) Unless your change to the meshes is fairly conspicuous lod1 may be all you'll need to worry about, but you still need to give my program the lod2 and lod3 morph meshes, modded or not.

Lastly - if you drag each file to the command line window, the name should appear complete with the path. The program will use the path and create the new BGEO in the same folder as the mesh files.

Hope all that helps! If you're not familiar with how the meshes and morphs work, and the underlying file structure, it's going to be confusing. Stick with it and you'll get it in no time.
Sockpuppet
#4 Old 19th Sep 2009 at 5:06 PM
yup that made sence thank you

I do know my way arround when it comes to meshing and morphs.

I only could drag 3 files into the window because the files were in subfolders.
After the 3rd file i could not add a 4th one as you prolly have set a max number of lines for adding the files.
sofar i did everything correct, i will move the files in just one folder on my disk.

I am srry, english is not my native language.

I added nipples to the bra mesh(and morphs) but they deform when using the sliders
Ms. Byte
Original Poster
#5 Old 20th Sep 2009 at 12:39 PM
Quote:
Originally Posted by Base1980
yup that made sence thank you

I do know my way arround when it comes to meshing and morphs.

I only could drag 3 files into the window because the files were in subfolders.
After the 3rd file i could not add a 4th one as you prolly have set a max number of lines for adding the files.
sofar i did everything correct, i will move the files in just one folder on my disk.

I am srry, english is not my native language.

I added nipples to the bra mesh(and morphs) but they deform when using the sliders


I see - you have the right idea of changing both the base mesh and the morph meshes so they have the same vertices. However, since the BGEO files used for the actual morphing have all three lods combined in one, if you've added vertices it's likely that there's some overlap of the vertex numbers between the lod meshes. I don't know firsthand the effects of having the same vertex number in two lods but I suspect it isn't pretty.

One of the projects I want to take on is a tool to renumber mesh vertices, to handle exactly this kind of situation. That's going to take time to develop, though.

Take a look at this thread: http://www.modthesims.info/showthread.php?t=355471

Morgade did the same kind of thing you're trying to do, using a plugin he wrote with Blender instead of Milkshape and keeping the original morphs. That might be something to try if you can use Blender.
Sockpuppet
#6 Old 20th Sep 2009 at 3:32 PM
Oh, i thought this tool would actual fix the added vertices by recreating the BGEO files..

The Blender plugin doesn't fix them either as it only duplicates the nearest vertID.
With Wes his GEOM plugin you can do the same but his extra data tool gives you the opportunity to change the vertID to one you prefer.
I just got to be patient i guess.
Alchemist
#7 Old 21st Sep 2009 at 2:23 AM
Automatically renumbering the vertices while loaded in MilkShape is certainly something I could do; I could make all of the VertexIDs for all the morphs the same as the base (or complain if the face list and vertex count are not all the same). I could build that into the CCTool plugin, and pretty easily.

What I haven't ever finished researching is what number ranges we should use. I do know that your seams will not match if your VertexIDs at the edges do not match the originals, but that may just mean they have to match what was used in the BGEO file.

I have noted that the body seems to use the 5,000 - 6,999 range, and the feet start at 30,000. I also noted that vertices that are duplicated because they are split (the seams) have identical VertexIDs. I can handle renumbering to accommodate that also.

If you guys have some additional observations/insight on this I would like to hear about it. I have just never gotten enough research done, because I started doing object mesh work and of course that project swelled to consume all available time, although it is now pretty stable.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#8 Old 21st Sep 2009 at 2:36 AM
Maybe it is easier to just continueing?
Like a top mesh i have has a highest vertID of 6493(took me a while :D)
Then you do not have to worry if the top ever will fit another bottom or match the head etc

I think there should be a easy way to check wat the highest vertID is?
Then count from there?
Alchemist
#9 Old 21st Sep 2009 at 7:05 AM
As I see the choices, we can start with the highest and continue.
We can start with a specified value and renumber all.
In both cases I can treat extra groups that are loaded as morphs, and make them be the same, vertex by vertex.
And in the process, I can make all the duplicated vertices share a single VertexID, as the game does.

I think the two ideas are to add new numbers, and the other is to start over again.
And I think we want to make it so that the morphs get the proper vertex/face list checks done, passing those they will get numbered just like the base mesh, because that is very important.

I want to see if CMar or Delphy have any input before I code this and we test, but I don't forsee any difficulty producing it pretty quickly.

If you like to say what you think, be sure you know which to do first.
Ms. Byte
Original Poster
#10 Old 21st Sep 2009 at 2:22 PM Last edited by CmarNYC : 21st Sep 2009 at 9:21 PM.
Quote:
Originally Posted by WesHowe
Automatically renumbering the vertices while loaded in MilkShape is certainly something I could do; I could make all of the VertexIDs for all the morphs the same as the base (or complain if the face list and vertex count are not all the same). I could build that into the CCTool plugin, and pretty easily.

What I haven't ever finished researching is what number ranges we should use. <* Wes *>


What I've seen from examining the BGEOs is that the numbers run sequentially through all three lods. (I'm only talking body, top, and bottom CAS parts here, haven't looked at the faces or other clothing items.) They seem to start at 5000, although I could swear I saw one starting at 15000 - could be wrong. My best guess is that any deviation from that sequence of numbers through the lods will break the morph.

The problem is that if you add vertex numbers in lod1, you have to not only renumber all the lod1 morphs to match, but also renumber all the vertices in lod2 and lod3 in the base mesh and all the morph meshes so that the numbers don't overlap or leave a gap. I don't know what this would be like to do in your Milkshape plugin. An external tool might be best since a minimum of 12 files are involved, 15 if the mesh has a pregnant morph.

I guess the ideal would be a tool that extracts all the meshes with a standarized file naming protocol, lets you add vertices to the base, adds the new vertices to the morphs and renumbers all the other files, lets you work on meshing the morphs if desired, and then imports everything back in. Basically a CTU for more extensive changes to the meshes.

Using duplicate vertex numbers in the base mesh to avoid this is what Morgade did, and works for smallish mesh changes. You then leave the vertices in the morphs alone, other than moving them, and the corresponding vertices in the base all move the same when the morph is applied... I'm pretty sure that's what happens. I don't think adding vertices with duplicate numbers in the morphs would have the expected results since the game seems to only find one instance of any given vertex number in the BGEO file. (I'm by no means sure of this, though, just a guess based on the list of offsets to each vertex in the index and flags word list that the game definitely uses to find morph vertices. When that list of offsets was off, I got the mother of all mesh explosions.)

It might be helpful to take a look at the GEOM file of the amBottomNude mesh with the - er - added part. Since the extra vertices don't move with the morphs (which works well for this particular modification) yet don't mess anything up, my guess of how it's done is that the vertex numbers of the addition are not in the range of the original lod1 through lod3 meshes. That way, when applying the morph the game would ignore those vertices. (I'll look for myself but my GEOM reading tool only reads morphs - I have to put in some time to rewrite it - but I think you already have a set of GEOM reading tools.) This could be a good workaround for additions to meshes that don't have to be morphed.

If you're getting back to the plugins could you take a look at the way the latest version handles morph meshes? Whenever I save a morph with it, the file size is WAY too big and they won't load back - incorrect vertex count. Also a little suggestion/request for whenever you have time - an option to save as a morph (when a mesh is loaded over a matching base) to save the user having to change the group comments.

Here's part of my readout of a BGEO file:

S3_067caa11_00000000_4e6bea76a422125e_amTopNudePuka_thin.bgeo

(various headers)

First vertex number (lod0?): 0
Number of vertices: 0
Number of coordinates: 0
First vertex number (lod1): 5000
Number of vertices: 1413
Number of coordinates: 2558
First vertex number (lod2): 6413
Number of vertices: 740
Number of coordinates: 1540
First vertex number (lod3): 7153
Number of vertices: 332
Number of coordinates: 951

Then the word list of offsets to the coordinates for each vertex. etc. The complete file is attached.
Download - please read all instructions before downloading any files!
File Type: zip BGEOdata_amnudePukaThin.zip (46.2 KB, 138 downloads) - View custom content
Description: Text readout of BGEO file
Alchemist
#11 Old 21st Sep 2009 at 10:15 PM
V0.14 breaks morphs if you have unsplit UV seams. V0.15 (recently uploaded) does not do this, but it will refuse to export the mesh until you fix it. I don't see any good automated way to split vertices automatically, because of issues keeping everything in sync.

The original meshes use the same VertexID on these splits, which are at the seams on the UV map. The GEOM file format (and many others used with DirectX) pairs the position, normal and UV in sets. In order to have different UV coordinates on face points that are coincident, separate vertices need to be created. While I say pairs, some meshes have more than one seam at certain points. If I just export the unsplit vertices, one of the UVs will be lost, and the texturing will be hosed. If I try to split them automatically (as I do on object meshes) we get these morph sync problems.

So as a process an automatic renumber would, theoretically, require you to load lod1 and all its morphs, specify the starting value (5,000) and hit the button, and the tool would report the ending value.

You could subsequently load lod2 plus morphs, specify a start value of ending+1, and hit go, and repeat this with a new start point for lod3.

Anyway, I think that is a viable solution, perhaps not the optimal one. But when all of the files for each lod are loaded, making each VertexID match between morphs is not difficult, because you can trace them by following the face list... the face lists have to match, or the morph is broken.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Ms. Byte
Original Poster
#12 Old 21st Sep 2009 at 11:04 PM
I missed the release of V0.15 - sorry about that and thanks for pointing it out. The morph export in that seems to work fine. I haven't done any work with seams so I don't follow everything you're talking about, but I'll get there eventually.

Yes, the method you describe for using your plugin for renumbering sounds very viable. I assume the user would have to create the identical vertices and faces in the base mesh and all the morphs and get them where they want them, then do the export and renumber, then take care of the other lods. That may be as close to optimal as possible and would be much better for most users than the kind of command line tool I could make at this point.
Alchemist
#13 Old 22nd Sep 2009 at 12:32 AM
Well, I will start it. I thought of it long ago, but never had the research to know what the heck I should be aiming at. And given the work you did, I would not have had any visible results from my testing anyway.

The seams issue is one that people will run into if they are making new meshes and parts, as opposed to just moving vertices. If you run into it later, we can handle it in the plugin forum. There is a way to do it, it is just that automating it does not seem to work properly.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#14 Old 22nd Sep 2009 at 4:45 AM Last edited by Base1980 : 22nd Sep 2009 at 5:02 PM. Reason: adding screenshots
Sweet to hear you 2 talk :D
I am very exited as i know that when this is solved every thing can be made.
It is all in those 2 files(bgeo and geom) as you can easily swap the morphs.
Tried it and as long as you swap the bgeo file it is working perfect.


Edit,
Amazing, thank you for making this!!
I was able to recreate the fit state( give her bigger boobies), edited the morph and created a new bgeo for it.
Also found out wat i was doing wrong....
I was convinced i had to add the files like lod 1, lod2, lod 3 and then enter.
But you have to add them one by one....srry
Screenshots
Ms. Byte
Original Poster
#15 Old 2nd Oct 2009 at 9:57 PM
Very cool, and some interesting effects there!

BTW, I've found a GUI package for Fortran and am currently working on a more friendly interface for this tool, and for a similar tool for facial morphs.
Forum Resident
#16 Old 9th Oct 2009 at 2:49 PM
So those tools enable you to create a new BGEO and VPXY... This is great, but is there a way to extract a mesh's fat/fit/pregnant morphs to an exploitable (GEOM) format? So far I've only been able to extract them to BLENDGEOM/BODYBLEND format and I can't modify those in MS3D nor use them as references to position my vertices right.
Ms. Byte
Original Poster
#17 Old 9th Oct 2009 at 8:00 PM
Quote:
Originally Posted by The_French_Sim
So those tools enable you to create a new BGEO and VPXY... This is great, but is there a way to extract a mesh's fat/fit/pregnant morphs to an exploitable (GEOM) format? So far I've only been able to extract them to BLENDGEOM/BODYBLEND format and I can't modify those in MS3D nor use them as references to position my vertices right.


You can't directly edit the BGEOs. Work with the morph meshes - you can find and export them with Postal. The morph meshes are GEOMs named with a _fat, _fit, _thin, or _special (pregnant); for example "amTopNudePuka_thin". Click on the 'Hex View' tab and then Export. To use them in Milkshape, first import the base mesh and then import the morph on top. They will show in Milkshape as two groups and can be exported separately.

To make an entirely new morph, import the base mesh again on top of itself, then open the group comments for the second import and change them to:

FVFItems: 3
TableType: 0
References: 1
TGIRef00: 00000000 00000000 00000000 00000000

Make your changes and export.

In both cases, be sure to hide your base mesh while you modify the morph - Wes's export calculates the difference between the two meshes and if you've modified both you'll get a morph that does nothing. (Can you tell I've done this more than once?)
Forum Resident
#18 Old 9th Oct 2009 at 8:35 PM Last edited by The_French_Sim : 9th Oct 2009 at 9:37 PM.
Thank you, Cmar, I finally found the morphs. I'll report back later on any progress made.

(For your information, I'm trying to make a sandwich board.



And the sim's build here plays a very important role in whether it looks good or out of place!)


EDIT: Ok, I think I'm not smart enough to use that programme. I'm never quite sure which files to input, and the window closes on me too fast when it displays a message. I believe I'll just wait till the programme is more documented.
Sockpuppet
#19 Old 10th Oct 2009 at 11:41 AM Last edited by Base1980 : 10th Oct 2009 at 11:52 AM.
I dont think we can make bGEO's for custom meshes yet?
Why not try to give the board the same vertID's as the front belly(one vertID for the whole board)
Clone a accesoire and try, but make sure you use format 7(accesoires are set to 6)as format 7 supports the vertID settings.
I already made a belly button ring that way, works perfect


Edit,
i must say i used TSR workshop wich kills the vpxy files, maybe thats why it is working........



@CmarNYC, is it possible to load a not working pregnant(special) vpxy into the thin/fat and fit vpxy's?
That way you can let them stop working?(when using accesoires without new bGEO files)
Forum Resident
#20 Old 10th Oct 2009 at 1:18 PM
Quote:
Originally Posted by Base1980
I dont think we can make bGEO's for custom meshes yet?
Why not try to give the board the same vertID's as the front belly(one vertID for the whole board)
Clone a accesoire and try, but make sure you use format 7(accesoires are set to 6)as format 7 supports the vertID settings.
I already made a belly button ring that way, works perfect
Thanks, but I have no idea how to set the format right or give vertices a vertID (bone assignments, yes, vertIDs, no :/). Would you mind posting a how-to, maybe in another thread if it'd steer this one off topic? Thanks in advance.
Sockpuppet
#21 Old 10th Oct 2009 at 2:28 PM
Wes H his GEOM plugins come with a extra tool, the extra data tool.
You find it under the vertex menu in Milkshape, it works the same as his boneassignement tool.
If you select a vert you can view its vertID, wich is used for the movement(sliders) between the morphs.
By copying that vertID on to your board it will move along with it.

When a accesoire is cloned the format is set to 6 (by default) it is the top line when opening the comments from the mesh in milkshape(FVFItems: 6)
But 6 doesn't support vertID's so you have to change that number to 7(like on bodymeshes)
Forum Resident
#22 Old 10th Oct 2009 at 4:54 PM
Quote:
Originally Posted by Base1980
Wes H his GEOM plugins come with a extra tool, the extra data tool.
You find it under the vertex menu in Milkshape, it works the same as his boneassignement tool.
If you select a vert you can view its vertID, wich is used for the movement(sliders) between the morphs.
By copying that vertID on to your board it will move along with it.

When a accesoire is cloned the format is set to 6 (by default) it is the top line when opening the comments from the mesh in milkshape(FVFItems: 6)
But 6 doesn't support vertID's so you have to change that number to 7(like on bodymeshes)

Alright, thanks. I'm noting, however, that there's no "apply to all" button. Another of my accessories, which requires that vertID modification, has about 3000 vertices. Since changing the vertID for 3000 vertices individually sounds rather tedious to me, I guess I'll need to write a PM to Wes for him to (if possible) add the feature.
Sockpuppet
#23 Old 10th Oct 2009 at 7:57 PM
true...i already asked him, maybe in the next version....but the board itself should not have more verts then like 50 or 60.(its just a box with 2 seams?)

edit,
srry CmarNYC for hijacking this thread....feel free to delete these posts!!
Forum Resident
#24 Old 10th Oct 2009 at 9:12 PM
Quote:
Originally Posted by Base1980
true...i already asked him, maybe in the next version....but the board itself should not have more verts then like 50 or 60.(its just a box with 2 seams?)

edit,
srry CmarNYC for hijacking this thread....feel free to delete these posts!!
The board will have 8 vertices. A comedy mask accessory I made, though, has many more.
Ms. Byte
Original Poster
#25 Old 10th Oct 2009 at 11:08 PM
French Sim: The tools exist, but mostly in testing form. If you'll look at this thread:

http://www.modthesims.info/showthre...5#startcomments

at post # 17 Wes has his new renumbering plugin for Milkshape and explains how the process should work. You would make and renumber the vertices for your new mesh, get a new set of morph meshes, and then use my BGEO creation tool. Theoretically it should work but no one has done the entire process as yet.

Speaking of my tool, when I get done with my pointed ears I'll finish up the more user-friendly interface for it that I'm also working on. Would have been this weekend but I'm sick and not up to spending a lot of time. Should be soon, though.
Back to top