Open m-7761 opened 4 years ago
Yeah, creating materials before creating groups makes sense.
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.)
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
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.