koobas.hobune.stream
Are the Awake functions not run on the main thread?
I ask this because I had an issue where I was getting a massive 2000-20000ms spike a few seconds AFTER the game would start, in fact I could even move around a bit first. Now after some profiling I realized this was caused by the Realtime Reflection Probes and their Update mode being OnAwake. Now I was always under the impression that Awake functions ran consecutively on the main thread, as it enabled each active object. So why then, does the reflection probe Awake update happen seconds after I am already able to move around? I would think it would happen when everything else initializes and that this spike would occur during the initial loading process. What am I missing here?
Awake is called on the main thread, otherwise you wouldn't be able to use any Unity API in that callback. Awake is usually called immediately after an object is created. However since the reflection probe are built in native components they are not bound to the managed scripting rules. "OnAwake" could mean anything since the component is actually handled on the native C++ side. Though such a long delay would be unusual. I haven't used the reflection probes yet so i can't say anything about them. Did you do a deep profile?
According to this the refresh mode OnAwake will update the probes at "start". Since they explicitly mention that this is useful for dynamically setup environments, the actual update can not be done during the managed Awake callback since you wouldn't have any time to setup anything dynamically. Awake is actually called before anything ever get rendered. However the reflection probes actually need to render the scene. So it most likely will do the update shortly after Start.
You could use the refresh mode "Via Scripting" and develop your own update procedure for the probes and see if it helps.
That makes a lot of sense, not sure why I didn't think about the fact the scene needs rendered BEFORE it can create reflection probe data. Also I guess the reason for the spike, and this is with profiling I discovered it, is that when reflection probe data is being constructed, it has to render all the effect objects at once, and I had a VERY complex scene with a lot of reflection probes. According to the profiler, it was basically rendering more than my computer was capable of handing, locking it up until it was able to complete the process. What bothered my was that it happened AFTER my play could move around, but I realize that Baked probes was more adequate for what I wanted, and they seem to have very little overhead and no runtime setup cost.
