RFC: When did you zturtleman pick up MM3D?

[m-7761]

Copyright © 2004-2008, Kevin Worcester Copyright © 2009-2019 Zack Middleton

From the following:

https://sourceforge.net/p/misfitmodel3d/mailman/message/36410673/

"2018-09-08"

From the following:

https://download.tuxfamily.org/sdtraces/BottinHTML/Bottin_K-O_files/Maverick_Model_3D-11890.html

"Created: | 2012-04-01"

P.S.

What do you think of the "libmm3d" component? Can/does/will Maverick dispense with that idea? It's a great burden to maintain a library. Is anyone using MM3D independent of the productivity software application? Is it distributed as a separate library?

I ask since the code is quite a mess in places... and the usual mentality for supporting libraries is to not remove old "public" functionality; which can be an insane (I would argue stupid) burden, that usually means, in practice, code is either dead or stillborn (locked in) when it's code is published.

[zturtleman]

I started improving MD3 model support in 2009 (patch for Misfit Model 3D 1.38 SVN r440) for my Turtle Arena player models. I made more MD3 player model improvements in 2010. I created a previous MM3D fork named Maverick Model 3D in 2011 (which is what that tuxfamily webpage is about). No releases were made.

In 2014 I created this new mm3d fork with full MM3D subversion history and kept autotools to be a drop in replacement for Misfit Model 3D. This is when I branched out to general bug fixes and improvements unrelated to my player model support. I ended up renaming it to Maverick Model 3D in 2018 to differentiate from official Misfit Model 3D releases.

---

The MM3D plugin API is stable for 1.(even).x versions and can break for each 1.(odd).x version. I would think this also applies to libmm3d and mm3dcore as they are part of the plugin API. The mm3d tests (in src/tests/) and plugins use libmm3d. libmm3d is not distributed separately.

I think libmm3d is a nice idea in theory and some sort of API is required for mm3d plugins. libmm3d is more or less internal code that is suppose to be independent and reusable. Not really designed for a stable library API (as it includes a bunch of non-model utility stuff). It should probably have it's own C++ namespace to avoid conflicts in other software. I don't have plans to remove it or change how API compatibility is handled (same as plugin API).

I plan to replace the OpenGL 1.1 model rendering code in libmm3d (possibly moving out of libmm3d) but it's not happening this year (#51).

[m-7761]

Incidentally, I'm going to be developing CMake scripts, in case you can find a way to use them. They will be based on my final code, which will probably delete upwards of 70% of the files; since there is a lot of junk code in there. I may want to discuss throwing out some of the code that is low value. Like old file formats, or the scripting stuff that the MM3D website suggests is defunct. The only reason to do that is to not have to work on those files.

Either way, you could use the CMake scripts and just change the files to your liking. I mean, you're welcome to them or anything I produce.

P.S. I am curious if the libmm3d part was for plugins to use or not. There is a separate plugin API. If they are conflated it's harder to keep plugins going. But actually, in the current installers, I check all of the boxes, yet the Plugins... menu is drawing a blank. It could be a bug. Or maybe those boxes in the installer aren't doing anything.

(EDITED: For the record, my rewrite work will drop direct interactions with Qt. But if you want to stick with Qt you might still find some value in it. Either in non UI parts only, or by cherry picking the UI parts. And by 70% I'm speaking in terms of individual files. In terms of their content, they will probably shrink down a lot also. And that might make it possible to combine files. Or move code into the headers where appropriate, in order to spread the bulk out over declaration/definition files. But either way, projects are better off if they have only a manageable number of source files, instead of seemingly hundreds! A lot of the bulk is pseudo-encapsulation code and Qt-isms. A lot of the flaws is misuses/misunderstanding of STL containers. The encapsulation stuff is not done well, and just obscures the code, making it hard to audit.)

[zturtleman]

CMake support could potentially be added to Maverick. Unmaintained formats (cal3d, cob, dxf, lwo) and formats nothing else supports (.txt triangle list model and .raw headerless 32-bit RGBA texture) will be removed eventually (probably in Maverick 1.5.0).

Plugins uses the Model, DataSource, etc classes from libmm3d. No plugins are included with Maverick by default. The check boxes in the installer are probably Windows file association.

As mainly a C developer I'm not all that knowledgeable about encapsulation and STL. Using them poorly is pretty stereotypical C++ though.

[m-7761]

The check boxes in the installer are probably Windows file association.

Yeah I think so. I probably didn't pay attention last time I tried to update it. I appreciate your feedback. Thanks!

P.S. In C++ "encapsulation" just means using the private and protected keywords, ideally, to make codependent states coherent and also sometimes just to make it possible to remove/shuffle data in the future without breaking client code. Like if you look at the "influences" code, pretty much all of the code is iterating over the vertices, and at each vertex copying a list, because the list is protected. And that is not a trivial copy, since each item in the list is its own object on the heap. And the list is just an int value. So it makes no sense at all. The copy requirement is encapsulation. The choice of list is not grasping what list is for. Actually list is the least commonly used of all STL containers, since it doesn't have a lot of upsides (items can't even be moved in the list without keeping a reference to the list itself) and has pretty bad performance characteristics.