Hey!
I’m working on a first person open-world app using the loading manager as a loading screen, before the app begins. It handles loading all elements (textures, GLBs, audio, etc.). However, since not all my GLBs are rendered in the same location, I experience a freeze when approaching them for the first time. When I move away and return, the freeze doesn’t occur, likely because the asset has been cached. But which assets are cached? I thought everything was being loaded by my Loading Manager.
Can anyone help me understand what’s causing this and suggest a potential fix? Would adding a 1-frame render of each object/location in the loading manager help prevent this issue? If so, how would I go about doing that? This happens with all my objects, and the freeze is much more noticeable on slower devices. So you might need to throttle the CPU in the dev tools to see it on the demo.
Cheers!
Code: Showroom-Prototype/src/Experience/Utils/Resources.js at 012867303b7ae47e4e0a24a9ff5797077556e97e · MattiasBaldi/Showroom-Prototype · GitHub
Prototype: https://prototype-three-showroom.vercel.app/
There are a bunch of blocking, or semi blocking events that happen when loading a GLB.
the fetch itself is mostly asynchronous… but then uploading the mesh and texture to the GPU the first time it is rendered, can cause a hitch, especially when addingmultiple objects all on the same frame. It’s sometimes worth putting them in a list and adding them one at a time each frame… that can spread some of the blocking stuff out over a few frames.
Another other option is to just preload everything at app start, and render it all once first like you describe.
2 Likes
You can run a performance profile and look at the flamechart to check, but in most cases the total texture resolution or vertex count are the problem. In this case I would look to reduce both if you can, and to reduce that large block in the flamechart:
Note that it’s total resolution of textures — not file size! — that matters here, because they need to be fully decompressed for GPU upload. Similarly, geometry compression like Draco reduces file size but the vertices still have to be decompressed, so this doesn’t help with the GPU upload. Blender decimation would help with the vertex count, perhaps.
If you feel like the vertex count and texture resolution are as low as you can get them while maintaining good quality, then everything @manthrax mentions is the next step I think!
1 Like
Hiya, I will get back to this soon, been really caught up with another project. Just wanna say thanks for taking the time to always get back on my posts, I appreciate it!
