AI Scenery objects

From FlightGear wiki
Jump to navigation Jump to search
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3).
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .

This feature is scheduled for FlightGear (unknown). 10}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

AI Scenery Objects
Started in 07/2018
Description Providing a way for controlling scenery objects from the scenery objects database by the AI subsystem
Contributor(s) ThomasS (since 07/2018)
Status Under active development as of 07/2018

Objective

The currently preferred way for defining animated jetways for an airport is putting the definitions into a ICAO.jetways.xml file and let someone with commit access upload the file to the scenery server for sharing it by TerraSync. But using a single file per airport has a few drawbacks:

  • Its difficult to maintain and to evolve the jetways step by step without always modifying the complete file
  • It bypasses parts of the well established process for adding objects to the scenery and always requires some manual intervention by a core developer for committing it.
  • Temporary runtime model files are created on demand for each airport.

After some discussion on the developer mailing list [1] the original idea scetched above broadened to a more generic solution, that not only disposes icao.jetways.xml, so the name "AI Scenery Object" arose. So an animated jetway is just one type of an AI Scenery Object. Cranes or bridges might be other types.

This page is about a proof of concept for an alternative way for maintaining animated jetways by uploading animated jetways as AI scenery Object to the scenery object database similar to other scenery objects and have these controlled by the AI subsystem and a Nasal module [2].

Specification

System Load (FPS)

Users not interested in animated objects (jetways) should not be affected.

STG

A new STG token OBJECT_AI is added for defining an AI scenery object. There is no need for providing a shared option as these models are highly location specific. Such a line looks like

OBJECT_AI <object-properties-path> <flags> <longitude> <latitude>...

This complies to other object definitions except for the file referenced. This will not by a model file but just a property list file defining the AI object (see below).

ReaderWriterSTG decides depending on a global switch "ai-scenery-objects-enabled" to either:

  • ignore these lines
  • load a static scenery object if available (supplied and defined by the scenery designer), otherwise the animated model is used. This provides the option to the scenery designer to define a less complex model for reducing frame rate drawbacks.
  • create a PagedLOD node to display a static object (jetway) until the range reaches a defined threhold (might be 100m for jetways), and then loads an animated object (jetway). Pass the model information to AIManager for creating an instance of FGAISceneryObject and load the object-properties-path into the AI/models subtree. The object-properties-path will be the file containing jetway location specific data.

"flags" will just be a placeholder for future use for hopefully avoiding a change to the file specification for upcoming requirements. The exact implementation ReaderWriterSTG works however might change.

object properties

The object properties file is a regular PropertyList file defining the characteristics of the scenery objects like

  • the animated model file
  • optionally a more simple static model file

Outline

References

References
  1. ThomasS  (July, 2018).  Mailing list discussion .
  2. ThomasS  (Jul 20th, 2018).  Animated Jetways: Type 1 or 2? .