search

zturtleman / mm3d

Maverick Model 3D is a 3D model editor and animator for games.
https://clover.moe/mm3d
GNU General Public License v2.0
114 stars 22 forks source link

Quibble: Should setEndianness be put to use in theory? #136

Open m-7761 opened 4 years ago

m-7761 commented 4 years ago

LE is dominating desktops, and I suppose it's not worth fixing until someone reports a problem, but I'm curious in theory (do we know?) if the loaders should be checking for the file's byte-order (where possible) at runtime?

P.S. I ask too just to verify that MM3D format files are always stored LE? (Edited: I'm writing an Assimp loader and wondering if I should prefer hard-coded byte-order or runtime byte-order.)

m-7761 commented 4 years ago

What do you make of this?! Noticed readFile uses htob_u32 and htol_u32 at one point:

https://github.com/zturtleman/mm3d/blob/9c9a2318b3418ef69d24aea572aeace111e1b6e3/src/libmm3d/mm3dfilter.cc#L2046-L2065

This doesn't make any sense to me? If there's good reason behind this code it needs describing. I think it should probably be removed entirely.

zturtleman commented 4 years ago

Big endian mm3d files are outside of the specification and don't need to be supported. MM3D format spec: "MM3D uses Intel byte order (least significant byte first)."

The bone joint parent endian check is necessary for loading .mm3d models written by Misfit Model 3D 1.1.7 to 1.1.9 on big endian systems. There is however no support for .mm3d files written by MM3D 1.1.6 or earlier on big endian systems.

MM3D 1.1.6 and earlier wrote .mm3d files using native endian. MM3D 1.1.7 changed to always read and write as little endian. However the bone joint parent was still written using the native endian (bug). Writing bone joint parent was corrected to always be little endian in MM3D 1.1.10. This is also when the the run-time endian check for bone joint parent was added.

I doubt it's necessary for a new loader. I'll leave it in Maverick though. I added a comment in d89ab5104aeca890ee46321720a5266dbf80b45a.

m-7761 commented 4 years ago

Out of curiosity, why is the "ref" version of this file (mm3dfilter_ref.cc) maintained? Whatever it is, can't it be linked to in the version history?

m-7761 commented 4 years ago

Double-post: Are there file-format versions corresponding to those app versions? Does it apply to the current version? 1.7?

zturtleman commented 4 years ago

The reference mm3dfilter is the un-C++ified version I guess? I don't know why it's maintained. I'd rather not have the linked reference be immutable dead code but link it from where?

Misfit Model 3D 1.1.3—1.1.8 -- mm3d format version 1.3 Misfit Model 3D 1.1.9—1.2.4 -- mm3d format version 1.4

I think odd minor versions (of editor and model format) are development versions. 1.7 only exists in Maverick. 1.6 is the most recent official mm3d format version.

m-7761 commented 4 years ago

It occurred to me instead changing the "magic number" a major-version change is a viable alternative, but I looked now and noticed it checks for equality instead of less-equal:

https://github.com/zturtleman/mm3d/blob/d89ab5104aeca890ee46321720a5266dbf80b45a/src/libmm3d/mm3dfilter.cc#L720-L723

I changed the major-version to 2 with the magic-number change anyway. I suppose the magic-number could be kept. I think it's a bigger issue for third-party code that loads MM3D files than MM3D itself, of which I don't know if any such third-party code exists or not.

I think since Misfit has officially ended the software it's probably appropriate to change the magic-number anyway, just to sever ties to the company.

(Off-topic: It occurred to me only last week when I was penning an announcement that a perfectly generic name for a noncommercial modeling library using MM3D is "Multimedia-3D" which also has an anachronistic feel harking back to the 90s. Today it's not used. I'm definitely interested in adding support for other kinds of art, but not all in one app. The UI becomes unwieldy if it's not focused. The apps could talk between themselves.)

While I'm here, I really think we should finalize a system for either combining the animations into one or allowing for joint animation in frame-animation mode. I think it will be too much trouble for artists to have to work blind on frame-animations, just imagining what they'd look like combined with a skeletal animation, or too unwieldy to provide a third hybrid animation mode.