the translation is "baked" into the geometry data about gltf-pipeline HOT 5 CLOSED

@javagl is correct. node-_161000103jz0271b has a huge translation component in its matrix. This transform is applied to the primitives when the node hierarchy is flattened. My suggestion would be to make your transform matrix in the glTF more reasonable and then do the conversion. It looks like you're using Cesium for viewing, so you can do the translation by changing the origin of where you place the model instead of storing it in the glTF.

from gltf-pipeline.

@lasalvavida Is there a particular reason to bake the transform into the primitives? I can imagine that there are cases where this makes sense (maybe related to quantization?), but maybe there should be an option to disable this? At least, I found the idea somewhat appealing that a binary glTF is basically the same glTF asset (with the same buffer data, verbatim), only combined into a single file, but without unnecessary structural or semantic modifications.

from gltf-pipeline.

This is similar to #186. Right now the default behavior does not preserve the hierarchy. We plan on adding an optimize flag that will keep the hierarchy intact when false.

from gltf-pipeline.

@javagl We do it because this is an optimization pipeline. We want to reduce draw calls and the way to do that is to have fewer primitives. If two primitives are part of meshes on different nodes, we have to transform them to be under the same parent in order to combine them. It may be possible to make this process less greedy (don't transform anything unless there is a primitive we can combine with after flattening), but I think the best answer here is just to allow enabling/disabling of the optimization.

from gltf-pipeline.

Reducing the number of draw calls sounds familiar. (I'm not an expert here, but IIRC the draw calls are less of a problem than e.g. state changes, but I assume that this is optimized in the gltf-pipeline as well).

Intuitively, it could make sense to let the coordinates of one merged geometry refer to the bounding box of this geometry, and still use the nodes to set up the (possibly huge) translations of the merged geometries. But I'm sure that something like this will be part of the different options for the exact implementation of such an optimize flag that will be considered.

In any case, your suggestion of creating the glb with an identity transform and then translating the whole glb via the root modelMatrix should solve this particular issue.

from gltf-pipeline.