Hackathon Proposal:Feature Scaling

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)
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