During our last grant period (May-Oct), the protocol squad has experimented with thinking and testing new tools for SDK creators.
You can test by yourself the experiment and provide feedback (here, on updates or Discord): Introduction - DCL Explorer Book
In this case, the Exposing GLTF internals proposal is the one raised in the quoted ADR. In summary, with this, you can access to GLTF internal nodes and manipulate them seamlessly from the scene.
Very interesting conversation. I highly appreciate the performance concerns as I am rooted for a browser client (sad to see there isn’t much interest for a DCL client for browser). Yet, we should leave optimization choices to the scene developers. Let’s provide every possible tool creators want, so that we can benefit from their creativity as much as possible. Limiting creators is mostly a bad idea.
P.S.: Scene limitations and wearable limitations are fine. Limit how many you can create something, but don’t limit what you can create.
Performance is always a key while introducing new things. But the protocol discussion is in middle of the two actors that should tackle performance concern:
Explorer: it should identify when a scene is bad performing and take an action by limiting it or shutting it down (worst case, extreme case)
SDK: you as creator should have tools to realize when you scene is ok, to avoid that the explorer limitates it and to ensure you scene works fine, and it isn’t bad for the neighbors
Totally agree with your proposal. Changing material of a node could maybe achieved somehow but I was looking for a way to play with bones, sadly there is currently no way in the SDK.