FlightGear Newsletter July 2021: Difference between revisions

Jump to navigation Jump to search

FlightGear Newsletter July 2021 (view source)

Revision as of 10:09, 26 July 2021

1,029 bytes added ,  26 July 2021
m
Cleanup
m (Cleanup)
m (Cleanup)
Line 62: Line 62:
* use the following [[Command line options|command-line option]]: --compositor=Compositor/HDR/hdr
* use the following [[Command line options|command-line option]]: --compositor=Compositor/HDR/hdr
* To enable the command-line option simply copy/paste the line into the [[FlightGear Qt launcher]] > Settings > Additional Settings, or use the command-line or add it to the fgfsrc file
* To enable the command-line option simply copy/paste the line into the [[FlightGear Qt launcher]] > Settings > Additional Settings, or use the command-line or add it to the fgfsrc file
* Note: Currenlty FG will crash if any terrain is in view - so you need start over the ocean. You can start on a [[Howto:Carrier|Carrier]] like the Harry S Truman. If you encounter issues try useing the C172p/UFO. It may be that only NVIDIA cards are supported currently until the sim transitions properly to OpenGL 3+.
* Notes (''By the time you read this the prototype may have improved/changed'':
** Right now, FG will crash if any terrain is in view. So you need start over the ocean - or otherwise make sure no terrain is rendered e.g. by disabling TerraSync, and starting at a location for which you don't have terrain downloaded, or just temporarily rename your TerraSync folder.
** Aircraft: The C172P is confirmed to start without crashing right now. To do a mid-air start from the [[FlightGear Qt launcher]] you need to specify a location over the ocean by typing in lat/lon coordinates and then specify an altitude. <code>Qt-Launcher > Location tab > Location search bar > enter lat/lon coordinates over ocean separated by a comma e.g. 30,-40 > press enter</code>. <code>Move the altitude toggle to enable it, and enter an altitude in ft or m</code>. CTRL+u works to gain altitude. You can also try the video assistant which can be selected from the launcher. Try a clear sky as cloud rendering is broken right now. Right now the in-sim menus may not render.
** You can start on a [[Howto:Carrier|Carrier]] like the Harry S Truman, provided it's not placed near terrain.
** It may be that only NVIDIA cards are supported currently until the sim transitions properly to OpenGL 3+.


See Fernando's post about the first merge on the mailing list : '''https://sourceforge.net/p/flightgear/mailman/message/37325148/'''
See Fernando's post about the first merge on the mailing list : '''https://sourceforge.net/p/flightgear/mailman/message/37325148/'''
Line 68: Line 72:
'''Naming clarification'''
'''Naming clarification'''


Although the pipeline is called the "HDR pipeline", it's really a suite of rendering improvements in addition to a different HDR implementation. It's sort of the way ALS framework contains a huge amount of features besides Advanced Light Scattering (including creating forest or terrain detail), and the ALS name was chosen to distinguish it from the 'Default' and 'Rembrandt' renderers which are now obsolete in the next branch. Similarly HDR pipeline name is just something to distinguish it from the suite of features in the current ALS rendering pipeline, which is currently planned to be called the "Classic" renderer in an upcoming UI revamp (no single name can cover all the different features of a rendering pipeline - so in the planned GUI, actual rendering features will be listed in the UI and there will be toggles to enable features as applicable).
Although the pipeline is called the "HDR pipeline", it's really a suite of rendering improvements in addition to a different HDR implementation. It's sort of the way ALS framework contains a huge amount of features besides Advanced Light Scattering (including creating forest or terrain detail), and the ALS name was chosen to distinguish it from the 'Default' and 'Rembrandt' renderers which are now obsolete in the next branch. Similarly HDR pipeline name is just something to distinguish it from the suite of features in the current ALS rendering pipeline, which is currently planned to be called the "Classic" renderering pipeline in an upcoming UI revamp (no single name can cover all the different features of a rendering pipeline - so in the planned GUI, actual rendering features will be listed in the UI and there will be toggles to enable features as applicable).


'''OpenGL requirements'''
'''OpenGL requirements'''
Line 76: Line 80:
'''Compositor and rendering pipelines'''
'''Compositor and rendering pipelines'''


The Compositor is a framework to define rendering pipelines - so far the work has been to port the ALS renderer to the new framework, and add the distinguishing features of the old unmaintained Rembrandt renderer like shadows and environmental light definitions without being slow. The idea is to port existing features from both renderers to ensure everything works - the next preview release or LTS will transition to the Compositor. The next LTS will have the existing features as the classic rendering pipeline alongside any new pipelines that are finished, so there's no need to worry about performance hits of features from the new pipeline making very old hardware too slow to run FG.  
The Compositor is a framework to define rendering pipelines - so far the work has been to port the ALS rendering pipeline to the new framework, and add the distinguishing features of the old unmaintained Rembrandt renderer like shadows and environmental light definitions without being slow. The idea is to port existing features from both renderers to ensure everything works - the next preview release or LTS will transition to the Compositor. The next LTS will have the existing features as the Classic rendering pipeline alongside any new pipeline(s) that are finished, so there's no need to worry about performance hits from features in the new HDR pipeline making very old hardware too slow to run FG.  


'''New HDR pipeline'''
'''New HDR pipeline'''
Line 90: Line 94:
James Hogan, a brand new contributor (not to be confused with James Turner or James Hester), has been working on a ''very'' experimental/WiP project adding support for {{Wikipedia|Virtual reality headset|Virtual Reality ('''VR''') headsets}} to FlightGear. The project needs the [[Compositor]] and next branch of FlightGear (nightly builds), It will not work on 2020.3.x LTS. The work is still very experimental and has not been merged into the FlightGear next branch as of late July.
James Hogan, a brand new contributor (not to be confused with James Turner or James Hester), has been working on a ''very'' experimental/WiP project adding support for {{Wikipedia|Virtual reality headset|Virtual Reality ('''VR''') headsets}} to FlightGear. The project needs the [[Compositor]] and next branch of FlightGear (nightly builds), It will not work on 2020.3.x LTS. The work is still very experimental and has not been merged into the FlightGear next branch as of late July.


The reason that Virtual Reality support has not been worked on by core developers interested in relevant areas to date is that they do not have access to a VR headset - various developers have indicated in the past they are willing to provide support to people interested in adding VR support, or even willing to assist implementation if VR headset companies, companies of required supporting products like high-end GPUs, or others were willing to sponsor/donate VR hardware - e.g. see an old forum [https://forum.flightgear.org/viewtopic.php?f=6&t=34434#p358088 thread] on the topic. This general lack of VR hardware among interested core developers (including the Compositor developer), means it's important for interested contributors who use VR to get involved with development, and for people with VR to contribute with bug reports and testing. This includes testing on various VR headsets - James Hogan is developing on a HTC Vive which is 1 among a {{Wikipedia|Comparison of virtual reality headsets|number of VR headsets}}.
The reason that Virtual Reality support has not been worked on to date by core developers interested in relevant areas is that they do not have access to a VR headset hardware - various developers have indicated in the past they are willing to provide support to people interested in adding VR support, or even willing to directly assist implementation if they had access through sponsoring/donating VR hardware (from VR headset companies, from companies of required supporting products for VR like high-end GPUs, or others) - e.g. see an old forum [https://forum.flightgear.org/viewtopic.php?f=6&t=34434#p358088 thread] on the topic. This general lack of VR hardware among interested core developers (including the Compositor developer), means it's important for interested contributors who use VR to get involved with development, and for people with VR to contribute with bug reports and testing. This includes testing on various VR headsets - James Hogan is developing on a HTC Vive which is 1 among a {{Wikipedia|Comparison of virtual reality headsets|number of VR headsets}}.


James Hogan is using the {{Wikipedia|OpenXR|OpenXR API}} (https://www.khronos.org/openxr/) that supports multiple headsets and manufacturers. An API is a standard way for applications to 'talk' to the headsets via their drivers - similar to the way OpenGL allows applications to talk to the different GPU hardware cia their drivers. JamesH is working on a library called [https://github.com/amalon/osgXR osgXR] to add OpenXR support directly to [[Open Scene Graph]] (OSG) for the purposes of enabling VR support for FlightGear, after feedback from the OSG mailing list. This approach will mean the OSG project will help support and maintain osgXR in future, and non-FlightGear projects using OSG with VR will help extend and maintain osgXR in future. Similarly, Khronos and other non-OSG/non-FLightGear projects will also help maintain the OpenXR standard across new devices in future. This is an example of the strength of the Open Source approach. If you are involved in other projects that use OSG that might be interested in OSG VR support for their applications, you can give them a heads up regarding osgXR adding OpenXR support.
James Hogan is using the {{Wikipedia|OpenXR|OpenXR API}} (https://www.khronos.org/openxr/) that supports multiple headsets and manufacturers. An API is a standard way for applications to 'talk' to the headsets via their drivers - similar to the way OpenGL allows applications to talk to the different GPU hardware cia their drivers. JamesH is working on a library called [https://github.com/amalon/osgXR osgXR] to add OpenXR support directly to [[Open Scene Graph]] (OSG) for the purposes of enabling VR support for FlightGear, after feedback from the OSG mailing list. This approach will mean the OSG project will help support and maintain osgXR in future, and non-FlightGear projects using OSG with VR will help extend and maintain osgXR in future. Similarly, Khronos and other non-OSG/non-FLightGear projects will also help maintain the OpenXR standard across new devices in future. This is an example of the strength of the Open Source approach. If you are involved in other projects that use OSG that might be interested in OSG VR support for their applications, you can give them a heads up regarding osgXR adding OpenXR support.
Vs
1,746

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/132542"

Navigation menu