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"...???