Why is photogrammetry more demanding that autogen?

[pillowbee]

@Kjaye767

otogrammetry run slower than the autogenerated landscapes?

It makes no sense to me as Google Earth VR is butter smooth, and did so even on my old computer way back in 2017, it was like the photogrammetry has no impact on framerate.

Yet the photogrammetry is choppy in the sim? What’s weirder is that on flightsim.to I’ve downloaded mods that add photogrammetry from Google Earth into the sim, for example the city of Exeter. It looks great, but is unplayably choppy even with my 3090, whereas the same scenery in Google Earth VR is butter smooth?

Intuition and common sense make me think the computer having to precess autogen scenery would be a lot more demanding than merely displaying preformed photogrammetry, but in practice, the opposite seems true.

There are a couple of reasons for this, what I have found is what I believe to be one of two things;

Either a. the loading in of any cloud based scenery requires CPU usage that is tied to the main thread and will cause a ‘stutter’ if it cannot download said scenery in a timely manner. This is because the mainthread is ‘paused’ until it receives the data that has been requested and loaded in the scenery. Obviously, photogrammetry is ‘heavier’ to stream than the standard scenery + autogen so this effect is more noticeable with photogrammetry. There is nothing you personally can do but I have a thought that the developers may be able to think about below.

b. the loading in of scenery requires CPU usage whereby your CPU is already maxed out in several threads. This can be remediated by buying a better CPU. I don’t believe the stutters that photogrammetry loading in is caused by a GPU restriction (you can confirm this by looking at the developer FPS overlay).

I believe if the problem is A then the developers need to develop some sort of prioritization whereby scenery is a lower priority thread and does not hold up the main thread if it cannot load in quickly enough. A good example of this is if you play on a simulation rate of more than say 4x - you will notice a lot of stuttering caused by scenery trying to load in. If the simulator can prioritise the rendering before loading in the scenery you would end up in a position where it remains smooth but the scenery does not load in (i.e. the priority of loading scenery is reduced). What this MIGHT cause is that you see lower quality photogrammetry because your CPU cannot load the higher quality assets in a timely manner (essentially causing option B above).

I find this akin to how Android and iOS handled web page rendering - for anyone that has noticed this themselves. If you got back a few years when scrolling a webpage on Android it would always try to render the entire page so as you scroll you could see all of the content - the problem is the scrolling animation would be noticeably stuttery (even on high end Android phones). On iOS you would get the opposite issue - the scrolling animation was always buttery smooth but if you scroll too quickly you get the ‘checkerboard’ pattern while it tried to load in the graphic of the webpage for a moment. The scroll animation remained smooth all the way through though. Currently scenery loading is using the ‘Android’ approach hence why there are notable stutters when scenery is loaded in.

You can prove this to yourself by looking at your FPS whilst the scenery loads in (i.e. downloads) and compare it to after a few seconds once it has already loaded in. CPU usage drops and the FPS stabilises after it has loaded in.