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

MM3D file order: Is reordering at issue? #130

Open m-7761 opened 4 years ago

m-7761 commented 4 years ago

I've been fixing some code that bypasses the API (encapsulation) and one problem that comes up is the loaders put the Group code before the Material code so setGroupTextureId fails to take.

For mm3dfilter.cc the Group sections can just be made to go after the Material sections. I've just used a const_cast to bypass the API to set the ID but future code might want to do bookkeeping to be better optimized... which is what I'm doing, just not regarding group/materials.

zturtleman commented 4 years ago

Yeah, creating materials before creating groups makes sense.

m-7761 commented 4 years ago

I changed it (read/write) to MDT_Materials/MDT_Groups/MDT_SmoothAngles (though I think it would be good to stop writing MDT_SmoothAngles if I remember to work on it) and following that (unchanged) is MDT_ExtTextures/MDT_TexCoords. (I think implementing the embedded textures feature is probably worthwhile. Right now I'm trying to wrap up my work and take a break from MM3D maybe for the rest of 2020 except for light fixes/changes/negotiations.)

I've left the MS3D loader to use const_cast for now. It could use a vector but I don't expect this to be a problem. What I'm doing is moving the getVertexList API (and friends) from ModelFilter into Model and making it const only so changing the model can't bypass the API without const_cast. I'm doing this because the triangle indices need to build a list of triangles inside Vertex to better the normal generation facilities. (The triangle indices hold the index in the high 2 bits to access the smooth normal angles.)

Later this connectivity data can be used to do spot-fixes on normals but for right now I'm just going to leave it at recalculating the entire model since there are lot of things that would benefit from more granular bookkeeping and I'd rather implement and test them all at the same time. (I think it will perform better but that will depend on cache performance. I'm using std::string for the list so it may benefit from small-string optimization.)

EDITED: Exposing the data via const should speed up a lot of code, but using the API for reading is not as optimal as before but safer... there could be new APIs for reading. Currently the library relies on the API to no-op when reading fails. That's why the API has to be so defensive, which I'm not sure is for the best. A new read API could be so defensive. (In theory exceptions could be used on read failure but that wouldn't protect against files with bad data.)

m-7761 commented 4 years ago

Related, I'm removing MDT_JointVertices from writing. It's some kind of anachronistic thing that is work intensive... a comment says:

    // Joint Vertices
    // Newer versions of the file format do not use this section,but old
    // versions of mm3d need it.  Write it for the sake of backwards 
    // compatibility