TheCrazyT / BlenderMhwModelImporter

Plugin for blender to import mod3 files
15 stars 5 forks source link

Extra data in LOD index affecting mesh and severed body parts #7

Open UberGrainy opened 5 years ago

UberGrainy commented 5 years ago

Not sure if you already knew about this. I commented on the Nexus forum, but I'll copy paste here too, just in case you don't check there.

Found a few new problems:

  1. When replacing monster tail LODs, it can break the "hide tail on tail cut" flag. Not sure which byte it is, but I got around the issue by using the original LOD data but referring to the new mesh's address in the file (via hex editing).

  2. In some models (currently the one I'm using is the Handler Mischevous Dress), the LOD object mesh you replacing seems to affect how the mesh deforms, and maybe how it's shaded (unconfirmed). For example, 2b's skin model fails to move properly when replacing some objects, but if I dupe that object or even copy paste from another instance, into a different LOD slot, the problem vanishes. Very strange.

  3. Noticed that in some of my exports (based on the Handler Mischevous Dress) the bottom of the mod3 is padded with 00s. Is that normal?

Then in another comment I wrote this: So about the LOD thing, I think there is data in the LOD index that tells the game what kind of skeleton is being used, and limits the influences for that specific LOD. This would explain why replacing some LOD objects causes only some parts of the mesh to stop moving along with the skeleton. Or why replacing some LOD will cause some parts of the mesh to distort and stretch heavily.

I think this may be more common in full body meshes. Similarly, head meshes seem to have some kind of limitations on usable bones. If you try to replace a head mesh with another type of mesh, most parts referring to other bones will distort.

AsteriskAmpersand commented 5 years ago

For part 1: The first one is controlled by a mesh part unk1. Unk1 is 0 if a mesh should be visible at all times, other values change for different types. For bows 1 is show only on back and 2 is show only when deployed.

For part 2: A mesh part shading is dictated by it's material, you need to change the material idx of the mesh part if you want it to be shaded by another shader on the mod3 file. You can add materials to mod3 (but you also have to add the corresponding material on the mrl3). When you replace a meshpart you inherit some of it's values amongst those the material idx that was there previously. Related to the deformation I've ran into this with the Deviljho bow, where only certain meshparts allow float weights and other meshparts only respond as if weights were 0 or 1.

The deformation of mesh parts is a bit more complex. Are you by any chance model replacing an armour part from which the model you are rigging to was not taken? (For example you are rigging to tzitzi armour but replacing harvest set).

As for usable bones this is most likely because of a combination of the bonemap and head properties. Indices beyond the very basic probably map to swag bones for specific armours for head pieces so you are getting animations from other headpieces or god knows what. You can just kill them by 0ing out the non essential entries on the bonemap.

TheCrazyT commented 5 years ago

Slightly off-topic: changed Unkn1 to "visibleCondition" in one of my templates: https://github.com/TheCrazyT/MHW-Research/blob/master/010%20Templates/MOD3.bt#L71

AsteriskAmpersand commented 5 years ago

I can confirm that the property of how weights are allowed to affect a mesh is in the data of meshpart on the unknowns. Transplanting the unknowns allows meshes that previously had no fractional deformation to be able to have non 0/1 response to bones. This property is also taken away through transplanting.