Search Issue Tracker
Fixed
Fixed in 2023.1.0a10
Votes
4
Found in
2020.3.26f1
Issue ID
UUM-1883
Regression
Yes
TerrainData.AwakeFromLoad takes around 13-19 ms after loading a Terrain from an asset bundle
How to reproduce:
1. Open the attached project ("TerrainBundleTest.zip")
2. Open Profiler if it's not open (Ctrl/command + 7)
3. Enter Play Mode, wait for the terrain to load, and exit Play Mode
4. In the Profiler hierarchy view search for the keyword "TerrainData.AwakeFromLoad" in the first few frames of the Profiler data
Expected result: TerrainData.AwakeFromLoad does not take 13-19 ms of time
Actual result: TerrainData.AwakeFromLoad takes 13-19 ms of time
Reproducible with: 2020.2.0b10, 2020.3.26f1
Not reproducible with: 2019.4.34f1, 2020.2.0b9, 2021.2.8f1, 2022.1.0b4, 2022.2.0a2
Note:
- If you select the Assets/Terrain and change the heightmap resolution of the terrain to 513 * 513, rebuild the asset bundle that contains the terrain asset (I.e. Go to the addressables group window and perform a rebuild there) and repeat steps 1 - 5, the delay for TerrainData.AwakeFromLoad reduces to less than 5 ms.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- SRP Batcher compatibility of the same shader changes when changing Graphics API for Windows from OpenGLES3 to Direct3D11
- Crash on PhysicsManager::AwakeFromLoad when entering Play Mode
- Freeze/crash on MemoryProfilerStats::UnregisterObject when DownloadHandlerTexture is used and Texture2D is already destroyed
- Nested Prefab structure breaks when Redoing override operation
- Crash on Scripting::ScriptingWrapperFor(Object*) when opening project
Resolution Note (fix version 2023.1.0a10):
The fix reduces the amount of time taken on the main thread to async load a terrain. The physics system still takes some time on the main thread to set up the terrain collider.