I want to spawn the character.
and my characters has 60k vertices / 20 materials(4mb for texture) for individual.
so, I instantiate assets, and combine in the scripts.
in the editor, my character spawned well without time problem.
but when I simulate / playtodevice / device build, the process is so slow down.
is the problem about the conversion of shader?
If this in MR mode/PolySpatial, the conversion of shader graphs to MaterialX happens at build time, so it wouldn’t be an issue here. However, loading the actual converted MaterialX materials does take time on visionOS. Does the character load faster on subsequent runs? I believe visionOS caches the compiled MaterialX in order to make runs after the first load faster.
Either way, if you submit a repro project with the assets that load slowly as a bug report and let us know the incident number (IN-#####), we can look into it.
Can material loading time be up to 20 seconds? (for about one hundred materials)
It doesn’t seem to matter whether it’s the first spawn or second spawn (or execution) from what I observe.
Additional information in my case:
I am using the Addressable system for my project.
The texture size is 1024*1024.
Have you ever experienced this?
I apologize for not being able to produce a detailed report
What are your thoughts on this issue?
Do you have any suggestions or advice for resolving it?
Do you mean a hundred different shader graphs, or just a few shader graphs reused on a hundred different material instances? We have seen long shader graph load times (even up to 30s, at least on initial load) for very complicated shader graphs (like the ones we use for bake-to-texture particles). We’re investigating ways to preload them (along with other assets) and perhaps provide an API to show a loading indicator of some sort.
It would be interesting to see if you experience the same issues if you replace all the materials with basic (non-shader-graph) unlit ones. Similarly, if it’s the textures, you might try replacing those with single pixel textures just to narrow down what’s taking so long.
Another option would be using time sample profiling from Xcode instruments (for the 20s loading interval) just to see if that indicates where the processing is happening during loading (and, especially, if it’s in Unity code that we can optimize or Apple code that we can report to them).
1 Like
That’s a long time for a mesh! I’d ask if it was large, but you said it was only 60k vertices. That code (MeshResource.replace) isn’t under our control, but in the future (on visionOS 2.0), we might be able to use the LowLevelMesh API to make mesh updates faster.