3 réponses à ce sujet

[tmp7704]

I have a .msh and associated .mmh file for a piece of amour. Both files are for the _0 level of detail model. There is no level _2 and _3 files provided for the game. However, when camera pulls away far enough to warrant a LoD change something odd happens -- while the mesh appears to remain the same, the .mmh bone structure either becomes replaced with something or perhaps certain bones are no longer taken into account which results in the associated mesh becoming warped all over the place as some of its vertices no longer are affected by their bones.

I tried to trick the engine by providing copy of level _0 .mmh as levels _2 and _3 but the warping still occurs, apparently the engine decides it knows better and provides its unasked for "optimization" just the same, or there's something else at play?

Just wondering if someone has explanation what exactly is happening there, and if there's a workaround for that that'd be less work-intensive than basically re-weighting the mesh in best case or rebuilding it with lesser LoD if i got really determined to do it the 'proper' way...

[Eshme]

I havnt exactly tried all the steps necessary. But i already see the problem with the Boneindex.



You are probably working on multipart models, there is a Head ,Hair ,Eye model too. They probably have a LOD too!

The lower LOD models come with fewer bones, and with different Boneindex. This is a different referenceskeleton than the higher LOD.

When you have a multipartmodel, one skeleton will be the boss, this is likely the Head or the Eye with different Boneindices than your LOD1 copy.



In the Exporter, the Blendindices in the MSH file now point to different Boneindices than the low LOD reference skeleton of the Head or Eye. Or simply point nowhere, because the low LOD doesnt have as much bones either. And this is why the mesh goes out of random.



You need your bones to have exactly the same Boneindex as the reference skeleton in multipart models. I think i already told you that? Unless u redo everything that is, but that is probably too much to do.

[tmp7704]

From my experience so far it'd appear the 'master' skeleton object is the torso item .mmh at least given that changes made to this .mmh affect things like placement of attachment points, the bones for hands even if the hands are technically separate model etc.

That's why it's rather puzzling to see the item undergo such changes -- i'm not providing the engine with low level of detail version of the chest item. Meaning it should be in theory forced to keep using the level _0 bone structure, yet there is some sort of switch occuring there.

If it's actually the head item that provides the overall skeleton then it'd explain why the change takes place, although it would in turn not explain why altering the chest skeleton layout actually works at all, then. Unless the chest .mmh is acting as sort of an override... but that in turn doesn't explain why the engine feels entitled to ignore such override for level _2 if it has more bones than the default items. (even if it skipped the bones which are no longer present in the 'master' head mesh i'd expect it to still properly remap the main bones which *are* present like the arm bones, and it doesn't seem to be the case) The whole setup feels rather convoluted, to say the least.

Modifié par tmp7704, 21 mai 2010 - 04:02 .

[Eshme]

I wouldnt take the fixed position that there is a master skeleton for everything. Afterall the boneindex could be merged on its own for a realtime skinweighting purpose. It is the case of the Ogre where its the Head.

But It wouldnt matter which part is what, either way they got to be equal to some degree. Some things may even be dropped which the other skeleton of a multipart model fixes. This for example is the Boneindex entry for each node. But it means you run into problems sooner or later, if no master skeleton exists to fix the issue.



See that position and layout could be handled in another part of realtime application. But Bioware may as well not have accounted for these things to happen ,and as such it may be bugridden to do, as really the positioning for original skeletons is equal for the modeltypes. But i figure you have found the spot to tweak layout by the Chest skeleton.



That a lod0 has more bones than a lod3 means nothing, if the boneindex is boss when it comes to skinweighting.



The only practical way of doing would be to import a LOD model/skeleton while storing the Boneindex, to have something represent what Bioware worked with. When exporting ,export the Bonindex. This is what my import/export does.



Be assured, that Boneindex isnt the only number to work with, as there are also HookID's of specialeffect nodes, which have a fixed meaning.