various MDL related MDL7 SDK questions

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.

Wladimir said that the groups function in the MDL7 SDK was for a future extension to make models similar to WMB files, with many meshes. It's currently not supported by the engine. I should know because I'm the guy who would have to implement it .

Haha... funny but it is a riddle to me why the model is properly rendered, though. And as far as I remember that feature existed since A7, because I know I used it to animate a character for an A7 game prototype.

I think that there's a misunderstanding, MED offers the functionality of Groups, it even has a Group Mode along with Vertex and Triangle Mode. Those groups are in fact distinct meshes (/ mesh groups/ subsets) that can be f.i. disabled in the engine via vmask.

Then there's another thing called group in the MDL7 SDK, it allows something different like in WMB files, but has nothing to do with the current mesh group feature in MED (and the engine). Correct?

I don't want to be nitpicking, but I believe that these are the same and that this submesh feature already works. The SDK reports the MED groups correctly and when I throw away all groups but group one, only the sphere is saved.

This is what I get from the SDK, when I load the model; iterating over all groups:



Which reflects exactly the properties of the groups and their group numbers shown in MED (see the model I uploaded) - in this order:

- sphere
- cube
- cylinder

Superku is correct: The word "group" is used for many different things in Gamestudio, this might be confusing. F.i. collision groups, or subset groups. What you set up in MED with the Group function are mesh subsets. The mesh subset a triangle belongs to is read with the mdl7.TriangleSkin() function in the MDL7 SDK.

Ok, I got this, as expected, though:

- given: two bones b1 and b2 and b1 is the parent of b2
- if you save them in order (first b1, then b2) and the index of b1 is lower than b2's (no forward referencing), the bones and the parent' reference is correctly saved
- other than that (wrong order or wrong ordered indices), the bones are saved, too; but as root bones

Conclusion: Sort your bones yourself before you push them into the SDK! The underlying graph-theoretical problem is the problem of Topological Sorting, which you have to solve. Best way to embed that is to do it right when you add a bone to your model (or when you remove it).

Thanks for the explanation. Though, there is no TriangleSkin function in the whole SDK. At least not in mine which I got from the download page. ... I just use the instructions (and their order) from the LoadMDL7-example as template to start from. I also came up with the term "groups", because that is what the member functions indicated by their names, and, which are in fact used to read triangles and vertices and skinpoints - this might be an excuse for my nitpicking, because it leads to the assumptions I made all the way

[EDIT] Like...

virtual bool Head(long & bones_num, long & groups_num,long & mdllump_size, long & entlump_size, long & medlump_size);

virtual bool Group(unsigned char & typ, long & groupdata_size, char * name = NULL);
virtual bool Group(long& skins, long & stpts,long & tris, long & verts, long & frames);

The function is in mdlr.h:

int TriangleSkin(int &skin, int skinset=0);
// to be called after Triangle(), read the skin index per triangle

The skin index is the number of the submesh that you set up in MED in Group mode. skinset is 0 or 1 dependent on whether it's the first or second UV set.

I'm sorry, there is no "mdlr.h" file in the wmpmdlsdk7 archive which is available for download here: http://server.conitec.net/down/wmpmdlsdk7.zip --- I also opened all files in the inc\ folder and searched for "TriangleSkin", but there were no matches. What am I doing wrong?

Question

5) I figured out, that I can only properly save a MDL file with bones, when the bones are not only in topological order (for back referencing by indices), but also uniquely named. So, what I do is that if I have bones with the same name, I enumerate them by adding a '#' plus an ascending integer. As I am not interested in the way bones are named, I always generate bones with "" as name, which leads to names like "#0", "#1", ... "#42" ... and so on.

Now, I read by accident in the manual for "ent_bonehandle":


Is this a secret boundary condition which I must be aware of or is this old and can be waived? Because I didn't read that anywhere in the SDK and I also was able to properly save a MDL with a bone named "#0"...???

It's unrelated to the SDK, but a requirement by engine functions that accept both char* and STRING*. They detect the difference through the STRING index, but this requires the char* to be at least 4 bytes in length.

So, what happens when I use the index to get the name "#0" with ent_bonehandle into a STRING* and pass that STRING* to ent_bonemove??

That would work, the 4-bytes restriction is for char* only.

6) Are the normals stored with the Z-axis as the up-vector?

7) This is not directly a SDK related question: How are you calculating the center of a model in MED (Edit\Transform Global\Center Model)? --- I wrote for my dll a function for that and I simply sum up the vertex positions and divide by the number of vertices; but the model is still moved around when I hit the "center model" button in MED...

Here is some code:

By taking the outer most vertices (like a bounding box) ...