形态键测试41.zip (2.5 KB)
This is a test model, which is a cube with six sides of different materials. I added three form keys to it in blender. I imported it into the sandbox to check that its six faces were divided into six primitives, each with a complete set of morphs. And they are not referential relationships. This makes a single modification of the value of a form key appear unpredictably, and morph referenced vertex data doubles the memory footprint. I wonder why it doesn’t reference the same origin as material and geometry?I think this leads to excessive memory consumption when importing a model with very many morphic keys and multiple primitives.
1 Like
I’m assuming this was a translation since it’s a bit difficult to understand what you are saying. I think you are asking why the morph targets are not stored as deltas from the original shape? glTF stores morph target attributes (e.g., positions) as deltas. Babylon.js stores the morph targets as absolute values. I’m not sure how much memory would actually be saved since everything gets uploaded to the shader anyways as an array of values (either an a uniform or a texture).
Sorry, this is translated, it’s a little hard to understand.
I mean, babylonjs creates a separate morphTarget set for each of the isolated primitives.
I double-checked my model and found that my idea was wrong.
The morphTarget vertex data is split up along with the primitives and does not have the memory footprint problem I assumed.
Now I just need to figure out how to correlate these split morphTarget influence property changes together.
Thanks for your reply!
1 Like
Test unicode | Babylon.js Playground (babylonjs.com)
Example of primitive grid synchronization morphTarget.influence.
1 Like