You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When I was working on a lot of animation objects, I found that even if I used the same objects and the same animation in blender, I still found that the file size became larger after exporting due to the duplication of animation data.
I can understand that it is normal for TRS animations of multiple objects to have no reference relationship, but shape key animations based on object data do need reference relationships (because they are the same in most cases)
This also makes the export time longer.
To Reproduce
Steps to reproduce the behavior:
1 I first made a mesh with shape key animation in blender (based on the MDD plug-in, the baked vertex animation has 100 frames), and then copied it 360 times
20241127-155628.mp4
2 When exporting, I exported two files by checking whether the shape key animation was checked, one with animation and one without animation (but both contain shape key data)
3 After exporting, it can be noticed that the file with shape key animation is 14.2MB, and the file without shape key animation is 9.5MB. The export time of the former is 41s and the latter is 1.5s
In addition, I tested the export of 180 files. The export time was 12 seconds and the file size was 11.8 MB.
I just discovered that the slow export speed issue can be solved by checking force keeping channel for objects in optimize animations. However, this does not help with the file size.
I just discovered that the slow export speed issue can be solved by checking force keeping channel for objects in optimize animations. However, this does not help with the file size.
I can not reproduce any big performance changes using this option or not with the test file. But please do not mix different subjects into a single ticket.
Come back to original one:
I can confirm that sampler inputs are shared, but not outputs.
Currently outputs are not cached.
I just tested it. It will work, with a little performance slowdown (and probably an increase of memory usage)
Thank you. Back to the original question, I tested and exported it and there was no performance change (several or hundreds of the same shape key animations get about the same FPS in babylon.js), but the file size will increase a little (and the increase will be greater as the number increases). This is what bothers me at the moment.
Because I may need to do some crowd animations at work (maybe thousands of them, using GPU instance and shape key animation to optimize performance) but this will make the file very large, thus reducing usability
Describe the bug
When I was working on a lot of animation objects, I found that even if I used the same objects and the same animation in blender, I still found that the file size became larger after exporting due to the duplication of animation data.
I can understand that it is normal for TRS animations of multiple objects to have no reference relationship, but shape key animations based on object data do need reference relationships (because they are the same in most cases)
This also makes the export time longer.
To Reproduce
Steps to reproduce the behavior:
1 I first made a mesh with shape key animation in blender (based on the MDD plug-in, the baked vertex animation has 100 frames), and then copied it 360 times
20241127-155628.mp4
2 When exporting, I exported two files by checking whether the shape key animation was checked, one with animation and one without animation (but both contain shape key data)
3 After exporting, it can be noticed that the file with shape key animation is 14.2MB, and the file without shape key animation is 9.5MB. The export time of the former is 41s and the latter is 1.5s
In addition, I tested the export of 180 files. The export time was 12 seconds and the file size was 11.8 MB.
.blend file/ .gltf (mandatory)
test-blend.zip
test-glb.zip
Version
The text was updated successfully, but these errors were encountered: