Menu
▾
▴
#1975 Too many objects at KBOS
Accepted
Medium
2018-10-21
2017-06-29
No
The scenery at KBOS has brought my system to its knees:
AMD_x64, NVidia 750Ti (2GBy ) 4GBy ram.
Sure, small RAM but I bought and installed 8GBy RAM ( unstable, no BIOS timing controls ) but the problem remained, as soon as KBOS terminals come into view the sim stops for upwards of four seconds. There have been pleas, before, for some kind of throttle so that the user can limit the number of objects seen but I can't find
any way to limit the absurd number of little people, handacrts, firetrucks, FedEx vans and whatever littering the apron.
Please provide some method for the average user to temper the scenery creator's evident enthusiasm.
That title's as bad as saying Mozart wrote too many notes, I'll re-phrase
The immersive scenery improvement at KBOS is great. It exposes a need for a way of selectively filtering objects for adjusting frame rate and spacing. Tks!
:)
You can control the range at which the various objects appear by setting the LOD ranges in the GUI. You can also set /sim/static-log/rough
However, the objects will still be loaded when they get in range. Offering the option to disable loading of smaller objects is something on my TODO list, but needs synchonization with terrasync data.
-Stuart
+1 While at other airports I normally have >20 fps, at KBOS I have around 10. So I use other airports.
I'd highly welcome such an option. (LOD is a poor control here, imho). May be not filter smaller objects (small details provide some realistic touch), may be set percentage of all these optional objects.
Nearing the ticket's first birthday, it's still not possible to filter objects in increasingly complex scenery.
Huntley, please share any ideas you have on how this would work.
Stuart, do you have an approach worked out?
I can envision a couple of approaches:
1, allow the user to set an airport object limit... e.g. 50 objects max.
Things like Windsocks, VASI, Localizers, and Control Tower are excluded, not counted, and always drawn.
Things like static aircraft, hangars, etc, are counted
2, Classify airport objects and allow the user to turn them on or off:
light fixtures
hangars
jetways
pushbacks
static aricraft
ground vehicles
other
3, present the user with a list of all object types within a "zone" (e.g. BTG)
Things like smokestakes and pylons would be only a single item on the list.
User can select which objects to disable until they achieve a reasonable frame rate.
This would allow the user to optimize all the scenery and not just the airport areas.
I'm sure there are other viable approaches if we continue to brainstorm on it.
Scott
The problem with all the proposed options is, at the point we're loading the scenery STG, we have no meta-data to tell us if this model is entire terminal building or a cargo container in a corner. The loading code is simple (dumb) and just loads all the objects, and it has no criteria about from range (which is what LOD) uses to avoid or select objects. So every fix requires extending STG so the secenery author can tag object as 'decorations' or even a few tiers of importance. That would be a great thing to have, but it needs someone to orchestrate the new STG feature, change the loading code, and then change the upload / submission system so scenery authors can supply the new data.
Again, all of this would be excellent to add, but someone needs to care enough to drive it forward.
Unfortunately, the problem is even worse than that - whatever change would
also need to be back-compatible with previous FG versions as we currently
only have a single STG file per tile.
One possibility without changing the STG file itself would be to have a
user-controlled list of models that will not be loaded by the STG loader.
So the user could disable particular models of directories. That won't
work for non-shared models, but would be a step in the right direction.
-Stuart
I guess being able disable all shared models could also work? I've no idea what % of the models at say KBOS are shared vs static.
BTW I foolishly assumed the STG loader in older version would ignore unknown trailing elements in the command, if it doesn't that's a big compatability problem indeed.
I was just brainstorming on potential user interfaces. The technical design needs a lot more thought, but I think we come up with implicit rules to simplify the model. A couple of ideas include:
Option 1 - Objects defined within the STG located in the Terrain folder is always loaded and not counted. STG in Objects folder is counted.
Option 2 - These classification can be implied by the folder in which the object resides. So anything in Models/Airport/Jetway is known to be a Jetway.
Option 3 - This is where I agree that metadata would be benefical to implement, or optionally, use the same "folder implies classification" concept from Option 2. Option 3 is the most complex, but also potentially the most flexible.
I'm not tied to any of these. Just throwing out concepts to begin to ideate. I'd like to hear Huntley's ideas also.
Heuristic schemes are (especiallyt option 2) are possible but I'd much sooner we figrued out option 3, and especially allowed backwards-compatible data in STGs. I've had a quick look at the parser and I think we can do something evil - we can set key=value data in comments, which the old parsers will ignore.
i.e
# flag:model_priority=3 OBJECT_SHARED foo 0.0 0.0 0.0 0.0.0 0.0The STG author can then set the model priority (or even group the entires, so all jetways / pylons / baggage carts use the same one). And we can stil do an 'auto clasification' based on the model path if we want.
Then the user interface becomes a 'load fewer scenery objects > load more scenery objects slider' to say if levels 1, 2, 3, 4, ... n are loaded. (I'm assuming model_priority=0 means always load)
This could also be used as a hint to bias the LOD range, so important builds are loaded first.
Hi James,
Putting commands in comments is indeed truly evil.
I may have spoken too soon: I've had a look back at the code in 3.6.0 and
1.9.1, and we always pull in values from an std::stringstream:
in >> obj._lon >> obj._lat >> obj._elev >> obj._hdg >> obj._pitch >>
obj._roll;
So in fact, I think we can just add an extra element to represent the model
priority on the end of the STG file. We can put defaults into the loader
so that SHARED objects have lower priority than STATIC, and then enhance
the scenery object DB to support setting this on a per-model basis.
I'll do a quick experiment to check that the code ignores extra tokens
(I'm not an expert on overloading operators!), and then propose something
on the -devel list.
-Stuart
I've been trying to get consistent results from KBOS, using a startpoint about 12 mi away ( KNZW ) . From start, there's a 3-4 second freeze when the skyline and airport come into the FOV. At first it looked as if reducing LOD of only AI/MP craft was a help but with stopping and restarting fgfs the frame stutter effect changed.
The unique airport buildings, including jetways, seem to be the most important for the 'detailed airport' experience although they're usuually furthest from the user's POV. Equally important are signage, windsocks and nav structures which are closest. I'd think the carts, vehicles and miscellany on the apron together with static aircraft should be first for culling.
I'd thought of a 'detail slider' too, like the vegetation slider and I think it's a great idea.
I don't suppose it's possible to throttle model loading, is it , to spread the loading ? It's far less noticeable to have a frame rate drop over a few seconds than to have a complete freeze ( always during a turn ) .
I'm continuing test runs to try to see why each fgfs startup is different.
Many thanks for all your help.
Actually model loading is supposed to be throttled automatically, already, by OpenSceneGraph. But as you observed, it doesn't work so well at times - models that need Nasal done (animations, etc) need some work done in the main thread once the osgDB threaded loader has run.
Still, I'm surprised the Nasal parts could take /such/ large amounts of time. I wonder if we can further hint to the loader to spread things out more as a user setting?
tldr: It can self - heal.
Over many runs a 1sec freeze accompanied a console msg: " ... not found: CargoDoorFwd.ac" . Could well be, over a year other such bugs in new, detailed, models would have caused much worse frame rate earlier.
Now, with a best avg frame rate around 20 there's a 1Sec freeze at T/O roll, two ~330mSec stutters at 'rough detail' distance when some skyline, A/P buildings load and also jetways and suitcase trucks etc. I've yet to see any detail change at 'Detailed' distance.
Unfortunately I've been taking screencaps but just found F3-Screenshot is the Death Ray for A/P buildings and Debug-Reload Scenery doesn't re-display the detail. Maybe this affects my detail rendering.
So, I've done a quick experiment, and indeed our STG loader is ignoring any spurious entries. So we can add a new field to the STG file without any backwards compatibility issue. Hooray!
I'm going to take implementation discussion on-list.
Huntley: I do wonder if your freezes might be related to these complex models being added to the scene-graph after they are being loaded in a separate thread, rather than the model loader itself.
Out of interest, how many CPU cores do you have? Perhaps FG is using just one core?
-Stuart
Four, Ryzen.
The gkrellm monitor suggests at least some activity on more than one CPU. I've been confused by the things I've seen over the last couple of weeks but I can confirm that my default.xml has:
<multithreading-mode>AutomaticSelection</multithreading-mode>
active.
It seems to me that jetways and all of the unwanted ground objects appear at the LOD defined
by 'Rough' scenery and sometimes I have seen jetways and trolleys even with the actual buildings invisible. The 'Detailed' LOD number does nothing at all as far as I can see. Interframe delays are as much as 8 seconds, often in the three to four second range.
Ryzen 3 1300x Quad core, 16GBy RAM, SSD, GTX750Ti
One question, does it make sense to increase LOD numbers ? I wondered if doing that would identify any particular bottle neck in the display chain in that loading scenery at distance would mean fewer pixels on the screen are actually modified.
It would be very nice to have a separate setting to disable non-airport objects.
Personally, I have turn off scenery objects when flying to get enough FPS and re-enable them when taxiing to see the gates / lightposts.
Using this stationary position, looking towards the skyline:
--airport=KBOS
--runway=04L
--offset-distance=0.050
--offset-azimuth=120
These screencaps ilustrate that the distant skyline detail fills before anything nearby appears and that jetaways and miscellany appear before buildings proper :
ff with increasing Rough LOD
The link button doesn't.
http://www.bitwisetech.com/fgfs/acapKBOS/fgfs-Rgh-1000.png
etc
Last edit: Huntley Palmer 2018-10-21