Author Topic: Less aggressive LOD  (Read 2091 times)

Brokenbroccoli

  • Jr. Member
  • **
  • Posts: 77
Less aggressive LOD
« on: January 02, 2023, 06:51:09 pm »
I think the LOD by view distance is quite aggressive. You can clearly see that happen (firetrucks, lights and the light pole on the baggage tug are the worst, but it's visible on quite any vehicle). I know, you want to make it have as little performance impact as possible, but there are people, who have a high-end machine, who want visual quality over performance. Is it possible to have a setting (like low, med and high) on this? Thanks.

Richard1000

  • Newbie
  • *
  • Posts: 41
Re: Less aggressive LOD
« Reply #1 on: January 03, 2023, 10:16:19 am »
I definitely support this. Empty luggage trains that suddenly are full! Worse though are pushback tugs that use a tow bar - the tow bar often visible floating without the tug!
Richard

MediumRareBaku

  • Jr. Member
  • **
  • Posts: 81
Re: Less aggressive LOD
« Reply #2 on: January 20, 2023, 10:13:14 pm »
Agree, I feel like there it shouldn't be possible to have things popping out view when you're just using the regular spot camera, you're not that far away.

Copper

  • Full Member
  • ***
  • Posts: 159
Re: Less aggressive LOD
« Reply #3 on: January 21, 2023, 12:22:53 am »
Umberto claims that everything is according to Asobo guidelines:
https://www.fsdreamteam.com/forum/index.php/topic,26711.msg174817.html#msg174817

TL;DR: It's intentional the way it is.

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51443
    • VIRTUALI Sagl
Re: Less aggressive LOD
« Reply #4 on: January 21, 2023, 10:14:30 pm »
Yes, of course it's intentional, and the fact the LOD DO conform to the official LOD diagnostic tool in the SDK is not open to discussion, because they surely do.

Now, we can discuss if it might be sensible to IGNORE what the LOD tool is telling us and, instead of following it, intentionally make LOD "as we wanted to", instead of "how Asobo wants to". Note that, conformity to LODs is what MSFS uses to DECIDE which objects to kill first.

And right now, with the current situation of objects or even entire airports disappearing because the maximum number of objects is reached, the last thing we need right now, is to change something that will make this issue even worse so, before starting to intentionally create LODs that goes beyond what the Asobo tool recommends, it would be best to wait if this issue will ever get fixed.

Copper

  • Full Member
  • ***
  • Posts: 159
Re: Less aggressive LOD
« Reply #5 on: January 21, 2023, 11:16:04 pm »
Yes, of course it's intentional
Is it also intentional that the pushback tug disappears at close distance but the towbar stays visible far further away?

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51443
    • VIRTUALI Sagl
Re: Less aggressive LOD
« Reply #6 on: January 22, 2023, 12:02:46 am »
Is it also intentional that the pushback tug disappears at close distance but the towbar stays visible far further away?

More than "intentional", is a side effect of the fact that, for obvious efficiency and flexibility reasons, the towbar, the tug and the driver are separate objects that use the recent "object attach" feature that has been added in SU9 so, instead of having hugely inefficient "fat" objects made of the whole set ( for example, having a *copy* of the SAME towbar duplicated in every object, making it bigger for no reason ), we create an object by combining several together, with zero data duplication.

This has an effect on LODs, since the ones that drives the choice are always the ones from the "parent" object but, since an object might appear both as a parent or not ( the small pushback tow truck can also push baggage carts ), they change when their role changes so, it's likely to "fix" this, we WILL to intentionally break LOD rules, at least for those objects used in multiple roles.

As usual with GSX, whenever you see something you don't "like", always ask yourself the following question: "COULD BE they done it to save memory/fps/ctds ?" and the answer will almost invariably be YES.

As I've said, once we can be reasonably sure the basic underlying problems in the sim with multiple objects and the not entirely clear strategy of "who's get killed first" when low on memory are really fixed, we can THEN start experiment on bending the rules.

jonnydeadly

  • Newbie
  • *
  • Posts: 12
Re: Less aggressive LOD
« Reply #7 on: January 26, 2023, 08:28:42 pm »
How come Asobo can manage without the tugs disappearing? I realise they must know the intricacies of the game engine better than anyone, but surely that means it *is* possible.

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51443
    • VIRTUALI Sagl
Re: Less aggressive LOD
« Reply #8 on: January 30, 2023, 05:56:50 pm »
How come Asobo can manage without the tugs disappearing? I realise they must know the intricacies of the game engine better than anyone, but surely that means it *is* possible.

Doesn't seem you read the previous post from Cipher, who asked about why the tug disappears while the towbar stays, which clearly doesn't apply to Asobo tugs, since not only none of them has a Towbar to begin with, but also ( and here's is where you must have missed my reply ), none of them are made using a combination of two separate objects, which is used by GSX to have the tug work in different roles: as a Pushback with a Towbar, as a baggage Cart with a back cart towbar, and has a wandering airport vehicle with no towbar as well.

As I've said, we CAN raise the LOD level, but we won't do it unless you can be sure objects won't be killed by the sim because of that and, BECAUSE the simulator is currently experiencing a base problem of things disappearing already, even with our properly conservative approach to prevent that, trying to purposely against the rules NOW is not a very good idea.

HeicoH

  • Full Member
  • ***
  • Posts: 135
Re: Less aggressive LOD
« Reply #9 on: January 30, 2023, 07:00:45 pm »
To be honest, I don't see the logic behind that.

On the one hand you tell us that assembling the pushback vehicle from three separate objects saves memory/fps/ctds, on the other hand you tell us that there are often problems with GSX because Simconnect cannot handle the large number of objects.
My GSX test scenario (unless otherwise stated):
Sandbox environment
GSX v 2.9.1 (as of 20 Jan 2023)
Fenix A320, PMDG 737-800, ATR-72
EDDL (JustSim), EDDK (Aerosoft), both not Marketplace
GSX jetways disabled
no AI traffic
no antivirus or firewall software running
all apps started in admin mode

SK10

  • Newbie
  • *
  • Posts: 34
Re: Less aggressive LOD
« Reply #10 on: January 30, 2023, 08:20:40 pm »
Are LODs in GSX different in VR? I asked that for VGDS but got no reply. As good as the LODs might be, they are disturbing also, what does a VGDS helps, when there are no information on it.

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51443
    • VIRTUALI Sagl
Re: Less aggressive LOD
« Reply #11 on: January 31, 2023, 11:12:16 am »
Quote
On the one hand you tell us that assembling the pushback vehicle from three separate objects saves memory/fps/ctds, on the other hand you tell us that there are often problems with GSX because Simconnect cannot handle the large number of objects.

As with everything we do, the reason for doing something always have a very sound logic, which always give preference to the long term growth of the product and the sim, trying to use all features from the SDK that achieve that goal.

The "Attached objects" method came out with SU9, which was released in April 2022, before GSX, so we obviously took a chance to use it, because it's a way more efficient method of making large collection of objects without wasting memory and needlessly duplicating files. If we used the old style monolithic approach like FSX, following the example of the small tug, we have:

- the tug which carries the luggage carts, which uses a small towbar trolley

- the SAME tug used in a pushback role, which uses an airplane towbar

- the SAME tug used as a wandering ground traffic, which has no towbar

- the towbar driver, which is one from GSX when the vehicle is called by GSX, and one from Asobo when the tug is used as a default ground traffic.

In FSX/P3D, to achieve this, we would need to create separate versions of the SAME tug object, while in MSFS using the Attached objects method, there's only one Tug, a separate trolley towbar, a separate airplane towbar and the driver is separate.

Now, you might think the different is small but, in order to make up all variations, you would need to multiply that number by:

- The number of ground handlers ( currently 256 )

- The number of different drivers ( currently 6 )

Which means, the 4 truck variations * 256 * 6 = 6144 different variations JUST to represent the 4 roles for the small Tug, compared to just 256 ( one for each operator ) + 6 drivers + a couple of towbars.

If we wanted to add a new operator, with the "single object" method, it will add 24 new Tug variations ( 6 drivers *  4 different roles ) while now, when we add a new operator, it will only add ONE variation for each GSX object class.

If you take into account all GSX objects classes, the saving in variations is HUGE, like ten of thousands objects LESS compared to having every object made a single object. Because I hope you don't really think there's no limit on the number of variations as well. While we don't know if there is an hard limit, each variation will need to be scanned at start to be "mounted" in the VFS ( virtual file system ), and this table is allocated in memory so, not only adding a huge number of variations will affect the startup time, but their number will also affect the system memory.

Some users already complained with GSX the sim can take up to a minute more to start, imagine how bad this would be if we didn't use attached objects, so we had like 15-20K more variations, with hundreds of new variations added when adding a new operator.

In addition to that, by separating an object into these major components that are shared between objects, we give the simulator a better chance to optimize its memory because consider this:

 Suppose we have an American Airline Tug with a Male driver and Towbar embedded on a gate, with a United Tug with a Female driver on the next gate.

- With the legacy monolithic approach we only added two objects to the sim, but they are surely larger and, in this case, data for the identical towbar has been loaded twice for sure, since the sim has no way to optimize for the duplicated towbar, which is present in both objects.

- With the attached object method, we added 6 objects to the sim ( 2 tugs, 2 drivers and 2 towbars ), but now the sim CAN recognize it already has a towbar in memory, so it can optimize it and load it only once, and use instancing to let the video card draw it multiple times with a very low cost in fps.

This might seem a small benefit but, that's just with two gates to make the example clear but, what about a whole airport, were you might have dozen of identical objects like towbars and drivers in use ? It should be obvious THIS is a way better method, it wouldn't be added to the SU9 SDK if there was no benefit.

And this method worked just fine, UNTIL some AI traffic products came out, around October, and it was then then suddenly the maximum number of Simobject became an issue. You couldn't reach it with GSX alone, and you still can't, if you are flying online with real user planes instead of AI traffic.

As I've said, so many times already, it's nobody's fault if the limit is reached, and the PROPER solution for the long term growth of the sim is to Asobo to finally have a serious look at it and fix it, instead of reverting back to a way worse method to create multiple objects, which comes with serious issues on its own.

It's like when we only had 32 bit simulators, and sceneries more and more complex started to appear, up to the point nobody could use a complex airplane with a dense airport without an OOM ( P3D V3 was the worse: it consumed more memory because it had better graphic than FSX, but it was still 32 bit ), so the PROPER solution was to fix the simulator itself, and move to 64 bit, today is the same, since memory ( at least on PC ) is not really a problem, the PROPER solution is to remove the max number of Simobjects limitation, otherwise shortly nobody will ever be able to do anything in the detail users ask for.

Because detailed airport interiors, detailed airport ground clutter, they ALL contribute to the max number of objects, it's NOT a single product that causes this, it's always the combination.

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51443
    • VIRTUALI Sagl
Re: Less aggressive LOD
« Reply #12 on: January 31, 2023, 11:14:10 am »
Are LODs in GSX different in VR? I asked that for VGDS but got no reply. As good as the LODs might be, they are disturbing also, what does a VGDS helps, when there are no information on it.

Yes, it seems all the objects size LODs change completely in VR.

It might be possible to offer some configuration option that will change the LOD levels, but it will always require a sim restart, if you switch in/out from VR during flight, the LODs won't follow.

SK10

  • Newbie
  • *
  • Posts: 34
Re: Less aggressive LOD
« Reply #13 on: January 31, 2023, 10:30:10 pm »
Are LODs in GSX different in VR? I asked that for VGDS but got no reply. As good as the LODs might be, they are disturbing also, what does a VGDS helps, when there are no information on it.

Yes, it seems all the objects size LODs change completely in VR.

It might be possible to offer some configuration option that will change the LOD levels, but it will always require a sim restart, if you switch in/out from VR during flight, the LODs won't follow.
Thanks Umberto, would be nice to have those option.