News: https://github.com/mick-p1982/mm3d (experimental fork)

[m-7761]

For the record, I've published my work at https://github.com/mick-p1982/mm3d/releases/tag/win32-demo2 concerning #106 and following up on #105.

I've changed the "magic number" to MM3D2020 and I recommend using this with Maverick after we get the core code files (everything except "implui") coordinated between the projects. The existing mm3dfilter.cc code doesn't check the version numbers like it should, so changing the magic-number code (which it does check) is best, plus I think "Misfit" doesn't exactly inspire confidence, so it's not a bad idea to switch to different language. (I know making the magic-number the same as the file-extension is a little bit circular logic, but it's probably fine.)

Needless to say the code changes are extensive and represent a vast improvement to Maverick's existing code. We can take our time integrating the code. I don't have strong feelings other than to include all of the changes in some form (functional equivalence) and I want to keep the same code style... no auto-formatting. It's very close to the existing code's. (That's one reason I chose to work with MM3D's code in the first place. Edited: I will insist on using tabs for indent.)

[m-7761]

I've made a list of patches here (https://github.com/mick-p1982/mm3d/issues/1) and I've just updated the sources and demos because I forgot to only compare the minor version if the major version is the same. (This made standard MM3D files to not read. I just realized it's still broken if a MISFIT3D version is newer than the current version: 1.7! This will be addressed by the next patch.)

[m-7761]

I (finally) got the user-interface component published (https://sourceforge.net/p/widgets-95/code/4/) so that the demonstration can be built with Linux (though what's recommend is wxGTK3 which is wxWidgets based on GTK3. GTK4 may work too, but GTK2 won't be as nice and is mostly untested.)

(I don't necessarily recommend building it. It works well in my development environment. It probably needs to be put in Debug mode since it's littered with #error directives as soon as it's put in Release mode.)

[m-7761]

Just now I've removed 8 model-filter headers (78be69092331b940140cb1749ef82beb901902c3) just to cut down on the number of files to wade through (as I've done for other needless headers.)

Just to add until we discuss a timeline I am still making non-patch changes that come up without prior notice.

I was going to do this I think, but possibly because of the ModelFilter::Options instances I neglected to. I moved those into modelfilter.h using C++11 inline-member-initialization to make their definitions brief. I think it's worth having fewer source code files to visually scan when looking for files to edit.

[m-7761]

Sorry about this... I wrote some code that packs more info into MM3DFILE_KeyframeT::objectIndex yesterday.

https://github.com/mick-p1982/mm3d/blob/widgets95-ui/src/libmm3d/mm3dfilter.cc#L1865-L1886

I thought might as well, and if the format is Little-Endian it could be rewritten with uint16_t, etc. But it can be added to the back of the structure just as easily. I just (I think) wanted to put the object-type beside the object index and felt there was room leftover for the interpolation mode (which I was adding because I forgot to read/write it.)

Afterward I felt this is maybe out of character, but I don't have a strong feeling either way.

[m-7761]

I noticed splitAnimation is returning the wrong number today.

Lately I've been overhauling several routines that merge/copy/duplicate/split/join models and animations: d684d5bd3ed5bda74d56a8f410a3b64d4aa0ec5b

I've added frame-animations to the merge-animation feature in the Model menu. It actually calls this "Import animations" but it's distinctly different from the Merge feature because it applies the animations to the existing model.

It could stand to be configurable or refined but how it works is to compare the vertex positions and apply the frame-animations that way, since the actual order or number of the vertices is subject to all manner of 3D data manipulations and so unlikely to survive.

Specifically what I'm doing with this is taking a model with a very baroque texture addressing model inherited from the PlayStation architecture and remapping it in Blender, and then pulling the finished model back into MM3D with the positions unaltered, and then importing the animation data to produce a finished animated model. Blender can't begin to represent the animation data, hence why I'm using my modified MM3D to prepare the animated model data.

I happened to find myself needing to merge the models and textures also since some of the models are broken up into pieces. That means using the Merge feature and then using the Animation Set window's Merge button.

I worked on these algorithms for a few days and cleaned them up a lot in the process while adding the more advanced feature set that takes into account timestamps, duration, and interpolation modes.