Ok, I'll start a new thread here, because I will have to deal now to the full extent with the MDL part of the MDL7 SDK. Here are my first four questions:

1) In your LoadMdl7 example, you open a mdl, read the group count and iterate over them. For each group, you do the following:



which leads to the assumption, that skins are not associated to the model itself (like in .HMP files), but to a group. This feels wrong, given that you have in MED only a list of skins unrelated to any group(s). Then, in your SaveMdl7-example, you use a function save_skins to save skins. Though, you conditioned it to g == 0, whereas g is the iterator variable in the surrounding loop, that, well, iterates over all groups:


which leads to the observation, that skins are only saved in the first group and which confirms my feeling concerning my experience with MED. --- So how are you treating skins anyway? It is a bit confusing.

• When loading, will group 0 only return any skins?
• Can it happen (during loading), that any other group reports skins?
• During saving - shall I just save the skins into group 0? What happens if I save skins in any other skins?
• During loading, triangles refer to a material index. I guess, this is the index of the loaded skins. So, do I just then use the index of skins in group 0?

2) You are in fact doing all references (bone parents, skin asisgnment to triangles, vertex assignments to triangles, etc.pp.) via indices, which is fine for me. I observed, that all references are passed to me during loading in an ascending order. For example, if I get the bone with index = 6 and this bone has a parent, the parent index is guaranteed to be always < 6 (and not > 6; which I wil call a forward reference). This accounts to all other references as well. My question is, if I have to provide this sorting during saving or if I can do foward references, too. Subquestions are:

• When passing indices during saving, must I hold the ascending condition? Will the function fail if I do a forward reference?
• Can I pass the indices arbitrarily and the SDK sorts them during saving anyway?
• What happens if do such a forward referencing, save and load the mdl... will the SDK will do a sorting before I get them or do I get them as I entered them during saving?
• Will such a forward referencing cause trouble in MED or the engine?

3) In your LoadMdl7-example, you just get the amount of triangles and use the method



to read them out. Nevertheless, in the class MDL7R there is a second one:


which I assume to be the method for getting the 2nd uv-set data. Question: how do I know if there is a second uv-set at all and how do I handle that?

4) Have you seen my saving-related feature request here?: http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=391472#Post391472

Regards,
-Christian

As to the best of my knowledge:

1) Model files have one group only.

2) Bones indexes start with the root bone, so there should be no forward references. I'm not sure if the SDK sorts the indexes, but I believe it doesn't.

3) The second UV set can be found with TriangleSkin(index,1) - if index is nonzero, the mesh has a second UV set.

4) I'll pass the buffer save request to Wladimir. He's occupied with another project at the moment, but when overworking the SDK the next time, this can be implemented.

Thanks for the answers!



Hm, but in MED you can have more than one group per model? I will make some tests, though to check this out once I am ready for that

I did some tests, and model files indeed can have more than one group. All (!) skins are reported only for the first group, though. Although no skins are reported for following groups (and their triangles), reported triangle material indices are referencing to the skins reported for the first group.

@HeeIX: so is it possible to use multiple groups for the mesh? And all skins are just in group0 even when used in group2?

You can do that already with MED: select faces of your mesh, and then edit/create group. That skins are reported only for group0 is apparently part of the downwards compatibility towards older MDL versions, which were not able to store multiple groups. So, apart of this rather technical observation, skins are "global", although reported "locally"

Besides, afaik, it is not favorable to have multiple groups in your model for performance reasons - it is quiet helpful, when editing a model in MED; but when you ship your game, you should merge the groups to get a speed enhancement.

I did not know that MDL models can have more than one group; that must be a feature implemented recently for some test purposes. It has no practical use anyway because the engine only loads the first group of the model. So you won't ever see whatever the other groups contain, and need not load or save them.

@JCL: and what is with vmask? isnt it based on groups?(hiding or showing them)?

No, vmask is based on mesh subsets. HeelX was referring to the groups in the MDL SDK.

I'm afraid that this is not right. I used this feature (which is accessable via MED) a long time now and apparently all groups are properly rendered. Here is a model with 3 groups and if you open it in the engine, everything is shown and rendered nicely: mdl_groups.rar

In addition, I see a lot of good things that come with that:

• If a mesh is organized in groups, they can be edited more easily, like, when assigning bones in MED.
• Groups are created for nodes in imported FBX files for instance. This is a valueable feature, when explicitely deleting stuff.

So, in my engine plugin, I have to take care of all groups during loading and during saving. If I would throw away for instance all other groups than the first, only one of the two primitives would make it into the saved model.