Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Sockpuppet
#51 Old 18th Sep 2009 at 5:29 PM Last edited by Base1980 : 18th Sep 2009 at 6:39 PM. Reason: Found the solution
Hey Wes
I got another small issue with the plugins.
I made a female mesh loaded and edited with the correct skcon file.
I saved it under another name and the next time i import it it will load the correct skcon file, no problems there.

I want that same mesh available for males also, so i imported a default male mesh with the correct skcon file and then import the female mesh.
When importing that mesh i get no messages but after i export it the next time i import i get the message the default skeleton is used and not the male skcon file(wich is there in the folder.)

So it seems the male skcon file got overwritten by the one from the female.
Atleast that is wat i thought but after trying to do the same with the female teen and adult female.(scaling the mesh to teen size.) the mesh used the correct skeleton ingame except i still get the message it uses the default skeleton.


With Unimesh you could easily fix skeleton issues by importing a original basegame mesh/skeleton, then import your custom one and export, it would replace the skeleton.
With these plugins i keep gettin ''default skeleton used''


EDIT,
sorry...i found out wat i did wrong.
You have to copy the data from the GEOM-00 comment box and paste it in the box from your imported mesh(GEOM-01)
Advertisement
Alchemist
Original Poster
#52 Old 18th Sep 2009 at 7:20 PM
Thanks for leaving your post up. You have the correct answer, and perhaps someone else will be searching for a solution to that, find you post and fix it.

There is actually only a part of the comments that would be needed to be copied, that is the "TgiRefXX" line (XX is some digits) that has "00AE6C67" in the first column. The rest of the line is the group and instance for the bone (.skcon) file you want. The others are references to default textures and bumpmap textures for the mesh. You can change those values to be different DDS files if needed.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Theorist
#53 Old 18th Sep 2009 at 10:36 PM
Quote: Originally posted by Kiara24
Please help me!
I think I installed everything but Q-mesh does not appear

Please help
Alchemist
Original Poster
#54 Old 18th Sep 2009 at 10:46 PM
If it does not appear, you have done something wrong.
This plugin requires at least MilkShape 1.8.5 beta1 to work, it will not work on MilkShape 1.8.4.

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#55 Old 18th Sep 2009 at 11:02 PM
yup, thats why i left the post as it was...)
Thnx for your help, the tootsies are up(the females) at http://www.bloomsbase.net/
Theorist
#56 Old 18th Sep 2009 at 11:34 PM
Quote: Originally posted by WesHowe
If it does not appear, you have done something wrong.
This plugin requires at least MilkShape 1.8.5 beta1 to work, it will not work on MilkShape 1.8.4.

So the problem is that... I have MilkShape 1.8.4.
Thanks!
Alchemist
Original Poster
#57 Old 18th Sep 2009 at 11:43 PM
Good. 1.8.5 is a free upgrade, and there is a reason this requires that version. Hair meshes have an extra values in them that does not fit into older version of MilkShape. Mete (the author of MilkShape) added that in there to support Sims 3 meshing for us.

The object mesh plugins (in a different thread) are supported by older versions, back to 1.7.8. That's because the object meshes do not have that feature in them.

I hate to make you guys & gals chase these updates down, but the MilkShape one is for a very good reason, and the Visual Studio 2008 Runtime is just a newer version of the Visual Studio 2005 Runtime, which most people probably already have installed. The 2008 edition has some added security features, and at some point in time, if you didn't install it for me, something else new you get will require it.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Theorist
#58 Old 19th Sep 2009 at 3:46 PM
Sockpuppet
#59 Old 20th Sep 2009 at 10:31 PM
Hey Wes
I was wondering if you would be willing to include a commit all button within the extra data tool?
Alchemist
Original Poster
#60 Old 21st Sep 2009 at 12:35 AM
Commit All from the BoneTool is the same as the Save All button. There is no Commit button in the CCTool, it gets committed automatically with the "copy to all" button.

What is it that you are trying to do?
Perhaps I can help solve the problem.

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#61 Old 21st Sep 2009 at 2:12 AM
I want to unassigne all vertices, all set to 0.(the vertID)
But keep the bonesettings
But the mesh im testing has 1960 vertices.......so setting them all to zero is a alot work lol.
Alchemist
Original Poster
#62 Old 21st Sep 2009 at 2:29 AM
I posted on this in the GEOM Tool thread, as the topics are related. We can do something, if we can decode what needs done... adding an auto-renumber button is possible, it could number any morphs that are loaded the same as the base.

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#63 Old 21st Sep 2009 at 2:39 AM
Ye, that would be way cooler!
Alchemist
Original Poster
#64 Old 21st Sep 2009 at 6:53 AM
Let's finalize a plan in that thread.

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#65 Old 22nd Sep 2009 at 4:58 AM
I dont know if this is caused by your plugins but by using a external uvmapper(like Unwrap) the vertID numbers go bizar.
Like making one foot, then duplicate and mirror it/then move the coordinates from the copied foot on the uvmap(so that they are seperated)
Then save as ms3d and open it with unwrap.
Select one foot and mirror the uvcoordinates and save as luv.
When i imported that newuvmap back into Milkshape all vertID's on the foot went bizar...like from 1 to millions :D

And i always lose half of my bonesettings when doing that(same with sims 2 meshes), strange isn't it?
I do get a message that i might need to reweld the seems but often irrelevant.
Alchemist
Original Poster
#66 Old 22nd Sep 2009 at 4:59 PM
The VertexIDs and TagVals are stored in the .ms3d file, but I don't think that data field was added until maybe version 1.8.0. I ran a test here with UU3D, resaving an original EA mesh with a copy saved as an .ms3d file, and the VertexIDs were just zeroed out.

All of these external programs are probably several MilkShape versions behind on their file format support. Although the extra were added in 1.7.8, somewhere between three and four years ago.

I don't have any good solutions for ways to retain the values, as they are getting lost in the file transfer process, but if I get the autonumber plugin working it will make the issue irrelevant.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#67 Old 22nd Sep 2009 at 11:39 PM
Yup, o well i am used to it and know how to fix most of the issues.


Another thing....srry
When i have a base mesh and its morphs loaded i can not import another morph for, lets say using parts.
I know you prolly did that on purpose, to avoid implosions and errors.
Is it possibly you take that warning(think it was ''verts dont match or something) out on the next plugins?
It is is impossible to combine diffrent clothing meshes right now....also importing a objective file fails, it simply dissapairs(only when morphs are also loaded.)
srry, thinking ahead
Alchemist
Original Poster
#68 Old 23rd Sep 2009 at 2:00 AM
I am thinking through what you requested, and I think you can do this already by loading the base, then the morph, deleting the base group, changing the comment and saving the mesh data out as a different file type with weights, via UniMesh. I think the main changes will be juggling the comments to do so.

On disk, morphs are very different from base groups in basic ways. The plugins know how to convert morphs to meshes, and meshes to morphs on export, but it does this always the same way, base as the first group and additional groups as morphs, because GEOM files only ever have one group per file.

If you use a weighted format like UniMesh has, and adjust the group comments using cut-and-paste, then the only difference will be the VertexID (except for hair, which may also have TagVals). I am actively working on the autonumber plugin, which, if it works right, should make the final step be to just number the VertexIDs and then make a new BGEO.

Try that and see if it doesn't work for you. However, I learned on TS2 that most of the time trying to edit a morph in parallel with a base ends up being a disaster. The best way is to edit your base group until it looks good and is mapped the way you want, and then duplicate it, change the comments and just move vertices to form the morph. I know you are making special things, and have more than average experience in doing so, but trying to combine morphs with morphs is going to be hard. When I get you the autonumber tool, it will make the process a lot easier, because aside from the VertexID, everything in a TS3 mesh (once loaded into MilkShape) is just like TS2 except the comments, and those can be managed well with cut-and-paste. This is why the BoneTool from TS2 works in TS3, because it is a basic mesh item and the same dude wrote both plugins.

<* Wes *>

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#69 Old 23rd Sep 2009 at 3:12 AM
Roger that sir
Sockpuppet
#70 Old 26th Sep 2009 at 3:38 AM Last edited by Base1980 : 26th Sep 2009 at 4:19 AM.
FVFItems: 7
TableType: 2

Were does the 7 and 2 stand for?
I see this with bodymeshes

Accesoires have 6 and 1
Alchemist
Original Poster
#71 Old 26th Sep 2009 at 5:42 AM
These are slightly misnamed, but I had the code written before I learned a bit more detail on the format.

TableType: is a set of flags that are part of the bone hash list table. I am not sure what the value differentiates, it is probably bitmapped, but having it in the comments allows it to carry over from the import to the export.

FVFItems: is also slightly misleading. It is the number of items in the Flexible Vertex Format table. Since the game always uses the same sets of format order, the count allows me to make an output that includes all of the elements used in the import. But the flexible vertex format is really a list of what elements are included in the vertex.

All mesh types have at least three elements, position, normal and VertexID are in the morph files, but position and normal are deltas, they must be added to a vertex position from a regular mesh, and when that is done you have the new morph position and normal. That is why the morphs have to be loaded after the right base is loaded, because they are useless without the base position data.

Type 6 is a mesh with position, normal, UV, bone assignment, skin weights and tangent (bumpmap) normals. Six items. Because there is no VertexID, this type never has any morphs.

Type 7 is a mesh with the previous items, but either a VertexID or a TagVal is inserted after the skin weights. There is a different comment (HasTagVal that remembers which one. Some hair meshes use this value, with the TagVal. Usually, though, it is a body mesh with a VertexID and there is probably one or more morphs for this.

Type 8 has everything, both a VertexID and a TagVal. These are (I think) all hair meshes, although maybe the face meshes use this type also.

The importer follows the FVF item list, but once loaded, all that is saved is the count, and for type 7 whether it have a VertexID or a TagVal, and on export the order written includes the right elements, but always in a fixed order. It isn't a perfect implementation of the standard, but it save a lot of unnecessary detail, because most of the possible configurations of elements are useless on a practical level. The exporter also makes sure that for a Type 3 that it exports deltas instead of true positions, making a morph mesh instead of a regular one.

If you are making accessories from regular meshes, just change those two values, and the exporter will leave out the VertexIDs. If you are changing accessories to regular meshes, you will need to add VertexIDs and change the two comment values.

The GEOM format is documented at http://sims2wiki.info/wiki.php?title=Sims_3:0x015A1849.

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#72 Old 26th Sep 2009 at 6:03 AM
Thank you
i am making a accesoire that moves with the sliders.
And when using the correct TGI reference for the bones it works perfect.
But somewhere along the way i lose a material setting, the transparancy that i need.
Or(when using the settings for the accesoire) i lose the VertID's
just need to find the correct settings to have both
Alchemist
Original Poster
#73 Old 27th Sep 2009 at 3:30 AM
Yeah, the Type 6 will not save the VertexIDs. You need a Type 7 to save them.

All of the comments that start with "Embedded" are the materials data, so that is where you are losing your transparency at. Copy them all, as a set, because it is a single data block.

If you like to say what you think, be sure you know which to do first.
Sockpuppet
#74 Old 27th Sep 2009 at 3:08 PM
Aha...
Test Subject
#75 Old 16th Oct 2009 at 12:47 AM
Do these plugins work for Blender, or are there plugins that work for blender?

Don't compare yourself to me... You'll make yourself feel bad...
Page 3 of 10
Back to top