The hell?!? displayFrameAnimPrimitiveError

[m-7761]

Did you know MM3D won't edit models with frame-animations? You can find this anywhere displayFrameAnimPrimitiveError is present. It's crazy it has so many features, but is basically unfinished. I wonder if it was designed for frame animations, or if they just got tacked on.

[zturtleman]

Yes, I'm aware that most editing isn't allowed if frame animations exist. Frame animations themselves can be edited. I don't know the history of when frame animation support was added. According to the MD2 help page editing is not allowed because of "enormous overhead of saving undo information". It goes on to recommend working with skeletal animations.

To me it seems like frame animation support is mainly useful for Quake MD2 and MD3 importing / model viewing purposes. Though one is free to create frame animations directly for animations that don't work well with bones. Just make sure the model editing is done first.

[m-7761]

There is something called forceAddOrDelete that overrides this, but it's used for loading files, so I wonder if it would break things if used in the normal context.

In any case, I'm personally interested in "frame" animation, so it's something I will be overhauling in short order.

If there is connectivity information in every frame, that's obviously a giant, and awful, hack... if not I don't understand why changing the model would be a showstopper for frame animations. The reason I'm developing an in-house modeler is because I want to be able to streamline frame-animation work to be as productive as can possibly be. I've stayed away from using other modeling software for it, because I'm skeptical it would be worthwhile to invest in any one of them provided how nonexistent import/export is for frame animations.

[m-7761]

P.S. I think if MM3D has any shot at being a shared library the user-base should try to call it "MM3D" whenever possible, and maybe call it M. Model 3D sometimes. That way it would be less trouble to find-replace names everywhere. Just a thought I had yesterday. Your name is Middleton, my name is Michael, the original is Misfit, maybe that can keep these pieces together, and honor the source too. I assume you changed the name only because it was asked of you.

My UI labors are panning out. I think you might be impressed with the switch away from Qt. Maybe we can abandon Qt then. I don't know if you're still interested in MM3D. You were pretty vocal about making a new modeler before right?

[zturtleman]

Making libmm3d a library used by multiple projects and maintaining it with stable API is not a goal I'm interested in pursuing. It seems like every time I make or enhance a model exporter or importer I have to change something in Model class which breaks ABI compatibility.

I changed the name because it would be difficult to refer to the original Misfit Model 3D and my fork otherwise.

You mean replace "Maverick Model 3D" with "MM3D" in the libmm3d code? If you mean in exporter messages, maybe add a define in mm3dconfig.h or function to set application name? If libmm3d was going to be a standalone library used by multiple projects it should probably be renamed and called "lib whatever" instead of "MM3D" to avoid confusion between Misfit Model 3D's libmm3d and whatever one the projects are sharing. I'm not a fan of "M. Model 3D" for the copyright headers for instance as this is not the name of the project.

Sure, it will be interesting to see how the UI turns out. Though I still have no intention of replacing Qt or maintaining multiple UIs for Maverick.

Maverick Model 3D will remain available and usable for creating and viewing models for Quake 3 and other old video games. It is not part of my future content creation workflow or a high priority for me to improve. I don't plan to work on code cleanup or trying to fix all the issues. (Non-UI redesign) pull requests are welcome though.

The new model utility I mentioned previously will replace my usage of Maverick for model viewer and skeletal animator. It will not have mesh or texture coordinates editing capabilities (which I don't use in Maverick) or support for a wide variety of model formats.

[m-7761]

I don't think MM3D rises to the level of a library fit for package systems. But it can still be useful, because there are not many 3D modeling libraries. I think it's a shame if it can't find a stable home. I think modeling software is one of the most complicated domains, so it is not appropriate to an ABI.

For me personally, I'm appalled by the primitive state of noncommercial 3D modeling software (libraries, utilities) so I think someone should be working responsibly in this area. I think copyright headers are dumb bloat, more talismans. But a full history of MM3D can be included in any materials. Somewhere there is licenses that must trace the origins because like every license has a clause that their wording must be included in all products going forward. But I think it doesn't rightly belong in source-code. That's one of those annoying trends that people do that truly amounts to nothing but hot air. Especially today, no one takes software copyrights seriously (it's like going to ridiculous lengths to protect your home from burglary when its net value of its contents is a few hundred dollars. Ideally code should be public domain anyway. The information age is in full swing now.)

In any case, I mean that ideally a proper name would only appear in licensing materials (not online help documentation) and in as few places in the application as possible, so it's easier to maintain. I think MM3D can be a general system for building 3D software. It's not without potential. When I get behind something it can turn around very quickly. But I've never had a good track record of achieving popularity with any of my projects. Quality and popularity don't go hand in hand unfortunately.

I think "M. Model 3D" can be fine in cases where you want to specifically refer to a proper name (assuming M. fits) but don't want to do find/replace on it. MM3D is best. But is more generic. It's like referring to the whole lineage. Like, the help files can easily make do with MM3D.

[m-7761]

For the record I'm looking at this problem right now, trying to include it in a round of code I'm soon to publish that also addresses the similar #53 that prevents most operations in the animation mode.

To address https://github.com/zturtleman/mm3d/blob/8c6c6ea29e2ad423d35ed1c2147f09c68f49d94b/doc/html/olh_quakemd2.htm#L42-L60 I'm thinking probably the frame data (which is quite small now) should be stored inside Vertex and instead of copying vertices on undo/redo, they should be inserted/deleted like some of the animation frames and other larger objects are already. I.e. the undo object takes ownership of the Vertex pointer. (EDITED: Actually they already seem to be deleted/inserted this way. Maybe that comment (quoted) came from an earlier time?)

[m-7761]

Solved: #134