Ah ok I understand now... it's a ball in { 0, 0, 0 } right? Then it's because you are not rebuilding the skeleton, that's all.
Ah ok I understand now... it's a ball in { 0, 0, 0 } right? Then it's because you are not rebuilding the skeleton, that's all.
Yes, that's correct. So basically, I have to rebuild the skeletons from the ones "in-game". I need to read again how to do that because each time I've tried, I had an error message. I must do something wrong
That's also why I was asking originally about the XIDX (see previous page).
Under the patronage of Flinn, proud patron of Jadli, from the Heresy Vault of the Imperial House of Hader
Can you describe me steb by step what you are doing please?
Also... why are you using XIDX if my tool is implementing an unpacker for anims and skeletons since 0.4?
Last edited by Vipman; February 10, 2015 at 11:45 AM.
Every model has a bounding sphere except stratmap ones. Basically, all what can be used in a battlemap, must have a bounding sphere: siege engines, mounts, soldiers, captains, generals... everybody. And yes, 99,9% of the non-Vanilla models around there have an incorrect one... and this is the result of the bad practice of using comments for new models taken from similar existing models. If you change only one extreme X/Y/Z axis extreme vertex, then you invalidate the bounding sphere since:
Given a non-empty set of points of finite extension in a 3-dimensional space, the bounding sphere for that set is the smallest 3-dimensional solid sphere containing all its points.
Spoiler Alert, click show to read:
Hence, if you take a soldier and you change his weapon from a sword to a pike, you have invalidated the current bounding sphere and he will start behaving in a silly way.
If you want more information about this, I just wrote it down in the Technical Details spoiler of the first post. My tools can acually recalculate (hence, fix) the bounding sphere of a model during the conversion from MS3D to MESH. So basically, if you convert a MESH to MS3D and then convert the resulting MS3D model into a MESH again without making any change, you will have a fixed bounding sphere. I'm working on a tool that can fix bounding spheres on a large scale (fully recursive directory search) for the upcoming version.
Last edited by Zarathos; February 10, 2015 at 11:44 AM.
I checked the OP after I posted and saw you wrote about it, I tried to edit the post above but because of internet problems I couldn't save it until now... Thank you for your answer!
It seems this is really important, I can't believe no one did something to fix this until now, I think you really deserve an opifex for this tool! And being able to fix the bounding spheres for lots of models at once would be great, any idea when you'll release the new version? And until then, wouldn't it work if I use the Shift (All) function and convert lots of models to meshes at once?
For the moment all you can do is to mass convert to MS3D and mass reconvert to MESH to fix the problem. Upcoming version is coming soon but maybe it will take a week or so.
I can't belive this too. Actually all what I did to discover this was to take a few Vanilla M2TW units, read their bounding's sphere values (assuming they are correct since they were made by CA/M2TW developers), extract the models' data and apply 5 the five most common bounding sphere calculation algorithms to them. Comparing the results, I immediately spotted it was the Ritter algorithm since in all the tests it was always producing identical values. The discovery took me no more than a half-day of coding.
Last edited by Zarathos; February 10, 2015 at 12:20 PM.
Basically, I'm trying to use your tool to convert mesh files to ms3d files. But I'd like to see the skeleton as well. The purpose is to make the appropriate unit card for the new units that we're adding to SSHIP. Until now, I was using GOAT but as your tool seems better, why not using only that one? Unfortunately, I can't make the conversion and see the skeleton unless I rebuild it (and if I'm right).
Following the point 4) of your Tutorials (1st post), it is mentioned to use XIDX to unpack the file "skeletons.dat". So far so good. But when I use your tool (rebuilding the skeleton), when the tool asks me to choose the file, an error message appears and says that the file is invalid.
I suspected XIDX first as I couldn't use the update made by Europa Barbarorum Team. I don't understand how to use it actually. I've posted on their thread but so far, nobody has answered.
I hope I'm clear.
Under the patronage of Flinn, proud patron of Jadli, from the Heresy Vault of the Imperial House of Hader
Ok here are the steps I'm taking:
1) I unpack skeletons.dat with my tool ("Unpack DAT" button). The file is unpacked correctly as I can see many extensionless files (MTW2_Mace, MTW2_Spear, ...) into the directory where the file itself was located.
2) I click on "MESH to MS3D" with "Rebuild Skeletons" option set to ON. I select the MESH I want to convert to MS3D (hussars_lod0.mesh in my case). When asked if I want to rebuild its skeleton I answer YES and the prompt takes me to the folder I used to unpack the skeletons.dat file... I can still see all of the unpacked skeletons from there (MTW2_Mace, MTW2_Mace_Primary, MTW2_Spear, ...). Since my unit is using a pike as primary weapon, I select MTW2_Pike (not MTW2_Pike_Primary, since it's the "animated skeleton", it's very small and contains only joints shifting data).
It's up to you to recognize the right skeletons. Normally, if they are around 1 Kb, they are shifting data and they can't be used during the rebuilding process. I can't do this kind of analysis with my tool... all it can do is telling you whether you choose a good skeleton or not.
Holpà. Works like a charm.
Last edited by Zarathos; February 11, 2015 at 09:47 AM.
I have to agree with this, it's the only thing I don't like about this tool, if it would also build the skeleton like GOAT it would be perfect.
Very few people know how to work with animations/skeletons, having to learn this just to get the basic skeleton files is a point down for this tool.
Last edited by Vipman; February 11, 2015 at 09:54 AM. Reason: nevermind, stupid
Many thanks for the explanation Zarathos. I'll try as explained and will let you know about the result.
Under the patronage of Flinn, proud patron of Jadli, from the Heresy Vault of the Imperial House of Hader
This might be a dumb question but does anybody know where the siege engine skeletons are? I know where their models and animations are, but I can't find their skeleton files like the other types. I'm trying to get a trebuchet model to work with it's animations in Milkshape but I can't get this to work properly.
Do you know what GOAT does with skeletons, at least? GOAT does nothing except using a template of 3 or 4 premade skeletons. If it recognizes the model as a siege engine, it gives him the siege engine's premade skeleton... if it recognizes the model as a horse, it gives him the horse's premade skeleton... and so on. That's .
He is completely unaware of the real bones (count and names) belonging to the model itself because it doesn't even try to read that kind of data from the MESH. For human bodies it uses a premade human skeleton with 26 bones. You know what this produces? Well... if you have a soldier with more than the 26 basic/default bones, let's take as example the archers with animated bowstrings, it will just keep on using its dumb premade human skeleton no matter what. Hence, vertices assignments to the two extra bones get lost and as a result you will receive a MS3D model with unassigned or underweighted vertices for primaryactive and two missing bones. At that point you have two paths to follow:
1) if you are unaware of the existance of animated bowstrings (if it's the first time you work on a mod this can happen and GOAT is not even helping you to discover this, but it's tricking you instead), you assign all the bow's vertices to weapon01 or rhand and lose animated bowstrings forever and ever (this is what happened with many mods, TATW: DaC included);
2) if you are aware of the existance of animated bowstrings (because you implemented them at first instance or because someone told you), you take the default MS3D model of the archer with animated bowstrings from the author's thread, delete every group inside it, merge it with your archer and rerig every vertex correctly (because, of course, GOAT doesn't handle rerigging correctly during the merging process).
Are you still sure it's a point down now?
Only a few modders know how to work with animations, and they don't mess with them frequently. The ones who know how to work with them will also know how to correctly use my tool to rebuild skeletons when it's necessary (UI cards, new animations, animation variants and rigging tests into Milkshape - which is quite uncommon since you can have a better view of the unit itself on the battlemap and you normally don't need this if you know how to rig vertices correctly).
GOAT is outdated, unmaintained and contains ENORMOUS flaws (like premade skeletons and unrecalculated bounding spheres that kept on messing up models over the years). If you think that showing a fake, premade skeleton that destroys the model itself can help you, you are free to keep on using it. But if you want real skeletons always up after conversions from my tool, it should:
1) read the MESH;
2) read the corresponding BMDB entry (how can I locate the file from the path of a simple model? what can I do if you are just working on a model located on your desktop? what can I do if you have multiple mods installed? what can I do if the model doesn't belong to any of your installed mod? what can I do if there are many entries using the same model? what if the file is corrupt or using a wrong synthax?);
3) silently extract the correct skeleton from skeletons.dat (same problems from above plus a few bonuses: how can it know which skeleton to chose if there are also shifting skeletons with similar name? what I can do if the extraction process fails?);
4) apply the extracted skeleton to the MS3D output.
Or, alternatively, read your mind which is, at this day, still impossible. Jokes apart... honestly... no. It's just too much work and there are too many exceptions/situations to handle. I'm glad to share this tool with the community, but I'm mainly developing it following my workshop needs... in other words, I'm not going to undertake an enormous work to make someone else happy when the result is completely unnecessary to me.
Unpacking my skeletons.dat I can clearly see "MTW2_Catapult", "MTW2_Trebuchet" and so on...
Last edited by Zarathos; February 11, 2015 at 10:24 PM.
Those are for the crews of those siege weapons, not for the engine itself. I was confused by this too, but I know that it's not for the engine because if you open up the MTW2_Trebuchet in a hex editor or notepad it'll show human skeleton references. So unfortunately, that's not it.
It's probably a CAS inside "siege engines" directory then.
Hi, do you know something about this problem, after adding a new unit with new animations and unpack/ repack the pack and the skeletons files :
Spoiler Alert, click show to read:
Spoiler Alert, click show to read:
He point me in the other mod, i have inserted the animations from Myth mod to Tatw.
A detailed descreption of what i did can be found here:
http://www.twcenter.net/forums/showt...4#post14354614
thankyou for your time and help
Last edited by gosho; February 12, 2015 at 02:14 PM.
Looks like you didn't merge everything from the other mod's pack or maybe you converted the model forgetting to take care of the bones.
I don't know, honestly M2TW error logs are pure , and trying to understand the problem from them is hilarious.
I need more detals concerning the model, skeletons and maybe your step by step process.
I don't modify animations, i have to learn yet i only take the file i need for the unit and insert it in TATW.
here is what i did:
http://www.twcenter.net/forums/showt...4#post14354614
I can also send you the file of the unit.
Grazie Mille!!
A little update: the next version, 0.6, will be available soon and will contain a CAS/MS3D MS3D/CAS converter tool too. I'm fixing various errors contained in the GOAT CAS functions and cracking the CAS format itself even more. I already discovered a few interesting things about it.