The current implementation of the VRM0 exporter does not support generating sparse accessors. When I import a VRM0 file with sparse accessors and then export without doing any changes the exported file size expands much larger.
To Reproduce
Steps to reproduce the behavior:
Import VRM file that has sparse accessors (tested with vrm0 and vrm1)
Export VRM file with default settings
Notice that the exported VRM0 file does not contain sparse accessors and has a significantly larger file size compared to the original VRM0 file.
Here is a couple sample files with sparse accessors to test with:
Import and export to have the same file size if no changes were applied. For example, here's a couple other programs I tested to show that it's not the VRM file fault. The input and output are around the same size, unless sparse accessors were removed:
Expected Behavior:
The VRM0 exporter should generate sparse accessors when appropriate, optimizing the file size while maintaining compatibility with the glTF specification.
Actual Behavior:
The VRM0 exporter does not generate sparse accessors, resulting in larger file sizes compared to the original VRM0 files that contain sparse accessors.
Screenshots
Perhaps might want to look into these files:
When I modify like 2131 in vrm1_exporter.py to set export_try_sparse_sk=True the filesize doubles still from 34M -> 62M
Desktop (please complete the following information)
(Via Claude 3 Opus): To address this issue, I suggest the following steps:
In the export_vrm method of the Vrm0Exporter class, include the export_try_sparse_sk=True parameter when invoking the glTF exporter, similar to the VRM1 exporter.
Update the mesh_to_bin_and_dict method in the Vrm0Exporter class to export sparse accessors when the data is suitable, following the glTF specification. This may involve modifying the logic to identify and generate sparse accessors based on the sparsity of the data.
Ensure that any other relevant methods or classes in the VRM0 exporter are updated to handle sparse accessors correctly.
Describe the bug
The current implementation of the VRM0 exporter does not support generating sparse accessors. When I import a VRM0 file with sparse accessors and then export without doing any changes the exported file size expands much larger.
To Reproduce
Steps to reproduce the behavior:
Here is a couple sample files with sparse accessors to test with:
1.vrm.zip
1996.vrm.zip
Expected behavior
Import and export to have the same file size if no changes were applied. For example, here's a couple other programs I tested to show that it's not the VRM file fault. The input and output are around the same size, unless sparse accessors were removed:
Expected Behavior:
Actual Behavior:
Screenshots
Perhaps might want to look into these files:
When I modify like 2131 in vrm1_exporter.py to set
export_try_sparse_sk=Truethe filesize doubles still from 34M -> 62MDesktop (please complete the following information)
Additional context
Lyuma mentions sparse accessors here: https://github.com/saturday06/VRM-Addon-for-Blender/issues/381#issuecomment-1838365762
(Via Claude 3 Opus): To address this issue, I suggest the following steps:
export_vrmmethod of theVrm0Exporterclass, include theexport_try_sparse_sk=Trueparameter when invoking the glTF exporter, similar to the VRM1 exporter.mesh_to_bin_and_dictmethod in theVrm0Exporterclass to export sparse accessors when the data is suitable, following the glTF specification. This may involve modifying the logic to identify and generate sparse accessors based on the sparsity of the data.