Component counts are generated by counting the decimal points on each line, there is potential for this to break if any data happens to contain whole numbers for the v/vt/vn or colour values.
Some wavefront files contain square faces, currently we don't read past 3 face components.
Material files are parsed, but not handled in import/export.
Exporting a model after a call to Entitiy::flipVertexOrder() causes the model to be exported with flipped vertices, this has the effect of the same code then loading the exported model instead, and rendering the wrong faces.
Texture current has bindToShader() method, this would be more logical the other way round. Whereby shader has a wrapper over addTextureUniform() that takes a Texture subclass. Similarly it could also be proxied through Entity?
If an .obj file contains multiple components, and only some of those components use texture coords (or similar), the loader is likely to crash, as it will assume that all components use textuer coords. (It loads all components as a single component)
Entitiy::flipVertexOrder()causes the model to be exported with flipped vertices, this has the effect of the same code then loading the exported model instead, and rendering the wrong faces.Texturecurrent hasbindToShader()method, this would be more logical the other way round. Whereby shader has a wrapper overaddTextureUniform()that takes aTexturesubclass. Similarly it could also be proxied throughEntity?