A significant amount of time is being spent in CullResult.CreateSharedRendererScene and ExtractRenderNodeQueue.
The very weird part of the problem is that it’s even that expensive at locations where the camera looks at pretty much nothing. For example when I place the camera at the end of the world and look towards the world border and skydome only. While in other locations, where a huge part of the level is actually visible, this ExtractRenderNodeQueue cost does not exist.
There is only a single active Camera that renders the world and it uses Occlusion Culling. I have another Camera that renders a minimap and is placed below the world, it does not use Occlusion Culling. I also tested with OcclusionCulling turned off, but the cost is still there.
What is this CullResult.CreateSharedRendererScene and how can I get rid of the cost?
Sometimes Unity requires a huge amount of time to find the closest LightProbe in specific areas in one of our levels and for whatever reason, the cost is hidden under the “CreateSharedRendererScene” profiler entry.
@MartinTilo Can you add a profiler-marker to make the “find the closest LightProbe” cost more visible? At the moment it seems it’s tracked as CreateSharedRendererScene.
Hi @Peter77 ,
I’ve pinged the light-transport team about it and they replied that there has been a recent improvement around light probe performance, which came with new markers …
There was a related bug, which may provide some context, but the changes were implemented as a new feature, so there are no plans to backport this.
Hello, any api can do a operate like preload in Editor or Runtime? If has this api, i want to place it on a loading ui to prevent visible performance issue.
For Editor, if I can know which File need to open, I can read the file in a loading ui
Hello,
This gets out of my area of expertise so I’m not sure how much I can help with that. This may be better to be placed in it’s own thread in an appropriate subforum. I’ll try to give you some pointers though to get you started:
In 2020.3, you have the AsyncReadManagerMetrics API to record the operatuons done by the AsyncReadManager. That could probably help you identify the files that were read with this operation.
Also, in the CPU Profiler Module’s Hierarchy view, the toolbar for that view has a drop-down menu at it’s far right labeled “No Details”. In there is an option to show Related Data. With that details view added, and the File.Open sample selected, you may be able to see further data like the file name. I’m not certain if that was added in 2020 or 2021.
Also, if you switch to Timeline view and turn on Flow Event visualization, you may be able to see which AsyncReadManager requests this code is being synced on, and when selecting these, see the correlated file names in the selection tooltip.
As for preloading these assets to avoid these hitches, I’m not sure what could be done there. I guess it partially depends on what assets these are and if they can maybe be split into smaller ones, combined into bigger ones or loaded via Asset Bundles? I’m unsure what would provide what kind of benefits or drawbacks for either approach and would have to experiment myself, but with the Profiler to measure the results, and possibly Profile Analyzer to help compare the results in the broader scheme, this may put you in a better spot at optimizing this hitch out of your game.
If not, as I said, I’d take your findings to the forums and start a new thread
Hello, thanks for the detail answer, I use profiler and see File.Open first open a material and then open some Library/Artifacts files, and the amount is same with the material depedent textures, so I think these files are textures’ Library files.
We use AssetBundle load in final game, but in editor LoadAssetAtDataBase is more convenience, so leads this performance issue, now I think I can use AssetDatabase.GetDependcies before load asset and preload all these dependcies in loading ui.
Same here. After reading your reply the easiest solution for me was to add a gameobject with a lightprobe group, with several dozen lightprobes scattered around the map so that all the objects that use lightprobes have at least 3 somewhat close. That made the problem go away.
