# Call to participate: keep adopting GLTF standard, an ongoing conversation

**URL:** https://forum.decentraland.org/t/call-to-participate-keep-adopting-gltf-standard-an-ongoing-conversation/23324
**Category:** Implementation Journal
**Created:** [November 18, 2024, 2:27pm UTC](https://forum.decentraland.org/t/call-to-participate-keep-adopting-gltf-standard-an-ongoing-conversation/23324 "2024-11-18T14:27:34Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![leangodotdev](https://avatars.discourse-cdn.com/v4/letter/l/d78d45/32.png) [@leangodotdev](https://forum.decentraland.org/u/leangodotdev)
#### Post date: [November 18, 2024, 2:27pm UTC](https://forum.decentraland.org/t/call-to-participate-keep-adopting-gltf-standard-an-ongoing-conversation/23324/1 "2024-11-18T14:27:34Z")

</div>

Hello community, I’m creating this post to give visibility to this ongoing conversation

- [ADR 253: Exposing GLTF internals by leanmendoza · Pull Request #273 · decentraland/adr · GitHub](https://github.com/decentraland/adr/pull/273)

## Context

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](https://dclexplorer.github.io/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.

---

<div class="post-metadata">

### Author: ![OnSr](https://avatars.discourse-cdn.com/v4/letter/o/a8b319/32.png) [@OnSr](https://forum.decentraland.org/u/OnSr)
#### Post date: [November 18, 2024, 3:39pm UTC](https://forum.decentraland.org/t/call-to-participate-keep-adopting-gltf-standard-an-ongoing-conversation/23324/2 "2024-11-18T15:39:57Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![leangodotdev](https://avatars.discourse-cdn.com/v4/letter/l/d78d45/32.png) [@leangodotdev](https://forum.decentraland.org/u/leangodotdev)
#### Post date: [November 18, 2024, 3:50pm UTC](https://forum.decentraland.org/t/call-to-participate-keep-adopting-gltf-standard-an-ongoing-conversation/23324/3 "2024-11-18T15:50:09Z")

</div>

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

---

<div class="post-metadata">

### Author: ![OnSr](https://avatars.discourse-cdn.com/v4/letter/o/a8b319/32.png) [@OnSr](https://forum.decentraland.org/u/OnSr)
#### Post date: [November 18, 2024, 5:57pm UTC](https://forum.decentraland.org/t/call-to-participate-keep-adopting-gltf-standard-an-ongoing-conversation/23324/4 "2024-11-18T17:57:39Z")

</div>

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.
