everything you put into the same bound will go live if all async ops have finished. everything out of it is not affected and will render instantly. for instance
the sphere is sync, it renders immediately. model and environment are async, model most likely uses useGLTF which is suspense, and env loads a RGBE-texture, which is suspense. zoomcamera doesn’t suspend, but it will only render when both the model and the env are finished, all three will render together. so this becomes a formidable way to orchestrate behaviour, for instance, like above, zooming the cam in when everything’s loaded.
you can see an example of that here: Viking ship - CodeSandbox
when do you not want that … in cases where new things come in runtime. for instance, given this:
when ModelThatChangesEverySecond suspends the fallback is triggered, the fallback is null, that means everything inside the bound unmounts, and mounts again when ModelThatChangesEverySecond is finished. the solution is to wrap it into its own suspense so that it won’t disturb anything else:
now Model just remains and ModelThatChangesEverySecond lazily loads and shows when it’s ready.
there are more usecases, read through this to get an idea: https://twitter.com/0xca0a/status/1402558011357470720 in general understanding suspense will boost threejs like nothing else, this solves most if not all loading, async and orchestration problems people suffer from.
ps, i would recommend that you use suspense for each and every asset. suspense isn’t just good for orchestration, it will also allow re-use and memory efficient handling of resources. if you have an async thing and do not put it into suspense, why would you?