Still a draft. So far this PR tracks which properties have been created or cloned during the quantization process, and considers only those properties for pruning.
We'll still need to consider how to implement deduplication without actually running the whole dedup() transform. Currently the implementation of dedup is fairly complicated — it was written before a.equals(b) was available I think. Maybe it could be simpler by using that. But we need to be pretty careful to not introduce performance regressions for models that may have many thousands of accessors. My rough ideas for next steps would be:
expose separate functions like
getDuplicateMaterials(materials)
getDuplicateAccessors(accessors)
...
call those functions with all materials/accessors/... in dedup() and only with modified properties in quantize()
clean things up and simplify as much as possible
If anyone is interested in improving dedup() in a separate PR please let me know, I'm not sure yet when I'll get to that.
Still a draft. So far this PR tracks which properties have been created or cloned during the quantization process, and considers only those properties for pruning.
We'll still need to consider how to implement deduplication without actually running the whole
dedup()
transform. Currently the implementation ofdedup
is fairly complicated — it was written beforea.equals(b)
was available I think. Maybe it could be simpler by using that. But we need to be pretty careful to not introduce performance regressions for models that may have many thousands of accessors. My rough ideas for next steps would be:getDuplicateMaterials(materials)
getDuplicateAccessors(accessors)
dedup()
and only with modified properties inquantize()
If anyone is interested in improving
dedup()
in a separate PR please let me know, I'm not sure yet when I'll get to that.