You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 10, 2022. It is now read-only.
Currently GLTF resources, such as materials, textures, index, and vertex buffers are reused across apps or instances, and if drawn multiple times would automatically be batched by the instance renderer.
However, if an MRE manually creates a material or mesh, each instances would create GPU resources. So two instances of an MRE in the same space would create 2 instances of the resources, causing separate, un-batched drawcalls.
We could look at, in the unity runtime, hashing the material creation properties and cache the generated resources based on the hash. We'd then rely on the same copy-on-write logic we use for other resources to avoid modifying assets that another instance may consider immutable.
This approach wouldn't just help a single MRE, but help across MREs that share identical materials, for example using a shared UI library
The text was updated successfully, but these errors were encountered:
We did this in the browser-based Altspace SDK, and it added a lot of complexity (read: hard to debug Unity-side and hard to optimize app-side) for very little benefit. How often are multiple instances of the same MRE rendering at the same time in real usage? Probably better to encourage the apps to reuse materials than to try to guess when it's safe to reuse.
Maybe we could write a VSCode extension that would detect if you're never modifying materials, and suggest static glTFs instead?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently GLTF resources, such as materials, textures, index, and vertex buffers are reused across apps or instances, and if drawn multiple times would automatically be batched by the instance renderer.
However, if an MRE manually creates a material or mesh, each instances would create GPU resources. So two instances of an MRE in the same space would create 2 instances of the resources, causing separate, un-batched drawcalls.
We could look at, in the unity runtime, hashing the material creation properties and cache the generated resources based on the hash. We'd then rely on the same copy-on-write logic we use for other resources to avoid modifying assets that another instance may consider immutable.
This approach wouldn't just help a single MRE, but help across MREs that share identical materials, for example using a shared UI library
The text was updated successfully, but these errors were encountered: