Hackathon Proposal:Feature Scaling

From FlightGear wiki
Revision as of 15:25, 15 October 2020 by Hooray (talk | contribs) (placeholder based on hackathon ideas discussed on the devel list: https://sourceforge.net/p/flightgear/mailman/message/37129569/)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.


Title: Automatic/abstracted rendering settings (Feature Scaling)

screen shot showing the OSG on-screen stats
Potential mentors:
Intro: (short intro)
Interested Parties: please add yourself if you are interested in working on this
Status: n/a
Summary: a test mode, which flies a 30 second replay tape with the C172 around Hawaii, measures the FPS and repeats for each graphical config: that would be reasonably simple to code up, and give something approximating a sane value (modulo all the zillion ways it can screw up, but…) [1]
Background: There is a performance problem in OSG with too many LOD nodes deep down in the tree, but that’s the usual ‘too many nodes == small batch sizes == too many draw calls == sucky performance’ problem.

But there’s no problem with LOD nodes per-se, they just need to be high up in the tree, switching large amounts of stuff, eg a complete tile, not one window on the front door of a house :) And OSG LOD nodes can use distance or screen-space pixel metrics, and they update per frame, so you could absolutely increase the visibility, but reduce the detail levels, with increasing altitude; turning off trees, OSM buildings, and then /all/ objects. [2]

Details:
Ideas:
Required skills: Property tree, PropertyList XML File, Nasal, Instant Replay, Fgtape, Logging properties
Learning Opportunities:

Notes:
References