Only part of the model saving

[quakemmo]

Heya,

So I made a composite Q3 MD3 model from scratch - lower, upper, head. I grouped all faces in different groups.

It all works wonderfully, in game or in the mm3d software, EXCEPT! when I load the whole model (and click Yes when the popup asks whether I want to load all of the parts of the composite model), and save then.

In this case, for some reason, only the torso, the head and the lower model is saved - not the arms/hands which are actually separate from the torso in my case (the model is for testing purposes only and I separated different body parts a bit to make it easier to distinguish between them in-game).

It works perfectly if I click No to the question, and save the model piece by piece, upper, lower, head. But if I click Yes and then save - no arms/hands.

Any idea? :)

[zturtleman]

The arms and hands need "u_" group name prefix to be saved in upper.md3. More details in the MD3 manual page. If it's still an issue you could post the models here in a zip for me to take a quick look at.

[quakemmo]

Do you think this constraint is really needed? Maybe I'm missing something but I feel it's just some kind of legacy constraint. If so, think we could get rid of it in a future release?

I'm using a different naming scheme (not u_..) for some particular reasons. I could just work around the issue unless this can just be removed. Thanks!

[zturtleman]

All of the official Quake 3 players use l_, u_, and h_ prefixes for mesh names though aside from export process it doesn't matter.

Awhile back I figure out how to determine MD3 player segments for skeletal models using the bone hierarchy and tags. It's not committed and probably has some assumptions about how models are structured.

But for frame animated models, how do you suggest connecting which meshes belongs to which MD3 player segment? I guess there could be a MD3 export dialog where you pick for each mesh and save it in the mm3d metadata. This a little overly complicated to avoid two characters at the beginning of mesh names so I'm not quite sold on it. I may give it some more thought.

Having groups with unknown prefix be saved in lower.md3 so meshes don't get lost in the nether would be a good idea. Though the meshes animations may be lost. Hmm, well could also check if group is animated in torso_ or leg_ frame animations to detect MD3 player segment but it would be hard to handle meshes that are simply unanimated.

[quakemmo]

Oh I'm not saying the whole l, u, h_ nomenclature should be removed - just that mm3d should not require these to be present to save a composite Q3 model. This way, people could use mm3d for modeling something that isn't really vanilla Q3 - while not taking anything away from Q3 modelling.

I'm working on a ioq3 fork where I rewrote lots of model- and animation- related code, and I do not use the u_ (etc) nomenclature. I still do use MD3 though, and mm3d is the only decent MD3 editor.

Maybe it could be a checkbox in the optios, like "Enforce Q3 group nomenclature", checked by default. Leaving lost souls such as myself with the option to uncheck it. :)

[quakemmo]

Bump for the Z dude!

[zturtleman]

To avoid lost groups (not saved in any player segment) it's no longer possible to export MD3 player if a group name does not have the prefix H, U, or L_. 8db13ae7fa018b02c215153ddbd0c157efeaf859

tl;rd What you are asking for [saving groups back to the player segment they were loaded from] is totally possible but inconsistent with other Quake 3 nomenclature used by MM3D (filenames, tag names, animation names) and I'm not prepared to make multi-segment model export and import in MM3D fully customizable. I don't find control of the first two characters of group name (which you could easily skip if using group name for something in your game) to be a particularly useful feature so I am disinclined to add it.

---

As-is mm3d loads the player segments and then has no idea where the groups came from to be able to export them back.

zturtleman: I guess there could be a MD3 export dialog where you pick for each mesh and save it in the mm3d metadata. This a little overly complicated to avoid two characters at the beginning of mesh names so I'm not quite sold on it. I may give it some more thought.

What I meant here was loading the player segments would set metadata of what segment the groups are in and the export dialog would display a list of all groups with combo boxes to pick player segment (filled in from metadata and some default method) and then update metadata when you confirm.

Your solution of just hide it from the user doesn't sound good to me. Next you'll ask why renaming "arm" to "arms" refuses to export and I'll explain (the hypothetical) metadata uses the group name for which segment it belongs to. It would be nice to display list of groups with combo boxes at export.

Full control of group names doesn't seem like a huge benefit to me (you could easily skip the prefixes if you're parsing the group names in your game). Next would be to allow renaming tag_torso and tag_head and setting player segments for every tags (which currently default to all segments if unknown) and setting player segments for every animation to try to work toward no hard coded text strings. But why are head.md3, upper.md3, and lower.md3 hard coded? Why only three segments, why not player with weapon, weapon flash, and weapon barrel as well?

What you are asking for is totally possible but inconsistent with other Quake 3 nomenclature (filenames, tags, animations) and I'm not prepared to make multi-segment model export and import in MM3D fully customizable.