Closed andreasplesch closed 1 year ago
I addressed some of these points in https://github.com/KhronosGroup/glTF-Sample-Assets/pull/15
(The Sample-Models repo will probably soon be migrated to the Sample-Assets repo. I could integrate the same changes here, but that could be done if the other PR is considered to be OK...)
Thanks. The optimized glTF looks good to me from manual inspection. Interesting that there are still two different cube meshes, perhaps they are slightly different, from floating point precision or similar.
Admittedly, I didn't inspect the result in all details But the meshes do have the same indices and essentially the same vertex positions (and normals)
I assume that one mesh was created from the other one by "baking" a certain transformation (like a rotation or mirroring) into the positions. One could certainly optimize this further, boiling down to hand-tweaking the model or creating such a model programmatically from scratch. But I think that for the purpose of having a model for demonstrating the interpolation modes (without too many hints/warnings from the validator), the updated state should be OK.
Yes, completely agreed. I had manually reused the same box for all instances and it looked fine. Better to have a coded optimizer. Let me close this issue.
Looking more closely at the InterpolationTest example, there are a few oddities which are likely results from automated conversions:
The nine boxes have exactly the same mesh physically but are using distinct bufferViews and Material entries. This is confusing. The identical meshes and materials could be removed, and the nodes could refer to the same cube mesh.
There is a "Camera" and "Light" node which are not used.
The "Camera" node has a non-uniform scale, for some confusing reason.
The "Camera" and "Light" nodes could be removed.