This is call for third party developers because I keep finding airports which use insane amounts of Simobjects to reproduce general aviation parked on big airports. I recently found one airport using 250 of them but it´s not the only case I found during the past months. The impact on performance using such insane amount of Simobjects is severe for several reasons, even on high-end systems. First one is that those 3D models are very detailed (they are exactly the same ones used when you fly those airplanes in game as player). The other reason is that game still handles their physics even if they are just parked and inactive. They are still simulated objects to the eyes of the engine.
Please, if you still want to use some of them to decorate your airports just add small amounts of them. Using them is like using AI traffic without the optimized generic 3D models game has for AI traffic. The correct approach would be to replace them by static 3D models (type scenery) as they have a much lower FPS hit and they are not simulated objects for the game engine. You can also combine those static models with a few Simobjects at specific locations as well, but that number should not be too high anyway. I hope this helps.
Also there is a hard coded limit in MSFS of 1000 sim objects existing at a time, if you breach it then the sim just stops creating them and this causes mayhem with products like GSX. This is a limit that many have hit, myself included.
It would be well worth listing sceneries which are using excessive sim objects so that consumers can make an informed choice about how they spend their money.
Even 100 Simobjects create performance problems on big airports, so imagine. An that´s with AI traffic completely disabled. Once you add any traffic the performance figures drop like crazy. The amount of Simobjects should be kept low and tests are needed before releasing the addon to calibrate the performance impact. You can disable them at world editor and compare the difference between airport alone and airport with those parked Simobjects.
When I read your OP yesterday, I just wanted to shove my head in the sand about it.
I wish the MSFS ecosystem had (at least as far as the Marketplace is concerned) a baseline of standards that add-ons had to meet; beyond MS’ ESRB/PEGI requirements and whatever other minor checks they require.
Throughout this forum there are debates regarding how much MS ought to do regarding quality control, gatekeeping, etc. and I don’t wish to reopen that sort of dialog here (because it doesn’t conclude), but I do wish there was some basic technical standards.
This is especially important when we are talking about add-ons that wreak havoc on the sim’s performance that the end-user would have no realization of why.
There are numerous cases of errors in the base configuration files of add-ons that cause issues. I’m always baffled when I’ve bought something as innocuous as a livery pack on the Marketplace and the livery pack alters the basic name of an aircraft as listed in the aircraft selection page of the sim. How can something like that not be rejected by the add-on ingestion QC process?
Likewise, why isn’t there a basic check for the “heaviness” of a scenery/airport add-on? Given the issues the Xbox user-base face with black avionics, CTDs, heavy stutters, etc. due to the overhead of these add-ons, coupled with no refunds, it just seems really messed up and unfair to them, specifically.
I’m not talking about a QC process that clears or rejects add-ons for subjective reasons, but if an add-on isn’t adhering to the base SDK’s requirements/format, it ought to get kicked back to the dev for reworking prior to being placed for sale.
It is really frustrating to be a hapless, unsuspecting consumer here.
Unfortunatelly you can´t claim that those addons are not following the standards, because they do it indeed. Adding Simobjects is not only possible according to SDK but even required at some situations. But a wrong usage is like using a superdetailed terminal with interior in an int. airport inside a giant city. It will have an impact because the surrounding area without the airport already has an impact itself. This is something QC may not be able to reject. It´s author´s responsibility to develop something reasonable and balanced and test it progressively as new features are added to the addon to detect the potential performance bottlenecks.
I agree with you that we are living hard times nowadays. Game baseline does not help either because it´s also plagged with issues itself. However many airport addons still work really fine and they have a correct balance between quality and performance, so it´s clearly possible to produce good content that works also reliably.
Right, I’m not saying they aren’t, I’m suggesting they need a standard for these SimObjects as scenery.
I’ve linked this post a few times, because it outlines how hard the dev team has worked to try and get the Xbox version to work — to make everyone happy. What is ridiculous about this is, because they don’t have a standard/requirement for the use of SimObjects, they are having to go to extraordinary measures at the development-end to address the problem.
Why the **** wouldn’t you just gatekeep these add-ons at the outset and pour all that development effort into something else?!
Yeah I see the point. Situation is not so black or white. It´s true that most developers just use one LOD for terminals and secondary objects for instance because that´s easier, while Asobo´s content still uses several LODs for terminals for instance. One LOD only loads the airport at full detail at around 20-30 nm away. On the other hand game has a limitation using CGLs (the satellite textures), because they can´t be compressed. So engine needs to load the full resolution texture, which is like 3-4 GB size in one go as soon as airport is loaded. Third parties and even myself had to use those CGLs as original Bing textures had errors or airport area was hidden by Bing if airport did not exist in game, like in the case of military bases. Some Asobo handcrafted airports also use those CGLs too (LDRI for instance) but covering smaller areas and therefore with not so big sizes normally because they come once the WUs are already in place and the ground textures have been therefore updated.
Reducing LODs artificially in engine as they did does not solve the problems, even if they may still help a little to mitigate them. That was only a patch. The real problem is not only the detailed LODs and CGLs but that main thread drives all efforts from this and from the rest relevant features from simulation. You can reduce LODs to silly values that the problems will be still there. Airport may load at full resolution 5 nm away instead of 30 nm, but when it loads the situation will be the same as the one you originally had.
Another practical example. Next to Mojave (KMHV) there is a giant wind farm with tons of wind turbines, specially near or at to the mountains to the west of airport. Those are animated Simobjects as well. Flying at 14.000ft still drops performance to 30-40 FPS with main thread being hammered and CPU graph showing spikes. Prior to arrive to such area it was on the 60 FPS range and smooth. This is just 100% default MSFS scenery so also MS/Asobo need to take care of scenery design aspects.
Mainly they need to release MSFS 2024 with the claimed multithreaded performance improvements. Recent generation CPUs should be quite capable of handling all of these simobjects and more, except most of the cores are sitting idle due to the single mainthread limitation.
