Performance on high draw calls

[Aloalo]

The attached GLB has ~3000 draw calls, and performance on it is poor (~20FPS on a relatively powerful desktop). Three.js based viewers and babylon.js have much better performance (locked to 60FPS on the same machine).
I understand that the sample viewer is meant to be a reference viewer and not compete with production level viewers in performance. My question is whether any improvement on this is planned?

dress.zip

[UX3D-nopper]

I assume, that they batch a mesh (primitive and the same material) into one draw call and use internally instanced rendering.
For this asset, of course, this does provide a big boost.
The glTF Sample Viewer - for any asset - currently iterates the node hierachy and - if required for transparency - sorts them.
Technically correct, but regarding performance of course not optimal.
At this point of time, regarding performance, nothing is planned.

[Aloalo]

Understood, thank you. Regarding your assumption - it's correct for babylon.js but the three.js based viewers actually preform all the draw calls. They only use instancin if EXT_mesh_gpu_instancing is enabled for the asset.

[UX3D-nopper]

Okay, I'll keep the ticket open. Maybe somewhere - a low hanging fruit - can improve the performance.

[UX3D-nopper]

@UX3D-becher @UX3D-eckerlein Maybe someone can have a look, if e.g. somewhere some tasks can be avoided?