FlightGear wiki - User contributions [en]

Virtual Reality

2024-10-20T11:33:43Z

Nia:

{{Experimental|disclaimer=VR support in flightgear still comes with a number of caveats.}}

{{infobox subsystem
|image = VR screenshot c182s.png
|name = Virtual Reality
|started = 07/2021
|description = Virtual Reality support using osgXR / OpenXR
|status = Active
|developers = James Hogan <ref>https://sourceforge.net/u/amalon/profile/</ref>
|changelog = https://sourceforge.net/u/amalon/profile/feed.rss
}}

The '''Virtual Reality''' project aims to add immersive VR support to FlightGear. This is done using the OpenXR<ref>{{cite web |url=https://www.khronos.org/OpenXR/ |title=OpenXR Overview |publisher=The Khronos Group Inc}}</ref> API, via an external library called osgXR<ref name="github-osgXR">{{github source |user=amalon |repo=osgXR |full=1}}</ref> for handling OpenXR and OpenSceneGraph specifics, which is being developed in parallel.

== Background ==

A previous attempt to support some form of VR is described in [[OculusImplementation]].

The portable OpenXR API now seems to be getting widespread adoption, which will allow FlightGear to support a variety of VR devices across multiple platforms.

== Source code ==

* osgXR source can be found on github<ref name="github-osgXR"/>, or the version included in the flightgear 3rdparty directory can be used.
** On ArchLinux, you can install the osgxr AUR package <ref>https://aur.archlinux.org/packages/osgxr/</ref> to get the version needed by FlightGear's next branches.
* Some VR code can now be found in FlightGear's next branches (see below for details).
** On ArchLinux, you can use the -git AUR packages, i.e. flightgear-git, simgear-git, flightgear-data-git.
** On Windows, you can use the [[Nightly Build#Windows|Windows nightly builds]].
* More FlightGear changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased). A mirror is available on github for issue tracking<ref>{{github source |user=amalon |repo=flightgear-vr}}</ref>.
* More SimGear changes can be found in James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).
* More FGData changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).

== Building & Packaging Notes ==

When CMake runs for FlightGear (next or osgxr/osgxr_clean branches), by default it will attempt to enable VR on Windows and Linux (same as <code>-DENABLE_VR=ON</code>). It will do the following:
# Look for the osgXR library, and if found it will link against that (same as <code>-DSYSTEM_OSGXR=ON</code>).
# If no osgXR library is found it will check for OpenXR and if found it will build its own static built-in copy of osgXR to use.
# If no OpenXR is found it will disable VR support.

In any case it will print a message along the lines of <code>-- VR support enabled/disabled...</code>.

To avoid implicit dependencies when packaging, packagers may need to do ONE of the following:
* preferably depend upon an osgXR package providing the osgXR dynamic library
* OR depend on OpenXR and GLX, and explicitly pass `-DSYSTEM_OSGXR=OFF` to CMake so the built-in osgXR is built statically
* OR explicitly pass `-DENABLE_VR=OFF` to CMake to disable VR support altogether

== Status ==
'''Last updated: 31st March 2024'''

Highly experimental, partially in next, partly out of tree. Development in progress.

Working in next branch (e.g. [[Nightly Build#Windows|Windows nightly builds]]):
* Enable/disable at startup via --enable-vr / --disable-vr command line options, or from GUI (View->VR Options).
* VR friendly splash screen.
* Displaying stereo images on the HMD.
* Motion tracking updates HMD views (but doesn't move main camera).
* Configurable VR mirror (see View->VR Settings) shown in default camera view (blank, left, right, side-by-side left & right).
* Visibility mask support.

Working in osgxr/osgxr_clean branch:
* Controller support for flight (helicopter collective in left hand, helicopter cyclic in right).
* Controller pointing support with some mouse emulation.
* Rendering of controllers (as basic cuboids).

Current priorities:
* Support [[HDR Pipeline]] and accelerated multiview rendering.
* Continue to polish controller flight support, add haptics etc.
* Get started on other controller interaction and controller rendering.

=== Known issues ===

* <s>Splash screen is rendered directly onto the left eye viewport which isn't very pleasant in VR.</s>
* Performance could be better so crank down the graphics if frame rate is low.
* Shadows are broken:
** When shadows are enabled, the FlightGear window doesn't appear to refresh even though buffers are swapped, but VR output works.
** Sun position is fixed relative to head, presumably because shadow maps are rendered based on master camera, but osgXR only moves slave cams.
* Spotlights (taxi/landing lights) are relative to camera in default mode
** Affects default / scene view mode (<code>--prop:/sim/vr/mode=AUTOMATIC</code>), as stereo callbacks position cameras
** Doesn't affect slave cameras mode (<code>--prop:/sim/vr/mode=SLAVE_CAMERAS</code>), as slave cameras are positioned correctly
* ALS filters appear to operate in screen space but don't take into account side by side rendering
* [[HDR Pipeline]] is unsupported, but work to support it is in progress
* Still some Monado issues:
** <s>Saturated output due to not using SRGB textures</s> (use osgXR 0.3.8)
** <s>Suboptimal depth format used</s> (osgXR 0.3.8 should end up using GL_DEPTH32F_STENCIL8)
** Warnings about suggesting bindings of attached action sets when restarting VR (looks like a monado issue at first glance)
* Multiple SteamVR issues on Linux:
** If it doesn't close cleanly on Linux it may be due to a SteamVR bug<ref name="github-SteamVR-422"/>, but a ctrl+c / SIGINT on the command line should close it.
* osgXR doesn't support Direct3D graphics bindings for WMR (it isn't a priority for me). Contributions welcome.

=== Testing ===

VR has been tested with the following hardware & software configurations:
* HTC Vive, SteamVR, Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 21:43, 27 August 2021 (UTC)
* Oculus Quest 2, SteamVR (ALVR), Linux/X11 (Fedora 34) -- [[User:vezza|vezza]] ([[User talk:vezza|talk]]) 16:30 27 August 2021 (UTC)
* Oculus Quest 2, Oculus App, Windows 10 --[[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 13:22, 7 June 2023 (UTC)
** Works fine, shadows gets rendered, but move when turning the head.
** Eye view point is about 0.2 meter above where the view is defined, so I have to duck my head to look out through the HUD and stuff.
* Oculus Quest 2, SteamVR via Virtual Streamer App, Windows 10, Nightly build --[[User:Skyclmbr]] 18:17, 11 October 2023 (UTC)
** Head tracking works fine, but right eye screen flickers constantly throughout flight
** Starting head position is off, depending on how much I move around while it's loading on the SteamVR page.
* HTC Vive, Monado (to window), Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
* Monado dummy driver, Linux/X11 (ArchLinux), Intel mesa -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
** /sim/vr/depth-info=false
* Monado Dummy HMD, Linux/X11 (Debian), AMD Mesa Drivers [[User:nia|Nia]] ([[User talk:nia|talk]]) 23:27, 17 December 2021 (UTC)
** Applying the following patch: <syntaxhighlight lang="diff">
diff --git a/src/XRState.cpp b/src/XRState.cpp
index ce09bcd..5bcbbca 100644
--- a/src/XRState.cpp
+++ b/src/XRState.cpp
@@ -1017,7 +1017,7 @@ XRState::UpResult XRState::upSession()
unsigned int thisDepthBits = 0;
switch (format)
{
- case GL_RGBA16:
+ case GL_RGB10_A2:
// FIXME This one will do for now...
if (!chosenSwapchainFormat)
chosenSwapchainFormat = format;
</syntaxhighlight>

* HP Reverb G2, Gigabyte (AMD) RX 6700 XT, Windows 10, SteamVR -- [[User:Gastcan|Gastcan]] ([[User talk:Gastcan|talk]]) 02:15, 09 July 2023 (UTC)
** (Using the Windows nightly build 08-Jul-23)
** The view follows the direction of the headset, but the image stutters; outside scenery and within the cockpit

* HP Reverb G2, Gigabyte (AMD) RX 6700 XT, Debian (Trixie), Monado -- [[User:Gastcan|Gastcan]] ([[User talk:Gastcan|talk]]) 16:15, 14 August 2023 (UTC)
** Compiled from sources: OpenXR-SDK-Source, Monado, osgXR (amalon), SimGear (amalon), FlightGear (amalon)
** The view follows the direction of the headset with minor stuttering.
**<s>The viewpoint/perspective drifts clockwise, to the right.</s> <- Drifting is virtually eliminated by adding '[https://gitlab.freedesktop.org/mateosss/basalt Basalt for Monado]' (provides 6DoF).

If you've got VR working, feel free to add your configuration above.

The following testing is desired:
*SteamVR, Linux, AMD graphics:
**Test that motion smoothing works (its unsupported on NVidia)
** moving head side to side should reproject using depth buffer
**try suspending fgfs with Ctrl+Z in terminal (resume with fg) to force reprojection
*Monado, Linux:
** May be awkward to test as it crashes in latest NVidia proprietary drivers<ref>https://gitlab.freedesktop.org/monado/monado/-/issues/122</ref>.
***There's now a workaround mentioned in that ticket that allows for basic testing
** Use at least osgXR 0.3.6 for monado workaround, or <code>--disable-vr</code> and enable VR with GUI
*SteamVR, Windows, with a headset (I've only attempted to null driver, and it at least partly worked):
**Needs building with at least osgXR 0.3.7 for Windows bindings, and my osgxr/osgxr_clean branch of flightgear/fgdata/simgear
**May need --disable-sentry
**Test headset output and controllers

Issues can be reported:
* On the flightgear-devel [[Mailing lists|mailing list]]
* To the {{tickets|FlightGear bug tracker}} if the issue is reproducible on the next branch
* To the [{{github issues url |user=amalon |repo=flightgear-vr}} flightgear-vr issue tracker]
* To the [{{github issues url |user=amalon |repo=osgXR}} osgXR issue tracker] if it is known to be a non-flightgear specific bug in osgXR

But please be aware of the known caveats mentioned above, and the roadmap below.

==Performance==

Here are some pointers to get the best VR experience.
* Ensure your runtime supports asynchronous reprojection, which may alleviate the nausea induced by lower frame rates.
**On Linux / SteamVR / NVidia proprietary driver, ensure you have at least driver version 270.
*If your frame rate is being capped at the refresh rate of your desktop monitor, try disabling VSync in both flightgear settings and your driver settings
**On Linux / NVidia proprietary driver, its found in OpenGL settings in nvidia-settings.
*If FlightGear is getting throttled by SteamVR (to try and ensure a consistent, if slow, frame rate), consider switching to fixed throttling (in per-application video settings) and playing with the sliders. You may prefer no frame rate throttling but a higher predicted frame time.
*Enabling multithreading may get you better performance, e.g. <code>--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext</code>
*If using an AMD GPU, use [https://gitlab.com/corectrl/corectrl CoreCtrl] and set the GPU to the "Virtual Reality" power profile with GPU and memory clocked to max. You may also benefit from changing the CPU frequency governor to Performance.

==Implementation Details==

===Concepts===

====Interaction Modes====

Interaction modes are a way of describing (via XML) how a VR controller should look and behave in a particular context. It roughly corresponds to a virtual control you can hold (and let go of), for example:
*When you're holding a helicopter collective control, the pitch angle of the controller should control the collective pitch (and look like a collective in your hand).
*When you're pointing the controller at a GUI or cockpit controls it should pick along a line, rendered in a specific way, and emulate mouse events to those controls (and look like a small laser pointer control or a pointing hand/glove).
*When you're teleporting around, it should pick along a parabolic arc, rendered a specific way, and teleport there when the button is released.
*When you're using the flight recorder it should treat the controller trackpad as a rewind/fast forward (and look like a fancy TV remote or something).

The definition of interaction modes should be generic enough that custom ones can be provided with aircraft, or defined separately and work with any aircraft, but also powerful enough that a complex and intuitive control can be defined with a minimum of Nasal scripting.

==Roadmap==

===Development targets===
*Merge stable & minimally functional code into next ({{Merge-request |project=flightgear |id=253}}, {{Merge-request |project=fgdata |id=238}}) {{done}}
**Bare functionality {{done}}
**Stability {{done}}
*Merge some form of desktop mirroring of VR view ({{Merge-request |project=flightgear |id=260}}, {{Merge-request |project=fgdata |id=241}}) {{done}}
*Merge visibility mask support ({{Merge-request |project=simgear |id=98}}, {{Merge-request |project=flightgear |id=264}}, {{Merge-request |project=fgdata |id=244}}) {{done}}
* Polish {{not done}}
**Make launcher accessible to VR user {{not done}}
**Make splash screen VR friendly {{done}}
**Make GUI accessible to VR user {{not done}}
**Make aircraft center accessible to VR user {{not done}}
*Functionality {{progressbar|40}}
**Controller flight support {{progressbar|80}}
*** Haptic feedback {{not done}}
**Controller interaction support {{progressbar|40}}
** Walker locomotion / room scale {{not done}}

===General tasks ===

*Stability {{done}}
**Clean shutdown {{done}}
***SteamVR for Linux hangs on OpenXR app shutdown<ref name="github-SteamVR-422">{{github issues url|ValveSoftware|SteamVR-for-Linux|number=422}}</ref>.
** Handle OpenXR stopping {{done}}
***SteamVR for Linux kills running app even if it ends session<ref>{{github issues url|ValveSoftware|SteamVR-for-Linux|number=461}}</ref>.
*Resolve questions around VR mirror switching {{done}}
*Performance {{progressbar|10}}
** Handle shouldRender=false by somehow disabling VR cameras (maybe setting cull mask to 0) {{not done}}
**SceneView mode: Combine culling traversal {{not done}}
**Check why update isn't proceeding in parallel with multithreading {{not done}}
**Use OpenXR visibility mask extension to avoid rendering to invisible fragments {{done}}
*Sound {{progressbar|0}}
** Ensure surround sound is relative to user's head {{not done}}
**Investigate a way to use appropriate OpenAL binaural mode automatically {{not done}}
**Specify separate sound device for VR so it switches automatically? {{not done}}

===User facing features ===

*Display {{progressbar|60}}
**Show views on HMD {{done}}
**Configurable mirror on desktop window {{done}}
***Left, Right, Left & Right {{done}}
***Composited mirror mode (combine & blend views and allow zooming) {{paused}}
**General [[HDR Pipeline]] Support {{progressbar|50}}
**Geometry shader multi viewport ([[HDR Pipeline]]) {{progressbar|50}}
**OVR_multiview2 with OSG branch ([[HDR Pipeline]]) {{progressbar|20}}
* Motion tracking {{progressbar|50}}
** Follow motion of HMD {{done}}
**Move master camera instead of scene slave cameras (presumably would fix surround sound) {{not done}}
*Settings {{progressbar|20}}
** Mirror settings {{done}}
**Dynamic toggling of VR {{done}}
**Sound settings? {{not done}}
***Sound reference frame (user's head or room)? {{not done}}
**Advanced VR settings {{not done}}
***validation layer {{not done}}
*** submit depth information {{done}} but needs testing (SteamVR+Linux+nVidia doesn't do motion smoothing yet)
***osgXR VR mode {{not done}}
****Fix slave cameras mode clearing {{not done}}
***osgXR swapchain mode {{not done}}
*Platform support {{progressbar|70}}
**Linux/X11/OpenGL graphics bindings {{done}}
** Monado support {{progressbar|60}}
**Windows/OpenGL graphics bindings {{done}}
**Windows Mixed Reality render via DirectX bindings {{not done}}
* Splash screen {{progressbar|80}}
**Show splash screen as quad layer for runtime to composite {{done}}
**Cube map/quads background provided by aircraft {{progressbar|20}}
*GUI {{progressbar|10}} {{priority|2}}
**Shown over mirror on desktop window {{done}}
** Expose a menubar & GUI, rendered to a quad or cylinder in front of VR user when they activate {{not done}}
**Interact with GUI buttons etc using controllers as lasers {{not done}}
*Launcher {{not done}}
**Show launcher in VR similar to GUI when enabled via command line or launcher option {{not done}}
**Transition to flightgear {{not done}}
**Transition to aircraft center with VR already started {{not done}}
**Transition back to flightgear from aircraft center {{not done}}
**More VR friendly environment
***A simple background cubemap, shared with splash {{not done}}
***A hanger (like xplane11)? {{not done}}
*Controller support {{progressbar|50}}
**Basic action support in osgXR API {{done}}
**Tie osgXR actions into FG's input system {{done}}
**Helicopter flight controls (can use for planes too) {{done}}
**Plane flight controls {{not done}}
** Render controllers {{progressbar|20}}
**Hand tracking (robot hand) {{progressbar|90}}
** Render skinned hand {{not done}}
**Basic interaction with controls {{progressbar|80}}
***Grasp surfaces {{{progressbar|90}}
***Force feedback for haptic gloves {{not done}}
**Advanced interaction with animated controls {{progressbar|90}}
*** Direct manipulation mouse mode for testing without VR {{progressbar|90}}
***Inverse kinematics of translate and rotate animations {{done}}
***Ability to specify frictions {{not done}}
***Ability to specify ranges (where can't be deduced) {{not done}}
***Ability to hint what aircraft processes/filters/kinematics should be reversible {{progressbar|10}}
** Haptic feedback {{not done}}
* Walker VR locomotion / Room scale {{progressbar|0}}
** Walker follows user {{not done}}
**Parabolic arc teleport {{not done}}
**Snap into seats {{not done}}
**Easy turning around {{not done}}

===Aircraft compatibility===

This section is largely about how usable controls are in VR with direct manipulation.

====[[Cessna 172P]] ====
*Controls
**Flaps {{progressbar|90}}
***kinematic needs to be reversible {{progressbar|90}}
** Visors {{progressbar|70}}
***correct relative friction {{not done}}
**Opening of doors {{not done}}
***reversing of gain expression {{not done}}

====[[Eurocopter EC130 B4]] ====
* Engine start
** Engine cutoff lever reversing (Alt+C required) {{not done}}
**External power on (GUI required) {{not done}}
**External power off (GUI required) {{not done}}
**Throttle roll (middle mouse drag required) {{not done}}
*Take off & flight
** Arms & hands get a bit in the way {{not done}}
*Controls
** Engine cutoff lever {{not done}}
***Uses nasal, needs pick animation binding of some sort
**ELT {{progressbar|50}}
***Both /ELT/test and /ELT/armed can be set to bool
***Both can get set though
**Doors & hatches {{not done}}
***Add limits

====[[McDonnell Douglas F-15 Eagle]] ====
*Model
**Floating switches are very noticeable {{not done}}
**HUD should be at infinity {{not done}}

====[[Robinson R22]] ====
*Controls
**Tilting T-bar {{progressbar|90}}
***limit range? {{not done}}
**Collective awkward to get at {{not done}}
**Throttle roll & governor switch? {{not done}}

====[[Robinson R44]] ====
*Controls
**Tilting T-bar {{not done}}

==References==
{{Appendix}}

[[Category:Core development projects]]

World Scenery 3.0

2024-07-18T21:17:16Z

Nia: /* Airports */

{{WS30 Navbar}}
World Scenery 3.0 is a project to replace the tiled single-mesh World Scenery 2.0 with an LoD-based approach using a regular elevation mesh, landclass texture and vector line features.

This leverages OSG's Virtual Planet Builder and OpenStreetmap APIs.


== Currently Available Scenery ==

=== Terrain ===
Scenery is currently not distributed using the official Terrasync, Nia provides a terrasync compatible download, point your terrasync client to https://de1mirror.flightgear.org/ws3/ to make use of it. As of writing (2024-01-15) it contains all of the sceneries below (duplicates removed) and will get updated when a new Airports package is made and when Wayne provides her with new US scenery. If you don't wanna deal with changing your terrasync settings, you can always download sections of scenery via the links individually and added to your [[FG SCENERY|scenery path]]. If you set these in your scenery path ahead of any other scenery, it will pick up osm2city, scenery objects etc. from the underlying scenery as well.
{| class="wikitable"
|+
Currently Available World Scenery 3.0
!Scenery
!Area
!Size
!Bottom Left
!Top Right
!Area (degrees^2)
!Landclass Source
!Landclass Resolution (m)
!Raster format
!Comments
!Osm2city Scenery for WS3
|-
|[https://drive.google.com/file/d/1EapHG6qEYU6CWdXnp0_aqjUaX61Lk5EL/view?usp=sharing WS30_UK]
|UK and Eire
|1.5GB
| -11,49
|1,60
|121
|CORINE
|10
|PNG
|Includes detailed roads and water features.
|
|-
|[https://drive.google.com/file/d/120QOxfTWEm6EBmjK0eCNb07hrm3clavi/view?usp=sharing NL (terrain only)]
|Amsterdam and Lelystad
|716MB (ca. 8GB uncompressed)
|2,50
|10,53
|24
|CORINE
|10
|PNG
|Includes high resolution water raster from OpenStreetMap. Check out the canals!
|[https://drive.google.com/file/d/13inL4UqSyvRh5FVq62quVOYXnlEhxU1G/view?usp=sharing contains osm2city stuff incl. trees etc. also contains the static objects from Terrascync]. NB: contains also the terrain - no need to download the terrain seperatly (as per first column). Use with the new airport download and do NOT run on top of WS2.0 scenery.
|-
|[https://drive.google.com/file/d/1MrYuDKbMl4WhCEq9gnnt8Tz61lTAScvD/view?usp=share_link WS_Alps]
|
|49MB
|6,45
|8,47
|4
|CORINE
|25
|DDS
|
|
|-
|[https://drive.google.com/file/d/1x-kuCTfyMWddTi0fbr_nl41LR41Ylvwb/view?usp=share_link WS30_MTQ]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|10
|PNG
|Small French Caribbean island. One airport (TFFF)
|[https://drive.google.com/file/d/1QtojSTbnAAfkMzirQHnDJWbBDGOtnwIK/view?usp=sharing osm2city buildings, trees, maritime, pylons etc.] (ca. 40 MB).
|-
|[https://drive.google.com/file/d/14kbbgXbofDmqxho-bMCfOG4jDwcDqwBd/view?usp=share_link WS30_MTQ_25m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|25
|PNG
|Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1-LS3yQZ0OkWX38Ne89n69wtrT7SreV69/view?usp=sharing WS_MTQ_5m]
|Martinique
|8MB
| -62,14
| -60,15
|2
|CORINE
|5
|PNG
|Includes high resolution water raster from OpenStreetMap. Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1Um7WC8h8Y4BlwgoVSd2xoVO5gTd3E-bI/view?usp=sharing Switzerland_5m]
|Switzerland plus small border
|1.4 GB (ca. 7 GB unzipped)
| 5.75,45.75
| 10.75,48
|10
|CORINE
|5
|PNG
|By mistake taken default airports. If you are using Nia's updated airports, then it will most often work fine, but there might be residuals with osm2city (e.g. tree on APRON).
|included
|-
|[https://de1mirror.flightgear.org/hosting/wayne/ WS3.0 USA]
|USA
|200 to 400 KB (zipped)
| 125,48
| 81,24
|
|NLCD, Tree Canopy Data
|30
|
|by state
|
|-
|[https://github.com/SP-NTX/PolandWS30/ Poland]
|Poland
|1.2GiB
|
|
|
|
|
|
|
|}

=== Airports ===
In addition to the selected areas above, global up-to-date WS3.0 airports have been built. You can find them [https://de1mirror.flightgear.org/ws3/ here]

=== Scenery Files Placement ===
Uncompress the downloaded scenery files into a folder of your choice, such as E:\MySceneryFolder. To be recognized by FlightGear, the selected scenery (from the table above) must be located in a folder with a "vpb" subfolder, such as (EX: C:\mysceneryfolder\hawaii\vpb). The scenery files above are compressed and include the "vpb" folder.

=== Installing ===
Using the FlightGear [[FlightGear_Qt_launcher]] both the terrain and the airport are "installed" by going to tab "Add-ons" and then add the respective folders to "Additional scenery folders". When adding an additional scenery folder, you need to point to the folder immediately above the "vpb" subfolder.

If you add the airports the first time you might have to close the launcher and reopen it again to get the navigation data loaded properly into the session.

== Running World Scenery 3.0 ==
To run WS3.0 you need to set the <code>/scenery/use-vpb</code> property to <code>true</code> at startup. Either set <code>--prop:/scenery/use-vpb=true</code> on your command-line, or in the Launcher in "Settings" -> "Rendering" (you might need to click on "Show more" on the right side to see the choice for "Scenery version".

WS3.0 can use a lot of memory - significantly more than WS2.0. You can control the memory usage with the following properties:

* <code>/sim/rendering/max-paged-lod</code> controls the minimum number of objects that will be kept in memory. The default setting is 200.
* <code>/sim/rendering/plod-minimum-expiry-time-secs</code> controls how long objects remain loaded for after they are no-longer in view. The default value is 180 (3 minutes).

Reducing these properties will reduce the memory footprint of WS3.0.

If you have lots of spare cores, you can run multiple threads to load scenery by setting <code>/sim/rendering/database-pager/threads</code> to a number greater than 4 on startup. E.g. <code>--prop:/sim/rendering/database-pager/threads=8</code>.

=== WS 2.0 scenery might still be needed ===
To have airports displayed plus some of the default scenery objects, you might still want to have the WS 2.0 scenery for the same area installed.

However, if you want updated airports, checkout the global WS3.0 airports above. To avoid collisions you need to not have any WS2.0 airports enabled if you use these.

=== Using osm2city ===
WS3.0 has built-in support for OpenStreetMap roads, so you should not have it enabled in rendering settings.

You have 2 options:

* If you have WS2.0 world scenery, then it already contains osm2city buildings etc. You can just use these and live with slight elevation offsets.
* The other option is to use the provided osm2city scenery in the table above instead. If doing so you need to makes sure that WS2.0 osm2city has not been downloaded (or delete the folders manually). E.g. if you are using [[TerraMaster]] then you can remove the ticks in Settings for "Buildings", "Pylons" and "Roads".

Using the explicitly provided osm2city scenery gives you trees in gardens/parks and some improvements only available on NEXT.

User:Zayamatias/Adding HID devices to FlightGear

2024-04-23T21:41:23Z

Nia: /* Understanding how data is received and processed by your device: */ change the shebang to work on more distros (such as NixOS)

'''Adding HID devices to FlightGear''' hopes to explain how to set-up any HID device to work with [[FlightGear]] in a step-by-step easy to follow guide, it is my belief that any HID can and will work with FlightGear

First disclaimer: The HID subsystem seems to be working only under Linux and MacOS, I am not sure if one day it will work in Windows.
Second Disclaimer: This guide was done under an Ubuntu distribution, this means that other distros may vary slightly.
Last but not least: I take no responsibility in the unlikely event of you breaking your HID device by using this guide

== Getting started ==

Before starting, there are a couple of tools you need to install:

* [https://github.com/hidviz/hidviz HIDVIZ]
*: This tool will allow you to have a look at the inner workings of your HID device, I'll talk about it later.
* [https://code.visualstudio.com/ VS Code]
*: I use this for creating the XMLfiles and the [[Nasal]] code, as it has very nice extensions for this, but this is not mandatory and you can use anything you are used to.
* Python
*: I've created some quick and dirty tools under Python to test the device, so make sure Python (3.9 at least) is installed in your system if you want to use them.

== The Device ==

For this guide, I'll be using the [https://www.logitechg.com/en-gb/products/flight/flight-simulator-cockpit-radio-panel.945-000011.html Saitek/Logitech radio panel] as an example that would hopefully help you with any other device.

So let the fun begin!

== Understanding what's the name of the device ==

Start your PC and go to the terminal, do not connect any device yet, and let's see what has been detected in the USB connections:
<syntaxhighlight>
lsusb
Bus 002 Device 003: ID 045b:0210 Hitachi, Ltd
Bus 002 Device 002: ID 045b:0210 Hitachi, Ltd
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 012: ID 138a:00ab Validity Sensors, Inc.
Bus 001 Device 011: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 008: ID 258a:0001 SINO WEALTH USB KEYBOARD
Bus 001 Device 005: ID 214b:7250 Huasheng Electronics USB2.0 HUB
Bus 001 Device 003: ID 04f2:b669 Chicony Electronics Co., Ltd HP HD Camera
Bus 001 Device 013: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
Bus 001 Device 004: ID 045b:0209 Hitachi, Ltd
Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
</syntaxhighlight>

By issuing the 'lsusb' command you can see what the PC has detected as connected devices, no sign yet of my radio panel, so let's connect it now and issue the same command:

<syntaxhighlight>
lsusb
Bus 002 Device 003: ID 045b:0210 Hitachi, Ltd
Bus 002 Device 002: ID 045b:0210 Hitachi, Ltd
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 012: ID 138a:00ab Validity Sensors, Inc.
Bus 001 Device 011: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 008: ID 258a:0001 SINO WEALTH USB KEYBOARD
Bus 001 Device 005: ID 214b:7250 Huasheng Electronics USB2.0 HUB
Bus 001 Device 003: ID 04f2:b669 Chicony Electronics Co., Ltd HP HD Camera
Bus 001 Device 013: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
Bus 001 Device 014: ID 06a3:0d05 Saitek PLC Pro Flight Radio Panel
Bus 001 Device 004: ID 045b:0209 Hitachi, Ltd
Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
</syntaxhighlight>

Interestingly, I now see the ''Bus 001 Device 014: ID 06a3:0d05 Saitek PLC Pro Flight Radio Panel'' being shown in my connected devices.

If your device does not show up, make sure that it is properly connected, and powered if needed, and as a last resort try to see if it is connectable to any other PC. If still it does not show, then either probably it is not an HID device, or it is not working at all.

So now, save the name ''Saitek PLC Pro Flight Radio Panel'', we will need it afterwards.

== Making sure your Linux user has full access to the device ==

One of the issues with Linux and HID devices is user permissions, Linux is quite secure and usually will let a specific subset of users use the HID device, so let's make sure your user has access to this particular one.

Let's go back to the 'lsusb' output from earlier:

<syntaxhighlight>
Bus 001 Device 014: ID 06a3:0d05 Saitek PLC Pro Flight Radio Panel
</syntaxhighlight >

See that there are 2 hexadecimal numbers in there: '''06a3:0d05 '''? The part before the colon is the vendor id (or VID for shorts) and the second one is the product ID (or PID) for shorts. The first one will change depending on the manufacturer of the device, you can check [https://the-sz.com/products/usbid/index.php?v=0x06A3&p=0d05&n= here if you're curious].

Now, keep those numbers somewhere safe, we will need them.

One of the first parameters to have access to a HID device is to make sure that the user belongs to a group we can refer to, for example in Ubuntu, if your user has to have access to joysticks (as any kind of gaming device) then it has to be added to the 'js' group, like this:

<syntaxhighlight>
usermod -a -G examplegroup exampleusername
</syntaxhighlight>

Where ''examplegroup'' is ''js'' in our case and ''exampleusername'' is your Linux user. You will need to run this as root, so add the 'sudo' prefix before the command

<syntaxhighlight>
sudo usermod -a -G examplegroup exampleusername
</syntaxhighlight>

Remember this 'sudo' for later on.

Ok, so now let's make sure your user belongs to the js group:

<syntaxhighlight>
groups
pi adm dialout cdrom sudo dip plugdev lpadmin lxd sambashare usb wireshark js
</syntaxhighlight>

I can see my user's last group is js, well done, one thing less.

Now we have to make sure that your device is recognized as a joystick, for this, you need to create a new udev rule. Do not worry about what this means exactly (although you can read about it at [https://opensource.com/article/18/11/udev Opensource.com])

We need to tell your Linux install that the Saitek device is a joystick (fun fact, my Linux install though the panel was a mouse, and moving the dials would move the actual mouse...) :

There are several ways you can do this but this one works for me:

Open the (or create a new) rule file under ''/etc/udev/rules.d/'', I have called it ''00-local.rules''

so, let's go for it:

<syntaxhighlight>
nano /etc/udev/rules.d/00-local.rules
</syntaxhighlight>

This will open an editor (nano), feel free to use any editor, just remember that you have to be root to be able to save the file.

Add the following line to your file:

<syntaxhighlight>
SUBSYSTEM=="input", ATTRS{idVendor}=="06a3", ATTRS{idProduct}=="0d05", ENV{ID_INPUT_JOYSTICK}="1",ENV{ID_INPUT_MOUSE}="0", TAG+="uaccess"
</syntaxhighlight>

We now are saying to Linux that the device with VID 06a3 and PID 0d05 is a joystick and not a mouse (do those numbers ring a bell?)

Just for completion's sake, there's another possibility to do this, alas less 'secure' by Linux standards. You can create a new file:
''/etc/udev/rules.d/99-hid.rules'' and in it add the following lines:

<syntaxhighlight>
SUBSYSTEM=="usb", ATTRS{idVendor}=="06a3", ATTRS{idProduct}=="0d05", MODE="0666"
KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="06a3", ATTRS{idProduct}=="0d05", MODE="0666"
</syntaxhighlight>

This will give anyone access to the device in question (and hence less secure in Linux terms).

So now we have setup the device so it is a joystick and your user can access it. Let's go and play with it:

== Understanding your device's Inputs and outputs ==

Make sure your device is connected and powered if needed, Once you're sure, launch hidviz:

(I have compiled the version from the link I've put in the tools section, I won't be explaining how to build it since it is already explained in the GitHub page)

<syntaxhighlight>
./hidviz
</syntaxhighlight>

This will present you with the following screen:

[[File:Hidviz-device-selector.png|Screenshot of hidviz tool main screen]]

Click on 'Select Device', this will ask you for your password to gain root access if you have not run the command as 'sudo'

[[File:Hidviz-device-selector-2.png|Device selector from hidviz]]

You should see the Saitek pro panel there, select it:

[[File:Hidviz-device-descriptor-saitek-radio-panelpng.png|Hiviz showing the HiD descriptor for the Saitek radio panel]]

As you can see, there are 24 buttons (bits) (top section Collection/Input) and there seem to be 2 features. One containing 20 (report count) 8-bit values (report size) with a maximum logic value of 255 and then another report of 14 times 1-bit values (fun fact, when I started with the HID devices I didn't use hidviz, so I'm intrigued by this second feature report which I was not aware of!).

For completion, HID devices (as far as I am aware) have 3 types of reports, input (which is data sent from device to PC) output (which is data sent from PC to device) and feature, which seems to be also in the PC to device category. As you can see, here you have 1 input (buttons) 2 features (we'll talk about these later) and a padding of 2 bits, this is there because usually reports need to be of a specific size (multiplier of 24 if I remember correctly), if you do your maths: 24bits + 20*8 (160 bits) + 14 bits = 198 + 2 padding bits = 200 bits in total, ok it does not add up, go figure, but this is not the only weird thing about this descriptor, look at the actual features described: water cooling device! either Saitek devs had a great sense of humor or they didn't spend much time figuring out how to do proper HID reports. In any case, I was expecting also to have an output report instead of a feature report and each report with its unique ID. Saitek: some improvements are needed here! All of this to say: '''HID is a big grey area amongst manufacturers, so your levels of patience to make the device work may vary'''

If the descriptor would have been set up properly, you should have seen something like this for the output reports: (This is for one of my custom devices):

[[File:Hidviz-device-descriptor-fgmod.png|Hidvizz showing the fgmod descriptor]]

This would have allowed you to easily enter values in the output report and understand how the device treated data, alas, it is not the case for the Saitek device, so let's go Python!

== Understanding how data is received and processed by your device: ==

So we now know a little bit more about the device, it has 24 buttons, and it has 20 possible inputs (spoiler: the Saitek panel has 4*5 segment displays, could it be?? Hmmmm...)

Let's try Python.

First, you need to check which hidraw Linux device corresponds to your actual device, Linux will map your device under ''/dev/hidrawx'' and to find it, create script (call it findhid.sh):

<syntaxhighlight lang="bash">
#!/usr/bin/env bash

FILES=/dev/hidraw*
for f in $FILES
do
FILE=${f##*/}
DEVICE="$(cat /sys/class/hidraw/${FILE}/device/uevent | grep HID_NAME | cut -d '=' -f2)"
printf "%s \t %s\n" $FILE "$DEVICE"
done
</syntaxhighlight>

And then

<syntaxhighlight lang="sh">
chmod 775 findhid.sh
</syntaxhighlight>

And finally execute it:

<syntaxhighlight lang="sh">
./findhid.sh
hidraw0 SYNA3083:00 06CB:8265
hidraw1 ELAN2514:00 04F3:288A
hidraw2 SINO WEALTH USB KEYBOARD
hidraw3 SINO WEALTH USB KEYBOARD
hidraw4 PixA琀 USB Optical Mouse
hidraw7 Logitech Logitech Flight Radio Panel
</syntaxhighlight>

so, this means that our Saitek panel is linked to /dev/hidraw7, nice!

Now, open an editor and create hidtest.py:

<syntaxhighlight lang="python">
import os

def send_data_to_hidraw(data, hidraw_path):
try:
# Open the HIDRAW device
hidraw = os.open(hidraw_path, os.O_RDWR | os.O_NONBLOCK)

# Write data to the HIDRAW device
os.write(hidraw, bytes(data))

print("Data sent successfully to HIDRAW device.")

# Close the HIDRAW device
os.close(hidraw)
except Exception as e:
print("Error:", e)

if __name__ == "__main__":
# Define your data to send
data_to_send = [0x01, 0x02, 0x03,0x01, 0x02, 0x03,0x01, 0x02, 0x03,0x01, 0x02, 0x03,0x01, 0x02, 0x03,0x01, 0x02, 0x03,0x01, 0x02, 0x03] # Example data

# Specify the path to your HIDRAW device
hidraw_path = "/dev/hidraw7" # Replace with the actual path to your HIDRAW device

# Send the data to the HIDRAW device
send_data_to_hidraw(data_to_send, hidraw_path)
</syntaxhighlight>

Two important things: change hidraw_path to your devices' correct link and make sure that the data_to_send variable is of the same length as the report we found in hidvix, in this case, we have 20 times one byte, noted in hex format in Python (0xXX).

Small clarification, as you can see I'm sending 21 bytes, the reason behind this is that the first byte indicates the report_id you're sending to, in the case of the Saitek panel, there's no real report id, so whatever you put in the first byte will still work. Make sure you consider this when testing your device.

Now run the Python script

<syntaxhighlight lang="python">
python3 hidtest.py
</syntaxhighlight>

Nothing happened? well, this could be down to several factors:

- No permissions (go back to the start)
- The report is of incorrect size (try again, remember you are sending bytes, so a report of 8 times 1 bit, equals a nibble (half byte), and the same goes for bits. The safest thing to do is to count the number of bits and then divide by 8, this is the number of bytes you ill need to send)

If you are lucky you should go from this:

[[File:Saitek-radio-off.jpg|Saitek radio panel with all digits off|800x800px]]

To this:

[[File:Saitek-radio-on.jpg|Saitek radio panel with all digits on|800x800px]]

Congratulations, you just sent the first pieces of data to your device. As you can see it shows the numbers in the order we sent in the report, or so it looks like.

Now, it is a game of sending reports with different values and understanding what's your device's reaction, for example, if I sent just zeroes:

[[File:Saitek-all-zeros.jpg|800x800px]]

Now the fun starts.

So this is a radio panel right, aren't radio frequencies supposed to have a 'dot' somewhere, but hey, how do I tell the device I want to have a dot? Let's think, why do I have the possibility to send 20 bytes, with a maximum value of 255? Makes no sense right, watch byte represents a number in the panel that can go up to 9 (0 to 9), so anything else is overkill, unless...

Let's try to send something over 9, for example the second byte in data_to send I put it as 0x0A (A is 10 in hex), what happened there?

[[File:Saitek-all-zeros first-off.jpg|Saitek radio panel showing all zeros except first digit switched off|800x800px]]

My first digit just switched off!! Interesting so now I can show numbers of less than 5 digits (XPDR, DME, hmm...) because I can switch any digit off as I please, let's try that again:

[[File:Saitek-alternate-zeros.jpg|Saitek radio panel showing alternate zeroes and off|800x800px]]

Nice!

So we now know, 0 to 9 is the digit in question, 10 switches off the digit, but what about the 'dot' ???

Let's send 11 (0x0B):

[[File:Saitek-all-zeros first-off.jpg|Saitek radio panel showing all zeros except first digit switched off|800x800px]]

Disappointment, nothing happens, let's keep trying other values.

Hey what's this?

[[File:Saitek-all-ones_and_dots.jpg|800x800px]]

I was at 209, so what if I send all 208 (0xD0)

[[File:Saitek-all-zeroes_and_dots.jpg|Saitek radio panel showing all zeroe and dots|800x800px]]

Ok! So if I want to add a dot to any digit, I need to add 0xD0 the the value, so 0xD0 for 0, 0xD1 for one and so on)

What if I continue?

This is what happens with 224 (0xE0)

[[File:Saitek-all-dashes.jpg|800x800px]]

I get a 'dash'!

And there's nothing else interesting in the tests, the numbers repeat a lot, but basically when now:

0 to 9 -> the numbers in each digit
10 -> Switch off the digits
208-217 -> The numbers with a dot (to the right)
224 -> A dash

Important point, we have not used any proprietary drivers or anything that could be linked to Saitek's proprietary development (AFAIK, I'm not a lawyer), we're just sending data to the device.

Now that we know the logic, we're ready to go to the next step, make it work in FlightGear! [To be continued in next post]

So now we have understood (more or less) how our device works, how we can send data to it, and what this data does.

Let's fire up FlightGear.

== Making sure FlightGear detects the device ==

The first thing we need to do is to launch FlightGear with debug on, to do this make sure you set the log level to debug via the <code>--log-level=debug</code> flag, do this either in the command line or if you use the launcher, in the additional settings.

I would also recommend you to capture the output of the log:

<syntaxhighlight lang="bash">
./dnc-managed/run_fgfs.sh --launcher 2>&1 | tee log.txt
</syntaxhighlight>

This is my command, yours may be slightly different, the important part is the ''2>&1 | tee log.txt'' at the end of it.

launch FG and let the log start capturing all the information we need.

Once the airplane's cockpit is showing up, you can shut down FlightGear, that's all we need for now.

Open the ''log.txt'' and start looking for the name of your device, you should see things like:

<syntaxhighlight>
225.20 [DBUG]:input name=<null>, node=<null>
225.20 [DBUG]:input name=Logitech Logitech Flight Radio Panel, node=/dev/input/event23

225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-0 modifiers=0 value=1
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-1 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-2 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-3 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-4 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-5 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-6 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-7 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-8 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-9 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-266 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-267 modifiers=0 value=1
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-268 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-269 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-270 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-271 modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-left modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-right modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-middle modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-side modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-extra modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-forward modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-back modifiers=0 value=0
225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-task modifiers=0 value=0
225.26 [DBUG]:input using InputDevice Logitech Logitech Flight Radio Panel_0

225.28 [WARN]:input Unhandled HID generic desktop usage:1
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown, bits: 0:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:2
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-1, bits: 8:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:3
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-2, bits: 16:8, report=0
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:joystick, bits: 24:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:5
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-3, bits: 32:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:6
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-4, bits: 40:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:7
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-5, bits: 48:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:8
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-6, bits: 56:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:9
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-7, bits: 64:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:10
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-8, bits: 72:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:11
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-9, bits: 80:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:12
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-10, bits: 88:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:13
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-11, bits: 96:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:14
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-12, bits: 104:8, report=0
225.28 [WARN]:input Unhandled HID generic desktop usage:15
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-13, bits: 112:8, report=0
225.29 [WARN]:input Unhandled HID generic desktop usage:16
225.29 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-14, bits: 120:8, report=0
225.29 [WARN]:input Unhandled HID generic desktop usage:17
225.29 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-15, bits: 128:8, report=0
</syntaxhighlight>

As you can see from the log, there are already several interesting pieces of information:

The device has ben recognized! ''25.20 [DBUG]:input name=Logitech Logitech Flight Radio Panel, node=/dev/input/event23''

It has detected the buttons ''225.26 [INFO]:input Logitech Logitech Flight Radio Panel_0 has event button-0 modifiers=0 value=1''

And even the feature reports '' 225.28 [WARN]:input Unhandled HID generic desktop usage:2
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown-1, bits: 8:8, report=0''

As you can see, we have everything under control, FG has detected the device and has detected the different buttons and feature reports. All of these are called 'events' by FlightGear.

Important point, when we're going to be creating the properties files, we need to refer to the name you see in the logs, as strange as it sounds, you will get different buttons name not necessarily in a sequential order (things like thumb2, or button-333).

== The properties files ==

The way that FlightGear communicates with the devices is via XML files located under the FlightGear directory ('~/.fgfs' for most linux installs) and then under Input, with 2 different options, either 'Joysticks' or 'Event':
<syntaxhighlight>
drwxr-xr-x 2 pi pi 4096 Mar 27 16:12 Event
drwxr-xr-x 2 pi pi 4096 Apr 1 15:49 Joysticks
</syntaxhighlight>
The joystick directory will hold, amongst others, the files that are created automatically by the joystick configurator within the simulator, the directory we're interested in is this:

<syntaxhighlight>~/.fgfs/Input/Event</syntaxhighlight>

Note, there's no problem in having both a joystick file and an event file for the same device, I do have this for my Honeycomb alpha, where the axes are in the joystick file and the rest of the buttons in the event file (which allows me to go beyond the 32 button limitation, yes, you can use this HID way of doing things for devices over 32 buttons).

So let's start writing. First of all, create an empty file called 'YOURDEVCIE.xml' (this is an example and the filename is not relevant as FG will read inside to understand to which device each file belongs (although I name it as the device with '-' just for clarity, for example for the Saitek panel ''Logitech-Logitech-Flight-Radio-Panel.xml'' )

Put the XML header:

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<name type="string">Logitech Logitech Flight Radio Panel</name>
<debug-events type="bool">true</debug-events>
</syntaxhighlight>

This will indicate FG this is the file for your device, as the ''name'' tag defines it.

If you plan to have some 'logic' in your properties file, add the nasal tags:

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<name type="string">Logitech Logitech Flight Radio Panel</name>
<debug-events type="bool">true</debug-events>
<nasal>
<open>
<![CDATA[]]>
</syntaxhighlight>

Your basic file is starting to get some form. Now we need to start defining what do we do when each of the events is triggered:
I'm going to paste below the bindings (that's how it's called in FG) for the fact that you have switched the upper selector of the radio panel into 'comm1' mode:

<syntaxhighlight lang="xml">
<event>
<desc>UK COMM1</desc>
<name>button-1</name>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknoba</property>
<value>/instrumentation/comm/frequencies/selected-mhz</value>
</binding>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobb</property>
<value>/instrumentation/comm/frequencies/standby-mhz</value>
</binding>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobt</property>
<value>5</value>
</binding>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobsw</property>
<value>/instrumentation/comm/frq-swap-btn</value>
</binding>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobmax</property>
<value>137</value>
</binding>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobmin</property>
<value>118</value>
</binding>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobfstep</property>
<value>1</value>
</binding>
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobhstep</property>
<value>0.025</value>
</binding>
<binding>
<command>nasal</command>
<script>refreshPanels();</script>
</binding>
</event>
</syntaxhighlight>

Do not be scared by that size! I like to make things generic, so you will see a lot of reference and proxy properties being set that would allow to handle the logic of what happens when we're in 'comm1' mode in the upper panel.

First of all we set the property ''saitek/RP/upknoba'' to ''/instrumentation/comm/frequencies/selected-mhz''

<syntaxhighlight lang="xml">
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknoba</property>
<value>/instrumentation/comm/frequencies/selected-mhz</value>
</binding>
</syntaxhighlight>

We then set the standby frequency to the ''/saitek/RP/upknobb'' property

<syntaxhighlight lang="xml">
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobb</property>
<value>/instrumentation/comm/frequencies/standby-mhz</value>
</binding>
</syntaxhighlight>

Then the property ''/saitek/RP/upknobt'' to 5, which is the number of digits a frequency has

<syntaxhighlight lang="xml">
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobt</property>
<value>5</value>
</binding>
</syntaxhighlight>

Then the 'swap' button to change frequencies

<syntaxhighlight lang="xml">
<binding>
<command>property-assign</command>
<property>/saitek/RP/upknobsw</property>
<value>/instrumentation/comm/frq-swap-btn</value>
</binding>
</syntaxhighlight>

The some max,min and incremental values, and last but not least, I call the refresh panel function (that I've created) to put the proper values in the panels:
<syntaxhighlight lang="xml">
<binding>
<command>nasal</command>
<script>refreshPanels();</script>
</binding>
</event>
</syntaxhighlight>

This has to be done to every single button in the device, so they act the way you expect them to do. You can check the full file at the bottom of this post.

Ok, so we have the buttons set up, now we want the display to show the proper values:

We use the same tag, event, only that now we have to link a property to the event, so FG will send that value to the output/feature report in the proper position.

Before we continue, remember that in the log, we saw things like:

<syntaxhighlight>
225.28 [WARN]:input Unhandled HID generic desktop usage:1
225.28 [INFO]:input Logitech Logitech Flight Radio Panel_0: add:unknown, bits: 0:8, report=0
</syntaxhighlight>

And I did mention that the name that you saw there is the name that should be used for the event, in the case of unknown, you need to add the suffix ''-0'' for the first one, the rest will already have it ''-1, -2,-3 etc..''

Let's add the event to the XML:

<syntaxhighlight lang="xml">
<event>
<desc>RADIO INDICATORS</desc>
<name>unknown-0</name>
<setting>
<property>/saitek/RP/ULpanel/digit1</property>
</setting>
</event>
</syntaxhighlight>

You're telling FlightGear to watch for the property ''/saitek/RP/ULpanel/digit1'' and set its value to the vendor-0 byte.

As you can see there's a strange property there: ''saitek/RP/ULpanel/digit1''. This property is of my choice and you can create any property you want to be sent to the device. Remember that in this particular case, we have a value for each digit, so we cannot send the actual value, we have to slice it so we send each digit in the correct position.

And then again, do the same for the rest of the events.

Once the events have been set and saved, you can launch FG to see if it worked!

Yes! I see the same frequencies in the panel

[[File:Saitek-working.jpg|800x800px]]

as in the simulator

[[File:FG-Radio_Panel_for_Saitek.jpg|800x800px]]

Of course, every time you modify the frequencies in any of the sim or panel, the other one reflects the same value as expected.

You can have a look at [https://github.com/zayamatias/flightgear/blob/main/.fgfs/Input/Event/Logitech-Logitech-Flight-Radio-Panel.xml the complete xml file], where you can see I use nasal heavily to do some extra logic, for example, do not turn on the panel unless the contact is set on the aeroplane, how I use the swap button to select the digit when in XPDR mode, and so on. There is no limits to what you can do once you understand the properties and what you're able to do with them.

I hope I have not forgotten anything essential and I also hope this has helped. I'm really looking forward to other devices becoming available in FG.

This also opens the possibility of creating your own devices, have a look at my [https://github.com/zayamatias/flightgear repo].

Airbus A320 family/info

2024-04-17T22:41:04Z

Nia:

<includeonly>{{infobox aircraft
| name = Airbus A320 family
| hangar = fgaddon
| aircraft = A320-family
| image = A320-family.jpg
| image2 = A320VirtualCockpit.png
| alt2 = The 3d [[cockpit]] of the A320-family
| type = Airliner
| config = Low wing aircraft/Monoplane aircraft/Retractable gear aircraft/Tricycle landing gear aircraft
| propulsion = Twinjet
| manufacturer = Airbus
| authors = Josh Davidson (Octal450)/legoboyvdlp/Nia/Matthew Maring (hayden2000)/Thorsten Herrmann (TH-555)/Semir Gebran (CaptB)
| fdm = JSBsim
| status-fdm = 4
| status-systems = 5
| status-cockpit = 5
| status-model = 4
| ready = checklist/canvas
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Airbus A320 family]].
[[Category:Aircraft infobox documentation]]
</noinclude>

FlightGear Newsletter August 2020

2024-04-17T22:40:20Z

Nia:

{{User:Skybike/Template:Newsletter-header-translate|2020-08}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== Development news ==


''See the [[FlightGear_Newsletter_August_2020#Help_wanted|Help wanted]] section.''

=== 2020.2 LTS release candidates ===
Release candidates are for the Flightgear 2020.2 LTS are available at [http://download.flightgear.org/builds/rc/ download.flightgear.org/builds/rc/]. Bugs and issues can be reported by making a [https://sourceforge.net/p/flightgear/codetickets/ ticket on Sourceforge].

Nightly builds are also following the 2020.2 LTS branch. Nightlies will return to following the latest changes, once the large changes are stabilised in the 'next' branch that builds towards the release after 2020.2.

===Global OSM2City build===
There is ongoing work on the world build of OSM2City (and a terrain build for the continent of Australia) by Nia, as well as investigations into the feasibility of distributing the world build of OSM2City using Terrasync by StuartB and the OSM2City team.

== New software tools and projects ==


=== FGCom-mumble ===
[http://wiki.flightgear.org/FlightGear_Newsletter_July_2020#FGCom-mumble:_Load_tests_successful.2C_RDF_implemented.2C_Live-Status_page_added The last issue mentioned] the work on a new [https://github.com/hbeni/fgcom-mumble mumble based FGCom] implementation. The development is discussed in the {{forum link|title=FGCom-mumble|f=32|t=37644}}. Releases can be downloaded from [https://github.com/hbeni/fgcom-mumble github].

==== current state ====
Mid-august the development reached [https://github.com/hbeni/fgcom-mumble/releases/tag/v0.4.0 release 0.4.0] which should propose a first complete draft. Some further testing was conducted and bugs ironed out. Testing was mainly conducted with custom tools, the stock C172p, the C182s and ATC-Pie ([https://gitlab.com/atc-pie/atc-pie/-/tree/dev dev version] has fgcom-mumble support). Also small feature enhancements got implemented and, most importantly, 8.33kHz channel names do now work properly. To make things easier, core documentation was translated to german.

After the previous 0.3.0 release some work has been added, mostly cleaning up some internals; but there is also a very basic HF and UHF radio model now, as well as an implementation of the mumble plugin updater, which will check the github page for new releases and notifies the user if there is one.

'''To summarize the main features currently working:'''
* Simulates a continuous frequency spectrum: tune and use any frequency, regardless where you are
** Simple HF radio model (line of sight+skywave propagation, range depending on output power)
** Simple VHF radio model (line of sight, range depending on output power)
** Simple UHF radio model (line of sight, range depending on output power)
** 8.33 channel support
* 910.00 Echotest
* ATIS recording/playback
* Landline support
* RDF support in ATC-Pie

==== open tasks ====
To conduct further and broader testing, we probably need to wait for mumble 1.4.0. As this is probably still a long time out, early testing under linux is welcome.
Also, i still have no idea if the windows plugin loads, so someone with a windows build environment is most appreciated to compile mumble and try the plugin.

The [https://github.com/hbeni/fgcom-mumble/issues issue tracker] still lists some points, but those are either minor ones or are not implementable at the current time. Nonetheless, please see trough the items, maybe you can lend a hand. Also, some code review is welcome!

==== trying it out yourself ====
As mumble 1.4.0 is still in the pipeline, you need a self compiled mumble (and murmur) from the [https://github.com/Krzmbrzl/mumble/tree/plugin-API Krzmbrzl:plugin-API branch] to test this out. If you additionally want to run the server side bots, you also need [https://github.com/bkacjios/lua-mumble lua-mumble].
Detailed installation descriptions are laid out in the readmes.

It would be cool if someone with a public server could try to setup that, so i can verify the readmes are correct and we get an online test bed.

== In the hangar ==


=== Updated aircraft ===

====Diamond DA 40 with G1000====
FGUK have created an updated {{wikipedia|Diamond_DA40_Diamond_Star|Diamond DA 40}} with the [[FG1000|FG1000]] glass cockpit. See the [https://forum.flightgear.org/viewtopic.php?f=4&t=37220 forum thread] for details and [http://fguk.me/hangar/download/6-civil-piston/573-diamond-da-40 download].
* ALS Glass and fuselage effects including rain and livery specific levels of reflection.
* FG1000 glass cockpit.
* Entire cockpit panel layout updated.
* MP Passenger option. Optional wheel spats. MP Sound. 12 liveries.

{{#ev:youtube|a6wZten0np0|480px||Flight in the Diamond DA40 with the new [[FG1000]] from LIDT to LIPX in Flightgrear 2020.1 by FGUK}}

FGAddon currently has 2 versions with partial updates by maintainer Helijah (Emmanuel Baranger). Both are currently updated with FG1000 panel options, but do not have updates with ALS glass cockpit and rain etc. yet:
* YaSim: ''Diamond DA40 (YaSim)'': Normal and copilot variants. To switch between FG1000 use ''in-sim menu > Diamond DA 40 > Panel mode''.
* JSBSim: ''Diamond DA40 NG VFR (JSBSim)'': VFR, FG1000 panel, and IFR variants.

====Eurocopter EC145====
Litzi, StuartC and FGUK have released a GPL update to the {{wikipedia|Eurocopter_EC145|EC145}}, version 1.3. The EC145 is a fully glass cockpit helicopter. See the [https://forum.flightgear.org/viewtopic.php?f=4&t=24800 forum thread] for more information, screenshots, and download.

{{#ev:youtube|TwPBvVvFlI4|480px||How to manually start the [https://forum.flightgear.org/viewtopic.php?f=4&t=24800 EC145] by FGUK. Note the ALS rain effect. The EC145 also features ALS cockpit shadows - which remain the recommended option in the upcoming Compositor: ALS cockpit shadows are extremely fast, can handle tinted glass, and can remain sharp compared to default shadow maps.}}

====Eurocopter EC130 / Airbus Helicopters H130====
FGUK have released a GPL update to the {{wikipedia|Eurocopter_EC130|EC130 / H130}} in FGAddon fixing bugs, updating FDM/Garmin, adding ALS rotorwash and rain effects etc. B4 and T2 versions. See [http://www.fguk.me/hangar/rotary/download/13-rotary-wing/582-eurocopter-ec-h-130-fguk-edition this page] for more information, screenshots and [http://www.fguk.me/hangar/rotary/summary/13-rotary-wing/582-eurocopter-ec-h-130-fguk-edition download]. The [[Eurocopter_EC130_B4|EC130]] in FGAddon has not been updated yet.

{{#ev:youtube|lXj2C1lIFK8|480px||Starting and flying the FGUK version of the [http://fguk.me/hangar/rotary/download/13-rotary-wing/582-eurocopter-ec-h-130-fguk-edition EC130 / H130] by FGUK}}

====AgustaWestland AW159 Wildcat====
FGUK have released an update for the {{wikipedia|AgustaWestland_AW159_Wildcat|AW159 Wildcat}}. See [https://www.youtube.com/watch?v=ZZOeIQHawEk here] for a video from early development in March. See the [https://forum.flightgear.org/viewtopic.php?f=4&t=37766 froum thread] for more information, screenshots, and download.

====Boeing-Sikorsky RAH-66 Comanche====
FGUK have released an update for the {{wikipedia|Boeing–Sikorsky_RAH-66_Comanche|RAH-66 Comanche}}. The Comanche was a futuristic prototype reconnaissance and light-attack helicopter that never reached production phase due to being deemed too expensive. See [https://www.youtube.com/watch?v=kB5qWFq5l84 here] for a video from early development flight testing in February. See the [https://forum.flightgear.org/viewtopic.php?f=4&t=37595 forum thread] for more information, screenshots, and download.







== Help wanted ==
{{Help wanted}}

== AI ==


The AI team makes FlightGear more realistic, colorful and lively every month. You can support the important development of ''Interactive Traffic'' and contribute at the FlightGear {{forum link|title=AI|f=23}}.



== Scenery corner ==


===New releases===

====Argentina====
Barta has released areas of Argentina updated with OSM2City data. The latest releases can be found at [http://scenery.bartatech.net/ http://scenery.bartatech.net/]. Currently the server contains these areas: Santiago (including Valparaiso), Mendoza, Buenos Aires, complete Rosario area. The other parts only have terrain (no roads, buildings etc). The server will eventually contain all of the sceneries in the southern cone of South America: Argentina, Chile, Uruguay. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37489 forum thread] for details on this project.

The [http://scenery.bartatech.net/ scenery.bartatech.net] server can be directly used as a terrasync server. Just use the following in the [[FlightGear_Qt_launcher|launcher]] or .fgfsrc file:
: ''--prop:/sim/terrasync/http-server=<nowiki>http://scenery.bartatech.net/</nowiki>''

====Fernando de Noronha island, Brazil====
Lomar has released a build of Fernando de Noronha island and SFBN airport. The release includes new data sources for terrain, and contains new material definitions and roads. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=29182&start=30#p372380 forum thread] for screenshots and [http://www.mediafire.com/file/pwflzsm7y1c1hxl/fernando_de_noronha_0.2.zip/file download].

====Valdivostock area, Russia====
[[User:Legoboyvdlp|J. Redpath]] has released a scenery build for the Vadivostock area. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for screenshots and github [https://github.com/legoboyvdlp/Vladivostok-fg-CustomScenery/archive/master.zip download].

====Moscow area, Russia====
[[User:Legoboyvdlp|J. Redpath]] has released a scenery build for the Moscow area covering 14 tiles. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for screenshots and github [https://github.com/legoboyvdlp/Moscow-fg-CustomScenery/archive/master.zip download].=

====Eastern China====
[[User:Legoboyvdlp|J. Redpath]] has released a scenery build for the eastern portion of China covering the area around ZSAM and ZSNJ airports. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for screenshots and github [https://github.com/legoboyvdlp/EastChina-fg-CustomScenery/archive/master.zip download].

====Beijing area, China====
[[User:Legoboyvdlp|J. Redpath]] has released a scenery build for the area around Beijing covering 15 tiles (see ZBAA airport). See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for screenshots and github [https://github.com/legoboyvdlp/Beijing-fg-CustomScenery/archive/master.zip download].













== Community news ==







=== FlightGear on Youtube ===
{{#ev:youtube|7pdf_DR4Ku0}}

=== FlightGear on Facebook ===
Since early December 2010, FlightGear has an [http://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.

=== FlightGear on Instagram ===
In January 2018 the [https://www.instagram.com/flightgear_sim/ @flightgear_sim Instagram account] was brought back to life. If you've got nice screenshots to be featured, feel free to {{forum link|text=contact the maintainer|t=33636}}.

=== FlightGear on FlightSim.com ===
Flightgear has also a [https://www.flightsim.com/vbfs/forumdisplay.php?102-FlightGear sub-forum] on flightsim.com - just like the commercial flightsims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.

== Multiplayer events ==









== Contributing ==

=== Translators needed ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====


If you want to participate in the screenshot contest , you can submit your candidate to {{forum link|title=this|f=19|t= }}. Be sure to see the first post for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter.

''Thanks for reading {{PAGENAME}}!''

{{Appendix}}

[[Category:Changes after 2020.1]]
[[Category:FlightGear Newsletter|2020 08]]

[[de:FlightGear Newsletter {{#time: F Y | 2020-08 | de }}]]

FlightGear Newsletter July 2020

2024-04-17T22:39:53Z

Nia:

{{User:Skybike/Template:Newsletter-header-translate|2020-07}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== Development news ==


=== Early CompositeViewer Experiments ===
{{Main article|CompositeViewer Support}}

[[File:Fg-cv.png|thumb|Julian just made some progress on CompositeViewer integration actually.He set things up so that one can 'clone' the current view using akey-press. This creates a new top-level view window with its own copyof the current view's camera projection matrix etc. The view is addedto the CompositeViewer so it sees the same scene.For now at least, cloned views' projection matrices don't change so thecloned views are completely independent from movement of the aircraft orchanges to the main view. Eventually he'd like to make them behave moredynamically, e.g. follow the aircraft if cloned from Helicopter View.At the moment most of the scenery doesn't show up and the backgroundcolours are wrong, but this screen shot shows it working]]

For the time being, FlightGear only supports one view position at a time. Multiple independent view positions (e.g. one screen for the tower view and a second screen for the plane) would complicate a "locked to cache" flag quite a lot...<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28864.html</ref>.

Aircraft can define their own views and so on. But only one view can be active at a time. So no matter how many windows and cameras you define in [[Defaults.xml]], they all are relative to the current view in FG (i.e. cockpit, tower...). <ref>http://forum.flightgear.org/viewtopic.php?p=146136#p146136</ref>

People requiring multiple independent views on the same scenery, e.g. cockpit and tower view [...] these each need their own camera groups and so require OSG's CompositeViewer.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059117/</ref>

And that's not really supported by the current architecture, neither by the tile cache nor by osgViewer::Viewer. We would need to move to a CompositeViewer model, which supports several scene graphs, and rely completely on the osg database paging machinery.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28869.html</ref>

That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17263.html</ref>

Julian Smith reported some success by changing flightgear's FGRenderer's osgViewer::Viewer to an osgViewer::CompositeViewer with a single osgViewer::View, and patching up all the calling code so it compiles.

It all builds ok, and he now got fgfs mostly working with CompositeViewer and the usual single View.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/</ref>

CompositeViewer is not a build-time option any more. It is disabled by default, and enabled on startup with a new --composite-viewer=1 option.<ref>https://sourceforge.net/p/flightgear/mailman/message/37075130/</ref>

Julian made the use of CompositeViewer configurable at runtime, which might simplify getting involved in testing/further development - the same binary can now be used for normal use and for investigating CompositeViewer behaviour.

To execute the patched binary with the compositeviewer enabled, use: <code>fgfs --composite-viewer=1</code> <ref>https://sourceforge.net/u/cgdae/flightgear/ci/059cf073c74d43a57c11f363cae6c9271772d869</ref>

== New software tools and projects ==


=== FGCom-mumble: Load tests successful, RDF implemented, Live-Status page added ===
[http://wiki.flightgear.org/FlightGear_Newsletter_June_2020#FGCom-mumble:_first_prototype The last issue mentioned] the work on a new [https://github.com/hbeni/fgcom-mumble mumble based FGCom] implementation.

The development is discussed in the {{forum link|title=FGCom-mumble|f=32|t=37644}}.
 Releases can be downloaded from [https://github.com/hbeni/fgcom-mumble github].

This prototype was recently completed and load tests showed very promising results (>100 users!). Also advanced features like 910.00 Echotest, ATIS recording and a [https://user-images.githubusercontent.com/13608602/87289717-4a449500-c4fd-11ea-8e4a-cd99242bea07.png live status website] were implemented. RDF detection support was the latest addition and ATC-Pie already has good support for FGCom-mumble based radios with RDF in a development branch.

The plugin now also supports several client sessions within a single mumble session. Clients are distinguished using the client port number of the UDP input packets.

Basicly i think this is ready for public testing now. Testers still need to wait for mumbles official 1.4 release (if you don't want to compile yourself, or on linux want to use my precompiled binarys).
Also open is the question on which hardware this might run on (just needs mumble server, luajit 5.1 and php for the bots and status page).
It would also be very good if some experienced developers could review the code for hidden issues (I'm new to C++ and lua).

== In the hangar ==











== Help wanted ==
{{Help wanted}}

== AI ==


The AI team makes FlightGear more realistic, colorful and lively every month. You can support the important development of ''Interactive Traffic'' and contribute at the FlightGear {{forum link|title=AI|f=23}}.



== Scenery corner ==














== Community news ==
=== Flightgear Community Survey ===
Nia has created a community survey so see, what systems we develop for and what the expectations of the community are.
The results will be published on the [https://forum.flightgear.org/viewtopic.php?f=42&t=37773 forum].
You can take the survey [https://lime.merspieler.tk/index.php/978382?lang=en here]








=== FlightGear on Facebook ===
Since early December 2010, FlightGear has an [http://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.

=== FlightGear on Instagram ===
In January 2018 the [https://www.instagram.com/flightgear_sim/ @flightgear_sim Instagram account] was brought back to life. If you've got nice screenshots to be featured, feel free to {{forum link|text=contact the maintainer|t=33636}}.

=== FlightGear on FlightSim.com ===
Flightgear has also a [https://www.flightsim.com/vbfs/forumdisplay.php?102-FlightGear sub-forum] on flightsim.com - just like the commercial flightsims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.

== Multiplayer events ==









== Contributing ==

=== Translators needed ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====


If you want to participate in the screenshot contest , you can submit your candidate to {{forum link|title=this|f=19|t= }}. Be sure to see the first post for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter.

''Thanks for reading {{PAGENAME}}!''

{{Appendix}}

[[Category:Changes after 2020.1]]
[[Category:FlightGear Newsletter|2020 07]]

[[de:FlightGear Newsletter {{#time: F Y | 2020-07 | de }}]]

World Scenery 3.0 roadmap

2024-04-17T22:39:28Z

Nia:

{{Scenery Core Development}}
{{WS30 Navbar}}
{{See also|TerraGear roadmap}}
{{Project
|name = World Scenery 3.0
|description = New world-wide scenery
|start-date = 2019-Sep
|current-status = Active <ref>https://sourceforge.net/p/flightgear/mailman/message/37074319/</ref>
|developers = Scott Giese Richard Harrison Stuart Buchanan

|motivation-body =
{{Main article|Virtual Planet Builder}}
{{FGCquote
|Virtual Planet Builder (VPB) is OSG's terrain-database-building tool.
It loads GIS elevation data for a
region, combines it with imagery and produces a spatially-balanced
quadtree tiled database that can be navigated simply by loading the
top-level file. All of the LOD Ranges are pre-configured and the
DatabasePager automatically loads and unloads different segments of
terrain without any supporting userspace code required. VPB can build
terrain models ranging from a small area to the entire planet. These
databases can be fluidly navigated at 60fps from outer space down to
ground level with no interruptions. The terrain models are built of
regular grid arrays with optional edge-skirts to conceal any cracks
caused by adjacent LOD differences. 
|{{cite web |url=http://alphapixel.com/wp-content/uploads/2015/04/OpenSceneGraph-OSG-Virtual-Planet-Builder-VPB-OSGDEM.pdf
|title=<nowiki>OpenScenGraph's Virtual Planet Builder/OSGDEM</nowiki>
|publisher=<nowiki>AlphaPixel, LLC</nowiki>
}}
}}

|objective-body =

[[File:Edinburgh rendering using WS3.0.jpg|thumb|Initial rendering of Edinburgh scenery using a raster landclass and texture lookup for city, water and grass]]
[[File:WS3.0 terrain with WS2.0 EGPH.jpg|thumb|Screenshot showing a WS2.0 airport .btg file rendered with WS3.0 terrain]]
[[File:EGPH roads.jpg|thumb|WS3.0 Edinburgh airport with runtime-generated roads from OSM data]]
[[File:WS30 - West Lothian.png|thumb|WS30 view of West Lothian, with 25m resolution landclass data, vegetation, osm2city buildings, and OSM-based roads and rivers.]]
[[File:WS30 street lighting.jpg|thumb|Edinburgh at night, with osm2city buildings, OSM-base roads, including whether they are lit or not. Note the road in the foreground which is lit near the buildings and unlit in the countryside.]]
[[File:Fgfs-20220528191253.png|thumb|WS30 using OSM data to define the coastline. This shows a view near Oban in Scotland looking South. The coastline is applied as a high resolution overlay texture that is generated at runtime from OSM data and mixed with the landclass texture by the ws30 shader.]]

Produce high-quality scenery using the best-known practices.

TerraGear becomes obsolete in favor of VPB.

* '''OpenGL 3.3 Core Profile''': WS3.0 will require us to eliminate the usage of the fixed-function pipeline. 
* '''Shader-based Rendering''': All of the terrain renderings will be done via GLSL shaders. 
* '''OSG Core''': OpenSceneGraph will require targeting of the OpenGL Core Profile.

WS3.0 will continue to cooperate with osm2city.

Easy upgrade: Initially the plan was that airport layouts will be generated in real-time. Apt.dat will continue to be the primary source for airport layouts and that airports will be draped over the terrain. This would eliminate the need to cut airport layouts into the underlying terrain.
Due to difficulties with this approach, it has been decided, that we keep using the WS2.0 airports for now. Work has been done to automatically update the airports from the X-Plane gateway which can be done automatically now.
The apt.dat file gets update with this as well. Here it remains for the navdb parser to understand the 8.33kHz frequencies.

WS3.0 also offers the opportunity for well performing ortho scenery with acceptable memory impact. Nia has acquired GPL compatible sources so we could theoretically have a demo area with ortho scenery in the first WS3.0 release. It adds significant storage requirement tho (~14.7GB per 1x1 degrees tile). There hasn't been a decision made yet, on how to proceed on this.

|background-body =
=== Data Sources ===

:;SRTMGL3.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL3.003/
:;SRTMGL1.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL1.003/
:;Global Land Cover:: https://lcviewer.vito.be/
:;Natural Earth:: https://www.naturalearthdata.com/
:;OpenStreetMap :: https://www.openstreetmap.org (See https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/ genroads.py, gencoastline.py, genwater.py for details)

|status-body =

As of 11/2021, WS30 is available on "next", and on the [https://download.flightgear.org/builds/nightly/ nightly builds].

Scenery is available for Scotland, but must be downloaded directly (https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=sharing). You need to add the downloaded and then extracted folder as additional scenery folder.

WS30 can be enabled from the Rendering Options menu, with fine-tuning from the LoD menu. Alternatively you can set --prop:/scenery/use-vpb=true to enable it as command line option.

Airports are currently in the old WS2 format - including airport keep terrain. The WS30 terrain goes under the airport so it is not visible.

Roads are implemented. Lights on roads are implemented - to see, set time to night. WiP rendering.

Vegetation is available - initial version.

While large water bodies are defined in the landclass texture, rivers are draped on top from OSM data. Coastlines are taken from OSM by are applied as a higher resolution overlay texture to reduce the tiling effect.

Scenery generation workflow is at an advanced stage. It's fast to build. Scott was able to do UK in a matter of hours [https://sourceforge.net/p/flightgear/mailman/message/37259618/]. People interested in generating scenery for the World Build, or getting their landclass or elevation work on [[Suggested custom scenery|custom scenery]] in, should start learning the tools and process. The exact VPB settings and scenery file format may change several times before the final build. But the process of getting work in to shouldn't change much for scenery creators. See the [[Virtual Planet Builder]] page for instructions.

====Scenery generation tool availability ====
* [[VPB]]: '''Linux:''' build from source, docker image available. '''Windows and Mac:''' build from source, no binaries yet, needs NVTT binaries - see "[[Mailing lists|fg-devel]]" mailing list to assist.
* [[QGIS]]: Not needed when experimenting with terrain generation using lower res landclass rasters provided by CORINE. '''Linux:''' build from source, binary packages[https://qgis.org/en/site/forusers/download.html], official docker release available: https://hub.docker.com/r/qgis/qgis but Fahim was not sure easy the GUI is to use [https://sourceforge.net/p/flightgear/mailman/message/37381800/]. '''Windows, Mac:''' official QGIS binary releases [https://qgis.org/en/site/forusers/download.html].

===LoD settings===
Go to ''View > Adjust LoD > World Scenery 3.0 section'' (Nov 2021).
* 7 LoD levels - most detailed is 6, shown at closest range. Least detailed is 0, shown at long range. LoD 0 tiles with Scotland scenery are 1x1 degree, or approx 111 km x 111 km at the equator.
* Scenery is divided into chunks called tiles. As view distance increases, tiles with a LoD level are replaced by tiles with the next lowest LoD level. e.g. Four LoD 6 tiles are replaced by one LoD 5 tile. Four LoD 5 tiles are replaced by one LoD 4 tile. As view gets closer the reverse happens. One LoD 2 tile is replaced by four LoD 3 tiles.
* Detail range - The LoD level below which each type of feature is not visible. e.g. setting vegetation to LoD 3 means vegetation is shown for LoD 3/4/5/6 and not shown for tiles with LoD 0/1/2.
* Minimum line feature width (line features are things like roads or rivers) - for every LoD level, the width in meters below which a line feature is not shown. e.g. setting LoD level four to 30 meters means rivers or roads that are narrower than 30 meters are not shown for level four tiles. The minimum widths should stay the same or decrease when going down a LoD level.
* Minimum area feature width (area features are things like lakes) - similar to minimum line feature width, but for area in square meters. Setting LoD 3 to 100 square meters means lakes of size 99 square meters or 40 square meters will not show for LoD level 3 tiles.

Proof of Concept {{progressbar|100}}
* VPB {{done}}
* osgOcean {{done}}
* osgVegetation {{done}}
* Generate terrain for Hawaii {{done}}
* Hack Hawaii VPB into FG {{done}}
 

OSG {{progressbar|70}}
* Core Profile: {{done}}
* GLVND Support: {{done}}
* glTF Plugin Support: {{ongoing}}
 

{{gallery
| title = Standard-Fidelity
| align = right
| N00-N10-LC100m-SRTMGL3.png | N00-N60 lat
| Africa-LC100m-SRTMGL3.png | Africa Land Coverage
| Africa-Natural.png | Natural Earth
| Ocean-N00-N90.png | Ocean Fill
}}
=== Standard-Fidelity - 90m SRTMGL3 - 100m Global Land Cover ===

=== Northern Hemisphere: 152.3 GB ===
=== Southern Hemisphere: 57.4 GB ===

Virtual Planet Builder {{progressbar|70}}
* Procure Demographic Data: SRTMGL3.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Ocean {{done}}
** Northern: {{progressbar|100}}
** Southern: {{progressbar|100}}
 

=== High-Fidelity - 30m SRTMGL1 - Best Available Land Cover ===

Virtual Planet Builder {{progressbar|30}}
* Procure Demographic Data: SRTMGL1.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
 

|news-body=
The northern hemisphere, up to N60, has been completed. The southern hemisphere, above S56, has been completed.
SRTM data was not captured above N60 and below S56, so alternative data sources need to be procured.

Oceans are complete.
}}

{{gallery
| title = Standard-Fidelity Gallery
| align = center
| Terrain-Mesh.jpg | WS3 Terrain Mesh
| S10-N60-LC100m-SRTMGL3.png | Asia/India
| N00-N10-LC100m-SRTMGL3.png | Europe
| N00-N40-LC100m-SRTMGL3.png | USA
| Africa-LC100m-SRTMGL3.png | Land Coverage
| Africa-Natural.png | Natural Earth
| Africa-Natural2.png | Natural Earth
}}

For the experimental runtime generated mesh/landclassing engine - which may become WS3.0 - see [[Experimental terrain engine]].

[[Category:Development projects‎]]
[[Category:Scenery]]

Virtual FSweekend Hackathon 2023

2024-04-17T22:38:55Z

Nia:

Normally in mid-November a group of FlightGear enthusiasts participate in [[FSWeekend]] in [https://www.aviodrome.nl/ Aviodrome] at the [https://www.lelystadairport.nl/ Lelystad Airport] in the Netherlands. Over the years this has been a focal point for both finishing existing development/releases and a catalyst for new ideas in FlightGear, as well as an opportunity for FlightGear enthusiasts to share a beer. This year the [https://www.aviodrome.nl/evenementen/flight-simulator/?_gl=1*1hh597t*_up*MQ..&gclid=EAIaIQobChMIhdjmndaLgQMVKpiDBx3wFwOwEAAYASAAEgI64vD_BwE Flight Simulator Weekend] has been re-scheduled to March 16/17 2024.

To keep the spirit alive and repeat the successful execution of the [[Virtual_FSweekend_Hackathon_2020|Virtual FSweekend Hackathon 2020]] and [[Virtual_FSweekend_Hackathon_2021|Virtual FSweekend Hackathon 2021]], we are planning to hold another Virtual FSweekend Hackathon on the weekend of {{{days_string|10/11/12}}} November {{{year|2023}}} (in {{days from now|{{{year|2023}}}|11|10}}).

== Hackathon? ==
For those who have not participated in a hackathon before, the broad idea is to get people from a wide variety of experience and backgrounds together to solve problems over a short period of time - typically 24 or 48 hours. Details vary, but typically at the start of the event, people pitch ideas and groups form organically based on what people are interested in. The groups then work together intensively, often fueled by pizza and caffeine etc. At the end of the hackathon the groups present their work and there are often prizes for the best hacks.

The general idea of virtual FSWeekend hackathons is to encourage existing and new contributors to collaborate over the course of a weekend to create new and exciting features for FlightGear in the broadest sense. The core developers would particularly like to use it as an opportunity to encourage people to get their hands dirty in the core code, so they will be primarily there to help/coach people rather than hacking themselves, but anything is possible :)

No prior development experience is necessary - there might be run some education sessions ahead of the weekend so people can hit the ground running (otherwise you will learn during the hackathon). Also, do not feel you have to commit to coding the entire weekend to the exclusion of all else. We think participants will still get real value if they can just commit to one day and some late evenings.

== Only Core Development? ==
While the core of the hackathon incl. support previously has been dedicated to development in the very core of FlightGear (mostly C++, [[Nasal_scripting_language|Nasal]] and xml), you are also welcome to participate if you are developing stuff, which contributes to the general FlightGear ecosystem (e.g. [[Addon]], visual artwork or [[Osm2city.py|osm2city]]). However, in that case you might need to provide your own support.

== Sign up ==
{{Note|There is space for many participants, so don't be shy. {{{organizer|Rick}}} is happy for people to register right up to the Friday night, but we will not be able to help out with getting builds and git working if you leave it that late!}}

To register your participation, please contact {{{organizer|Rick}}} either on the {{forum link|t=41662|text=forum post}}, by PM on the [https://discord.gg/rzuV2DR FlightGear Discord server] or via the [https://sourceforge.net/p/flightgear/mailman/message/37890811/ devel list].

Confirmed participants (in alphabetical order):

{| class="wikitable"
|-
! Name
! aka.
! Role
! Remarks
|-
|Nia
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21618 Nia], also Nia on [https://matrix.to/#/#flightgear-jsbsim:hacklab.fi FG Matrix]
|Infra provider, ask if you've got issues with Mattermost or Jitsi
|Can help with osm2city data processing (worldbuild stuff)
|-
|Rick Gruber-Riemer
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9140 vanosten], HB-VANO on FG Discord
|Organiser/mentor
|Can coach osm2city and OSM data processing
|-
|Stuart Buchanan
|[[User:Stuart|stuart]]
|Mentor
|Can coach on most part of FlightGear. Particularly interested in WS3.0 at the moment.
|-
|James Turner
|
|Mentor
|Can coach on most of FlightGear.
|-
|
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=25958 MariuszXC], MariuszXC on FG Discord
|Participant
|
|-
|Chris Frey
|
|Participant
|
|-
|Felix Zaho
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=27642 superxxx]
|Participant
|
|-
|Pat Callahan
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=14816 callahanp]
|Participant
|
|}

== Ahead of the Hackathon ==
There are a couple of key activities ahead of the weekend in {{{year|2023}}}.

=== Getting started ===
So we can hit the ground running, we really want everyone participating to already have:
* SourceForge credentials
* A working build environment with [[OpenSceneGraph|OSG]], [[PLIB]] etc.
* A Git checkout of simgear/flightgear (cf. [[FlightGear_Git]])
* A Git checkout of fgdata
* Some experience with [https://git-scm.com/ Git]

At the very least you should be able to work with a [[FlightGear_build_server|nightly version]] of FlightGear.

Before the Hackathon consider having a look into the dedicated [[:Category:Hackathon Materials|Hackathon Materials]] category for articles, which might help get you going.

=== Logistics ===
Being completely remote, we need the ability to collaborate in teams as well as video conference as a group.

There will be a [https://mattermost.com/ Mattermost] server for the weekend. We'll be using that for organization, discussion and collaboration.

We'll be using a [https://jitsi.org/ Jitsi] Server for video conferencing and demos.

To use the server, please start the Jitsi calls from within Mattermost (click on that power plug symbol in the top bar next to the search). Preferably use an app or Chrome/Chromium.

=== Ideation ===
The core of the Hackathon! These are the projects, ideas and problems that participants will be working on during the weekend. In the weeks before the Hackathon itself, participants can, and should, propose things to work on. Simply create a wiki page describing your idea, and encourage people to contribute and get interested.

Check out the [[:Category:Hackathon {{{year|2023}}} Ideas|Hackathon {{{year|2023}}} Ideas]] category page for a how-to as well as links to existing proposals.

You can also take a look at proposals from the previous years.

Not having an idea? No problem! Have a look at the proposed ideas, leave a comment on the Discussion page, and add yourself as an Interested Party for those ideas you consider working on during the Hackathon. There is no commitment until the start of the Hackathon on Friday evening.

== Schedule ==
With (hopefully) a world-wide group of participants, and varying real life constraints, at any given time over the weekend there will hopefully be a couple of people active.

We will have two big get-togethers:

=== {{{kick-off-totd-utc|Friday 10th November 2000-2200 UTC.}}} Kick-off ===
* General welcome
* Introductions
* Hack pitches
* Team formation

This is the point at which participants will decide, which Hacks they want to work on. The sponsors of each of the Hacks proposed ahead of time will be invited to give a 5 minutes pitch to the group, with some questions from the audience. Slides/screenshots optional.

After all the Hacks have been pitched, we will have a little break for people to chat and work out which Hack they want to work on.

If a Hack ends up with fewer than 2 people wanting to work on it (including the sponsor), then it will normally be dropped. This is to encourage people to work in groups - larger teams can get more done in the time, and have more opportunities to learn from each other, plus it is more sociable!

=== {{{wrap-up-totd-utc|Sunday 12th November 2000-2200 UTC.}}} Wrap up and demos ===
At the end of the hackathon we will have a get together and have each team present the results of their hack.

Depending on the number of hacks, each team will have 5-15 minutes to demonstrate their hack, describe what they have learned, and what their next steps are.

We will finish with voting for the best hack of the weekend.

== FAQ ==

'''Q''': What is the aim of the Hackathon? 
'''A''': To learn and have fun hacking FlightGear. Encourage people to get their hands dirty and modify code. Try out new ideas. Working with other people. Ultimately to increase the number of core developers.

'''Q''': What can participants expect to get out of the weekend? 
'''A''': The primary goal is for people to learn through experimentation. To try out new ideas and in the process learn about the internals of FlightGear. James, Stuart and Fernando will be be providing coaching over the course of the weekend.

'''Q''': What organization will be provided? 
'''A''': We will provide tools for collaboration, and organize a couple of meetings, but not much more. The idea behind hackathons is that participants largely self organize - teams form around interesting ideas on Friday evening and organize themselves. Participants will need to provide their own computers, pizza, Haribo, beer. The last three are traditional, but optional.

'''Q''': How much time do I need to commit? 
'''A''': The more the better. A traditional hackathon would be 24-48 hours of solid work with sleep optional. That is not realistic for most people, but 20 hours over the weekend would be a good amount to aim for. Certainly if you can only commit to a couple of evenings you may not get much out of Hackathon.

'''Q''': What skills do I need? 
'''A''': It depends on what you want to do. You need to know C/C++ already to be able to hack the core of FlightGear. The Hackathon is not a good place to learn C++ for the first time. However, there are lot of interesting projects using Python, Nasal etc.

'''Q''': I have got a great idea for the Hackathon. What do I do? 
'''A''': Great! Create a wiki page describing it to enthuse other people and collect comments (see [[#Ideation]] section above), and post a link to the Ideation section above so everyone can see it.

[[Category:Hackathon Materials]]
[[Category:Hackathons]]

Virtual Reality

2024-04-17T22:38:06Z

Nia:

{{Experimental|disclaimer=VR support in flightgear still comes with a number of caveats.}}

{{infobox subsystem
|image = VR screenshot c182s.png
|name = Virtual Reality
|started = 07/2021
|description = Virtual Reality support using osgXR / OpenXR
|status = Active
|developers = James Hogan <ref>https://sourceforge.net/u/amalon/profile/</ref>
|changelog = https://sourceforge.net/u/amalon/profile/feed.rss
}}

The '''Virtual Reality''' project aims to add immersive VR support to FlightGear. This is done using the OpenXR<ref>{{cite web |url=https://www.khronos.org/OpenXR/ |title=OpenXR Overview |publisher=The Khronos Group Inc}}</ref> API, via an external library called osgXR<ref name="github-osgXR">{{github source |user=amalon |repo=osgXR |full=1}}</ref> for handling OpenXR and OpenSceneGraph specifics, which is being developed in parallel.

== Background ==

A previous attempt to support some form of VR is described in [[OculusImplementation]].

The portable OpenXR API now seems to be getting widespread adoption, which will allow FlightGear to support a variety of VR devices across multiple platforms.

== Source code ==

* osgXR source can be found on github<ref name="github-osgXR"/>, or the version included in the flightgear 3rdparty directory can be used.
** On ArchLinux, you can install the osgxr AUR package <ref>https://aur.archlinux.org/packages/osgxr/</ref> to get the version needed by FlightGear's next branches.
* Some VR code can now be found in FlightGear's next branches (see below for details).
** On ArchLinux, you can use the -git AUR packages, i.e. flightgear-git, simgear-git, flightgear-data-git.
** On Windows, you can use the [[Nightly Build#Windows|Windows nightly builds]].
* More FlightGear changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased). A mirror is available on github for issue tracking<ref>{{github source |user=amalon |repo=flightgear-vr}}</ref>.
* More SimGear changes can be found in James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).
* More FGData changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).

== Building & Packaging Notes ==

When CMake runs for FlightGear (next or osgxr/osgxr_clean branches), by default it will attempt to enable VR on Windows and Linux (same as <code>-DENABLE_VR=ON</code>). It will do the following:
# Look for the osgXR library, and if found it will link against that (same as <code>-DSYSTEM_OSGXR=ON</code>).
# If no osgXR library is found it will check for OpenXR and if found it will build its own static built-in copy of osgXR to use.
# If no OpenXR is found it will disable VR support.

In any case it will print a message along the lines of <code>-- VR support enabled/disabled...</code>.

To avoid implicit dependencies when packaging, packagers may need to do ONE of the following:
* preferably depend upon an osgXR package providing the osgXR dynamic library
* OR depend on OpenXR and GLX, and explicitly pass `-DSYSTEM_OSGXR=OFF` to CMake so the built-in osgXR is built statically
* OR explicitly pass `-DENABLE_VR=OFF` to CMake to disable VR support altogether

== Status ==
'''Last updated: 31st March 2024'''

Highly experimental, partially in next, partly out of tree. Development in progress.

Working in next branch (e.g. [[Nightly Build#Windows|Windows nightly builds]]):
* Enable/disable at startup via --enable-vr / --disable-vr command line options, or from GUI (View->VR Options).
* VR friendly splash screen.
* Displaying stereo images on the HMD.
* Motion tracking updates HMD views (but doesn't move main camera).
* Configurable VR mirror (see View->VR Settings) shown in default camera view (blank, left, right, side-by-side left & right).
* Visibility mask support.

Working in osgxr/osgxr_clean branch:
* Controller support for flight (helicopter collective in left hand, helicopter cyclic in right).
* Controller pointing support with some mouse emulation.
* Rendering of controllers (as basic cuboids).

Current priorities:
* Support [[HDR Pipeline]] and accelerated multiview rendering.
* Continue to polish controller flight support, add haptics etc.
* Get started on other controller interaction and controller rendering.

=== Known issues ===

* <s>Splash screen is rendered directly onto the left eye viewport which isn't very pleasant in VR.</s>
* Performance could be better so crank down the graphics if frame rate is low.
* Shadows are broken:
** When shadows are enabled, the FlightGear window doesn't appear to refresh even though buffers are swapped, but VR output works.
** Sun position is fixed relative to head, presumably because shadow maps are rendered based on master camera, but osgXR only moves slave cams.
* Spotlights (taxi/landing lights) are relative to camera in default mode
** Affects default / scene view mode (<code>--prop:/sim/vr/mode=AUTOMATIC</code>), as stereo callbacks position cameras
** Doesn't affect slave cameras mode (<code>--prop:/sim/vr/mode=SLAVE_CAMERAS</code>), as slave cameras are positioned correctly
* ALS filters appear to operate in screen space but don't take into account side by side rendering
* [[HDR Pipeline]] is unsupported, but work to support it is in progress
* Still some Monado issues:
** <s>Saturated output due to not using SRGB textures</s> (use osgXR 0.3.8)
** <s>Suboptimal depth format used</s> (osgXR 0.3.8 should end up using GL_DEPTH32F_STENCIL8)
** Warnings about suggesting bindings of attached action sets when restarting VR (looks like a monado issue at first glance)
* Multiple SteamVR issues on Linux:
** If it doesn't close cleanly on Linux it may be due to a SteamVR bug<ref name="github-SteamVR-422"/>, but a ctrl+c / SIGINT on the command line should close it.
* osgXR doesn't support Direct3D graphics bindings for WMR (it isn't a priority for me). Contributions welcome.

=== Testing ===

VR has been tested with the following hardware & software configurations:
* HTC Vive, SteamVR, Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 21:43, 27 August 2021 (UTC)
* Oculus Quest 2, SteamVR (ALVR), Linux/X11 (Fedora 34) -- [[User:vezza|vezza]] ([[User talk:vezza|talk]]) 16:30 27 August 2021 (UTC)
* Oculus Quest 2, Oculus App, Windows 10 --[[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 13:22, 7 June 2023 (UTC)
** Works fine, shadows gets rendered, but move when turning the head.
** Eye view point is about 0.2 meter above where the view is defined, so I have to duck my head to look out through the HUD and stuff.
* Oculus Quest 2, SteamVR via Virtual Streamer App, Windows 10, Nightly build --[[User:Skyclmbr]] 18:17, 11 October 2023 (UTC)
** Head tracking works fine, but right eye screen flickers constantly throughout flight
** Starting head position is off, depending on how much I move around while it's loading on the SteamVR page.
* HTC Vive, Monado (to window), Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
* Monado dummy driver, Linux/X11 (ArchLinux), Intel mesa -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
** /sim/vr/depth-info=false
* Monado Dummy HMD, Linux/X11 (Debian), AMD Mesa Drivers [[User:merspieler|Nia]] ([[User talk:merspieler|talk]]) 23:27, 17 December 2021 (UTC)
** Applying the following patch: <syntaxhighlight lang="diff">
diff --git a/src/XRState.cpp b/src/XRState.cpp
index ce09bcd..5bcbbca 100644
--- a/src/XRState.cpp
+++ b/src/XRState.cpp
@@ -1017,7 +1017,7 @@ XRState::UpResult XRState::upSession()
unsigned int thisDepthBits = 0;
switch (format)
{
- case GL_RGBA16:
+ case GL_RGB10_A2:
// FIXME This one will do for now...
if (!chosenSwapchainFormat)
chosenSwapchainFormat = format;
</syntaxhighlight>

* HP Reverb G2, Gigabyte (AMD) RX 6700 XT, Windows 10, SteamVR -- [[User:Gastcan|Gastcan]] ([[User talk:Gastcan|talk]]) 02:15, 09 July 2023 (UTC)
** (Using the Windows nightly build 08-Jul-23)
** The view follows the direction of the headset, but the image stutters; outside scenery and within the cockpit

* HP Reverb G2, Gigabyte (AMD) RX 6700 XT, Debian (Trixie), Monado -- [[User:Gastcan|Gastcan]] ([[User talk:Gastcan|talk]]) 16:15, 14 August 2023 (UTC)
** Compiled from sources: OpenXR-SDK-Source, Monado, osgXR (amalon), SimGear (amalon), FlightGear (amalon)
** The view follows the direction of the headset with minor stuttering.
**<s>The viewpoint/perspective drifts clockwise, to the right.</s> <- Drifting is virtually eliminated by adding '[https://gitlab.freedesktop.org/mateosss/basalt Basalt for Monado]' (provides 6DoF).

If you've got VR working, feel free to add your configuration above.

The following testing is desired:
*SteamVR, Linux, AMD graphics:
**Test that motion smoothing works (its unsupported on NVidia)
** moving head side to side should reproject using depth buffer
**try suspending fgfs with Ctrl+Z in terminal (resume with fg) to force reprojection
*Monado, Linux:
** May be awkward to test as it crashes in latest NVidia proprietary drivers<ref>https://gitlab.freedesktop.org/monado/monado/-/issues/122</ref>.
***There's now a workaround mentioned in that ticket that allows for basic testing
** Use at least osgXR 0.3.6 for monado workaround, or <code>--disable-vr</code> and enable VR with GUI
*SteamVR, Windows, with a headset (I've only attempted to null driver, and it at least partly worked):
**Needs building with at least osgXR 0.3.7 for Windows bindings, and my osgxr/osgxr_clean branch of flightgear/fgdata/simgear
**May need --disable-sentry
**Test headset output and controllers

Issues can be reported:
* On the flightgear-devel [[Mailing lists|mailing list]]
* To the {{tickets|FlightGear bug tracker}} if the issue is reproducible on the next branch
* To the [{{github issues url |user=amalon |repo=flightgear-vr}} flightgear-vr issue tracker]
* To the [{{github issues url |user=amalon |repo=osgXR}} osgXR issue tracker] if it is known to be a non-flightgear specific bug in osgXR

But please be aware of the known caveats mentioned above, and the roadmap below.

==Performance==

Here are some pointers to get the best VR experience.
* Ensure your runtime supports asynchronous reprojection, which may alleviate the nausea induced by lower frame rates.
**On Linux / SteamVR / NVidia proprietary driver, ensure you have at least driver version 270.
*If your frame rate is being capped at the refresh rate of your desktop monitor, try disabling VSync in both flightgear settings and your driver settings
**On Linux / NVidia proprietary driver, its found in OpenGL settings in nvidia-settings.
*If FlightGear is getting throttled by SteamVR (to try and ensure a consistent, if slow, frame rate), consider switching to fixed throttling (in per-application video settings) and playing with the sliders. You may prefer no frame rate throttling but a higher predicted frame time.
*Enabling multithreading may get you better performance, e.g. <code>--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext</code>
*If using an AMD GPU, use [https://gitlab.com/corectrl/corectrl CoreCtrl] and set the GPU to the "Virtual Reality" power profile with GPU and memory clocked to max. You may also benefit from changing the CPU frequency governor to Performance.

==Implementation Details==

===Concepts===

====Interaction Modes====

Interaction modes are a way of describing (via XML) how a VR controller should look and behave in a particular context. It roughly corresponds to a virtual control you can hold (and let go of), for example:
*When you're holding a helicopter collective control, the pitch angle of the controller should control the collective pitch (and look like a collective in your hand).
*When you're pointing the controller at a GUI or cockpit controls it should pick along a line, rendered in a specific way, and emulate mouse events to those controls (and look like a small laser pointer control or a pointing hand/glove).
*When you're teleporting around, it should pick along a parabolic arc, rendered a specific way, and teleport there when the button is released.
*When you're using the flight recorder it should treat the controller trackpad as a rewind/fast forward (and look like a fancy TV remote or something).

The definition of interaction modes should be generic enough that custom ones can be provided with aircraft, or defined separately and work with any aircraft, but also powerful enough that a complex and intuitive control can be defined with a minimum of Nasal scripting.

==Roadmap==

===Development targets===
*Merge stable & minimally functional code into next ({{Merge-request |project=flightgear |id=253}}, {{Merge-request |project=fgdata |id=238}}) {{done}}
**Bare functionality {{done}}
**Stability {{done}}
*Merge some form of desktop mirroring of VR view ({{Merge-request |project=flightgear |id=260}}, {{Merge-request |project=fgdata |id=241}}) {{done}}
*Merge visibility mask support ({{Merge-request |project=simgear |id=98}}, {{Merge-request |project=flightgear |id=264}}, {{Merge-request |project=fgdata |id=244}}) {{done}}
* Polish {{not done}}
**Make launcher accessible to VR user {{not done}}
**Make splash screen VR friendly {{done}}
**Make GUI accessible to VR user {{not done}}
**Make aircraft center accessible to VR user {{not done}}
*Functionality {{progressbar|40}}
**Controller flight support {{progressbar|80}}
*** Haptic feedback {{not done}}
**Controller interaction support {{progressbar|40}}
** Walker locomotion / room scale {{not done}}

===General tasks ===

*Stability {{done}}
**Clean shutdown {{done}}
***SteamVR for Linux hangs on OpenXR app shutdown<ref name="github-SteamVR-422">{{github issues url|ValveSoftware|SteamVR-for-Linux|number=422}}</ref>.
** Handle OpenXR stopping {{done}}
***SteamVR for Linux kills running app even if it ends session<ref>{{github issues url|ValveSoftware|SteamVR-for-Linux|number=461}}</ref>.
*Resolve questions around VR mirror switching {{done}}
*Performance {{progressbar|10}}
** Handle shouldRender=false by somehow disabling VR cameras (maybe setting cull mask to 0) {{not done}}
**SceneView mode: Combine culling traversal {{not done}}
**Check why update isn't proceeding in parallel with multithreading {{not done}}
**Use OpenXR visibility mask extension to avoid rendering to invisible fragments {{done}}
*Sound {{progressbar|0}}
** Ensure surround sound is relative to user's head {{not done}}
**Investigate a way to use appropriate OpenAL binaural mode automatically {{not done}}
**Specify separate sound device for VR so it switches automatically? {{not done}}

===User facing features ===

*Display {{progressbar|60}}
**Show views on HMD {{done}}
**Configurable mirror on desktop window {{done}}
***Left, Right, Left & Right {{done}}
***Composited mirror mode (combine & blend views and allow zooming) {{paused}}
**General [[HDR Pipeline]] Support {{progressbar|50}}
**Geometry shader multi viewport ([[HDR Pipeline]]) {{progressbar|50}}
**OVR_multiview2 with OSG branch ([[HDR Pipeline]]) {{progressbar|20}}
* Motion tracking {{progressbar|50}}
** Follow motion of HMD {{done}}
**Move master camera instead of scene slave cameras (presumably would fix surround sound) {{not done}}
*Settings {{progressbar|20}}
** Mirror settings {{done}}
**Dynamic toggling of VR {{done}}
**Sound settings? {{not done}}
***Sound reference frame (user's head or room)? {{not done}}
**Advanced VR settings {{not done}}
***validation layer {{not done}}
*** submit depth information {{done}} but needs testing (SteamVR+Linux+nVidia doesn't do motion smoothing yet)
***osgXR VR mode {{not done}}
****Fix slave cameras mode clearing {{not done}}
***osgXR swapchain mode {{not done}}
*Platform support {{progressbar|70}}
**Linux/X11/OpenGL graphics bindings {{done}}
** Monado support {{progressbar|60}}
**Windows/OpenGL graphics bindings {{done}}
**Windows Mixed Reality render via DirectX bindings {{not done}}
* Splash screen {{progressbar|80}}
**Show splash screen as quad layer for runtime to composite {{done}}
**Cube map/quads background provided by aircraft {{progressbar|20}}
*GUI {{progressbar|10}} {{priority|2}}
**Shown over mirror on desktop window {{done}}
** Expose a menubar & GUI, rendered to a quad or cylinder in front of VR user when they activate {{not done}}
**Interact with GUI buttons etc using controllers as lasers {{not done}}
*Launcher {{not done}}
**Show launcher in VR similar to GUI when enabled via command line or launcher option {{not done}}
**Transition to flightgear {{not done}}
**Transition to aircraft center with VR already started {{not done}}
**Transition back to flightgear from aircraft center {{not done}}
**More VR friendly environment
***A simple background cubemap, shared with splash {{not done}}
***A hanger (like xplane11)? {{not done}}
*Controller support {{progressbar|50}}
**Basic action support in osgXR API {{done}}
**Tie osgXR actions into FG's input system {{done}}
**Helicopter flight controls (can use for planes too) {{done}}
**Plane flight controls {{not done}}
** Render controllers {{progressbar|20}}
**Hand tracking (robot hand) {{progressbar|90}}
** Render skinned hand {{not done}}
**Basic interaction with controls {{progressbar|80}}
***Grasp surfaces {{{progressbar|90}}
***Force feedback for haptic gloves {{not done}}
**Advanced interaction with animated controls {{progressbar|90}}
*** Direct manipulation mouse mode for testing without VR {{progressbar|90}}
***Inverse kinematics of translate and rotate animations {{done}}
***Ability to specify frictions {{not done}}
***Ability to specify ranges (where can't be deduced) {{not done}}
***Ability to hint what aircraft processes/filters/kinematics should be reversible {{progressbar|10}}
** Haptic feedback {{not done}}
* Walker VR locomotion / Room scale {{progressbar|0}}
** Walker follows user {{not done}}
**Parabolic arc teleport {{not done}}
**Snap into seats {{not done}}
**Easy turning around {{not done}}

===Aircraft compatibility===

This section is largely about how usable controls are in VR with direct manipulation.

====[[Cessna 172P]] ====
*Controls
**Flaps {{progressbar|90}}
***kinematic needs to be reversible {{progressbar|90}}
** Visors {{progressbar|70}}
***correct relative friction {{not done}}
**Opening of doors {{not done}}
***reversing of gain expression {{not done}}

====[[Eurocopter EC130 B4]] ====
* Engine start
** Engine cutoff lever reversing (Alt+C required) {{not done}}
**External power on (GUI required) {{not done}}
**External power off (GUI required) {{not done}}
**Throttle roll (middle mouse drag required) {{not done}}
*Take off & flight
** Arms & hands get a bit in the way {{not done}}
*Controls
** Engine cutoff lever {{not done}}
***Uses nasal, needs pick animation binding of some sort
**ELT {{progressbar|50}}
***Both /ELT/test and /ELT/armed can be set to bool
***Both can get set though
**Doors & hatches {{not done}}
***Add limits

====[[McDonnell Douglas F-15 Eagle]] ====
*Model
**Floating switches are very noticeable {{not done}}
**HUD should be at infinity {{not done}}

====[[Robinson R22]] ====
*Controls
**Tilting T-bar {{progressbar|90}}
***limit range? {{not done}}
**Collective awkward to get at {{not done}}
**Throttle roll & governor switch? {{not done}}

====[[Robinson R44]] ====
*Controls
**Tilting T-bar {{not done}}

==References==
{{Appendix}}

[[Category:Core development projects]]

Areas populated with osm2city scenery

2024-04-17T22:37:24Z

Nia:

{{Note|As of FlightGear 2020.3.7 LTS, OSM2City scenery is '''automatically''' downloaded as you fly, with [[TerraSync]] enabled - see [[OSM2City_1st_Worldbuild | 1st world-build of OSM2City]]. TerraSync is the normal way to download OSM2City.}}{{Note|You should '''remove''' old custom sceneries containing OSM2City object folders that are obsolete because of OSM2City on TerraSync. If these sceneries contain folders like Terrain that are not obsolete, you can contact the author or delete OSM2City folders. See [[OSM2City_1st_Worldbuild#Troubleshooting|Troubleshooting the 1st OSM2City worldbuild]].}}[[File:SOTM-Mar19.jpg|thumb|OSM2City output for Madrid, Spain - 2017.2. See [[:Category:Screenshots_of_scenery_with_OSM2City_output|here]] for more screenshots.]]

As of FlightGear 2020.3.8 and [https://www.flightgear.org/download/ later], the normal way to get OSM2City is ''automatic'' downloads as you fly through [[TerraSync]] with the latest version of FlightGear. OSM2City scenery for the whole world has been generated from the objects in the OSM database - see [[OSM2City_1st_Worldbuild |1st world-build of OSM2City]]. 2020.3.6 LTS and earlier will not automatically download OSM2City.

This article contains a list of areas having [[osm2city.py|osm2city]] generated scenery available for ''manual'' download. The [http://osm2city.readthedocs.io/en/latest/using.html OSM2City manual] describes how to use the sceneries in FlightGear.

'''Note:''' You only need to download from this page if: '''a)''' your internet connection is limited or, '''b)''' you are looking for OSM2City scenery built with different options or a new OSM2City version than the rollout on TerraSync or, '''c)''' you are using an old version of FlightGear and can't update to 2020.3.8 LTS or [https://www.flightgear.org/download/ later].

== FlightGear Versions ==
The FlightGear versions mentioned in the tables below indicate compatibility as follows:

{| class="wikitable"
! Version !! Compatible FG versions !! Effects !! Choose which objects to show !! Remarks
|-
| 2020.1 || 2019.2 x-mas and all newer versions || traffic, regionalization || yes || The big change is the possibility to render the majority of buildings with the FG random buildings shader, which results in faster rendering and depending on the region a factor 4-10 reduction in disk size. Your FG will most probably crash immediately if you use such a scenery with an older FG version.
|-
| 2017.2 || 2017.2.2 and all newer versions || traffic, regionalization || yes ||
|}

If a table entry specifies both 2017.2 and 2020.1, then it means there is a sub-folder "Buildings_list" within the scenery. By renaming folder "Buildings" to "Buildings_mesh" and then renaming "Buildings_list" to "Buildings" you can transform from 2017.2 to 2020.1 and get the rendering advantages. (There is no requirement for such a folder structure - vanosten might provide some of the sceneries like this for convenience.)

There are older osm2city sceneries around, but there is no reason to use an old FG version: if your computer does not run a newer version, then chances are high that the rendering of osm2city will be poor, too.

== Available areas ==
Announcements of new sceneries should be made in https://forum.flightgear.org/viewtopic.php?f=5&t=32254.

{| class="wikitable"
! Download link !! Area !! In [[TerraSync]] !! Min. FG version !! Created Date !! Created By !! [[Project3000]]<ref>Meaning that the scenery was generated respecting objects placed by Project3000, but does not contain it</ref> !! Remarks
|-
| [https://cdn.merspieler.tk/osm2city/current/ '''World''']
| '''Entire World''' || '''Yes'''
| '''2020.1''' || '''Completed''' || '''Nia''' || || '''NOTE:''' Downloaded ''automatically'' in FlightGear 2020.3.7 and [https://www.flightgear.org/download/ later]. Requires at least FlightGear 2020.1. See [https://forum.flightgear.org/viewtopic.php?f=5&t=35581 forum thread]. See [[OSM2City_1st_Worldbuild |1st world-build of OSM2City]] for info and tips on performance.
|-
| [https://drive.google.com/file/d/1z8706fqh2G5sCSRwkEAHZAo2UbnduyRd Iceland] || The island of Iceland || || 2017.2 and 2020.1 || 2020-05-11 || vanosten ||
||
To see buildings :
Flightgear 2020.1 and later: Rename <code>Buildings_list</code> folder to <code>Buildings</code> for faster buildings
Flightgear 2017.2 and later: Rename <code>Buildings_mesh</code> folder to <code>Buildings</code>
|-
| [https://drive.google.com/open?id=1kRormoV7na2WzPRrpMjQsBB8XhCpP_Cw Falkland] || All islands || || 2017.2 and 2020.1 || 2019-12-26 || vanosten || ||
|-
| [https://drive.google.com/open?id=196_ZMkIejQPGSyyKVArJc8mJseqAVekZ Kansas] || 37-39N, 96-98W || || 2017.2 and 2020.1 || 2019-12-24 || vanosten || || Using OWBB_GENERATE_BUILDINGS=True, i.e. placing buildings in plausible places even though no OSM information available.
|-
| [https://github.com/legoboyvdlp/London-OSM-fg-CustomScenery London]
| London area || || 2017.2 || 2019-10-04|| legoboyvdlp || ||
|-
| [https://sites.google.com/site/ecuadorflightgear/ Ecuador]
| Entire country|| || 2017.2 || 2019-07-28 || || || https://forum.flightgear.org/viewtopic.php?f=5&t=32254
|-
| [https://forum.flightgear.org/viewtopic.php?f=5&t=34582 Sweden]
| Entire country|| || 2017.2? || 2019-07-28 || || || https://forum.flightgear.org/viewtopic.php?f=5&t=34582
|-
|-
| [https://my.pcloud.com/publink/show?code=XZwMCT7ZAImYyISByDJsWLHR4BWgjBFwJum7 Hawaii]
| Hawaii main islands [-160.25_18.875_-154.75_22.25] || || 2017.2 || 2018-11-18 || vanosten || March 2017 ||
|-
| [https://my.pcloud.com/publink/show?code=XZup1T7Z3YpnkdPdHtHq9GFcrFDx0JRP6nqX Holland]
| Most of North and South Holland plus Flevoland in the Netherlands [4_52_6_53] || || 2017.2 || 2018-11-16 || vanosten || March 2017 ||
|-
| [https://1drv.ms/u/s!AuIh-169bDZ9tlKlP3GQ1Ez1r64p w060n10]
| Barbados [bottom=10 left=-60 top=20 right=-50] || || 2017.2 || 2017-11-04 || dutchguy || ||
|-
| [https://1drv.ms/u/s!AuIh-169bDZ9tlPnC1UGd7CjdgMf w070n10]
| Eastern Caribbean [bottom=10 left=-70 top=20 right=-60] || || 2017.2 || 2017-11-04 || dutchguy || ||
|-
| [https://my.pcloud.com/publink/show?code=XZa8Nk7Z5jaeflLeCvS9VpyVWS3k28jKEASV LKPR]
| Area around LKPR Prague airport [14-14.75 East, 49.875-50.25 North] || || 2017.2 || 2017-10-08 || vanosten || March 2017 ||
|-
| [https://my.pcloud.com/publink/show?code=XZrMy3Ze3rXYVgAurYFp96YIHMj9X9ptLoy Switzerland]
| Swiss national boundaries || || 2017.2 || 2017-05-23 || vanosten || March 2017 ||
|-
| [https://my.pcloud.com/publink/show?code=XZqjqaZtxBUwA5KJr5CeuqTYzk9Yk9KXbDk KBOS]
| bottom=59 left=4.5 top=62 right=6 || || 2017.2 || 2017-05-20 || vanosten || March 2017 ||
|-
| [https://my.pcloud.com/publink/show?code=XZaSqaZsbS9ltAfHozgY335PnEIE4sPwutV ENBR]
| bottom=42.125 left=-72 top=42.625 right=-70.5 || || 2017.2 || 2017-05-20 || vanosten || March 2017 ||
|-
| [https://drive.google.com/file/d/1aR1jF0AbeLkKk21SZc-Tg-0f3-GSg5nc/view?usp=sharing Europe/Spain]
| || || 2017.2 || || || || https://forum.flightgear.org/viewtopic.php?f=5&t=32062&start=15
|}

== Old and most probably obsolete sceneries ==
These sceneries are not supported, the links might be broken and they might not work. The Table is kept just for reference.

{| class="wikitable"
! Download link !! Area !! In [[TerraSync]] !! Forum thread !! Min. FG version !! Created Date !! Created By !! [[Project3000]]<ref>Meaning that the scenery was generated respecting objects placed by Project3000, but does not contain it</ref> !! Remarks
|-
| [https://onedrive.live.com/redir?resid=7d366cbd5efb21e2!1642&authkey=!APsD2Zn-Jq3m5OA&ithint=folder%2czip The Netherlands]
| [[File:EHoutline.png|thumb|150px]] || || || || || || ||
|-
| [https://onedrive.live.com/redir?resid=7d366cbd5efb21e2!1645&authkey=!AAx41T78jYrL4KI&ithint=file%2czip Southern UK]
| [[File:EGOutline.png|thumb|150px]] || || || || || || ||
|-
| [https://onedrive.live.com/redir?resid=7d366cbd5efb21e2!1646&authkey=!AFAFUx-rFpUiRPk&ithint=file%2czip Ireland]
| [[File:EIOutline.png|thumb|150px]] || || || || || || ||
|-
| [https://onedrive.live.com/redir?resid=7D366CBD5EFB21E2!1651&authkey=!APsD2Zn-Jq3m5OA&ithint=file%2czip Switzerland]
| [[File:LSOutline.png|thumb|150px]] || || || || || || ||
|-
| [https://drive.google.com/open?id=0B2CN49kDuXHgZ3U0LUFnU2ZJREE Phuket]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=30113 || || || || ||
|-
| [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_OSM_buildings_20140928.tgz LOWI]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=19625 || || || || ||
|-
| [https://drive.google.com/open?id=0B5TeZxXfefn3NUp4NkM2b1hPVDQ African/Canary islands]
| || || || || || || ||
|-
| [https://drive.google.com/open?id=0B5TeZxXfefn3Vll5cGVEcndZMTg Europe/Portugal]
| || || || || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Poland]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Slovakia]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Lithuania]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Latvia]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Estonia]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Bulgaria]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Hungary]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Romania]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [https://drive.google.com/open?id=0B5TeZxXfefn3VkViMDlCMXlrQUU Us/California]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32187 || 2017.1 || || || ||
|}

[[Category:Scenery]]
[[Category:Lists]]

Hackathon Proposal: WS3.0 Effects

2024-04-17T22:37:03Z

Nia:

{{Hackathon Proposal
|title=WS 3.0 Effects
|image = Edinburgh rendering using WS3.0.jpg
|sponsor=Stuart
|supporters=Nia
|background=
Currently we have some of the pieces required for WS3.0:
* We can generate the underlying LOD mesh with a texture draped over it.
* We can dynamically generate airports
* We can load the scenery in FG.
... but the WS3.0 scenery in FG is basically a dark gray blob. The bit that's missing is having the scenery pick up material definitions and therefore Effects and shaders.

This hackathon idea is to apply material definitions to that scenery and perhaps develop a shader that will use the landclass texture to generate some plausible texturing.
|skills=C++
|opportunities=

* Materials
* Effects
* OSG and Virtual Planet Builder
}}

Useful resources:
* [[Virtual Planet Builder]]
* [[World Scenery 3.0 roadmap]]
* How the VPB is rendered in FlightGear: https://sourceforge.net/p/flightgear/simgear/ci/cbd8e3acc4eab6724b5be32f64eeeb0530e207ed/
* How trees are created at the moment:
** simgear/scene/tgdb/obj.cxx
** simgear/scene/tgdb/SGTileGeometryBin.cxx
** simgear/scene/tgdb/SGTileDetailsCallback.cxx
** simgear/scene/tgdb/VPBTechnique.cxx
* Runtime Airport building
** flightgear/src/Airports/AirportBuilder.cxx
** add a line to the STG file - [ICAO].icao

==Adding Trees==

Details of sub-project to add trees to WS3.0.

===Background===
* FG has the concept of a Material - how a particular type of land (a landclass) is rendered by the simulator (e.g. texture, Effect, tree density, roughness).
** The materials are defined in a set of XML files in fgdata/Materials. Different regions (defined by lon/lat) can define different materials. So a forest in Norway contains different trees than one in Brazil.
** See fgdata/Docs/README.materials for the XML format information
** See [[Howto:Editing tile textures and materials]]
** See Materials/default/global-summer.xml for a good rundown of the different landclasses.
* The materials are built into a SGMaterialLibrary (simgear/simgear/scene/material/matlib.cxx).
* In the old scenery, the terrain consists of a triangular mesh that describes both the shape (elevation) of the terrain and the landclass of the terrain. Each triangle of the terrain mesh as a single landclass (e.g. "EvergreenBroadCover").
* In the WS3.0 scenery, the terrain mesh only contains shape (elevation) information, and is created at runtime from a heightmap. The landclass of the terrain is provided by the texture. Each triangle can contain bits of multiple landclasses.

=== How Trees are grown - old scenery ===

Trees are generated in the Old scenery as follows:
# simgear/simgear/scene/tgdb/obj.cxx SGLoadBTG(const std::string& path, const simgear::SGReaderWriterOptions* options) loads a "BTG" file.
## line 113 created a SGTileDetailsCallback. This is a callback that will generate more detail for the tile when the viewpoint gets within range. This avoid having to create trees for tiles that might be 100km away and which we never get any closer to.
## line 118 creates a PagedLOD which will call the FGTileDetailsCallback when the viewer gets within range.
# simgear/simgear/scene/tgdb/SGTileDetailsCallback.hxx readNode(const std::string&, const osgDB::Options*) does the actual work to generate the details for a tile such as forests, random objects, lights, and it called by the PagedLOD object above.
## line 138 calls generateRandomTileObjects to create the forest, buildings and buildings
## generateRandomTileObjects (line 976) builds a set of OSG nodes and makes various calls to generate the random features.
### line 1086 calls computeRandomForest to create a list of the random trees based on the terrain triangles and their landclasses. computeRa
### computeRandomForest considers each terrain triangle in turn and...
#### looks up the landclass in the materials library to determine if this landclass (and therefore triangle) contains any trees
#### assuming it does, gets a TreeBin to put these trees (based on having the same settings as an existing tree definitions), then
#### generates a series of random points across the triangle, each of which will be rendered into a tree.
### line 1089 converts that intermediate datastructure into the OSG code to actually render the trees.

=== How to grow trees in WS3.0 ===

As noted above, one of the key differences between the old scenery and WS3.0 is that a given triangle in the terrain mesh doesn't have a single landclass. Instead we need to look it up.

* simgear/simgear/scene/tgdb/VPBTechnique.cxx is used to create the mesh from the heightmap.
* The key function is VPBTechnique::init. At present this creates a BufferData containing an EffectGeode.
* We (probably?) want to change that so it creates an osg::Group node, which contains both the EffectGeode, plus some other nodes containing the trees and other random objects.
** Because this is already loaded in a PagedLOD, provided we generate this at the right LOD Level (_terrainTile->getTileID().level==6 perhaps? or configurable), we don't need to mess around with any callbacks.
* The landclass information is stored in the first texture, assigned by applyColorLayers().
* It should be possible to interpolate between the texture coordinates of the generated mesh and lookup the landclass of the texture. (osg::Texture2D.getImage()->getColor(const Vec2 &texcoord).
* We could extend the MaterialLibrary to include lookup via landclass code. The simplest way would be to add new <name> values that match the values from the landclass texture as integers. For the hackathon, I suggest just adding landclasses 22-24 to the "EvergreenForest" material.

So the pseudo-code might look like this:
# IF (_terrainTile->getTileID().level==6) THEN
# FOREACH triangle (geometry) :
## Generate a set of random points on the triangle
## FOREACH point (random points) :
### Determine the texture coordinate of the point
### Determine the landclass of the point in the texture
### Lookup the landclass in the MaterialsLibrary
### IF the landclass has mat->get_wood_coverage() > 0 THEN add the point to an appropriate TreeBin in an SGTreeBinList
# use the SGTileDetailsCallback::createForest() method to create the appropriate forest in OSG

Howto:Prototyping an OANS using MapStructure

2024-04-17T22:36:50Z

Nia:

{{Stub}}
[[File:OANS-prototype.png|thumb|Screen shot showing an OANS prototype based on the Canvas/MapStructure system]]
== Objective ==

== Status ==
[[File:AptDat850-canvas.png|thumb|Due to lack of apt.dat v850 support, most airports show only up as runways.<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39454&p=389593#p389541</ref>]]
'''Last updated: 08/2021'''

The latest apt.dat format is 1100. genapts already supports up to a fairly recent version. Functionally identical to 850, it has several new lighting and linear features (available since 2019.2 in terragear already, thanks to D-ECHO) and improvements to ATC / ground services.<ref>https://sourceforge.net/p/flightgear/mailman/message/37027889/</ref>

The newest specification is available at:
http://developer.x-plane.com/wp-content/uploads/2019/04/XP-APT-1100-Spec_revised_04-11-2019.pdf

X-Plane also now makes extensive use of so-called "polygons". This causes problems when authors use them for aprons or taxiways despite
X-Plane's efforts to discourage this. Stuggart in TerraSync is a good example and a fairly substantial number of airports, and a majority of major ones would be unusable using pure apt.dat at present.

This would either require manual conversion of polygons to taxiways (one click per airport using World Editor, not multiple airports at once however), or else parsing of the .dsf format.

The .dsf format is a binary format, with each .dsf corresponding to a
scenery tile (should be 1 lat / lon divisions).
The file may be extracted to a text file using the XPTools commandline
toolset provided by Laminar. This is feasible for large .dsf files (one per
scenery tile - still 64,800 files, however).

Specification:
https://developer.x-plane.com/article/dsf-file-format-specification/#DSF_Specification

Our navdb only parses the (old) 810 surface format. The rectangular blocks of taxiway in your screenshot indicate that that specific airport is in 810 format. Airports with polygon surfaces (850 format) therefore only show the runways, since the polygon surfaces are simply not available to the canvas layer. I believe the airport preview in the Qt launcher has the same limitation, as it uses the same navdb.<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39454&p=389593#p389545</ref>

== Background ==
MapStructure is all about identifying static elements and dynamic ones - to selectively update things that change, unlike things that don't change.

So the next step is to logically divide a "map" into a set of "layers", that contain layer-specific elements/information (think taxiways, runways, buildings, compass rose, text labels) - as a rule of thumb, anything that can be toggled on/off separately, could go into its own layer (for the sake of simplicity). Also, anything that responds to scale (LOD) needs be handled correctly - e.g., switching the range of map display, does not invalidate the previous data (model).

Basically, the taxiway layout of the airport no longer changes once it's initialized - so you primarily need one layer for the taxiways, and use other layers for more dynamic stuff.

We developed MapStructure so that people can easily reuse existing layers. The idea was to allow people to find related layers and only adapt what's needed. In this case, I would use the taxiway layer or ThomasS' ground services layers to get started quickly - and then copy/adapt those layers as needed, styling I would add once all other functionality is working.

== Example ==
<syntaxhighlight lang="nasal">
var (width,height) = (640,480);
var title = 'Canvas OANS experiments (by Nia)';

var window = canvas.Window.new([width,height],"dialog").set('title',title);

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas().set("background", canvas.style.getColor("bg_color"));

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

var TestMap = root.createChild("map");

var AirportChart = TestMap; # copy/paste adaptation

# Initialize the controller:
AirportChart.setController("Static position", "main");
var controller = AirportChart.getController();

var info = airportinfo("KNUQ");
AirportChart.getController().setPosition(info.lat, info.lon);

AirportChart.setRange(3.0);
AirportChart.setScreenRange(800);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);

##
# Styling:
var Styles = {};
Styles.get = func(type) return Styles[type];
var Options = {};
Options.get = func(type) return Options[type];

Styles.APT = {};
Styles.APT.scale_factor = 0.4; # 40% (applied to whole group)
Styles.APT.line_width = 3.0;
Styles.APT.color_default = [0,0.6,0.85]; #rgb
Styles.APT.label_font_color = Styles.APT.color_default;
Styles.APT.label_font_size=28;

Styles.PARKING = {};
Styles.PARKING.scale_factor = 0.4; # 40% (applied to whole group)
Styles.PARKING.line_width = 3.0;
Styles.PARKING.color_default = [0,0.85,0.6]; #rgb
Styles.PARKING.label_font_color = Styles.APT.color_default;
Styles.PARKING.label_font_size=28;

Styles.APS = {};
Styles.APS.scale_factor = 0.25;
Styles.APS.color_default = [1,0,0];

# this sets up a namespace for each layer with associated meta information
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('TAXI',1,0),r('RWY',1,1),r('TWR',1,2),r('PARKING',0,3),r('APS',1,4)] )
TestMap.addLayer( factory: canvas.SymbolLayer,
type_arg: type.name,
visible: type.vis,
priority: type.zindex,
style: Styles.get(type.name),
options: Options.get(type.name) );

</syntaxhighlight>

== References ==
{{Appendix}}

Virtual FSweekend Hackathon 2020

2024-04-17T22:36:33Z

Nia:

This is the landing page for the '''Virtual FSweekend Hackathon 2020'''.

Normally in mid-November a group of FlightGear enthusiasts participate in FSweekend at Lelystad Airport in the Netherlands. Over the years this has been a focal point for both finishing existing development/releases and a catalyst for new ideas in FlightGear, as well as an opportunity for FlightGear enthusiasts to share a beer. FSweekend 2020 was cancelled, so to keep the spirit alive, we are planning to hold a Virtual FSweekend Hackathon on the weekend of 14/15 November.

== Hackathon? ==
{{Hackathon Intro}}

== Sign up ==
{{Note|If you've not received Stuart's mail but are interested in taking part please drop him an email. While we now have 20 participants registered, there still is space for plenty more, so don't be shy. Stuart is happy for people to register right up to the Friday night, but we will not be able to help out with getting builds and git working if you leave it that late!<ref>https://sourceforge.net/p/flightgear/mailman/message/37129832/</ref>}}

To register your participation, please contact Stuart either on the {{forum link|t=38071|text=forum post}}, or via the [https://sourceforge.net/p/flightgear/mailman/message/37125347/ -devel list].

Confirmed participants (in no particular order):
* Stuart Buchanan
* James Turner
* Nia
* wlbragg
* Rick Gruber-Riemer (vanosten)
* Marc Eberhard
* Julian Smith
* Fernando García Liñán
* Henning Stahlke
* Pat Callahan
* Isaak Dieleman
* Michael Filhol
* Nik Brucker
* Patrick Trottier
* Mark Joseph
* CaptB
* Brendan Black
* Guenter Alzinger
* Chris Frey
* Bertrand Coconnier

== Ahead of the Hackathon ==

{{Hackathon Preparations}}

== Schedule ==
With (hopefully) a world-wide group of participants, and varying real life constraints, at any given time over the weekend there will hopefully be a couple of people active.

We will have two big get-togethers:

=== Friday 13th November 2000-2200 UTC. Kick-off ===
* General welcome
* Introductions
* Hack pitches
* Team formation

This is the point at which participants will decide which Hacks they want to work on. The sponsors of each of the Hacks proposed head of time will be invited to give a 5 minutes pitch to the group, with some questions from the audience. Slides/screenshots optional.

After all the Hacks have been pitched, we will have a little break for people to chat and work out which Hack they want to work on.

If a Hack ends up with fewer than 2 people wanting to work on it (including the sponsor), then it will normally be dropped. This is to encourage people to work in groups - larger teams can get more done in the time, and have more opportunities to learn from each other, plus it is more sociable!

=== Sunday 15th November 2000-2200 UTC. Wrap up and demos ===
At the end of the hackathon we will have a get together and have each team present the results of their hack.

Depending on the number of hacks, each team will have 5-15 minutes to demonstrate their hack, describe what they have learned, and what their next steps are.

We will finish with voting for the best hack of the weekend.

== FAQ ==
{{Hackathon FAQ}}

== References ==
{{Appendix}}

[[Category:Hackathon Materials]]
[[Category:Hackathons]]

Airbus A320 family

2024-04-17T22:36:00Z

Nia:

{{:{{PAGENAME}}/info}}
The '''Airbus A320 family''' is a series of twinjet narrowbody commercial passenger jets manufactured by [[Airbus|Airbus Industrie]]. Designed for short to medium haul flights, the aircraft pioneered fly-by-wire technology and regularly competes with the [[Boeing 737|Boeing 737 series]]. This is an accurate and complex recreation of the A320 family.

== Overview ==
Includes:
* A320-214 (CFM56)
* A320-232 (IAE V2500)
* A320-251N (CFM Leap)
* A320-271N (PW1100G)

See the right InfoBox for the repository or download. Remember to rename the aircraft's folder to "A320-family" if needed.

== The Team ==
* Flight Dynamics: Josh Davidson (Octal450)
* Systems, Displays: Josh Davidson (Octal450), legoboyvdlp, Nia, Matthew Maring (hayden2000)
* 3D/Textures: Thorsten Herrmann (TH-555), Semir Gebran (CaptB)

== Using the selector knobs on the FCU ==
The flight control unit (FCU) is the panel on the glareshield that contains controls for the auto flight system, electronic flight information system (EFIS) screens and other systems. It contains various selector knobs that rotate. Some knobs can also be pushed or pulled in order to change modes or other settings.

{| class="wikitable"
|+Turning, pushing or pulling FCU knobs with a mouse
|-moved
|
! style="font-weight:bold;" | Left click
! style="font-weight:bold;" | Middle click <nowiki>*</nowiki>
! style="font-weight:bold;" | Right click
! style="font-weight:bold;" | Scroll Up
! style="font-weight:bold;" | Scroll Down
|-
! style="font-weight:bold" | Normal (no modifier keys)
| style="text-align:center;" | Push
| rowspan="2" style="text-align:center;" | Pull
| rowspan="2" style="text-align:center;" | ---
| style="text-align:center;" | Turn clockwise
| style="text-align:center;" | Turn counterclocwise
|-
! style="font-weight:bold;" | While holding {{key press|Shift}} key 
| style="text-align:center;" | Pull
| style="text-align:center;" | Turn clockwise (10× faster)
| style="text-align:center;" | Turn counterclockwise (10× faster) 
|}

''<nowiki>*</nowiki> On many setups, the scroll wheel of a mouse can be used as a middle button by pressing directly down on the wheel.''

Note: This section describes how to physically manipulate controls within the cockpit. Details about what the controls do, when they should be used, etc., are beyond the scope of this section.

== Gallery Flightgear 2019+ ==
<gallery mode="packed">
File:SOTM_2020-03_Winter_Evening_Departure_by_legoboyvdlp_(A320).jpg|Rain effect (March 2020)
File:A320-family-cockpit.png
</gallery>

== Related content ==
=== Forum topics ===
* {{forum link|t=38387|title=Is the TCA Airbus edition Compatible with Flightgear ?}} (February 2021 -) - Hints and tips on using the Thrustmaster TCA Airbus edition sidestick and throttle quadrant with FlightGear.

== External links ==
* [https://forum.flightgear.org/viewtopic.php?f=4&t=36410 Development thread]
* [https://www.airbus.com/aircraft/passenger-aircraft/a320-family.html Airbus A320 Family official homepage]

{{Airbus}}

[[fr:Airbus A320 Family]]
[[Category:Red Griffin ATC compatible aircraft]]
[[Category:Octal450 hangar]]

WS3.0 Subprojects

2024-04-17T22:35:46Z

Nia:

{{WS30 Navbar}}

This page is intended to collect various WS3.0 sub-projects: Smaller self-contained projects that can be worked on independently to improve WS3.0

The aim is to encourage more people to contribute to the WS3.0 effort.

They are split by knowledge required.

== C++ ==

=== Smoother Line Features ===
Line features (roads, railways, rivers) are generated from OSM data at runtime, with different widths of roads generated for different LOD levels.

Currently the algorithm that generates the roads creates places a quad for each segment such that the width of the road is horizontal, a metre or so higher than the terrain.

There are a couple of improvements that could be made:

* Sharp corners look a bit rubbish because the end of a segment is always a normal to the segment length. This means that on sharp bends the road narrows and looks a bit rubbish. An improvement would be to calculate the width and angle based on both the last segment and the next one.
* At present no bridges are handled. using osm2city code bridges should be implemented.
* The roads currently following the elevation meshes exactly. Real roads have embankments and cuttings to smooth out elevation changes. Cuttings are probably too difficult because they would require modifying the elevation mesh, but embankments would be possible.
* We currently remove some points at the end of the tile where the intersection algorithm can produce many points close together. This currently creates some odd roads at the edges of tiles which could be improved.
[[File:Fgfs-20230306215131.jpg|thumb|Mountain pass new Srinagar, Jammu and Kashmir.]]

=== Water Bodies ===
We currently have a good solution for coastlines to remove the blockiness of the raster coastlines by using OSM line data and a separate high resolution raster.

We have a script to collect similar data for water bodies (lakes etc.), A scanline algorithm could be used with this data to fill a polygon in the same raster, creating more detailed water bodies.

=== Groundcache Lookup ===
In WS2.0 it is possible to get material information for a point in the scenery. This needs implementing for WS3.0, which will require a lookup into the landclass texture. Ideally this information would also be exposed in fgelev (or as a proxy as for WS20 whether it is a solid material or water).

'''Update 11/11/2023: This is now implemented and available in next.'''

=== Neighbouring Pixel ===
The higher level fragment shaders can blend the edges of textures. Currently this is done on the shader side. This could instead be done at scenery loading when the texture is generated in VPBTechnique.cxx by using some of the unused channels in the texture. There will be significant performance gains to be had by doing so.

'''Update 21/03/2023: Stuart prototyped this on his system and found no performance benefit at all.'''

=== Terrasync for WS3.0 ===
Currently we do not have the ability to distribute WS3.0 with Terrasync. We need both a distribution mechanism and probably some minor changes to Terrasync/FG to support this.

The base unit for distrbution will be a 1x1 degree tile, tarballed and compressed - e.g. .tgz. This is already used for other data.

Speak to Nia about this, as she has offered to assist with hosting.

'''Update 11/11/2023: Testing with Nia and some small changes to defaults.xml proved that this Just Works. However the data size remains an issue.'''

== GIS ==

=== More Accurate Coastlines ===
We currently have a good solution for coastlines to remove the blockiness of the raster coastlines by using OSM line data and a separate high resolution raster.

However if the main landclass raster isn't well aligned with this data it can cause graphics artifacts.

I (Stuart) solve this for the Martinique scenery on the final raster by:

- Deleting all the water so that it was NODATA

- Filling the NODATA with surround values

- Using the OSM coastline as a mask on the raster to delete the data that should be water

- filling the NODATA with water.

This works OK, but getting the OSM data as a multipolygon was a manual process. Having a script to do this would be good. Being able to do this all in vector data ahead of rasterization would be even better

'''Update 11/11/2023: This is now implemented as part of the fgmeta/ws30/genVPB.py script, which accepts a coastline polygon.'''

=== Scripted Toolchain ===
Developing standard scripted toolchain to convert from NLCD and/or CORINE to high quality 10m or 5m raster with the correct landclasses.

'''Update 11/11/2023: This is now implemented as fgmeta/ws30/genVPB.py but requires a raster file'''

== Python ==
fgmeta/ws30 contains a number of python scripts for generating scenery that could be improved

=== Script Efficiency - line features ===
At present the script to generate line features (genroads.py) simply dumps all the OSM data directly to text file and we generate line features using every point. This has a theoretical resolution of 1cm, which is probably higher than we need.

We could save storage and processing by :

* Rounding the lat/lon pairs to ~10cm resolution. This would save about ~10% disk space for the roads uncompressed.
* Skipping nodes in segments that are too close together.

== Textures ==

=== WS3.0 Materials ===
Currently WS3.0 uses the WS2.0 textures. Many of these have line features like roads baked into them. As WS3.0 include OSM roads down to ~ 2m width, the roads on the textures are now redundant. A new set of textures without roads would look a lot better (that is for textures in urban areas and certain agriculture textures).

This should be done at the point that we decide to move to WS3.0, or when we decide the osm2city roads are the WS2.0 solution for small roads.

== GUI ==

=== Quality Settings ===
[[file:Canvas_TabWidget_example.png|thumb]]
Currently WS3.0 has a lot of configuration properties. These should be consolidated into a dialog that's easier to use.
Stuart agreed that the Canvas UI could be a good option to use for this new UI dialog. <ref>https://sourceforge.net/p/flightgear/mailman/message/37785426/</ref>
We also have people volunteering to help with a Canvas based UI dialog. <ref>https://sourceforge.net/p/flightgear/mailman/message/37785343/</ref>

This new UI dialog could probably be based on the new [[Canvas_news#Tab_Widget|Canvas tab widget]] to neatly organize related settings into pages.

We could even use the [[CompositeViewer support]] and [[Compositor]] integration to provide actual previews for different settings in-sim, as suggested and discussed previously on the devel-list.

[[File:Cvcanvas-777.jpeg|thumb]]

There already is an [[Hackathon_Proposal:_CompositeViewer_and_Canvas|experimental canvas element]] that uses a compositor instance to render a view to a Canvas, work that Jules and Fernando came up with originally. Fernando in particular mentioned that these Compositor instances could use their own effects/shaders, which would make them ideally-suited for previewing different sorts of rendering settings in-sim.

{{Appendix}}

World Scenery 3.0

2024-04-17T22:34:31Z

Nia:

{{WS30 Navbar}}
World Scenery 3.0 is a project to replace the tiled single-mesh World Scenery 2.0 with an LoD-based approach using a regular elevation mesh, landclass texture and vector line features.

This leverages OSG's Virtual Planet Builder and OpenStreetmap APIs.


== Currently Available Scenery ==

=== Terrain ===
Scenery is currently not distributed using the official Terrasync, Nia provides a terrasync compatible download, point your terrasync client to https://de1mirror.flightgear.org/ws3/ to make use of it. As of writing (2024-01-15) it contains all of the sceneries below (duplicates removed) and will get updated when a new Airports package is made and when Wayne provides her with new US scenery. If you don't wanna deal with changing your terrasync settings, you can always download sections of scenery via the links individually and added to your [[FG SCENERY|scenery path]]. If you set these in your scenery path ahead of any other scenery, it will pick up osm2city, scenery objects etc. from the underlying scenery as well.
{| class="wikitable"
|+
Currently Available World Scenery 3.0
!Scenery
!Area
!Size
!Bottom Left
!Top Right
!Area (degrees^2)
!Landclass Source
!Landclass Resolution (m)
!Comments
!Osm2city Scenery
|-
|[https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=share_link WS30_UK]
|Most of the UK
|1GB
| -11,49
|1,61
|121
|CORINE
|30
|DDS
|
|-
|[https://drive.google.com/file/d/120QOxfTWEm6EBmjK0eCNb07hrm3clavi/view?usp=sharing NL]
|Amsterdam and Lelystad
|716MB (ca. 8GB uncompressed)
|2,50
|10,53
|24
|CORINE
|10
|PNG; Includes high resolution water raster from OpenStreetMap. Check out the canals!
|
|-
|[https://drive.google.com/file/d/1MrYuDKbMl4WhCEq9gnnt8Tz61lTAScvD/view?usp=share_link WS_Alps]
|
|49MB
|6,45
|8,47
|4
|CORINE
|25
|DDS
|
|-
|[https://drive.google.com/file/d/1V4AgqRcVo_7oFly8xCOZMPK7Gvb_X1HB/view?usp=share_link WS30_CA]
|Northern California
|350MB
| -124,34
| -119,39
|25
|NLCD
|30
|DDS
|
|-
|[https://drive.google.com/file/d/1j91qImcU28jrt290O5sUHbRZe7-fQJf-/view?usp=share_link WS30_CA2]
|Northern California, PNG
|454MB
| -124,34
| -119,40
|30
|NLCD
|30
|PNG; for most pilots this is the only scenery that works without troubles.
|[https://drive.google.com/file/d/1jrs7x4LOsdhn7IrISQIrHayu0yMQHaE1/view?usp=share_link osm2city buildings, trees, maritime, pylons etc.] (ca. 230 MB) - San Francisco Bay and San Pablo Bay
|-
|[https://drive.google.com/file/d/1x-kuCTfyMWddTi0fbr_nl41LR41Ylvwb/view?usp=share_link WS30_MTQ]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|10
|PNG; Small French Caribbean island. One airport (TFFF)
|[https://drive.google.com/file/d/1QtojSTbnAAfkMzirQHnDJWbBDGOtnwIK/view?usp=sharing osm2city buildings, trees, maritime, pylons etc.] (ca. 40 MB).
|-
|[https://drive.google.com/file/d/14kbbgXbofDmqxho-bMCfOG4jDwcDqwBd/view?usp=share_link WS30_MTQ_25m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|25
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1-LS3yQZ0OkWX38Ne89n69wtrT7SreV69/view?usp=sharing WS_MTQ_5m]
|Martinique
|8MB
| -62,14
| -60,15
|2
|CORINE
|5
|PNG; Includes high resolution water raster from OpenStreetMap. Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1Um7WC8h8Y4BlwgoVSd2xoVO5gTd3E-bI/view?usp=sharing Switzerland_5m]
|Switzerland plus small border
|1.4 GB (ca. 7 GB unzipped)
| 5.75,45.75
| 10.75,48
|10
|CORINE
|5
|PNG; By mistake taken default airports. If you are using Nia's updated airports, then it will most often work fine, but there might be residuals (e.g. tree on APRON).
|included
|-
|[https://de1mirror.flightgear.org/hosting/wayne/ WS3.0 USA]
|USA
|200 to 400 KB (zipped)
| 125,48
| 81,24
|
|NLCD, Tree Canopy Data
|30
|by state
|
|-
|[https://github.com/SP-NTX/PolandWS30/ Poland]
|Poland
|1.2GiB
|
|
|
|
|
|
|}

=== Airports ===
In addition to the selected areas above, global up-to-date WS3.0 airports have been built. You can find them [https://cdn.merspieler.tk/airports/ here]

=== Scenery Files Placement ===
Uncompress the downloaded scenery files into a folder of your choice, such as E:\MySceneryFolder. To be recognized by FlightGear, the selected scenery (from the table above) must be located in a folder with a "vpb" subfolder, such as (EX: C:\mysceneryfolder\hawaii\vpb). The scenery files above are compressed and include the "vpb" folder.

=== Installing ===
Using the FlightGear [[FlightGear_Qt_launcher]] both the terrain and the airport are "installed" by going to tab "Add-ons" and then add the respective folders to "Additional scenery folders". When adding an additional scenery folder, you need to point to the folder immediately above the "vpb" subfolder.

If you add the airports the first time you might have to close the launcher and reopen it again to get the navigation data loaded properly into the session.

== Running World Scenery 3.0 ==
To run WS3.0 you need to set the <code>/scenery/use-vpb</code> property to <code>true</code> at startup. Either set <code>--prop:/scenery/use-vpb=true</code> on your command-line, or in the Additional Settings part of the Settings pane of the launcher.

WS3.0 can use a lot of memory - significantly more than WS2.0. You can control the memory usage with the following properties:

* <code>/sim/rendering/max-paged-lod</code> controls the minimum number of objects that will be kept in memory. The default setting is 200.
* <code>/sim/rendering/plod-minimum-expiry-time-secs</code> controls how long objects remain loaded for after they are no-longer in view. The default value is 180 (3 minutes).

Reducing these properties will reduce the memory footprint of WS3.0.

If you have lots of spare cores, you can run multiple threads to load scenery by setting <code>/sim/rendering/database-pager/threads</code> to a number greater than 4 on startup. E.g. <code>--prop:/sim/rendering/database-pager/threads=8</code>.

=== WS 2.0 scenery might still be needed ===
To have airports displayed plus some of the default scenery objects, you might still want to have the WS 2.0 scenery for the same area installed.

However, if you want updated airports, checkout the global WS3.0 airports above. To avoid collisions you need to not have any WS2.0 airports enabled if you use these.

=== Using osm2city ===
WS3.0 has built-in support for OpenStreetMap roads, so you should not have it enabled in rendering settings.

You have 2 options:

* If you have WS2.0 world scenery, then it already contains osm2city buildings etc. You can just use these and live with slight elevation offsets.
* The other option is to use the provided osm2city scenery in the table above instead. If doing so you need to makes sure that WS2.0 osm2city has not been downloaded (or delete the folders manually). E.g. if you are using [[TerraMaster]] then you can remove the ticks in Settings for "Buildings", "Pylons" and "Roads".

Using the explicitly provided osm2city scenery gives you trees in gardens/parks and some improvements only available on NEXT.

Hackathon Proposal: Performance Improvement for Ortho Scenery

2024-04-17T22:33:07Z

Nia:

{{Hackathon Proposal 2021
| title = Performance Improvement for Ortho Scenery
| image = Oom bavaria ortho.jpg
| caption = Demonstrating out of memory issues with the open bavaria ortho scenery
| sponsor = Nia
| supporters = (Feel free to add yourself)
| status =
| summary = Improving the performance of ortho scenery by adding a LOD scheme and loading it in a background thread
| background = I've started the initiative of collecting openly licensed ortho sources to be used in flightgear.
For bavaria, there are high quality (80cm/px) images available under CC BY license from the Bayrische Vermessungsverwaltung. The generated (16k) scenery quickly showed its issues cause one would run out of RAM and VRAM, when running larger areas with such scenery. This can be solved by implementing a LOD scheme: only loading highres versions for near-by tiles and loading lower res versions for distant tiles. In addition, with altitude the need for highres images reduces. 4k scenery (roughly 4m/px, 1/16th the size of 16k scenery) starts looking fine at 10000-12000ft AGL on a FullHD monitor and is more than enough for airliner cruise altitude so 2k or maybe even 1k scenery would be enough for that. 4k Scenery is already enough to not cause any RAM or VRAM issues on a modern system by using about 13GB RAM and 5GB VRAM at cruise alt and a bare LOD of >200km.

The other issue that becomes aparent with large or many images is loading times. It can take several seconds to load a highres tile or in cruise a row of lowres tiles. Currently, flightgear freezes during loading. This could be solved by moving the loading into its own thread.
| details = Stuart has some ideas on how it might work with WS3.0: https://sourceforge.net/p/flightgear/mailman/message/37371092/
| skills = C++
| opportunities =
| notes = I will need help of someone familiar with the rendering and loading code.
}}

=== Progress during the Hackathon ===
We've got a working ortho scenery under WS3.0. The ortho scenery uses the same LOD scheme as WS3.0 does.

This already solved the loading performance issues seen with high resolution WS2.0 ortho scenery.

How to test (latest next version required):

* Download the [https://cdn.merspieler.tk/hosting/demo.zip scenery] (31GB Download) and unpack it.
* Add the scenery to your FG_SCENERY, or via the launcher
* Add the command line option `--prop:/scenery/use-vpb=true --prop:/sim/rendering/photoscenery/enabled=true`. This enables WS3.0 and photoscenery.
* Start at EDDM

Osm2city worldbuild

2024-04-17T22:32:35Z

Nia:

{{lowercase title}}
The '''osm2city worldbuild''' is an attempt by Nia started in May 2019 of providing global coverage with osm2city scenery. The 1st worldbuild has been completed.

== Machine ==
Since I was disappointed by the information I could get on the world scenery 2.0 build, espectailly on the machine it run on, I've decided to give some insight, on what is needed to run an osm2city worldbuild.

As of January 2020 the build is run on a server with two 8-core/16-thread CPUs and 96GB RAM. While at first the CPU seems to be the bottleneck, once you get into densly packed areas the RAM becomes the limiting factor. I've seen a single thread taking up more than 80GB of RAM and even caused out-of-memory problems on this server. As a general rule, watch how much RAM is currently used and adjust the number of running processes accordingly.

For storage I've started with five 4TB HDDs configured in a RAIDZ2 with an effective capacity of just below 12TB but changed to RAID10 (with one spare drive, about 8TB effective) to improve IO performance. Currently 8TB this is more than is needed.
As of writing the global osm data in the database has a size of 2.3TB but this requirement can be lowered (with a penalty in runtime) by only importing the required area from the highly compressed .osm.pbf file. With this approach, the initial try worked relativly well on a 1TB HDD with enough headroom. There are quite a number of random IOPS which causes some IO wait time, up to 80% of the CPU on my Server so an SSD would certainly benificial for some of the data or as L2ARC.

== Rollouts on LTS ==
''See [[OSM2City 1st Worldbuild|'''information and performance tips for the OSM2City 1st worldbuild''']] .''

The 1st rollout on the FlightGear [[Release Plan|Long Term Stable]] (LTS) stream was in [[Changelog 2020.3|FlightGear 2020.3.7]] point release. FlightGear 2020.3.7 LTS will automatically download from [[TerraSync]]. FlightGear 2020.3.6 and earlier will not automatically download OSM2City data. A small amount of existing experimental OSM2City data in an old format was removed from TerraSync.

[[Category:Osm2city]]
[[Category:Custom scenery]]

Hackathon Proposal: Shaderbased ND features

2024-04-17T22:32:21Z

Nia:

{{Hackathon Proposal
|title=Shaderbased ND features
|image = 787-8-terrain-map.jpeg
|imginfo = Early Terrain radar emulation (from the 787-8) see [[Canvas Tile Element]]
|sponsor=Nia
|supporters=none
|background=
To my knowledge, there are a couple of features which are currently not easily implementable on a navigation display or do not accurately represent the "outside" view (wxr)
These are:

* Terrain
* Airport moving map
* Weather radar

These could be implemented as effects and shaders on the Compositor to get an accurate view of the sourroundings.
|skills=
|opportunities=.
* Shader
* Effects
* Compositor
}}

For what its worth, user TDammers has successfully created all three of these using a non-shader based approach -- what is posing problems is that the terrain radar only shows as far as terrain is loaded; that might be a problem worth solving. What would be most useful would be a more efficient way to sample terrain, not least a way to sample terrain, beyond what is actually loaded. This avoids seeing tile boundaries in the terrain radar.

[[Category:Hackathon 2020 Ideas]]

Hackathon Proposal: Docker Container for osm2city

2024-04-17T22:32:06Z

Nia:

{| class="wikitable"
|-
| Title || '''<big>Docker container for osm2city</big>'''
|-
| Sponsor || [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9140 vanosten]
|-
| Supporters ||
|-
| Status || Proposed
|-
| Summary || Create a [https://opencontainers.org/ OCI container] ("Docker") for [[Osm2city.py | osm2city]], which is based on the originally Python based [https://gitlab.com/osm2city/osm2city osm2city] as well as the C++ based [https://gitlab.com/osm2city/osm2gear osm2gear] such that interested parties easier can contribute to generate scenery.
|-
| Background ||
|-
| Details || First step would be to update the CMake code to modern standards. Second to add more env variables. Third to dockify. Might be an idea to merge into Docker for WS3.0
|-
| Skills || C++, CMake, Python, Docker
|-
| Notes || Alternative to a container image, osm2city could be included into [[Scripted Compilation on Linux Debian/Ubuntu]] - which is good for installations on one machine, but less ideal to run multiple machines in a virtual setup.
[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21618 Nia] has already created such a container (about 2 years ago), but she didn't update it for the new C++ based branch and new features yet. Currently at https://git.merspieler.tk/fly/easy-osm2city-podman - should consider to add it to the osm2city repo in a folder.
|}
[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: Volumetric Clouds

2024-04-17T22:31:43Z

Nia:

{| class="wikitable"

|-

| Title || '''<big>Volumetric Clouds</big>'''

|-

| Sponsor || Nia

|-

| Supporters ||

|-

| Status ||

|-

| Summary || Create volumetric clouds

|-

| Background || Right now, the "3D" clouds are just billboards, which always face the camera (with the ufo look straight up and roll a little bit to observe clouds rotating). Since they're just 2 dimensional billboards you can never really be in a cloud. Right now we cheat here by reducing the visibility when being in a cloud which makes it strange looking when emerging from the cloud as you can see the visible area expand again. When flying toward the cloud it's a hard cut through it and it might clip into the cockpit.
The solution is having volumetric clouds. This could be realized using 3D textures (see [https://yt.artemislena.eu/watch?v=4QOcCGI6xOU this video] for how this could be approached)

|-

| Details ||

|-

| Skills || C++, GLSL

|-

| Notes || Stuart has thought about this a bit already and thinks this is doable and would be able to mentor.

|}

[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: Split FGElev into Libary and CLI

2024-04-17T22:31:32Z

Nia:

{| class="wikitable"
|-
| Title || '''<big>Split FGElev into Libary and CLI</big>'''
|-
| Sponsor || [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9140 vanosten]
|-
| Supporters ||
|-
| Status || Proposed
|-
| Summary || FGElev is a utility program used by [[Osm2city.py | osm2city]] and others to dynamically read elevation and material information at a specific lon/lat coordinate. The program uses a command line interface for dynamic query one coordinate at a time. The C++ based [https://gitlab.com/osm2city/osm2gear osm2gear] is also using FGElev - however it would be easier to call a C++ function in SimGear directly instead of interprocess communication. Therefore, it is proposed that the introspection logic is moved from [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/utils/fgelev/ fgelev in FlightGear] to a function in SimGear and only the CLI interface would stay in FlighGear.
|-
| Background ||
|-
| Details ||
|-
| Skills || C++, [http://www.openscenegraph.com/ OpenSceneGraph]
|-
| Notes || [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21618 Nia] is making a container image for FGElev. It could be interesting to combine the efforts.
|}
[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: Ground Services from apt.dat

2024-04-17T22:31:12Z

Nia:

{| class="wikitable"

|-

| Title || '''<big>Ground Services from apt.dat</big>'''

|-

| Sponsor || Nia

|-

| Supporters ||

|-

| Status ||

|-

| Summary || The newer apt.dat format defines routes for ground traffic. Idea is to read (if needed, pre-process the data) that and create ground traffic using this data.

|-

| Background || Airports are busy, not just the aircraft but also all the ground handling like baggage carts, fuel trucks, crew busses, etc. This is missing in FG, adding it would make the airport feel way more alive.

|-

| Details || First step would be to generate the net and make it available in a format in FG. Then make a subsystem in AI to use the net and visualize (animate).

|-

| Skills || C++

|-

| Notes || [https://developer.x-plane.com/article/airport-data-apt-dat-12-00-file-format-specification/ apt.dat 1200 spec]

|}

[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: WS3.0 Ortho Water Transition Shader

2024-04-17T22:30:55Z

Nia:

{| class="wikitable"

|-

| Title || '''<big>Ortho to Water transition shader for WS3.0</big>'''

|-

| Sponsor || Nia

|-

| Supporters ||

|-

| Status ||

|-

| Summary || Create a nice transition between water and ortho photos in WS3.0

|-

| Background || Right now, it's a rather hard cut between ortho scenery and water.
A transition shader would get rid of that hard cut and make underwater features in shallow water visible (such as reefs)

|-

| Details ||

|-

| Skills || C++?, GLSL

|-

| Notes || Stuart say this is doable and would offer mentorship.

|}

[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: Fractal Terrain shading

2024-04-17T22:30:41Z

Nia:

{{Hackathon Proposal
|title=Fractal Terrain Shading
|image =
|imginfo =
|sponsor=Nia
|supporters=none
|background=
Near the groud, many textures are rather blury or look very flat.
It would be nice to have some fractal shading to change that.

See Outerra for a good example of how it could look like.
|skills=
|opportunities=.
* Shader
* Effects
}}

[[Category:Hackathon 2020 Ideas]]

Virtual FSweekend Hackathon 2022

2024-04-17T22:30:32Z

Nia:

{{Note|This Hackathon did not take place, because the actual Flight Simulation Weekend was happening.}}

{{Hackathon

|year=2022
|organizer=Nia
|kick-off-totd-utc=Friday 5th November 2000-2200 UTC
|wrap-up-totd-utc=Sunday 7th November 2000-2200 UTC

}}

Virtual FSweekend Hackathon 2021

2024-04-17T22:30:17Z

Nia:

This is the landing page for the '''Virtual FSweekend Hackathon 2021'''.

Normally in mid-November a group of FlightGear enthusiasts participate in [[FSWeekend]] in [https://www.aviodrome.nl/ Aviodrome] at the [https://www.lelystadairport.nl/ Lelystad Airport] in the Netherlands. Over the years this has been a focal point for both finishing existing development/releases and a catalyst for new ideas in FlightGear, as well as an opportunity for FlightGear enthusiasts to share a beer. Like in 2020, FSweekend 2021 was unfortunately cancelled due to COVID-19 uncertainties (it will maybe take place in March 2022).

To keep the spirit alive and repeat the successful execution of the [[Virtual_FSweekend_Hackathon_2020|Virtual FSweekend Hackathon 2020]], we are planning to hold another Virtual FSweekend Hackathon on the weekend of 5/6/7 November 2021 (in {{days from now|2021|11|5}}).

== Hackathon? ==
{{Hackathon Intro}}

== Only Core Development? ==
While the core of the hackathon incl. support previously has been dedicated to development in the very core of FlightGear (mostly C++, [[Nasal_scripting_language|Nasal]] and xml), you are also welcome to participate if you are developing stuff, which contributes to the general FlightGear ecosystem (e.g. [[Addon]], visual artwork or [[Osm2city.py|osm2city]]). However, in that case you might need to provide your own support.

== Sign up ==
{{Note|There is space for many participants, so don't be shy. Rick is happy for people to register right up to the Friday night, but we will not be able to help out with getting builds and git working if you leave it that late!}}

To register your participation, please contact Rick either on the {{forum link|t=39793|text=forum post}}, by PM on the [https://discord.gg/rzuV2DR FlightGear Discord server] or via the [https://sourceforge.net/p/flightgear/mailman/message/37358418/ devel list].

Confirmed participants (in alphabetical particular order):
{| class="wikitable"
|-
! Name
! aka.
! Role
! Remarks
|-
|Fernando García Liñán
|{{Usr|Icecode}}
|Mentor (core dev)
|Can provide help regarding core development and graphics (OSG, [[Compositor]] and shaders)
|-
|Julian Smith
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=19719 cgdae]
|Mentor (core dev)
|Can help with thread-safe properties, recording/replay, [[CompositeViewer Support|CompositeViewer]], multiplayer
|-
|Lars Toenning
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=22241 Lars], LarsT on FG Discord
|Participant
|
|-
|Marc Eberhard
|
|Participant
|
|-
|
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=25958 MariuszXC], MariuszXC on FG Discord
|Participant
|
|-
|
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21618 Nia]
|Participant/Infrastructure
|Hit me up if you've got trouble with mattermost or jitsi.
|-
|Pat Callahan
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=14816 callahanp]
|Participant
|
|-
|Rick Gruber-Riemer
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9140 vanosten], HB-VANO on FG Discord
|Organiser/mentor
|Can coach osm2city and OSM data processing
|-
|Roman Ludwicki
|PlayeRom on FG Discord
|Participant
|-
|
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=26150 SDeAstis]
|Participant
|
|-
|Stuart Buchanan
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9 stuart]
|Mentor (core dev)
|As well as WS3.0, he can provide advices on a wide range of the codebase, as he has touched lots of different parts over the years
|}

== Ahead of the Hackathon ==

{{Hackathon Preparations|year=2021}}

== Schedule ==
With (hopefully) a world-wide group of participants, and varying real life constraints, at any given time over the weekend there will hopefully be a couple of people active.

We will have two big get-togethers:

=== Friday 5th November 2000-2200 UTC. Kick-off ===
* General welcome
* Introductions
* Hack pitches
* Team formation

This is the point at which participants will decide, which Hacks they want to work on. The sponsors of each of the Hacks proposed ahead of time will be invited to give a 5 minutes pitch to the group, with some questions from the audience. Slides/screenshots optional.

After all the Hacks have been pitched, we will have a little break for people to chat and work out which Hack they want to work on.

If a Hack ends up with fewer than 2 people wanting to work on it (including the sponsor), then it will normally be dropped. This is to encourage people to work in groups - larger teams can get more done in the time, and have more opportunities to learn from each other, plus it is more sociable!

=== Sunday 7th November 2000-2200 UTC. Wrap up and demos ===
At the end of the hackathon we will have a get together and have each team present the results of their hack.

Depending on the number of hacks, each team will have 5-15 minutes to demonstrate their hack, describe what they have learned, and what their next steps are.

We will finish with voting for the best hack of the weekend.

== FAQ ==
{{Hackathon FAQ}}

== References ==
{{Appendix}}

[[Category:Hackathon Materials]]
[[Category:Hackathons]]

World Scenery 3.0

2024-01-22T13:14:18Z

Nia: /* Terrain */

{{WS30 Navbar}}
World Scenery 3.0 is a project to replace the tiled single-mesh World Scenery 2.0 with an LoD-based approach using a regular elevation mesh, landclass texture and vector line features.

This leverages OSG's Virtual Planet Builder and OpenStreetmap APIs.


== Currently Available Scenery ==

=== Terrain ===
Scenery is currently not distributed using the official Terrasync, Nia provides a terrasync compatible download, point your terrasync client to https://cdn.merspieler.tk/ws3/ to make use of it. As of writing (2024-01-15) it contains all of the sceneries below (duplicates removed) and will get updated when a new Airports package is made and when Wayne provides her with new US scenery. If you don't wanna deal with changing your terrasync settings, you can always download sections of scenery via the links individually and added to your [[FG SCENERY|scenery path]]. If you set these in your scenery path ahead of any other scenery, it will pick up osm2city, scenery objects etc. from the underlying scenery as well.
{| class="wikitable"
|+
Currently Available World Scenery 3.0
!Scenery
!Area
!Size
!Bottom Left
!Top Right
!Area (degrees^2)
!Landclass Source
!Landclass Resolution (m)
!Comments
!Osm2city Scenery
|-
|[https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=share_link WS30_UK]
|Most of the UK
|1GB
| -11,49
|1,61
|121
|CORINE
|30
|DDS
|
|-
|[https://drive.google.com/file/d/19FodUumjOdfWFrzrDo5Yu2U5T8C5Ddzi/view?usp=share_link WS30_FSWeekend]
|Amsterdam and Lelystad
|120MB
|3,52
|8,55
|8
|CORINE
|10
|DDS Includes osm2city
|
|-
|[https://drive.google.com/file/d/1MrYuDKbMl4WhCEq9gnnt8Tz61lTAScvD/view?usp=share_link WS_Alps]
|
|49MB
|6,45
|8,47
|4
|CORINE
|25
|DDS
|
|-
|[https://drive.google.com/file/d/1V4AgqRcVo_7oFly8xCOZMPK7Gvb_X1HB/view?usp=share_link WS30_CA]
|Northern California
|350MB
| -124,34
| -119,39
|25
|NLCD
|30
|DDS
|
|-
|[https://drive.google.com/file/d/1j91qImcU28jrt290O5sUHbRZe7-fQJf-/view?usp=share_link WS30_CA2]
|Northern California, PNG
|454MB
| -124,34
| -119,40
|30
|NLCD
|30
|PNG; for most pilots this is the only scenery that works without troubles.
|[https://drive.google.com/file/d/1jrs7x4LOsdhn7IrISQIrHayu0yMQHaE1/view?usp=share_link osm2city buildings, trees, maritime, pylons etc.] (ca. 230 MB) - San Francisco Bay and San Pablo Bay
|-
|[https://drive.google.com/file/d/1x-kuCTfyMWddTi0fbr_nl41LR41Ylvwb/view?usp=share_link WS30_MTQ]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|10
|PNG; Small French Caribbean island. One airport (TFFF)
|[https://drive.google.com/file/d/1QtojSTbnAAfkMzirQHnDJWbBDGOtnwIK/view?usp=sharing osm2city buildings, trees, maritime, pylons etc.] (ca. 40 MB).
|-
|[https://drive.google.com/file/d/14kbbgXbofDmqxho-bMCfOG4jDwcDqwBd/view?usp=share_link WS30_MTQ_25m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|25
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1NwBjtISPAoTS0vqbV8idvu64CzKJNDQ-/view?usp=share_link WS_MTQ_5m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|5
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1Um7WC8h8Y4BlwgoVSd2xoVO5gTd3E-bI/view?usp=sharing Switzerland_5m]
|Switzerland plus small border
|1.4 GB (ca. 7 GB unzipped)
| 5.75,45.75
| 10.75,48
|10
|CORINE
|5
|PNG; By mistake taken default airports. If you are using merspieler's updated airports, then it will most often work fine, but there might be residuals (e.g. tree on APRON).
|included
|-
|[https://cdn.merspieler.tk/hosting/wayne/ WS3.0 USA]
|USA
|200 to 400 KB (zipped)
| 125,48
| 81,24
|
|NLCD, Tree Canopy Data
|30
|by state
|
|-
|[https://github.com/SP-NTX/PolandWS30/ Poland]
|Poland
|1.2GiB
|
|
|
|
|
|
|}

=== Airports ===
In addition to the selected areas above, global up-to-date WS3.0 airports have been built. You can find them [https://cdn.merspieler.tk/airports/ here]

=== Scenery Files Placement ===
Uncompress the downloaded scenery files into a folder of your choice, such as E:\MySceneryFolder. To be recognized by FlightGear, the selected scenery (from the table above) must be located in a folder with a "vpb" subfolder, such as (EX: C:\mysceneryfolder\hawaii\vpb). The scenery files above are compressed and include the "vpb" folder.

=== Installing ===
Using the FlightGear [[FlightGear_Qt_launcher]] both the terrain and the airport are "installed" by going to tab "Add-ons" and then add the respective folders to "Additional scenery folders". When adding an additional scenery folder, you need to point to the folder immediately above the "vpb" subfolder.

If you add the airports the first time you might have to close the launcher and reopen it again to get the navigation data loaded properly into the session.

== Running World Scenery 3.0 ==
To run WS3.0 you need to set the <code>/scenery/use-vpb</code> property to <code>true</code> at startup. Either set <code>--prop:/scenery/use-vpb=true</code> on your command-line, or in the Additional Settings part of the Settings pane of the launcher.

WS3.0 can use a lot of memory - significantly more than WS2.0. You can control the memory usage with the following properties:

* /sim/rendering/max-paged-lod controls the minimum number of objects that will be kept in memory. The default setting is 200.
* /sim/rendering/plod-minimum-expiry-time-secs controls how long objects remain loaded for after they are no-longer in view. The default value is 180 (3 minutes).

Reducing these properties will reduce the memory footprint of WS3.0.

If you have lots of spare cores, you can run multiple threads to load scenery by setting <code>/sim/rendering/database-pager/threads</code> to a number greater than 4 on startup. E.g. <code>--prop:/sim/rendering/database-pager/threads=8</code>.

=== WS 2.0 scenery might still be needed ===
To have airports displayed plus some of the default scenery objects, you might still want to have the WS 2.0 scenery for the same area installed.

However, if you want updated airports, checkout the global WS3.0 airports above. To avoid collisions you need to not have any WS2.0 airports enabled if you use these.

=== Using osm2city ===
WS3.0 has built-in support for OpenStreetMap roads, so you should not have it enabled in rendering settings.

You have 2 options:

* If you have WS2.0 world scenery, then it already contains osm2city buildings etc. You can just use these and live with slight elevation offsets.
* The other option is to use the provided osm2city scenery in the table above instead. If doing so you need to makes sure that WS2.0 osm2city has not been downloaded (or delete the folders manually). E.g. if you are using [[TerraMaster]] then you can remove the ticks in Settings for "Buildings", "Pylons" and "Roads".

Using the explicitly provided osm2city scenery gives you trees in gardens/parks and some improvements only available on NEXT.

World Scenery 3.0

2024-01-15T15:14:52Z

Nia: /* Terrain */

{{WS30 Navbar}}
World Scenery 3.0 is a project to replace the tiled single-mesh World Scenery 2.0 with an LoD-based approach using a regular elevation mesh, landclass texture and vector line features.

This leverages OSG's Virtual Planet Builder and OpenStreetmap APIs.


== Currently Available Scenery ==

=== Terrain ===
Scenery is currently not distributed using the official Terrasync, Nia provides a terrasync compatible download, point your terrasync client to https://cdn.merspieler.tk/ws3/ to make use of it. As of writing (2024-01-15) it contains all of the sceneries below (duplicates removed) and will get updated when a new Airports package is made and when Wayne provides her with new US scenery. If you don't wanna deal with changing your terrasync settings, you can always download sections of scenery via the links individually and added to your [[FG SCENERY|scenery path]]. If you set these in your scenery path ahead of any other scenery, it will pick up osm2city, scenery objects etc. from the underlying scenery as well.
{| class="wikitable"
|+
Currently Available World Scenery 3.0
!Scenery
!Area
!Size
!Bottom Left
!Top Right
!Area (degrees^2)
!Landclass Source
!Landclass Resolution (m)
!Comments
!Osm2city Scenery
|-
|[https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=share_link WS30_UK]
|Most of the UK
|1GB
| -11,49
|1,61
|121
|CORINE
|30
|DDS
|
|-
|[https://drive.google.com/file/d/19FodUumjOdfWFrzrDo5Yu2U5T8C5Ddzi/view?usp=share_link WS30_FSWeekend]
|Amsterdam and Lelystad
|120MB
|3,52
|8,55
|8
|CORINE
|10
|DDS Includes osm2city
|
|-
|[https://drive.google.com/file/d/1MrYuDKbMl4WhCEq9gnnt8Tz61lTAScvD/view?usp=share_link WS_Alps]
|
|49MB
|6,45
|8,47
|4
|CORINE
|25
|DDS
|
|-
|[https://drive.google.com/file/d/1V4AgqRcVo_7oFly8xCOZMPK7Gvb_X1HB/view?usp=share_link WS30_CA]
|Northern California
|350MB
| -124,34
| -119,39
|25
|NLCD
|30
|DDS
|
|-
|[https://drive.google.com/file/d/1j91qImcU28jrt290O5sUHbRZe7-fQJf-/view?usp=share_link WS30_CA2]
|Northern California, PNG
|454MB
| -124,34
| -119,40
|30
|NLCD
|30
|PNG; for most pilots this is the only scenery that works without troubles.
|[https://drive.google.com/file/d/1jrs7x4LOsdhn7IrISQIrHayu0yMQHaE1/view?usp=share_link osm2city buildings, trees, maritime, pylons etc.] (ca. 230 MB) - San Francisco Bay and San Pablo Bay
|-
|[https://drive.google.com/file/d/1x-kuCTfyMWddTi0fbr_nl41LR41Ylvwb/view?usp=share_link WS30_MTQ]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|10
|PNG; Small French Caribbean island. One airport (TFFF)
|[https://drive.google.com/file/d/1QtojSTbnAAfkMzirQHnDJWbBDGOtnwIK/view?usp=sharing osm2city buildings, trees, maritime, pylons etc.] (ca. 40 MB).
|-
|[https://drive.google.com/file/d/14kbbgXbofDmqxho-bMCfOG4jDwcDqwBd/view?usp=share_link WS30_MTQ_25m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|25
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1NwBjtISPAoTS0vqbV8idvu64CzKJNDQ-/view?usp=share_link WS_MTQ_5m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|5
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1Um7WC8h8Y4BlwgoVSd2xoVO5gTd3E-bI/view?usp=sharing Switzerland_5m]
|Switzerland plus small border
|1.4 GB (ca. 7 GB unzipped)
| 5.75,45.75
| 10.75,48
|10
|CORINE
|5
|PNG; By mistake taken default airports. If you are using merspieler's updated airports, then it will most often work fine, but there might be residuals (e.g. tree on APRON).
|included
|-
|[https://cdn.merspieler.tk/hosting/wayne/ WS3.0 USA]
|USA
|200 to 400 KB (zipped)
| 125,48
| 81,24
|
|NLCD, Tree Canopy Data
|30
|by state
|
|}

=== Airports ===
In addition to the selected areas above, global up-to-date WS3.0 airports have been built. You can find them [https://cdn.merspieler.tk/airports/ here]

=== Installing ===
Using the FlightGear [[FlightGear_Qt_launcher]] both the terrain and the airport are "installed" by going to tab "Add-ons" and then add the respective folders to "Additional scenery folders". If you add the airports the first time you might have to close the launcher and reopen it again to get the navigation data loaded properly into the session.

== Running World Scenery 3.0 ==
To run WS3.0 you need to set the <code>/scenery/use-vpb</code> property to <code>true</code> at startup. Either set <code>--prop:/scenery/use-vpb=true</code> on your command-line, or in the Additional Settings part of the Settings pane of the launcher.

WS3.0 can use a lot of memory - significantly more than WS2.0. You can control the memory usage with the following properties:

* /sim/rendering/max-paged-lod controls the minimum number of objects that will be kept in memory. The default setting is 200.
* /sim/rendering/plod-minimum-expiry-time-secs controls how long objects remain loaded for after they are no-longer in view. The default value is 180 (3 minutes).

Reducing these properties will reduce the memory footprint of WS3.0.

If you have lots of spare cores, you can run multiple threads to load scenery by setting <code>/sim/rendering/database-pager/threads</code> to a number greater than 4 on startup. E.g. <code>--prop:/sim/rendering/database-pager/threads=8</code>.

=== WS 2.0 scenery might still be needed ===
To have airports displayed plus some of the default scenery objects, you might still want to have the WS 2.0 scenery for the same area installed.

However, if you want updated airports, checkout the global WS3.0 airports above. To avoid collisions you need to not have any WS2.0 airports enabled if you use these.

=== Using osm2city ===
WS3.0 has built-in support for OpenStreetMap roads, so you should not have it enabled in rendering settings.

You have 2 options:

* If you have WS2.0 world scenery, then it already contains osm2city buildings etc. You can just use these and live with slight elevation offsets.
* The other option is to use the provided osm2city scenery in the table above instead. If doing so you need to makes sure that WS2.0 osm2city has not been downloaded (or delete the folders manually). E.g. if you are using [[TerraMaster]] then you can remove the ticks in Settings for "Buildings", "Pylons" and "Roads".

Using the explicitly provided osm2city scenery gives you trees in gardens/parks and some improvements only available on NEXT.

World Scenery 3.0

2024-01-15T14:32:16Z

Nia: /* Terrain */

{{WS30 Navbar}}
World Scenery 3.0 is a project to replace the tiled single-mesh World Scenery 2.0 with an LoD-based approach using a regular elevation mesh, landclass texture and vector line features.

This leverages OSG's Virtual Planet Builder and OpenStreetmap APIs.


== Currently Available Scenery ==

=== Terrain ===
Scenery is currently not distributed using the official Terrasync, Nia provides a terrasync compatible download, point your terrasync client to https://cdn2.merspieler.tk/ws3/ to make use of it. As of writing (2024-01-15) it contains all of the sceneries below (duplicates removed) and will get updated when a new Airports package is made and when Wayne provides her with new US scenery. If you don't wanna deal with changing your terrasync settings, you can always download sections of scenery via the links individually and added to your [[FG SCENERY|scenery path]]. If you set these in your scenery path ahead of any other scenery, it will pick up osm2city, scenery objects etc. from the underlying scenery as well.
{| class="wikitable"
|+
Currently Available World Scenery 3.0
!Scenery
!Area
!Size
!Bottom Left
!Top Right
!Area (degrees^2)
!Landclass Source
!Landclass Resolution (m)
!Comments
!Osm2city Scenery
|-
|[https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=share_link WS30_UK]
|Most of the UK
|1GB
| -11,49
|1,61
|121
|CORINE
|30
|DDS
|
|-
|[https://drive.google.com/file/d/19FodUumjOdfWFrzrDo5Yu2U5T8C5Ddzi/view?usp=share_link WS30_FSWeekend]
|Amsterdam and Lelystad
|120MB
|3,52
|8,55
|8
|CORINE
|10
|DDS Includes osm2city
|
|-
|[https://drive.google.com/file/d/1MrYuDKbMl4WhCEq9gnnt8Tz61lTAScvD/view?usp=share_link WS_Alps]
|
|49MB
|6,45
|8,47
|4
|CORINE
|25
|DDS
|
|-
|[https://drive.google.com/file/d/1V4AgqRcVo_7oFly8xCOZMPK7Gvb_X1HB/view?usp=share_link WS30_CA]
|Northern California
|350MB
| -124,34
| -119,39
|25
|NLCD
|30
|DDS
|
|-
|[https://drive.google.com/file/d/1j91qImcU28jrt290O5sUHbRZe7-fQJf-/view?usp=share_link WS30_CA2]
|Northern California, PNG
|454MB
| -124,34
| -119,40
|30
|NLCD
|30
|PNG; for most pilots this is the only scenery that works without troubles.
|[https://drive.google.com/file/d/1jrs7x4LOsdhn7IrISQIrHayu0yMQHaE1/view?usp=share_link osm2city buildings, trees, maritime, pylons etc.] (ca. 230 MB) - San Francisco Bay and San Pablo Bay
|-
|[https://drive.google.com/file/d/1x-kuCTfyMWddTi0fbr_nl41LR41Ylvwb/view?usp=share_link WS30_MTQ]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|10
|PNG; Small French Caribbean island. One airport (TFFF)
|[https://drive.google.com/file/d/1QtojSTbnAAfkMzirQHnDJWbBDGOtnwIK/view?usp=sharing osm2city buildings, trees, maritime, pylons etc.] (ca. 40 MB).
|-
|[https://drive.google.com/file/d/14kbbgXbofDmqxho-bMCfOG4jDwcDqwBd/view?usp=share_link WS30_MTQ_25m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|25
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1NwBjtISPAoTS0vqbV8idvu64CzKJNDQ-/view?usp=share_link WS_MTQ_5m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|5
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1Um7WC8h8Y4BlwgoVSd2xoVO5gTd3E-bI/view?usp=sharing Switzerland_5m]
|Switzerland plus small border
|1.4 GB (ca. 7 GB unzipped)
| 5.75,45.75
| 10.75,48
|10
|CORINE
|5
|PNG; By mistake taken default airports. If you are using merspieler's updated airports, then it will most often work fine, but there might be residuals (e.g. tree on APRON).
|included
|-
|[https://cdn.merspieler.tk/hosting/wayne/ WS3.0 USA]
|USA
|200 to 400 KB (zipped)
| 125,48
| 81,24
|
|NLCD, Tree Canopy Data
|30
|by state
|
|}

=== Airports ===
In addition to the selected areas above, global up-to-date WS3.0 airports have been built. You can find them [https://cdn.merspieler.tk/airports/ here]

=== Installing ===
Using the FlightGear [[FlightGear_Qt_launcher]] both the terrain and the airport are "installed" by going to tab "Add-ons" and then add the respective folders to "Additional scenery folders". If you add the airports the first time you might have to close the launcher and reopen it again to get the navigation data loaded properly into the session.

== Running World Scenery 3.0 ==
To run WS3.0 you need to set the <code>/scenery/use-vpb</code> property to <code>true</code> at startup. Either set <code>--prop:/scenery/use-vpb=true</code> on your command-line, or in the Additional Settings part of the Settings pane of the launcher.

WS3.0 can use a lot of memory - significantly more than WS2.0. You can control the memory usage with the following properties:

* /sim/rendering/max-paged-lod controls the minimum number of objects that will be kept in memory. The default setting is 200.
* /sim/rendering/plod-minimum-expiry-time-secs controls how long objects remain loaded for after they are no-longer in view. The default value is 180 (3 minutes).

Reducing these properties will reduce the memory footprint of WS3.0.

If you have lots of spare cores, you can run multiple threads to load scenery by setting <code>/sim/rendering/database-pager/threads</code> to a number greater than 4 on startup. E.g. <code>--prop:/sim/rendering/database-pager/threads=8</code>.

=== WS 2.0 scenery might still be needed ===
To have airports displayed plus some of the default scenery objects, you might still want to have the WS 2.0 scenery for the same area installed.

However, if you want updated airports, checkout the global WS3.0 airports above. To avoid collisions you need to not have any WS2.0 airports enabled if you use these.

=== Using osm2city ===
WS3.0 has built-in support for OpenStreetMap roads, so you should not have it enabled in rendering settings.

You have 2 options:

* If you have WS2.0 world scenery, then it already contains osm2city buildings etc. You can just use these and live with slight elevation offsets.
* The other option is to use the provided osm2city scenery in the table above instead. If doing so you need to makes sure that WS2.0 osm2city has not been downloaded (or delete the folders manually). E.g. if you are using [[TerraMaster]] then you can remove the ticks in Settings for "Buildings", "Pylons" and "Roads".

Using the explicitly provided osm2city scenery gives you trees in gardens/parks and some improvements only available on NEXT.

World Scenery 3.0 roadmap

2023-12-21T23:12:53Z

Nia: Removed abandoned approach from news section

{{Scenery Core Development}}
{{WS30 Navbar}}
{{See also|TerraGear roadmap}}
{{Project
|name = World Scenery 3.0
|description = New world-wide scenery
|start-date = 2019-Sep
|current-status = Active <ref>https://sourceforge.net/p/flightgear/mailman/message/37074319/</ref>
|developers = Scott Giese Richard Harrison Stuart Buchanan

|motivation-body =
{{Main article|Virtual Planet Builder}}
{{FGCquote
|Virtual Planet Builder (VPB) is OSG's terrain-database-building tool.
It loads GIS elevation data for a
region, combines it with imagery and produces a spatially-balanced
quadtree tiled database that can be navigated simply by loading the
top-level file. All of the LOD Ranges are pre-configured and the
DatabasePager automatically loads and unloads different segments of
terrain without any supporting userspace code required. VPB can build
terrain models ranging from a small area to the entire planet. These
databases can be fluidly navigated at 60fps from outer space down to
ground level with no interruptions. The terrain models are built of
regular grid arrays with optional edge-skirts to conceal any cracks
caused by adjacent LOD differences. 
|{{cite web |url=http://alphapixel.com/wp-content/uploads/2015/04/OpenSceneGraph-OSG-Virtual-Planet-Builder-VPB-OSGDEM.pdf
|title=<nowiki>OpenScenGraph's Virtual Planet Builder/OSGDEM</nowiki>
|publisher=<nowiki>AlphaPixel, LLC</nowiki>
}}
}}

|objective-body =

[[File:Edinburgh rendering using WS3.0.jpg|thumb|Initial rendering of Edinburgh scenery using a raster landclass and texture lookup for city, water and grass]]
[[File:WS3.0 terrain with WS2.0 EGPH.jpg|thumb|Screenshot showing a WS2.0 airport .btg file rendered with WS3.0 terrain]]
[[File:EGPH roads.jpg|thumb|WS3.0 Edinburgh airport with runtime-generated roads from OSM data]]
[[File:WS30 - West Lothian.png|thumb|WS30 view of West Lothian, with 25m resolution landclass data, vegetation, osm2city buildings, and OSM-based roads and rivers.]]
[[File:WS30 street lighting.jpg|thumb|Edinburgh at night, with osm2city buildings, OSM-base roads, including whether they are lit or not. Note the road in the foreground which is lit near the buildings and unlit in the countryside.]]
[[File:Fgfs-20220528191253.png|thumb|WS30 using OSM data to define the coastline. This shows a view near Oban in Scotland looking South. The coastline is applied as a high resolution overlay texture that is generated at runtime from OSM data and mixed with the landclass texture by the ws30 shader.]]

Produce high-quality scenery using the best-known practices.

TerraGear becomes obsolete in favor of VPB.

* '''OpenGL 3.3 Core Profile''': WS3.0 will require us to eliminate the usage of the fixed-function pipeline. 
* '''Shader-based Rendering''': All of the terrain renderings will be done via GLSL shaders. 
* '''OSG Core''': OpenSceneGraph will require targeting of the OpenGL Core Profile.

WS3.0 will continue to cooperate with osm2city.

Easy upgrade: Initially the plan was that airport layouts will be generated in real-time. Apt.dat will continue to be the primary source for airport layouts and that airports will be draped over the terrain. This would eliminate the need to cut airport layouts into the underlying terrain.
Due to difficulties with this approach, it has been decided, that we keep using the WS2.0 airports for now. Work has been done to automatically update the airports from the X-Plane gateway which can be done automatically now.
The apt.dat file gets update with this as well. Here it remains for the navdb parser to understand the 8.33kHz frequencies.

WS3.0 also offers the opportunity for well performing ortho scenery with acceptable memory impact. merspieler has acquired GPL compatible sources so we could theoretically have a demo area with ortho scenery in the first WS3.0 release. It adds significant storage requirement tho (~14.7GB per 1x1 degrees tile). There hasn't been a decision made yet, on how to proceed on this.

|background-body =
=== Data Sources ===

:;SRTMGL3.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL3.003/
:;SRTMGL1.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL1.003/
:;Global Land Cover:: https://lcviewer.vito.be/
:;Natural Earth:: https://www.naturalearthdata.com/
:;OpenStreetMap :: https://www.openstreetmap.org (See https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/ genroads.py, gencoastline.py, genwater.py for details)

|status-body =

As of 11/2021, WS30 is available on "next", and on the [https://download.flightgear.org/builds/nightly/ nightly builds].

Scenery is available for Scotland, but must be downloaded directly (https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=sharing). You need to add the downloaded and then extracted folder as additional scenery folder.

WS30 can be enabled from the Rendering Options menu, with fine-tuning from the LoD menu. Alternatively you can set --prop:/scenery/use-vpb=true to enable it as command line option.

Airports are currently in the old WS2 format - including airport keep terrain. The WS30 terrain goes under the airport so it is not visible.

Roads are implemented. Lights on roads are implemented - to see, set time to night. WiP rendering.

Vegetation is available - initial version.

While large water bodies are defined in the landclass texture, rivers are draped on top from OSM data. Coastlines are taken from OSM by are applied as a higher resolution overlay texture to reduce the tiling effect.

Scenery generation workflow is at an advanced stage. It's fast to build. Scott was able to do UK in a matter of hours [https://sourceforge.net/p/flightgear/mailman/message/37259618/]. People interested in generating scenery for the World Build, or getting their landclass or elevation work on [[Suggested custom scenery|custom scenery]] in, should start learning the tools and process. The exact VPB settings and scenery file format may change several times before the final build. But the process of getting work in to shouldn't change much for scenery creators. See the [[Virtual Planet Builder]] page for instructions.

====Scenery generation tool availability ====
* [[VPB]]: '''Linux:''' build from source, docker image available. '''Windows and Mac:''' build from source, no binaries yet, needs NVTT binaries - see "[[Mailing lists|fg-devel]]" mailing list to assist.
* [[QGIS]]: Not needed when experimenting with terrain generation using lower res landclass rasters provided by CORINE. '''Linux:''' build from source, binary packages[https://qgis.org/en/site/forusers/download.html], official docker release available: https://hub.docker.com/r/qgis/qgis but Fahim was not sure easy the GUI is to use [https://sourceforge.net/p/flightgear/mailman/message/37381800/]. '''Windows, Mac:''' official QGIS binary releases [https://qgis.org/en/site/forusers/download.html].

===LoD settings===
Go to ''View > Adjust LoD > World Scenery 3.0 section'' (Nov 2021).
* 7 LoD levels - most detailed is 6, shown at closest range. Least detailed is 0, shown at long range. LoD 0 tiles with Scotland scenery are 1x1 degree, or approx 111 km x 111 km at the equator.
* Scenery is divided into chunks called tiles. As view distance increases, tiles with a LoD level are replaced by tiles with the next lowest LoD level. e.g. Four LoD 6 tiles are replaced by one LoD 5 tile. Four LoD 5 tiles are replaced by one LoD 4 tile. As view gets closer the reverse happens. One LoD 2 tile is replaced by four LoD 3 tiles.
* Detail range - The LoD level below which each type of feature is not visible. e.g. setting vegetation to LoD 3 means vegetation is shown for LoD 3/4/5/6 and not shown for tiles with LoD 0/1/2.
* Minimum line feature width (line features are things like roads or rivers) - for every LoD level, the width in meters below which a line feature is not shown. e.g. setting LoD level four to 30 meters means rivers or roads that are narrower than 30 meters are not shown for level four tiles. The minimum widths should stay the same or decrease when going down a LoD level.
* Minimum area feature width (area features are things like lakes) - similar to minimum line feature width, but for area in square meters. Setting LoD 3 to 100 square meters means lakes of size 99 square meters or 40 square meters will not show for LoD level 3 tiles.

Proof of Concept {{progressbar|100}}
* VPB {{done}}
* osgOcean {{done}}
* osgVegetation {{done}}
* Generate terrain for Hawaii {{done}}
* Hack Hawaii VPB into FG {{done}}
 

OSG {{progressbar|70}}
* Core Profile: {{done}}
* GLVND Support: {{done}}
* glTF Plugin Support: {{ongoing}}
 

{{gallery
| title = Standard-Fidelity
| align = right
| N00-N10-LC100m-SRTMGL3.png | N00-N60 lat
| Africa-LC100m-SRTMGL3.png | Africa Land Coverage
| Africa-Natural.png | Natural Earth
| Ocean-N00-N90.png | Ocean Fill
}}
=== Standard-Fidelity - 90m SRTMGL3 - 100m Global Land Cover ===

=== Northern Hemisphere: 152.3 GB ===
=== Southern Hemisphere: 57.4 GB ===

Virtual Planet Builder {{progressbar|70}}
* Procure Demographic Data: SRTMGL3.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Ocean {{done}}
** Northern: {{progressbar|100}}
** Southern: {{progressbar|100}}
 

=== High-Fidelity - 30m SRTMGL1 - Best Available Land Cover ===

Virtual Planet Builder {{progressbar|30}}
* Procure Demographic Data: SRTMGL1.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
 

|news-body=
The northern hemisphere, up to N60, has been completed. The southern hemisphere, above S56, has been completed.
SRTM data was not captured above N60 and below S56, so alternative data sources need to be procured.

Oceans are complete.
}}

{{gallery
| title = Standard-Fidelity Gallery
| align = center
| Terrain-Mesh.jpg | WS3 Terrain Mesh
| S10-N60-LC100m-SRTMGL3.png | Asia/India
| N00-N10-LC100m-SRTMGL3.png | Europe
| N00-N40-LC100m-SRTMGL3.png | USA
| Africa-LC100m-SRTMGL3.png | Land Coverage
| Africa-Natural.png | Natural Earth
| Africa-Natural2.png | Natural Earth
}}

For the experimental runtime generated mesh/landclassing engine - which may become WS3.0 - see [[Experimental terrain engine]].

[[Category:Development projects‎]]
[[Category:Scenery]]

World Scenery 3.0

2023-12-21T23:09:26Z

Nia: /* WS 2.0 scenery is still needed */

{{WS30 Navbar}}
World Scenery 3.0 is a project to replace the tiled single-mesh World Scenery 2.0 with an LoD-based approach using a regular elevation mesh, landclass texture and vector line features.

This leverages OSG's Virtual Planet Builder and OpenStreetmap APIs.


=== Currently Available Scenery ===
Scenery is not currently distributed using Terrasync. Instead, sections of scenery must be downloaded individually and added to your [[FG SCENERY|scenery path]]. If you set these in your scenery path ahead of any other scenery, it will pick up osm2city, scenery objects etc. from the underlying scenery as well.
{| class="wikitable"
|+
Currently Available World Scenery 3.0
!Scenery
!Area
!Size
!Bottom Left
!Top Right
!Area (degrees^2)
!Landclass Source
!Landclass Resolution (m)
!Comments
!Osm2city Scenery
|-
|[https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=share_link WS30_UK]
|Most of the UK
|1GB
| -11,49
|1,61
|121
|CORINE
|30
|DDS
|
|-
|[https://drive.google.com/file/d/19FodUumjOdfWFrzrDo5Yu2U5T8C5Ddzi/view?usp=share_link WS30_FSWeekend]
|Amsterdam and Lelystad
|120MB
|3,52
|8,55
|8
|CORINE
|10
|DDS Includes osm2city
|
|-
|[https://drive.google.com/file/d/1MrYuDKbMl4WhCEq9gnnt8Tz61lTAScvD/view?usp=share_link WS_Alps]
|
|49MB
|6,45
|8,47
|4
|CORINE
|25
|DDS
|
|-
|[https://drive.google.com/file/d/1V4AgqRcVo_7oFly8xCOZMPK7Gvb_X1HB/view?usp=share_link WS30_CA]
|Northern California
|350MB
| -124,34
| -119,39
|25
|NLCD
|30
|DDS
|
|-
|[https://drive.google.com/file/d/1j91qImcU28jrt290O5sUHbRZe7-fQJf-/view?usp=share_link WS30_CA2]
|Northern California, PNG
|454MB
| -124,34
| -119,40
|30
|NLCD
|30
|PNG; for most pilots this is the only scenery that works without troubles.
|[https://drive.google.com/file/d/1jrs7x4LOsdhn7IrISQIrHayu0yMQHaE1/view?usp=share_link osm2city buildings, trees, maritime, pylons etc.] (ca. 230 MB) - San Francisco Bay and San Pablo Bay
|-
|[https://drive.google.com/file/d/1x-kuCTfyMWddTi0fbr_nl41LR41Ylvwb/view?usp=share_link WS30_MTQ]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|10
|PNG; Small French Caribbean island. One airport (TFFF)
|[https://drive.google.com/file/d/1QtojSTbnAAfkMzirQHnDJWbBDGOtnwIK/view?usp=sharing osm2city buildings, trees, maritime, pylons etc.] (ca. 40 MB).
|-
|[https://drive.google.com/file/d/14kbbgXbofDmqxho-bMCfOG4jDwcDqwBd/view?usp=share_link WS30_MTQ_25m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|25
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|-
|[https://drive.google.com/file/d/1NwBjtISPAoTS0vqbV8idvu64CzKJNDQ-/view?usp=share_link WS_MTQ_5m]
|Martinique
|7MB
| -62,14
| -60,15
|2
|CORINE
|5
|PNG; Small French Caribbean island. One airport (TFFF)
|(see above)
|}

In addition to the selected areas above, global up-to-date WS3.0 airports have been built. You can find them [https://cdn.merspieler.tk/airports/ here]

== Running World Scenery 3.0 ==
To run WS3.0 you need to set the <code>/scenery/use-vpb</code> property to <code>true</code> at startup. Either set <code>--prop:/scenery/use-vpb=true</code> on your command-line, or in the Additional Settings part of the Settings pane of the launcher.

WS3.0 can use a lot of memory - significantly more than WS2.0. You can control the memory usage with the following properties:

* /sim/rendering/max-paged-lod controls the minimum number of objects that will be kept in memory. The default setting is 200.
* /sim/rendering/plod-minimum-expiry-time-secs controls how long objects remain loaded for after they are no-longer in view. The default value is 180 (3 minutes).

Reducing these properties will reduce the memory footprint of WS3.0.

If you have lots of spare cores, you can run multiple threads to load scenery by setting <code>/sim/rendering/database-pager/threads</code> to a number greater than 4 on startup. E.g. <code>--prop:/sim/rendering/database-pager/threads=8</code>.

=== WS 2.0 scenery is still needed ===
To have airports displayed plus some of the default scenery objects, you should still have the WS 2.0 scenery for the same area installed.

If you want updated airports, checkout the global WS3.0 airports above. To avoid collisions you need to not have any WS2.0 airports enabled if you use these.

=== Using osm2city ===
WS3.0 has built-in support for OpenStreetmap roads, so you should not have it enabled in rendering settings.

You have 2 options:

* If you have WS2.0 world scenery, then it already contains osm2city buildings etc. You can just use these and live with slight elevation offsets.
* The other option is to use the provided osm2city scenery instead. If doing so you need to makes sure that WS2.0 osm2city has not been downloaded (or delete the folders manually). E.g. if you are using [[TerraMaster]] then you can remove the ticks in Settings for "Buildings", "Pylons" and "Roads".

Using the explicitly provided osm2city scenery gives you trees in gardens/parks and some improvements only available on NEXT.

World Scenery 3.0

2023-12-21T23:07:28Z

Nia: /* Currently Available Scenery */

World Scenery 3.0 roadmap

2023-09-25T19:58:34Z

Nia: For the airport updates are no longer any pending tasks required.

{{Scenery Core Development}}
{{WS30 Navbar}}
{{See also|TerraGear roadmap}}
{{Project
|name = World Scenery 3.0
|description = New world-wide scenery
|start-date = 2019-Sep
|current-status = Active <ref>https://sourceforge.net/p/flightgear/mailman/message/37074319/</ref>
|developers = Scott Giese Richard Harrison Stuart Buchanan

|motivation-body =
{{Main article|Virtual Planet Builder}}
{{FGCquote
|Virtual Planet Builder (VPB) is OSG's terrain-database-building tool.
It loads GIS elevation data for a
region, combines it with imagery and produces a spatially-balanced
quadtree tiled database that can be navigated simply by loading the
top-level file. All of the LOD Ranges are pre-configured and the
DatabasePager automatically loads and unloads different segments of
terrain without any supporting userspace code required. VPB can build
terrain models ranging from a small area to the entire planet. These
databases can be fluidly navigated at 60fps from outer space down to
ground level with no interruptions. The terrain models are built of
regular grid arrays with optional edge-skirts to conceal any cracks
caused by adjacent LOD differences. 
|{{cite web |url=http://alphapixel.com/wp-content/uploads/2015/04/OpenSceneGraph-OSG-Virtual-Planet-Builder-VPB-OSGDEM.pdf
|title=<nowiki>OpenScenGraph's Virtual Planet Builder/OSGDEM</nowiki>
|publisher=<nowiki>AlphaPixel, LLC</nowiki>
}}
}}

|objective-body =

[[File:Edinburgh rendering using WS3.0.jpg|thumb|Initial rendering of Edinburgh scenery using a raster landclass and texture lookup for city, water and grass]]
[[File:WS3.0 terrain with WS2.0 EGPH.jpg|thumb|Screenshot showing a WS2.0 airport .btg file rendered with WS3.0 terrain]]
[[File:EGPH roads.jpg|thumb|WS3.0 Edinburgh airport with runtime-generated roads from OSM data]]
[[File:WS30 - West Lothian.png|thumb|WS30 view of West Lothian, with 25m resolution landclass data, vegetation, osm2city buildings, and OSM-based roads and rivers.]]
[[File:WS30 street lighting.jpg|thumb|Edinburgh at night, with osm2city buildings, OSM-base roads, including whether they are lit or not. Note the road in the foreground which is lit near the buildings and unlit in the countryside.]]
[[File:Fgfs-20220528191253.png|thumb|WS30 using OSM data to define the coastline. This shows a view near Oban in Scotland looking South. The coastline is applied as a high resolution overlay texture that is generated at runtime from OSM data and mixed with the landclass texture by the ws30 shader.]]

Produce high-quality scenery using the best-known practices.

TerraGear becomes obsolete in favor of VPB.

* '''OpenGL 3.3 Core Profile''': WS3.0 will require us to eliminate the usage of the fixed-function pipeline. 
* '''Shader-based Rendering''': All of the terrain renderings will be done via GLSL shaders. 
* '''OSG Core''': OpenSceneGraph will require targeting of the OpenGL Core Profile.

WS3.0 will continue to cooperate with osm2city.

Easy upgrade: Initially the plan was that airport layouts will be generated in real-time. Apt.dat will continue to be the primary source for airport layouts and that airports will be draped over the terrain. This would eliminate the need to cut airport layouts into the underlying terrain.
Due to difficulties with this approach, it has been decided, that we keep using the WS2.0 airports for now. Work has been done to automatically update the airports from the X-Plane gateway which can be done automatically now.
The apt.dat file gets update with this as well. Here it remains for the navdb parser to understand the 8.33kHz frequencies.

WS3.0 also offers the opportunity for well performing ortho scenery with acceptable memory impact. merspieler has acquired GPL compatible sources so we could theoretically have a demo area with ortho scenery in the first WS3.0 release. It adds significant storage requirement tho (~14.7GB per 1x1 degrees tile). There hasn't been a decision made yet, on how to proceed on this.

|background-body =
=== Data Sources ===

:;SRTMGL3.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL3.003/
:;SRTMGL1.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL1.003/
:;Global Land Cover:: https://lcviewer.vito.be/
:;Natural Earth:: https://www.naturalearthdata.com/
:;OpenStreetMap :: https://www.openstreetmap.org (See https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/ genroads.py, gencoastline.py, genwater.py for details)

|status-body =

As of 11/2021, WS30 is available on "next", and on the [https://download.flightgear.org/builds/nightly/ nightly builds].

Scenery is available for Scotland, but must be downloaded directly (https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=sharing). You need to add the downloaded and then extracted folder as additional scenery folder.

WS30 can be enabled from the Rendering Options menu, with fine-tuning from the LoD menu. Alternatively you can set --prop:/scenery/use-vpb=true to enable it as command line option.

Airports are currently in the old WS2 format - including airport keep terrain. The WS30 terrain goes under the airport so it is not visible.

Roads are implemented. Lights on roads are implemented - to see, set time to night. WiP rendering.

Vegetation is available - initial version.

While large water bodies are defined in the landclass texture, rivers are draped on top from OSM data. Coastlines are taken from OSM by are applied as a higher resolution overlay texture to reduce the tiling effect.

Scenery generation workflow is at an advanced stage. It's fast to build. Scott was able to do UK in a matter of hours [https://sourceforge.net/p/flightgear/mailman/message/37259618/]. People interested in generating scenery for the World Build, or getting their landclass or elevation work on [[Suggested custom scenery|custom scenery]] in, should start learning the tools and process. The exact VPB settings and scenery file format may change several times before the final build. But the process of getting work in to shouldn't change much for scenery creators. See the [[Virtual Planet Builder]] page for instructions.

====Scenery generation tool availability ====
* [[VPB]]: '''Linux:''' build from source, docker image available. '''Windows and Mac:''' build from source, no binaries yet, needs NVTT binaries - see "[[Mailing lists|fg-devel]]" mailing list to assist.
* [[QGIS]]: Not needed when experimenting with terrain generation using lower res landclass rasters provided by CORINE. '''Linux:''' build from source, binary packages[https://qgis.org/en/site/forusers/download.html], official docker release available: https://hub.docker.com/r/qgis/qgis but Fahim was not sure easy the GUI is to use [https://sourceforge.net/p/flightgear/mailman/message/37381800/]. '''Windows, Mac:''' official QGIS binary releases [https://qgis.org/en/site/forusers/download.html].

===LoD settings===
Go to ''View > Adjust LoD > World Scenery 3.0 section'' (Nov 2021).
* 7 LoD levels - most detailed is 6, shown at closest range. Least detailed is 0, shown at long range. LoD 0 tiles with Scotland scenery are 1x1 degree, or approx 111 km x 111 km at the equator.
* Scenery is divided into chunks called tiles. As view distance increases, tiles with a LoD level are replaced by tiles with the next lowest LoD level. e.g. Four LoD 6 tiles are replaced by one LoD 5 tile. Four LoD 5 tiles are replaced by one LoD 4 tile. As view gets closer the reverse happens. One LoD 2 tile is replaced by four LoD 3 tiles.
* Detail range - The LoD level below which each type of feature is not visible. e.g. setting vegetation to LoD 3 means vegetation is shown for LoD 3/4/5/6 and not shown for tiles with LoD 0/1/2.
* Minimum line feature width (line features are things like roads or rivers) - for every LoD level, the width in meters below which a line feature is not shown. e.g. setting LoD level four to 30 meters means rivers or roads that are narrower than 30 meters are not shown for level four tiles. The minimum widths should stay the same or decrease when going down a LoD level.
* Minimum area feature width (area features are things like lakes) - similar to minimum line feature width, but for area in square meters. Setting LoD 3 to 100 square meters means lakes of size 99 square meters or 40 square meters will not show for LoD level 3 tiles.

Proof of Concept {{progressbar|100}}
* VPB {{done}}
* osgOcean {{done}}
* osgVegetation {{done}}
* Generate terrain for Hawaii {{done}}
* Hack Hawaii VPB into FG {{done}}
 

OSG {{progressbar|70}}
* Core Profile: {{done}}
* GLVND Support: {{done}}
* glTF Plugin Support: {{ongoing}}
 

{{gallery
| title = Standard-Fidelity
| align = right
| N00-N10-LC100m-SRTMGL3.png | N00-N60 lat
| Africa-LC100m-SRTMGL3.png | Africa Land Coverage
| Africa-Natural.png | Natural Earth
| Ocean-N00-N90.png | Ocean Fill
}}
=== Standard-Fidelity - 90m SRTMGL3 - 100m Global Land Cover ===

=== Northern Hemisphere: 152.3 GB ===
=== Southern Hemisphere: 57.4 GB ===

Virtual Planet Builder {{progressbar|70}}
* Procure Demographic Data: SRTMGL3.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Ocean {{done}}
** Northern: {{progressbar|100}}
** Southern: {{progressbar|100}}
 

=== High-Fidelity - 30m SRTMGL1 - Best Available Land Cover ===

Virtual Planet Builder {{progressbar|30}}
* Procure Demographic Data: SRTMGL1.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
 

|news-body=
The northern hemisphere, up to N60, has been completed. The southern hemisphere, above S56, has been completed.
SRTM data was not captured above N60 and below S56, so alternative data sources need to be procured.

Stuart has made good progress with the procedure needed to convert apt.dat into an airport object. Our goal is to utilize this to project/drape the airport layout over the terrain. This will enable localized edits of airports without requiring us to generate another world scenery build.

Oceans are complete.
}}

{{gallery
| title = Standard-Fidelity Gallery
| align = center
| Terrain-Mesh.jpg | WS3 Terrain Mesh
| S10-N60-LC100m-SRTMGL3.png | Asia/India
| N00-N10-LC100m-SRTMGL3.png | Europe
| N00-N40-LC100m-SRTMGL3.png | USA
| Africa-LC100m-SRTMGL3.png | Land Coverage
| Africa-Natural.png | Natural Earth
| Africa-Natural2.png | Natural Earth
}}

For the experimental runtime generated mesh/landclassing engine - which may become WS3.0 - see [[Experimental terrain engine]].

[[Category:Development projects‎]]
[[Category:Scenery]]

Hackathon Proposal: Ground Services from apt.dat

2023-09-16T19:15:57Z

Nia: Created page with "{| class="wikitable" |- | Title || '''<big>Ground Services from apt.dat</big>''' |- | Sponsor || merspieler |- | Supporters || |- | Status || |- | Summary || The new..."

{| class="wikitable"

|-

| Title || '''<big>Ground Services from apt.dat</big>'''

|-

| Sponsor || merspieler

|-

| Supporters ||

|-

| Status ||

|-

| Summary || The newer apt.dat format defines routes for ground traffic. Idea is to read (if needed, pre-process the data) that and create ground traffic using this data.

|-

| Background || Airports are busy, not just the aircraft but also all the ground handling like baggage carts, fuel trucks, crew busses, etc. This is missing in FG, adding it would make the airport feel way more alive.

|-

| Details ||

|-

| Skills ||

|-

| Notes || [https://developer.x-plane.com/article/airport-data-apt-dat-12-00-file-format-specification/ apt.dat 1200 spec]

|}

[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: WS3.0 Ortho Water Transition Shader

2023-09-03T21:22:33Z

Nia: Created page with "{| class="wikitable" |- | Title || '''<big>Ortho to Water transition shader for WS3.0</big>''' |- | Sponsor || merspieler |- | Supporters || |- | Status || |- | Summ..."

{| class="wikitable"

|-

| Title || '''<big>Ortho to Water transition shader for WS3.0</big>'''

|-

| Sponsor || merspieler

|-

| Supporters ||

|-

| Status ||

|-

| Summary || Create a nice transition between water and ortho photos in WS3.0

|-

| Background || Right now, it's a rather hard cut between ortho scenery and water.
A transition shader would get rid of that hard cut and make underwater features in shallow water visible (such as reefs)

|-

| Details ||

|-

| Skills || C++?, GLSL

|-

| Notes || Stuart say this is doable and would offer mentorship.

|}

[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: Volumetric Clouds

2023-09-03T20:34:52Z

Nia: Created page with "{| class="wikitable" |- | Title || '''<big>Volumetric Clouds</big>''' |- | Sponsor || merspieler |- | Supporters || |- | Status || |- | Summary || Create volumetric..."

{| class="wikitable"

|-

| Title || '''<big>Volumetric Clouds</big>'''

|-

| Sponsor || merspieler

|-

| Supporters ||

|-

| Status ||

|-

| Summary || Create volumetric clouds

|-

| Background || Right now, the "3D" clouds are just billboards, which always face the camera (with the ufo look straight up and roll a little bit to observe clouds rotating). Since they're just 2 dimensional billboards you can never really be in a cloud. Right now we cheat here by reducing the visibility when being in a cloud which makes it strange looking when emerging from the cloud as you can see the visible area expand again. When flying toward the cloud it's a hard cut through it and it might clip into the cockpit.
The solution is having volumetric clouds. This could be realized using 3D textures (see [https://yt.artemislena.eu/watch?v=4QOcCGI6xOU this video] for how this could be approached)

|-

| Details ||

|-

| Skills || C++, GLSL

|-

| Notes || Stuart has thought about this a bit already and thinks this is doable and would be able to mentor.

|}

[[Category:Hackathon 2023 Ideas]]

Hackathon Proposal: Docker Container for osm2city

2023-09-02T15:50:30Z

Nia:

{| class="wikitable"
|-
| Title || '''<big>Docker container for osm2city</big>'''
|-
| Sponsor || [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9140 vanosten]
|-
| Supporters ||
|-
| Status || Proposed
|-
| Summary || Create a [https://opencontainers.org/ OCI container] ("Docker") for [[Osm2city.py | osm2city]], which is based on the originally Python based [https://gitlab.com/osm2city/osm2city osm2city] as well as the C++ based [https://gitlab.com/osm2city/osm2gear osm2gear] such that interested parties easier can contribute to generate scenery.
|-
| Background ||
|-
| Details ||
|-
| Skills || C++, CMake, Python, Docker
|-
| Notes || Alternative to a container image, osm2city could be included into [[Scripted Compilation on Linux Debian/Ubuntu]] - which is good for installations on one machine, but less ideal to run multiple machines in a virtual setup.
[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21618 merspieler] has already created such a container (about 2 years ago) but she didn't update it for the new C++ based branch and new features yet.
|}
[[Category:Hackathon 2023 Ideas]]

Virtual FSweekend Hackathon 2023

2023-09-02T15:41:48Z

Nia: /* Sign up */

Normally in mid-November a group of FlightGear enthusiasts participate in [[FSWeekend]] in [https://www.aviodrome.nl/ Aviodrome] at the [https://www.lelystadairport.nl/ Lelystad Airport] in the Netherlands. Over the years this has been a focal point for both finishing existing development/releases and a catalyst for new ideas in FlightGear, as well as an opportunity for FlightGear enthusiasts to share a beer. This year the [https://www.aviodrome.nl/evenementen/flight-simulator/?_gl=1*1hh597t*_up*MQ..&gclid=EAIaIQobChMIhdjmndaLgQMVKpiDBx3wFwOwEAAYASAAEgI64vD_BwE Flight Simulator Weekend] has been re-scheduled to March 16/17 2024.

To keep the spirit alive and repeat the successful execution of the [[Virtual_FSweekend_Hackathon_2020|Virtual FSweekend Hackathon 2020]] and [[Virtual_FSweekend_Hackathon_2021|Virtual FSweekend Hackathon 2021]], we are planning to hold another Virtual FSweekend Hackathon on the weekend of {{{days_string|10/11/12}}} November {{{year|2023}}} (in {{days from now|{{{year|2023}}}|11|10}}).

== Hackathon? ==
For those who have not participated in a hackathon before, the broad idea is to get people from a wide variety of experience and backgrounds together to solve problems over a short period of time - typically 24 or 48 hours. Details vary, but typically at the start of the event, people pitch ideas and groups form organically based on what people are interested in. The groups then work together intensively, often fueled by pizza and caffeine etc. At the end of the hackathon the groups present their work and there are often prizes for the best hacks.

The general idea of virtual FSWeekend hackathons is to encourage existing and new contributors to collaborate over the course of a weekend to create new and exciting features for FlightGear in the broadest sense. The core developers would particularly like to use it as an opportunity to encourage people to get their hands dirty in the core code, so they will be primarily there to help/coach people rather than hacking themselves, but anything is possible :)

No prior development experience is necessary - there might be run some education sessions ahead of the weekend so people can hit the ground running (otherwise you will learn during the hackathon). Also, do not feel you have to commit to coding the entire weekend to the exclusion of all else. We think participants will still get real value if they can just commit to one day and some late evenings.

== Only Core Development? ==
While the core of the hackathon incl. support previously has been dedicated to development in the very core of FlightGear (mostly C++, [[Nasal_scripting_language|Nasal]] and xml), you are also welcome to participate if you are developing stuff, which contributes to the general FlightGear ecosystem (e.g. [[Addon]], visual artwork or [[Osm2city.py|osm2city]]). However, in that case you might need to provide your own support.

== Sign up ==
{{Note|There is space for many participants, so don't be shy. {{{organizer|Rick}}} is happy for people to register right up to the Friday night, but we will not be able to help out with getting builds and git working if you leave it that late!}}

To register your participation, please contact {{{organizer|Rick}}} either on the {{forum link|t=41662|text=forum post}}, by PM on the [https://discord.gg/rzuV2DR FlightGear Discord server] or via the [https://sourceforge.net/p/flightgear/mailman/message/37890811/ devel list].

Confirmed participants (in alphabetical order):

{| class="wikitable"
|-
! Name
! aka.
! Role
! Remarks
|-
|Rick Gruber-Riemer
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9140 vanosten], HB-VANO on FG Discord
|Organiser/mentor
|Can coach osm2city and OSM data processing
|-
|Nia
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21618 merspieler], Nia on [https://matrix.to/#/#flightgear-jsbsim:hacklab.fi FG Matrix]
|Infra provider, ask if you've got issues with Mattermost or Jitsi
|Can help with osm2city data processing (worldbuild stuff)
|}

== Ahead of the Hackathon ==
There are a couple of key activities ahead of the weekend in {{{year|2023}}}.

=== Getting started ===
So we can hit the ground running, we really want everyone participating to already have:
* SourceForge credentials
* A working build environment with [[OpenSceneGraph|OSG]], [[PLIB]] etc.
* A Git checkout of simgear/flightgear (cf. [[FlightGear_Git]])
* A Git checkout of fgdata
* Some experience with [https://git-scm.com/ Git]

At the very least you should be able to work with a [[FlightGear_build_server|nightly version]] of FlightGear.

Before the Hackathon consider having a look into the dedicated [[:Category:Hackathon Materials|Hackathon Materials]] category for articles, which might help get you going.

=== Logistics ===
Being completely remote, we need the ability to collaborate in teams as well as video conference as a group.

There will be a [https://mattermost.com/ Mattermost] server for the weekend. We'll be using that for organization, discussion and collaboration.

We'll be using a [https://jitsi.org/ Jitsi] Server for video conferencing and demos.

To use the server, please start the Jitsi calls from within Mattermost (click on that power plug symbol in the top bar next to the search). Preferably use an app or Chrome/Chromium.

=== Ideation ===
The core of the Hackathon! These are the projects, ideas and problems that participants will be working on during the weekend. In the weeks before the Hackathon itself, participants can, and should, propose things to work on. Simply create a wiki page describing your idea, and encourage people to contribute and get interested.

Check out the [[:Category:Hackathon {{{year|2023}}} Ideas|Hackathon {{{year|2023}}} Ideas]] category page for a how-to as well as links to existing proposals.

You can also take a look at proposals from the previous years.

Not having an idea? No problem! Have a look at the proposed ideas, leave a comment on the Discussion page, and add yourself as an Interested Party for those ideas you consider working on during the Hackathon. There is no commitment until the start of the Hackathon on Friday evening.

== Schedule ==
With (hopefully) a world-wide group of participants, and varying real life constraints, at any given time over the weekend there will hopefully be a couple of people active.

We will have two big get-togethers:

=== {{{kick-off-totd-utc|Friday 10th November 2000-2200 UTC.}}} Kick-off ===
* General welcome
* Introductions
* Hack pitches
* Team formation

This is the point at which participants will decide, which Hacks they want to work on. The sponsors of each of the Hacks proposed ahead of time will be invited to give a 5 minutes pitch to the group, with some questions from the audience. Slides/screenshots optional.

After all the Hacks have been pitched, we will have a little break for people to chat and work out which Hack they want to work on.

If a Hack ends up with fewer than 2 people wanting to work on it (including the sponsor), then it will normally be dropped. This is to encourage people to work in groups - larger teams can get more done in the time, and have more opportunities to learn from each other, plus it is more sociable!

=== {{{wrap-up-totd-utc|Sunday 12th November 2000-2200 UTC.}}} Wrap up and demos ===
At the end of the hackathon we will have a get together and have each team present the results of their hack.

Depending on the number of hacks, each team will have 5-15 minutes to demonstrate their hack, describe what they have learned, and what their next steps are.

We will finish with voting for the best hack of the weekend.

== FAQ ==

'''Q''': What is the aim of the Hackathon? 
'''A''': To learn and have fun hacking FlightGear. Encourage people to get their hands dirty and modify code. Try out new ideas. Working with other people. Ultimately to increase the number of core developers.

'''Q''': What can participants expect to get out of the weekend? 
'''A''': The primary goal is for people to learn through experimentation. To try out new ideas and in the process learn about the internals of FlightGear. James, Stuart and Fernando will be be providing coaching over the course of the weekend.

'''Q''': What organization will be provided? 
'''A''': We will provide tools for collaboration, and organize a couple of meetings, but not much more. The idea behind hackathons is that participants largely self organize - teams form around interesting ideas on Friday evening and organize themselves. Participants will need to provide their own computers, pizza, Haribo, beer. The last three are traditional, but optional.

'''Q''': How much time do I need to commit? 
'''A''': The more the better. A traditional hackathon would be 24-48 hours of solid work with sleep optional. That is not realistic for most people, but 20 hours over the weekend would be a good amount to aim for. Certainly if you can only commit to a couple of evenings you may not get much out of Hackathon.

'''Q''': What skills do I need? 
'''A''': It depends on what you want to do. You need to know C/C++ already to be able to hack the core of FlightGear. The Hackathon is not a good place to learn C++ for the first time. However, there are lot of interesting projects using Python, Nasal etc.

'''Q''': I have got a great idea for the Hackathon. What do I do? 
'''A''': Great! Create a wiki page describing it to enthuse other people and collect comments (see [[#Ideation]] section above), and post a link to the Ideation section above so everyone can see it.

[[Category:Hackathon Materials]]
[[Category:Hackathons]]

Autopush

2023-06-25T15:51:42Z

Nia: /* Source code */

'''Autopush''' aims to develop a generic pushback for [[JSBSim]] and [[YASim]] aircraft, with the following characteristics:

# Do the pushback procedure automatically.
# Scale to different aircraft with minimum changes to their logic.
# Use no computer resources in flight.

== Implementing Autopush ==
See <code>[https://gitea.merspieler.tk/fly/autopush/src/branch/master/README.TXT README.TXT]</code> in the development repository.

== Implementations ==
September 2021 the following aircraft have Autopush implemented:

{| class="wikitable sortable"
! --aircraft= || Aircraft || Hangar
|-
| Tu-144D || [[Tupolev Tu-144D]] || [https://gitlab.com/femboywings-fgfs femboywings]
|-
| A320-family|| [[A320-family|Airbus A320]] || [[FGAddon]]
|-
| IDG-A33X || [[IDG-A33X|Airbus A330]] || Octal450
|-
| MD-11 || [[MD-11|McDonnell Douglas MD-11]] || Octal450
|-
| MD-80 || [[MD-80|McDonnell Douglas MD-80]] || Octal450
|-
| B777 || [[Boeing 777]] || [[FGAddon]]
|-
| 747-400 || [[Boeing 747-400]] || [[FGAddon]]
|-
| E-Jet family || Embraer E-Jet || [https://github.com/YV3399/E-jet-family-YV Github]
|}

== Related content ==
=== Wiki articles ===
* [[Howto:Implement pushback]] - A different system
* [[Pushback]] - A drivable model that unfortunately can not do pushback

=== Forum topics ===
* {{forum link|title=Autopush help|t=37144}} (March 2020)
* {{forum link|title=Autopush: Automated pushback|t=34630}} (August 2018-July 2019) - Development topic

=== Source code ===
* https://gitea.merspieler.tk/fly/autopush/src/branch/master/README.TXT

[[Category:Aircraft enhancement]]

Autopush

2023-06-25T15:50:47Z

Nia: /* Implementing Autopush */

'''Autopush''' aims to develop a generic pushback for [[JSBSim]] and [[YASim]] aircraft, with the following characteristics:

# Do the pushback procedure automatically.
# Scale to different aircraft with minimum changes to their logic.
# Use no computer resources in flight.

== Implementing Autopush ==
See <code>[https://gitea.merspieler.tk/fly/autopush/src/branch/master/README.TXT README.TXT]</code> in the development repository.

== Implementations ==
September 2021 the following aircraft have Autopush implemented:

{| class="wikitable sortable"
! --aircraft= || Aircraft || Hangar
|-
| Tu-144D || [[Tupolev Tu-144D]] || [https://gitlab.com/femboywings-fgfs femboywings]
|-
| A320-family|| [[A320-family|Airbus A320]] || [[FGAddon]]
|-
| IDG-A33X || [[IDG-A33X|Airbus A330]] || Octal450
|-
| MD-11 || [[MD-11|McDonnell Douglas MD-11]] || Octal450
|-
| MD-80 || [[MD-80|McDonnell Douglas MD-80]] || Octal450
|-
| B777 || [[Boeing 777]] || [[FGAddon]]
|-
| 747-400 || [[Boeing 747-400]] || [[FGAddon]]
|-
| E-Jet family || Embraer E-Jet || [https://github.com/YV3399/E-jet-family-YV Github]
|}

== Related content ==
=== Wiki articles ===
* [[Howto:Implement pushback]] - A different system
* [[Pushback]] - A drivable model that unfortunately can not do pushback

=== Forum topics ===
* {{forum link|title=Autopush help|t=37144}} (March 2020)
* {{forum link|title=Autopush: Automated pushback|t=34630}} (August 2018-July 2019) - Development topic

=== Source code ===
* {{gitlab source|user=mdanil|repo=flightgear-autopush}}

[[Category:Aircraft enhancement]]

WS3.0 Subprojects

2023-03-19T21:09:41Z

Nia: Fix typo

{{WS30 Navbar}}

This page is intended to collect various WS3.0 sub-projects: Smaller self-contained projects that can be worked on independently to improve WS3.0

The aim is to encourage more people to contribute to the WS3.0 effort.

They are split by knowledge required.

== C++ ==

=== Smoother Line Features ===
Line features (roads, railways, rivers) are generated from OSM data at runtime, with different widths of roads generated for different LOD levels.

Currently the algorithm that generates the roads creates places a quad for each segment such that the width of the road is horizontal, a metre or so higher than the terrain.

There are a couple of improvements that could be made:

* Sharp corners look a bit rubbish because the end of a segment is always a normal to the segment length. This means that on sharp bends the road narrows and looks a bit rubbish. An improvement would be to calculate the width and angle based on both the last segment and the next one.
* At present no bridges are handled. using osm2city code bridges should be implemented.
* The roads currently following the elevation meshes exactly. Real roads have embankments and cuttings to smooth out elevation changes. Cuttings are probably too difficult because they would require modifying the elevation mesh, but embankments would be possible.
* We currently remove some points at the end of the tile where the intersection algorithm can produce many points close together. This currently creates some odd roads at the edges of tiles which could be improved.
[[File:Fgfs-20230306215131.jpg|thumb|Mountain pass new Srinagar, Jammu and Kashmir.]]

=== Water Bodies ===
We currently have a good solution for coastlines to remove the blockiness of the raster coastlines by using OSM line data and a separate high resolution raster.

We have a script to collect similar data for water bodies (lakes etc.), A scanline algorithm could be used with this data to fill a polygon in the same raster, creating more detailed water bodies.

=== Groundcache Lookup ===
In WS2.0 it is possible to get material information for a point in the scenery. This needs implementing for WS3.0, which will require a lookup into the landclass texture. Ideally this information would also be exposed in fgelev (or as a proxy as for WS20 whether it is a solid material or water).

=== Neighbouring Pixel ===
The higher level fragment shaders can blend the edges of textures. Currently this is done on the shader side. This could instead be done at scenery loading when the texture is generated in VPBTechnique.cxx by using some of the unused channels in the texture. There will be significant performance gains to be had by doing so

=== Terrasync for WS3.0 ===
Currently we do not have the ability to distribute WS3.0 with Terrasync. We need both a distribution mechanism and probably some minor changes to Terrasync/FG to support this.

The base unit for distrbution will be a 1x1 degree tile, tarballed and compressed - e.g. .tgz. This is already used for other data.

Speak to merspieler about this, as she has offered to assist with hosting.

== GIS ==

=== More Accurate Coastlines ===
We currently have a good solution for coastlines to remove the blockiness of the raster coastlines by using OSM line data and a separate high resolution raster.

However if the main landclass raster isn't well aligned with this data it can cause graphics artifacts.

I (Stuart) solve this for the Martinique scenery on the final raster by:

- Deleting all the water so that it was NODATA

- Filling the NODATA with surround values

- Using the OSM coastline as a mask on the raster to delete the data that should be water

- filling the NODATA with water.

This works OK, but getting the OSM data as a multipolygon was a manual process. Having a script to do this would be good. Being able to do this all in vector data ahead of rasterization would be even better

=== Scripted Toolchain ===
Developing standard scripted toolchain to convert from NLCD and/or CORINE to high quality 10m or 5m raster with the correct landclasses.

== Python ==
fgmeta/ws30 contains a number of python scripts for generating scenery that could be improved

=== Script Efficiency - line features ===
At present the script to generate line features (genroads.py) simply dumps all the OSM data directly to text file and we generate line features using every point. This has a theoretical resolution of 1cm, which is probably higher than we need.

We could save storage and processing by :

* Rounding the lat/lon pairs to ~10cm resolution. This would save about ~10% disk space for the roads uncompressed.
* Skipping nodes in segments that are too close together.

== Textures ==

=== WS3.0 Materials ===
Currently WS3.0 uses the WS2.0 textures. Many of these have line features like roads baked into them. As WS3.0 include OSM roads down to ~ 2m width, the roads on the textures are now redundant. A new set of textures without roads would look a lot better (that is for textures in urban areas and certain agriculture textures).

== GUI ==

=== Quality Settings ===
[[file:Canvas_TabWidget_example.png|thumb]]
Currently WS3.0 has a lot of configuration properties. These should be consolidated into a dialog that's easier to use.
Stuart agreed that the Canvas UI could be a good option to use for this new UI dialog. <ref>https://sourceforge.net/p/flightgear/mailman/message/37785426/</ref>
We also have people volunteering to help with a Canvas based UI dialog. <ref>https://sourceforge.net/p/flightgear/mailman/message/37785343/</ref>

This new UI dialog could probably be based on the new [[Canvas_news#Tab_Widget|Canvas tab widget]] to neatly organize related settings into pages.

We could even use the [[CompositeViewer support]] and [[Compositor]] integration to provide actual previews for different settings in-sim, as suggested and discussed previously on the devel-list.

[[File:Cvcanvas-777.jpeg|thumb]]

There already is an [[Hackathon_Proposal:_CompositeViewer_and_Canvas|experimental canvas element]] that uses a compositor instance to render a view to a Canvas, work that Jules and Fernando came up with originally. Fernando in particular mentioned that these Compositor instances could use their own effects/shaders, which would make them ideally-suited for previewing different sorts of rendering settings in-sim.

{{Appendix}}

World Scenery 3.0 roadmap

2022-05-29T22:59:23Z

Nia:

{{Scenery Core Development}}
{{See also|TerraGear roadmap}}
{{Project
|name = World Scenery 3.0
|description = New world-wide scenery
|start-date = 2019-Sep
|current-status = Active <ref>https://sourceforge.net/p/flightgear/mailman/message/37074319/</ref>
|developers = Scott Giese Richard Harrison Stuart Buchanan

|motivation-body =
{{Main article|Virtual Planet Builder}}
{{FGCquote
|Virtual Planet Builder (VPB) is OSG's terrain-database-building tool.
It loads GIS elevation data for a
region, combines it with imagery and produces a spatially-balanced
quadtree tiled database that can be navigated simply by loading the
top-level file. All of the LOD Ranges are pre-configured and the
DatabasePager automatically loads and unloads different segments of
terrain without any supporting userspace code required. VPB can build
terrain models ranging from a small area to the entire planet. These
databases can be fluidly navigated at 60fps from outer space down to
ground level with no interruptions. The terrain models are built of
regular grid arrays with optional edge-skirts to conceal any cracks
caused by adjacent LOD differences. 
|{{cite web |url=http://alphapixel.com/wp-content/uploads/2015/04/OpenSceneGraph-OSG-Virtual-Planet-Builder-VPB-OSGDEM.pdf
|title=<nowiki>OpenScenGraph's Virtual Planet Builder/OSGDEM</nowiki>
|publisher=<nowiki>AlphaPixel, LLC</nowiki>
}}
}}

|objective-body =

[[File:Edinburgh rendering using WS3.0.jpg|thumb|Initial rendering of Edinburgh scenery using a raster landclass and texture lookup for city, water and grass]]
[[File:WS3.0 terrain with WS2.0 EGPH.jpg|thumb|Screenshot showing a WS2.0 airport .btg file rendered with WS3.0 terrain]]
[[File:EGPH roads.jpg|thumb|WS3.0 Edinburgh airport with runtime-generated roads from OSM data]]
[[File:WS30 - West Lothian.png|thumb|WS30 view of West Lothian, with 25m resolution landclass data, vegetation, osm2city buildings, and OSM-based roads and rivers.]]
[[File:WS30 street lighting.jpg|thumb|Edinburgh at night, with osm2city buildings, OSM-base roads, including whether they are lit or not. Note the road in the foreground which is lit near the buildings and unlit in the countryside.]]
[[File:Fgfs-20220528191253.png|thumb|WS30 using OSM data to define the coastline. This shows a view near Oban in Scotland looking South. The coastline is applied as a high resolution overlay texture that is generated at runtime from OSM data and mixed with the landclass texture by the ws30 shader.]]

Produce high-quality scenery using the best-known practices.

TerraGear becomes obsolete in favor of VPB.

* '''OpenGL 3.3 Core Profile''': WS3.0 will require us to eliminate the usage of the fixed-function pipeline. 
* '''Shader-based Rendering''': All of the terrain renderings will be done via GLSL shaders. 
* '''OSG Core''': OpenSceneGraph will require targeting of the OpenGL Core Profile.

WS3.0 will continue to cooperate with osm2city.

Easy upgrade: Initially the plan was that airport layouts will be generated in real-time. Apt.dat will continue to be the primary source for airport layouts and that airports will be draped over the terrain. This would eliminate the need to cut airport layouts into the underlying terrain.
Due to difficulties with this approach, it has been decided, that we keep using the WS2.0 airports for now. Work has been done to automatically update the airports from the X-Plane gateway which can be done automatically now. Only thing which remains for this to go into production use is to pack everything into a container.
The apt.dat file gets update with this as well. Here it remains for the navdb parser to understand the 8.33kHz frequencies.

WS3.0 also offers the opportunity for well performing ortho scenery with acceptable memory impact. merspieler has acquired GPL compatible sources so we could theoretically have a demo area with ortho scenery in the first WS3.0 release. It adds significant storage requirement tho (~14.7GB per 1x1 degrees tile). There hasn't been a decision made yet, on how to proceed on this.

|background-body =
=== Data Sources ===

:;SRTMGL3.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL3.003/
:;SRTMGL1.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL1.003/
:;Global Land Cover:: https://lcviewer.vito.be/
:;Natural Earth:: https://www.naturalearthdata.com/
:;OpenStreetMap :: https://www.openstreetmap.org (See https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/ genroads.py, gencoastline.py, genwater.py for details)

|status-body =

As of 11/2021, WS30 is available on "next", and on the [https://download.flightgear.org/builds/nightly/ nightly builds].

Scenery is available for Scotland, but must be downloaded directly (https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=sharing). You need to add the downloaded and then extracted folder as additional scenery folder.

WS30 can be enabled from the Rendering Options menu, with fine-tuning from the LoD menu. Alternatively you can set --prop:/scenery/use-vpb=true to enable it as command line option.

Airports are currently in the old WS2 format - including airport keep terrain. The WS30 terrain goes under the airport so it is not visible.

Roads are implemented. Lights on roads are implemented - to see, set time to night. WiP rendering.

Vegetation is available - initial version.

While large water bodies are defined in the landclass texture, rivers are draped on top from OSM data. Coastlines are taken from OSM by are applied as a higher resolution overlay texture to reduce the tiling effect.

Scenery generation workflow is at an advanced stage. It's fast to build. Scott was able to do UK in a matter of hours [https://sourceforge.net/p/flightgear/mailman/message/37259618/]. People interested in generating scenery for the World Build, or getting their landclass or elevation work on [[Suggested custom scenery|custom scenery]] in, should start learning the tools and process. The exact VPB settings and scenery file format may change several times before the final build. But the process of getting work in to shouldn't change much for scenery creators. See the [[Virtual Planet Builder]] page for instructions.

====Scenery generation tool availability ====
* [[VPB]]: '''Linux:''' build from source, docker image available. '''Windows and Mac:''' build from source, no binaries yet, needs NVTT binaries - see "[[Mailing lists|fg-devel]]" mailing list to assist.
* [[QGIS]]: Not needed when experimenting with terrain generation using lower res landclass rasters provided by CORINE. '''Linux:''' build from source, binary packages[https://qgis.org/en/site/forusers/download.html], official docker release available: https://hub.docker.com/r/qgis/qgis but Fahim was not sure easy the GUI is to use [https://sourceforge.net/p/flightgear/mailman/message/37381800/]. '''Windows, Mac:''' official QGIS binary releases [https://qgis.org/en/site/forusers/download.html].

===LoD settings===
Go to ''View > Adjust LoD > World Scenery 3.0 section'' (Nov 2021).
* 7 LoD levels - most detailed is 6, shown at closest range. Least detailed is 0, shown at long range. LoD 0 tiles with Scotland scenery are 1x1 degree, or approx 111 km x 111 km at the equator.
* Scenery is divided into chunks called tiles. As view distance increases, tiles with a LoD level are replaced by tiles with the next lowest LoD level. e.g. Four LoD 6 tiles are replaced by one LoD 5 tile. Four LoD 5 tiles are replaced by one LoD 4 tile. As view gets closer the reverse happens. One LoD 2 tile is replaced by four LoD 3 tiles.
* Detail range - The LoD level below which each type of feature is not visible. e.g. setting vegetation to LoD 3 means vegetation is shown for LoD 3/4/5/6 and not shown for tiles with LoD 0/1/2.
* Minimum line feature width (line features are things like roads or rivers) - for every LoD level, the width in meters below which a line feature is not shown. e.g. setting LoD level four to 30 meters means rivers or roads that are narrower than 30 meters are not shown for level four tiles. The minimum widths should stay the same or decrease when going down a LoD level.
* Minimum area feature width (area features are things like lakes) - similar to minimum line feature width, but for area in square meters. Setting LoD 3 to 100 square meters means lakes of size 99 square meters or 40 square meters will not show for LoD level 3 tiles.

Proof of Concept {{progressbar|100}}
* VPB {{done}}
* osgOcean {{done}}
* osgVegetation {{done}}
* Generate terrain for Hawaii {{done}}
* Hack Hawaii VPB into FG {{done}}
 

OSG {{progressbar|70}}
* Core Profile: {{done}}
* GLVND Support: {{done}}
* glTF Plugin Support: {{ongoing}}
 

{{gallery
| title = Standard-Fidelity
| align = right
| N00-N10-LC100m-SRTMGL3.png | N00-N60 lat
| Africa-LC100m-SRTMGL3.png | Africa Land Coverage
| Africa-Natural.png | Natural Earth
| Ocean-N00-N90.png | Ocean Fill
}}
=== Standard-Fidelity - 90m SRTMGL3 - 100m Global Land Cover ===

=== Northern Hemisphere: 152.3 GB ===
=== Southern Hemisphere: 57.4 GB ===

Virtual Planet Builder {{progressbar|70}}
* Procure Demographic Data: SRTMGL3.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Ocean {{done}}
** Northern: {{progressbar|100}}
** Southern: {{progressbar|100}}
 

=== High-Fidelity - 30m SRTMGL1 - Best Available Land Cover ===

Virtual Planet Builder {{progressbar|30}}
* Procure Demographic Data: SRTMGL1.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
 

|news-body=
The northern hemisphere, up to N60, has been completed. The southern hemisphere, above S56, has been completed.
SRTM data was not captured above N60 and below S56, so alternative data sources need to be procured.

Stuart has made good progress with the procedure needed to convert apt.dat into an airport object. Our goal is to utilize this to project/drape the airport layout over the terrain. This will enable localized edits of airports without requiring us to generate another world scenery build.

Oceans are complete.
}}

{{gallery
| title = Standard-Fidelity Gallery
| align = center
| Terrain-Mesh.jpg | WS3 Terrain Mesh
| S10-N60-LC100m-SRTMGL3.png | Asia/India
| N00-N10-LC100m-SRTMGL3.png | Europe
| N00-N40-LC100m-SRTMGL3.png | USA
| Africa-LC100m-SRTMGL3.png | Land Coverage
| Africa-Natural.png | Natural Earth
| Africa-Natural2.png | Natural Earth
}}

For the experimental runtime generated mesh/landclassing engine - which may become WS3.0 - see [[Experimental terrain engine]].

[[Category:Development projects‎]]
[[Category:Scenery]]

World Scenery 3.0 roadmap

2022-05-29T22:46:32Z

Nia:

{{Scenery Core Development}}
{{See also|TerraGear roadmap}}
{{Project
|name = World Scenery 3.0
|description = New world-wide scenery
|start-date = 2019-Sep
|current-status = Active <ref>https://sourceforge.net/p/flightgear/mailman/message/37074319/</ref>
|developers = Scott Giese Richard Harrison Stuart Buchanan

|motivation-body =
{{Main article|Virtual Planet Builder}}
{{FGCquote
|Virtual Planet Builder (VPB) is OSG's terrain-database-building tool.
It loads GIS elevation data for a
region, combines it with imagery and produces a spatially-balanced
quadtree tiled database that can be navigated simply by loading the
top-level file. All of the LOD Ranges are pre-configured and the
DatabasePager automatically loads and unloads different segments of
terrain without any supporting userspace code required. VPB can build
terrain models ranging from a small area to the entire planet. These
databases can be fluidly navigated at 60fps from outer space down to
ground level with no interruptions. The terrain models are built of
regular grid arrays with optional edge-skirts to conceal any cracks
caused by adjacent LOD differences. 
|{{cite web |url=http://alphapixel.com/wp-content/uploads/2015/04/OpenSceneGraph-OSG-Virtual-Planet-Builder-VPB-OSGDEM.pdf
|title=<nowiki>OpenScenGraph's Virtual Planet Builder/OSGDEM</nowiki>
|publisher=<nowiki>AlphaPixel, LLC</nowiki>
}}
}}

|objective-body =

[[File:Edinburgh rendering using WS3.0.jpg|thumb|Initial rendering of Edinburgh scenery using a raster landclass and texture lookup for city, water and grass]]
[[File:WS3.0 terrain with WS2.0 EGPH.jpg|thumb|Screenshot showing a WS2.0 airport .btg file rendered with WS3.0 terrain]]
[[File:EGPH roads.jpg|thumb|WS3.0 Edinburgh airport with runtime-generated roads from OSM data]]
[[File:WS30 - West Lothian.png|thumb|WS30 view of West Lothian, with 25m resolution landclass data, vegetation, osm2city buildings, and OSM-based roads and rivers.]]
[[File:WS30 street lighting.jpg|thumb|Edinburgh at night, with osm2city buildings, OSM-base roads, including whether they are lit or not. Note the road in the foreground which is lit near the buildings and unlit in the countryside.]]
[[File:Fgfs-20220528191253.png|thumb|WS30 using OSM data to define the coastline. This shows a view near Oban in Scotland looking South. The coastline is applied as a high resolution overlay texture that is generated at runtime from OSM data and mixed with the landclass texture by the ws30 shader.]]

Produce high-quality scenery using the best-known practices.

TerraGear becomes obsolete in favor of VPB.

* '''OpenGL 3.3 Core Profile''': WS3.0 will require us to eliminate the usage of the fixed-function pipeline. 
* '''Shader-based Rendering''': All of the terrain renderings will be done via GLSL shaders. 
* '''OSG Core''': OpenSceneGraph will require targeting of the OpenGL Core Profile.

WS3.0 will continue to cooperate with osm2city.

Easy upgrade: Initially the plan was that airport layouts will be generated in real-time. Apt.dat will continue to be the primary source for airport layouts and that airports will be draped over the terrain. This would eliminate the need to cut airport layouts into the underlying terrain.
Due to difficulties with this approach, it has been decided, that we keep using the WS2.0 airports for now. Work has been done to automatically update the airports from the X-Plane gateway which can be done automatically now. Only thing which remains for this to go into production use is to pack everything into a container.
The apt.dat file gets update with this as well. Here it remains for the navdb parser to understand the 8.33kHz frequencies.

|background-body =
=== Data Sources ===

:;SRTMGL3.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL3.003/
:;SRTMGL1.003:: https://e4ftl01.cr.usgs.gov/MEASURES/SRTMGL1.003/
:;Global Land Cover:: https://lcviewer.vito.be/
:;Natural Earth:: https://www.naturalearthdata.com/
:;OpenStreetMap :: https://www.openstreetmap.org (See https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/ genroads.py, gencoastline.py, genwater.py for details)

|status-body =

As of 11/2021, WS30 is available on "next", and on the [https://download.flightgear.org/builds/nightly/ nightly builds].

Scenery is available for Scotland, but must be downloaded directly (https://drive.google.com/file/d/1tGXSI8RwQxFL0_AFhXaFRVA6go-u7YBW/view?usp=sharing). You need to add the downloaded and then extracted folder as additional scenery folder.

WS30 can be enabled from the Rendering Options menu, with fine-tuning from the LoD menu. Alternatively you can set --prop:/scenery/use-vpb=true to enable it as command line option.

Airports are currently in the old WS2 format - including airport keep terrain. The WS30 terrain goes under the airport so it is not visible.

Roads are implemented. Lights on roads are implemented - to see, set time to night. WiP rendering.

Vegetation is available - initial version.

While large water bodies are defined in the landclass texture, rivers are draped on top from OSM data. Coastlines are taken from OSM by are applied as a higher resolution overlay texture to reduce the tiling effect.

Scenery generation workflow is at an advanced stage. It's fast to build. Scott was able to do UK in a matter of hours [https://sourceforge.net/p/flightgear/mailman/message/37259618/]. People interested in generating scenery for the World Build, or getting their landclass or elevation work on [[Suggested custom scenery|custom scenery]] in, should start learning the tools and process. The exact VPB settings and scenery file format may change several times before the final build. But the process of getting work in to shouldn't change much for scenery creators. See the [[Virtual Planet Builder]] page for instructions.

====Scenery generation tool availability ====
* [[VPB]]: '''Linux:''' build from source, docker image available. '''Windows and Mac:''' build from source, no binaries yet, needs NVTT binaries - see "[[Mailing lists|fg-devel]]" mailing list to assist.
* [[QGIS]]: Not needed when experimenting with terrain generation using lower res landclass rasters provided by CORINE. '''Linux:''' build from source, binary packages[https://qgis.org/en/site/forusers/download.html], official docker release available: https://hub.docker.com/r/qgis/qgis but Fahim was not sure easy the GUI is to use [https://sourceforge.net/p/flightgear/mailman/message/37381800/]. '''Windows, Mac:''' official QGIS binary releases [https://qgis.org/en/site/forusers/download.html].

===LoD settings===
Go to ''View > Adjust LoD > World Scenery 3.0 section'' (Nov 2021).
* 7 LoD levels - most detailed is 6, shown at closest range. Least detailed is 0, shown at long range. LoD 0 tiles with Scotland scenery are 1x1 degree, or approx 111 km x 111 km at the equator.
* Scenery is divided into chunks called tiles. As view distance increases, tiles with a LoD level are replaced by tiles with the next lowest LoD level. e.g. Four LoD 6 tiles are replaced by one LoD 5 tile. Four LoD 5 tiles are replaced by one LoD 4 tile. As view gets closer the reverse happens. One LoD 2 tile is replaced by four LoD 3 tiles.
* Detail range - The LoD level below which each type of feature is not visible. e.g. setting vegetation to LoD 3 means vegetation is shown for LoD 3/4/5/6 and not shown for tiles with LoD 0/1/2.
* Minimum line feature width (line features are things like roads or rivers) - for every LoD level, the width in meters below which a line feature is not shown. e.g. setting LoD level four to 30 meters means rivers or roads that are narrower than 30 meters are not shown for level four tiles. The minimum widths should stay the same or decrease when going down a LoD level.
* Minimum area feature width (area features are things like lakes) - similar to minimum line feature width, but for area in square meters. Setting LoD 3 to 100 square meters means lakes of size 99 square meters or 40 square meters will not show for LoD level 3 tiles.

Proof of Concept {{progressbar|100}}
* VPB {{done}}
* osgOcean {{done}}
* osgVegetation {{done}}
* Generate terrain for Hawaii {{done}}
* Hack Hawaii VPB into FG {{done}}
 

OSG {{progressbar|70}}
* Core Profile: {{done}}
* GLVND Support: {{done}}
* glTF Plugin Support: {{ongoing}}
 

{{gallery
| title = Standard-Fidelity
| align = right
| N00-N10-LC100m-SRTMGL3.png | N00-N60 lat
| Africa-LC100m-SRTMGL3.png | Africa Land Coverage
| Africa-Natural.png | Natural Earth
| Ocean-N00-N90.png | Ocean Fill
}}
=== Standard-Fidelity - 90m SRTMGL3 - 100m Global Land Cover ===

=== Northern Hemisphere: 152.3 GB ===
=== Southern Hemisphere: 57.4 GB ===

Virtual Planet Builder {{progressbar|70}}
* Procure Demographic Data: SRTMGL3.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|70}}
* Ocean {{done}}
** Northern: {{progressbar|100}}
** Southern: {{progressbar|100}}
 

=== High-Fidelity - 30m SRTMGL1 - Best Available Land Cover ===

Virtual Planet Builder {{progressbar|30}}
* Procure Demographic Data: SRTMGL1.003 {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
* Process through VPB {{paused}}
** Northern: {{progressbar|70}}
** Southern: {{progressbar|0}}
 

|news-body=
The northern hemisphere, up to N60, has been completed. The southern hemisphere, above S56, has been completed.
SRTM data was not captured above N60 and below S56, so alternative data sources need to be procured.

Stuart has made good progress with the procedure needed to convert apt.dat into an airport object. Our goal is to utilize this to project/drape the airport layout over the terrain. This will enable localized edits of airports without requiring us to generate another world scenery build.

Oceans are complete.
}}

{{gallery
| title = Standard-Fidelity Gallery
| align = center
| Terrain-Mesh.jpg | WS3 Terrain Mesh
| S10-N60-LC100m-SRTMGL3.png | Asia/India
| N00-N10-LC100m-SRTMGL3.png | Europe
| N00-N40-LC100m-SRTMGL3.png | USA
| Africa-LC100m-SRTMGL3.png | Land Coverage
| Africa-Natural.png | Natural Earth
| Africa-Natural2.png | Natural Earth
}}

For the experimental runtime generated mesh/landclassing engine - which may become WS3.0 - see [[Experimental terrain engine]].

[[Category:Development projects‎]]
[[Category:Scenery]]

FlightGear Newsletter February 2022

2022-02-28T09:25:41Z

Nia: /* Scenery corner */ Osm2city next worldbuild

De/Piper PA34-200T Seneca II/info

2022-01-12T14:14:55Z

Nia: Created page with "<includeonly>{{infobox aircraft | name = Piper PA34-200T Seneca II | hangar = fgaddon | aircraft = SenecaII | image = Piper SenecaII.jpg | ima..."

<includeonly>{{infobox aircraft
| name = Piper PA34-200T Seneca II
| hangar = fgaddon
| aircraft = SenecaII
| image = Piper SenecaII.jpg
| image2 = SenecaII cockpit.jpg
| alt2 = {{LangSwitch
| en = The 3D [[cockpit]]
| fr = Le [[cockpit]] 3D
}}
| type = Civil aircraft/Civil utility aircraft
| propulsion = Twin-engine aircraft
| manufacturer = Piper
| authors = Torsten Dreyer
| fdm = JSBSim
| fgname = SenecaII
| status-fdm = 5
| status-systems = 5
| status-cockpit = 4
| status-model = 3
| ready = tutorials
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Piper PA34-200T Seneca II]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Virtual Reality

2021-12-17T23:31:50Z

Nia: /* Testing */

{{Experimental|disclaimer=VR support in flightgear still comes with a number of caveats.}}

{{infobox subsystem
|image = VR screenshot c182s.png
|name = Virtual Reality
|started = 07/2021
|description = Virtual Reality support using osgXR / OpenXR
|status = Active
|developers = James Hogan <ref>https://sourceforge.net/u/amalon/profile/</ref>
|changelog = https://sourceforge.net/u/amalon/profile/feed.rss
}}

The '''Virtual Reality''' project aims to add immersive VR support to FlightGear. This is done using the OpenXR<ref>{{cite web |url=https://www.khronos.org/OpenXR/ |title=OpenXR Overview |publisher=The Khronos Group Inc}}</ref> API, via an external library called osgXR<ref name="github-osgXR">{{github source |user=amalon |repo=osgXR |full=1}}</ref> for handling OpenXR and OpenSceneGraph specifics, which is being developed in parallel.

== Background ==

A previous attempt to support some form of VR is described in [[OculusImplementation]].

The portable OpenXR API now seems to be getting widespread adoption, which will allow FlightGear to support a variety of VR devices across multiple platforms.

== Source code ==

* osgXR source can be found on github.<ref name="github-osgXR"/>
** On ArchLinux, you can install the osgxr AUR package <ref>https://aur.archlinux.org/packages/osgxr/</ref> to get the version needed by FlightGear's next branches.
* Some VR code can now be found in FlightGear's next branches (see below for details).
** On ArchLinux, if you're using the -git AUR packages, i.e. flightgear-git, simgear-git, flightgear-data-git, as long as flightgear-git was built from scratch after installing osgxr it should use it.
* More FlightGear changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased). A mirror is available on github for issue tracking<ref>{{github source |user=amalon |repo=flightgear-vr}}</ref>.
* More SimGear changes can be found in James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).
* More FGData changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).

== Status ==
'''Last updated: 3/12/2021'''

Highly experimental, partially in next, partly out of tree. Development in progress.

Working in next branch:
* Enable/disable at startup via --enable-vr / --disable-vr command line options or /sim/vr/enabled property.
* Displaying stereo images on the HMD.
* Motion tracking updates HMD views, but doesn't move main camera.
* Configurable VR mirror (see View->VR Settings) shown in default camera view (blank, left, right, side-by-side left & right).
* Visibility mask support.

Working in osgxr/osgxr_clean branch:
* Improved osgXR detection and VR enable/disable with CMake.
* Controller support for flight (helicopter collective in left hand, helicopter cyclic in right).
* Controller pointing support with some mouse emulation.

Current priorities:
* Continue to polish controller flight support, add haptics etc.
* Get started on other controller interaction and controller rendering.

=== Known issues ===

* osgXR currently only supports Linux/X11. Adding alternative graphics bindings should be fairly simple, but isn't a priority for me. Contributions welcome.
* Splash screen is rendered directly onto the left eye viewport which isn't very pleasant in VR.
* Performance could be better so crank down the graphics if frame rate is low.
* If it doesn't close cleanly it may be due to a SteamVR bug<ref name="github-SteamVR-422"/>, but a ctrl+c / SIGINT on the command line should close it.
* Shadows are broken:
** When shadows are enabled, the FlightGear window doesn't appear to refresh even though buffers are swapped, but VR output works.
** Sun position is fixed relative to head, presumably because shadow maps are rendered based on master camera, but osgXR only moves slave cams.
* Spotlights (taxi/landing lights) are relative to camera in default mode
** Affects default / scene view mode (<code>--prop:/sim/vr/mode=AUTOMATIC</code>), as stereo callbacks position cameras
** Doesn't affect slave cameras mode (<code>--prop:/sim/vr/mode=SLAVE_CAMERAS</code>), as slave cameras are positioned correctly

=== Testing ===

VR has been tested with the following hardware & software configurations:
* HTC Vive, SteamVR, Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 21:43, 27 August 2021 (UTC)
* Oculus Quest 2, SteamVR (ALVR), Linux/X11 (Fedora 34) -- [[User:vezza|vezza]] ([[User talk:vezza|talk]]) 16:30 27 August 2021 (UTC)
* HTC Vive, Monado (to window), Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
* Monado dummy driver, Linux/X11 (ArchLinux), Intel mesa -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
** /sim/vr/depth-info=false
* Monado Dummy HMD, Linux/X11 (Debian), AMD Mesa Drivers [[User:merspieler|merspieler]] ([[User talk:merspieler|talk]]) 23:27, 17 December 2021 (UTC)
** Applying the following patch: <syntaxhighlight lang="diff">
diff --git a/src/XRState.cpp b/src/XRState.cpp
index ce09bcd..5bcbbca 100644
--- a/src/XRState.cpp
+++ b/src/XRState.cpp
@@ -1017,7 +1017,7 @@ XRState::UpResult XRState::upSession()
unsigned int thisDepthBits = 0;
switch (format)
{
- case GL_RGBA16:
+ case GL_RGB10_A2:
// FIXME This one will do for now...
if (!chosenSwapchainFormat)
chosenSwapchainFormat = format;
</syntaxhighlight>

If you've got VR working, feel free to add your configuration above.

The following testing is desired:
* SteamVR, Linux, AMD graphics:
** Test that motion smoothing works (its unsupported on NVidia)
** moving head side to side should reproject using depth buffer
** try suspending fgfs with Ctrl+Z in terminal (resume with fg) to force reprojection
* Monado, Linux:
** May be awkward to test as it crashes in latest NVidia proprietary drivers<ref>https://gitlab.freedesktop.org/monado/monado/-/issues/122</ref>.
*** There's now a workaround mentioned in that ticket that allows for basic testing
** Use osgXR <code>master</code> branch for monado workaround, or <code>--disable-vr</code> and enable VR with GUI

Issues can be reported:
* On the flightgear-devel [[Mailing lists|mailing list]]
* To the {{tickets|FlightGear bug tracker}} if the issue is reproducible on the next branch
* To the [{{github issues url |user=amalon |repo=flightgear-vr}} flightgear-vr issue tracker]
* To the [{{github issues url |user=amalon |repo=osgXR}} osgXR issue tracker] if it is known to be a non-flightgear specific bug in osgXR

But please be aware of the known caveats mentioned above, and the roadmap below.

== Performance ==

Here are some pointers to get the best VR experience.
* Ensure your runtime supports asynchronous reprojection, which may alleviate the nausea induced by lower frame rates.
** On Linux / SteamVR / NVidia proprietary driver, ensure you have at least driver version 270.
* If your frame rate is being capped at the refresh rate of your desktop monitor, try disabling VSync in both flightgear settings and your driver settings
** On Linux / NVidia proprietary driver, its found in OpenGL settings in nvidia-settings.
* If FlightGear is getting throttled by SteamVR (to try and ensure a consistent, if slow, frame rate), consider switching to fixed throttling (in per-application video settings) and playing with the sliders. You may prefer no frame rate throttling but a higher predicted frame time.
* Enabling multithreading may get you better performance, e.g. <code>--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext</code>

== Implementation Details ==

=== Concepts ===

==== Interaction Modes ====

Interaction modes are a way of describing (via XML) how a VR controller should look and behave in a particular context. It roughly corresponds to a virtual control you can hold (and let go of), for example:
* When you're holding a helicopter collective control, the pitch angle of the controller should control the collective pitch (and look like a collective in your hand).
* When you're pointing the controller at a GUI or cockpit controls it should pick along a line, rendered in a specific way, and emulate mouse events to those controls (and look like a small laser pointer control or a pointing hand/glove).
* When you're teleporting around, it should pick along a parabolic arc, rendered a specific way, and teleport there when the button is released.
* When you're using the flight recorder it should treat the controller trackpad as a rewind/fast forward (and look like a fancy TV remote or something).

The definition of interaction modes should be generic enough that custom ones can be provided with aircraft, or defined separately and work with any aircraft, but also powerful enough that a complex and intuitive control can be defined with a minimum of Nasal scripting.

== Roadmap ==

=== Development targets ===
* Merge stable & minimally functional code into next ({{Merge-request |project=flightgear |id=253}}, {{Merge-request |project=fgdata |id=238}}) {{done}}
** Bare functionality {{done}}
** Stability {{done}}
* Merge some form of desktop mirroring of VR view ({{Merge-request |project=flightgear |id=260}}, {{Merge-request |project=fgdata |id=241}}) {{done}}
* Merge visibility mask support ({{Merge-request |project=simgear |id=98}}, {{Merge-request |project=flightgear |id=264}}, {{Merge-request |project=fgdata |id=244}}) {{done}}
* Polish {{not done}}
** Make GUI accessible to VR user {{not done}}
** Make splash screen VR friendly {{not done}}
* Functionality {{progressbar|40}}
** Controller flight support {{progressbar|80}}
*** Haptic feedback {{not done}}
** Controller interaction support {{progressbar|40}}
** Walker locomotion / room scale {{not done}}

=== General tasks ===

* Stability {{done}}
** Clean shutdown {{done}}
*** SteamVR for Linux hangs on OpenXR app shutdown<ref name="github-SteamVR-422">{{github issues url|ValveSoftware|SteamVR-for-Linux|number=422}}</ref>.
** Handle OpenXR stopping {{done}}
*** SteamVR for Linux kills running app even if it ends session<ref>{{github issues url|ValveSoftware|SteamVR-for-Linux|number=461}}</ref>.
* Resolve questions around VR mirror switching {{done}}
* Performance {{progressbar|10}}
** Handle shouldRender=false by somehow disabling VR cameras (maybe setting cull mask to 0) {{not done}}
** SceneView mode: Combine culling traversal {{not done}}
** Check why update isn't proceeding in parallel with multithreading {{not done}}
** Use OpenXR visibility mask extension to avoid rendering to invisible fragments {{done}}
* Sound {{progressbar|0}}
** Ensure surround sound is relative to user's head {{not done}}
** Investigate a way to use appropriate OpenAL binaural mode automatically {{not done}}
** Fix: It always seems to select speakers rather than headphones on HTC Vive {{not done}}

=== User facing features ===

* Display {{progressbar|60}}
** Show views on HMD {{done}}
** Configurable mirror on desktop window {{done}}
*** Left, Right, Left & Right {{done}}
*** Composited mirror mode (combine & blend views and allow zooming) {{paused}}
** Geometry shader multi viewport {{not done}}
** OVR_multiview2 with OSG branch {{not done}}
* Motion tracking {{progressbar|50}}
** Follow motion of HMD {{done}}
** Move master camera instead of scene slave cameras (presumably would fix surround sound) {{not done}}
* Settings {{progressbar|20}}
** Mirror settings {{done}}
** Dynamic toggling of VR {{done}}
** Sound settings? {{not done}}
*** Sound reference frame (user's head or room)? {{not done}}
** Advanced VR settings {{not done}}
*** validation layer {{not done}}
*** submit depth information {{done}} but needs testing (SteamVR+Linux+nVidia doesn't do motion smoothing yet)
*** osgXR VR mode {{not done}}
**** Fix slave cameras mode clearing {{not done}}
*** osgXR swapchain mode {{not done}}
* Platform support {{progressbar|30}}
** Linux/X11/OpenGL graphics bindings {{done}}
** Windows/OpenGL graphics bindings {{not done}}
** Windows Mixed Reality render via DirectX bindings {{not done}}
** Monado support {{progressbar|10}}
* Splash screen {{progressbar|0}}
** Show splash screen as quad layer for runtime to composite {{not done}} {{priority|2}}
** Cube map/quads background provided by aircraft {{not done}}
* GUI {{progressbar|10}} {{priority|2}}
** Shown over mirror on desktop window {{done}}
** Expose a menubar & GUI, rendered to a quad or cylinder in front of VR user when they activate {{not done}}
** Interact with GUI buttons etc using controllers as lasers {{not done}}
* Controller support {{progressbar|50}}
** Basic action support in osgXR API {{done}}
** Tie osgXR actions into FG's input system {{done}}
** Helicopter flight controls (can use for planes too) {{done}}
** Plane flight controls {{not done}}
** Render controllers {{not done}}
** Hand tracking (robot hand) {{not done}}
** Render skinned hand {{not done}}
** Basic interaction with controls {{progressbar|80}}
** Advanced interaction with animated controls {{not done}}
** Holding axis controls (joystick, yoke, helicopter collective) {{not done}}
** Haptic feedback {{not done}}
* Walker VR locomotion / Room scale {{progressbar|0}}
** Walker follows user {{not done}}
** Parabolic arc teleport {{not done}}
** Snap into seats {{not done}}
** Easy turning around {{not done}}

== References ==
{{Appendix}}

[[Category:Core development projects]]

Virtual Reality

2021-12-17T23:30:59Z

Nia: /* Testing */

{{Experimental|disclaimer=VR support in flightgear still comes with a number of caveats.}}

{{infobox subsystem
|image = VR screenshot c182s.png
|name = Virtual Reality
|started = 07/2021
|description = Virtual Reality support using osgXR / OpenXR
|status = Active
|developers = James Hogan <ref>https://sourceforge.net/u/amalon/profile/</ref>
|changelog = https://sourceforge.net/u/amalon/profile/feed.rss
}}

The '''Virtual Reality''' project aims to add immersive VR support to FlightGear. This is done using the OpenXR<ref>{{cite web |url=https://www.khronos.org/OpenXR/ |title=OpenXR Overview |publisher=The Khronos Group Inc}}</ref> API, via an external library called osgXR<ref name="github-osgXR">{{github source |user=amalon |repo=osgXR |full=1}}</ref> for handling OpenXR and OpenSceneGraph specifics, which is being developed in parallel.

== Background ==

A previous attempt to support some form of VR is described in [[OculusImplementation]].

The portable OpenXR API now seems to be getting widespread adoption, which will allow FlightGear to support a variety of VR devices across multiple platforms.

== Source code ==

* osgXR source can be found on github.<ref name="github-osgXR"/>
** On ArchLinux, you can install the osgxr AUR package <ref>https://aur.archlinux.org/packages/osgxr/</ref> to get the version needed by FlightGear's next branches.
* Some VR code can now be found in FlightGear's next branches (see below for details).
** On ArchLinux, if you're using the -git AUR packages, i.e. flightgear-git, simgear-git, flightgear-data-git, as long as flightgear-git was built from scratch after installing osgxr it should use it.
* More FlightGear changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased). A mirror is available on github for issue tracking<ref>{{github source |user=amalon |repo=flightgear-vr}}</ref>.
* More SimGear changes can be found in James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).
* More FGData changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).

== Status ==
'''Last updated: 3/12/2021'''

Highly experimental, partially in next, partly out of tree. Development in progress.

Working in next branch:
* Enable/disable at startup via --enable-vr / --disable-vr command line options or /sim/vr/enabled property.
* Displaying stereo images on the HMD.
* Motion tracking updates HMD views, but doesn't move main camera.
* Configurable VR mirror (see View->VR Settings) shown in default camera view (blank, left, right, side-by-side left & right).
* Visibility mask support.

Working in osgxr/osgxr_clean branch:
* Improved osgXR detection and VR enable/disable with CMake.
* Controller support for flight (helicopter collective in left hand, helicopter cyclic in right).
* Controller pointing support with some mouse emulation.

Current priorities:
* Continue to polish controller flight support, add haptics etc.
* Get started on other controller interaction and controller rendering.

=== Known issues ===

* osgXR currently only supports Linux/X11. Adding alternative graphics bindings should be fairly simple, but isn't a priority for me. Contributions welcome.
* Splash screen is rendered directly onto the left eye viewport which isn't very pleasant in VR.
* Performance could be better so crank down the graphics if frame rate is low.
* If it doesn't close cleanly it may be due to a SteamVR bug<ref name="github-SteamVR-422"/>, but a ctrl+c / SIGINT on the command line should close it.
* Shadows are broken:
** When shadows are enabled, the FlightGear window doesn't appear to refresh even though buffers are swapped, but VR output works.
** Sun position is fixed relative to head, presumably because shadow maps are rendered based on master camera, but osgXR only moves slave cams.
* Spotlights (taxi/landing lights) are relative to camera in default mode
** Affects default / scene view mode (<code>--prop:/sim/vr/mode=AUTOMATIC</code>), as stereo callbacks position cameras
** Doesn't affect slave cameras mode (<code>--prop:/sim/vr/mode=SLAVE_CAMERAS</code>), as slave cameras are positioned correctly

=== Testing ===

VR has been tested with the following hardware & software configurations:
* HTC Vive, SteamVR, Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 21:43, 27 August 2021 (UTC)
* Oculus Quest 2, SteamVR (ALVR), Linux/X11 (Fedora 34) -- [[User:vezza|vezza]] ([[User talk:vezza|talk]]) 16:30 27 August 2021 (UTC)
* HTC Vive, Monado (to window), Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
* Monado dummy driver, Linux/X11 (ArchLinux), Intel mesa -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
** /sim/vr/depth-info=false
* Monado Dummy HMD, Linux/X11 (Debian), AMD Mesa Drivers [[User:merspieler|merspieler) ([[User talk:merspieler|talk]]) 23:27, 17 December 2021 (UTC)
** Applying the following patch: <syntaxhighlight lang="diff">
diff --git a/src/XRState.cpp b/src/XRState.cpp
index ce09bcd..5bcbbca 100644
--- a/src/XRState.cpp
+++ b/src/XRState.cpp
@@ -1017,7 +1017,7 @@ XRState::UpResult XRState::upSession()
unsigned int thisDepthBits = 0;
switch (format)
{
- case GL_RGBA16:
+ case GL_RGB10_A2:
// FIXME This one will do for now...
if (!chosenSwapchainFormat)
chosenSwapchainFormat = format;
</syntaxhighlight>

If you've got VR working, feel free to add your configuration above.

The following testing is desired:
* SteamVR, Linux, AMD graphics:
** Test that motion smoothing works (its unsupported on NVidia)
** moving head side to side should reproject using depth buffer
** try suspending fgfs with Ctrl+Z in terminal (resume with fg) to force reprojection
* Monado, Linux:
** May be awkward to test as it crashes in latest NVidia proprietary drivers<ref>https://gitlab.freedesktop.org/monado/monado/-/issues/122</ref>.
*** There's now a workaround mentioned in that ticket that allows for basic testing
** Use osgXR <code>master</code> branch for monado workaround, or <code>--disable-vr</code> and enable VR with GUI

Issues can be reported:
* On the flightgear-devel [[Mailing lists|mailing list]]
* To the {{tickets|FlightGear bug tracker}} if the issue is reproducible on the next branch
* To the [{{github issues url |user=amalon |repo=flightgear-vr}} flightgear-vr issue tracker]
* To the [{{github issues url |user=amalon |repo=osgXR}} osgXR issue tracker] if it is known to be a non-flightgear specific bug in osgXR

But please be aware of the known caveats mentioned above, and the roadmap below.

== Performance ==

Here are some pointers to get the best VR experience.
* Ensure your runtime supports asynchronous reprojection, which may alleviate the nausea induced by lower frame rates.
** On Linux / SteamVR / NVidia proprietary driver, ensure you have at least driver version 270.
* If your frame rate is being capped at the refresh rate of your desktop monitor, try disabling VSync in both flightgear settings and your driver settings
** On Linux / NVidia proprietary driver, its found in OpenGL settings in nvidia-settings.
* If FlightGear is getting throttled by SteamVR (to try and ensure a consistent, if slow, frame rate), consider switching to fixed throttling (in per-application video settings) and playing with the sliders. You may prefer no frame rate throttling but a higher predicted frame time.
* Enabling multithreading may get you better performance, e.g. <code>--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext</code>

== Implementation Details ==

=== Concepts ===

==== Interaction Modes ====

Interaction modes are a way of describing (via XML) how a VR controller should look and behave in a particular context. It roughly corresponds to a virtual control you can hold (and let go of), for example:
* When you're holding a helicopter collective control, the pitch angle of the controller should control the collective pitch (and look like a collective in your hand).
* When you're pointing the controller at a GUI or cockpit controls it should pick along a line, rendered in a specific way, and emulate mouse events to those controls (and look like a small laser pointer control or a pointing hand/glove).
* When you're teleporting around, it should pick along a parabolic arc, rendered a specific way, and teleport there when the button is released.
* When you're using the flight recorder it should treat the controller trackpad as a rewind/fast forward (and look like a fancy TV remote or something).

The definition of interaction modes should be generic enough that custom ones can be provided with aircraft, or defined separately and work with any aircraft, but also powerful enough that a complex and intuitive control can be defined with a minimum of Nasal scripting.

== Roadmap ==

=== Development targets ===
* Merge stable & minimally functional code into next ({{Merge-request |project=flightgear |id=253}}, {{Merge-request |project=fgdata |id=238}}) {{done}}
** Bare functionality {{done}}
** Stability {{done}}
* Merge some form of desktop mirroring of VR view ({{Merge-request |project=flightgear |id=260}}, {{Merge-request |project=fgdata |id=241}}) {{done}}
* Merge visibility mask support ({{Merge-request |project=simgear |id=98}}, {{Merge-request |project=flightgear |id=264}}, {{Merge-request |project=fgdata |id=244}}) {{done}}
* Polish {{not done}}
** Make GUI accessible to VR user {{not done}}
** Make splash screen VR friendly {{not done}}
* Functionality {{progressbar|40}}
** Controller flight support {{progressbar|80}}
*** Haptic feedback {{not done}}
** Controller interaction support {{progressbar|40}}
** Walker locomotion / room scale {{not done}}

=== General tasks ===

* Stability {{done}}
** Clean shutdown {{done}}
*** SteamVR for Linux hangs on OpenXR app shutdown<ref name="github-SteamVR-422">{{github issues url|ValveSoftware|SteamVR-for-Linux|number=422}}</ref>.
** Handle OpenXR stopping {{done}}
*** SteamVR for Linux kills running app even if it ends session<ref>{{github issues url|ValveSoftware|SteamVR-for-Linux|number=461}}</ref>.
* Resolve questions around VR mirror switching {{done}}
* Performance {{progressbar|10}}
** Handle shouldRender=false by somehow disabling VR cameras (maybe setting cull mask to 0) {{not done}}
** SceneView mode: Combine culling traversal {{not done}}
** Check why update isn't proceeding in parallel with multithreading {{not done}}
** Use OpenXR visibility mask extension to avoid rendering to invisible fragments {{done}}
* Sound {{progressbar|0}}
** Ensure surround sound is relative to user's head {{not done}}
** Investigate a way to use appropriate OpenAL binaural mode automatically {{not done}}
** Fix: It always seems to select speakers rather than headphones on HTC Vive {{not done}}

=== User facing features ===

* Display {{progressbar|60}}
** Show views on HMD {{done}}
** Configurable mirror on desktop window {{done}}
*** Left, Right, Left & Right {{done}}
*** Composited mirror mode (combine & blend views and allow zooming) {{paused}}
** Geometry shader multi viewport {{not done}}
** OVR_multiview2 with OSG branch {{not done}}
* Motion tracking {{progressbar|50}}
** Follow motion of HMD {{done}}
** Move master camera instead of scene slave cameras (presumably would fix surround sound) {{not done}}
* Settings {{progressbar|20}}
** Mirror settings {{done}}
** Dynamic toggling of VR {{done}}
** Sound settings? {{not done}}
*** Sound reference frame (user's head or room)? {{not done}}
** Advanced VR settings {{not done}}
*** validation layer {{not done}}
*** submit depth information {{done}} but needs testing (SteamVR+Linux+nVidia doesn't do motion smoothing yet)
*** osgXR VR mode {{not done}}
**** Fix slave cameras mode clearing {{not done}}
*** osgXR swapchain mode {{not done}}
* Platform support {{progressbar|30}}
** Linux/X11/OpenGL graphics bindings {{done}}
** Windows/OpenGL graphics bindings {{not done}}
** Windows Mixed Reality render via DirectX bindings {{not done}}
** Monado support {{progressbar|10}}
* Splash screen {{progressbar|0}}
** Show splash screen as quad layer for runtime to composite {{not done}} {{priority|2}}
** Cube map/quads background provided by aircraft {{not done}}
* GUI {{progressbar|10}} {{priority|2}}
** Shown over mirror on desktop window {{done}}
** Expose a menubar & GUI, rendered to a quad or cylinder in front of VR user when they activate {{not done}}
** Interact with GUI buttons etc using controllers as lasers {{not done}}
* Controller support {{progressbar|50}}
** Basic action support in osgXR API {{done}}
** Tie osgXR actions into FG's input system {{done}}
** Helicopter flight controls (can use for planes too) {{done}}
** Plane flight controls {{not done}}
** Render controllers {{not done}}
** Hand tracking (robot hand) {{not done}}
** Render skinned hand {{not done}}
** Basic interaction with controls {{progressbar|80}}
** Advanced interaction with animated controls {{not done}}
** Holding axis controls (joystick, yoke, helicopter collective) {{not done}}
** Haptic feedback {{not done}}
* Walker VR locomotion / Room scale {{progressbar|0}}
** Walker follows user {{not done}}
** Parabolic arc teleport {{not done}}
** Snap into seats {{not done}}
** Easy turning around {{not done}}

== References ==
{{Appendix}}

[[Category:Core development projects]]

Hackathon Proposal: Performance Improvement for Ortho Scenery

2021-11-09T14:57:46Z

Nia: Added how to test

{{Hackathon Proposal 2021
| title = Performance Improvement for Ortho Scenery
| image = Oom bavaria ortho.jpg
| caption = Demonstrating out of memory issues with the open bavaria ortho scenery
| sponsor = merspieler
| supporters = (Feel free to add yourself)
| status =
| summary = Improving the performance of ortho scenery by adding a LOD scheme and loading it in a background thread
| background = I've started the initiative of collecting openly licensed ortho sources to be used in flightgear.
For bavaria, there are high quality (80cm/px) images available under CC BY license from the Bayrische Vermessungsverwaltung. The generated (16k) scenery quickly showed its issues cause one would run out of RAM and VRAM, when running larger areas with such scenery. This can be solved by implementing a LOD scheme: only loading highres versions for near-by tiles and loading lower res versions for distant tiles. In addition, with altitude the need for highres images reduces. 4k scenery (roughly 4m/px, 1/16th the size of 16k scenery) starts looking fine at 10000-12000ft AGL on a FullHD monitor and is more than enough for airliner cruise altitude so 2k or maybe even 1k scenery would be enough for that. 4k Scenery is already enough to not cause any RAM or VRAM issues on a modern system by using about 13GB RAM and 5GB VRAM at cruise alt and a bare LOD of >200km.

The other issue that becomes aparent with large or many images is loading times. It can take several seconds to load a highres tile or in cruise a row of lowres tiles. Currently, flightgear freezes during loading. This could be solved by moving the loading into its own thread.
| details = Stuart has some ideas on how it might work with WS3.0: https://sourceforge.net/p/flightgear/mailman/message/37371092/
| skills = C++
| opportunities =
| notes = I will need help of someone familiar with the rendering and loading code.
}}

=== Progress during the Hackathon ===
We've got a working ortho scenery under WS3.0. The ortho scenery uses the same LOD scheme as WS3.0 does.

This already solved the loading performance issues seen with high res WS2.0 ortho scenery.

How to test (latest next version required):

* Download the [https://cdn.merspieler.tk/hosting/demo.zip scenery] (31GB Download) and unpack it.
* Add the command line option `--prop:/scenery/use-vpb=true`. This enables WS3.0.
* Start at EDDM and enable Photoscenery as well as Ultra terrain quality in the rendering settings.

Hackathon Proposal: Performance Improvement for Ortho Scenery

2021-11-07T21:27:19Z

Nia:

{{Hackathon Proposal 2021
| title = Performance Improvement for Ortho Scenery
| image = Oom bavaria ortho.jpg
| caption = Demonstrating out of memory issues with the open bavaria ortho scenery
| sponsor = merspieler
| supporters = (Feel free to add yourself)
| status =
| summary = Improving the performance of ortho scenery by adding a LOD scheme and loading it in a background thread
| background = I've started the initiative of collecting openly licensed ortho sources to be used in flightgear.
For bavaria, there are high quality (80cm/px) images available under CC BY license from the Bayrische Vermessungsverwaltung. The generated (16k) scenery quickly showed its issues cause one would run out of RAM and VRAM, when running larger areas with such scenery. This can be solved by implementing a LOD scheme: only loading highres versions for near-by tiles and loading lower res versions for distant tiles. In addition, with altitude the need for highres images reduces. 4k scenery (roughly 4m/px, 1/16th the size of 16k scenery) starts looking fine at 10000-12000ft AGL on a FullHD monitor and is more than enough for airliner cruise altitude so 2k or maybe even 1k scenery would be enough for that. 4k Scenery is already enough to not cause any RAM or VRAM issues on a modern system by using about 13GB RAM and 5GB VRAM at cruise alt and a bare LOD of >200km.

The other issue that becomes aparent with large or many images is loading times. It can take several seconds to load a highres tile or in cruise a row of lowres tiles. Currently, flightgear freezes during loading. This could be solved by moving the loading into its own thread.
| details = Stuart has some ideas on how it might work with WS3.0: https://sourceforge.net/p/flightgear/mailman/message/37371092/
| skills = C++
| opportunities =
| notes = I will need help of someone familiar with the rendering and loading code.
}}

=== Progress during the Hackathon ===
We've got a working ortho scenery under WS3.0. The ortho scenery uses the same LOD scheme as WS3.0 does.

This already solved the loading performance issues seen with high res WS2.0 ortho scenery.

Test files and instructions, how to test will soon be added.