Board index FlightGear The FlightGear project

Using a game engine for FlightGear

Questions about the FlightGear organisation, website, wiki etc.

Using a game engine for FlightGear

Postby MrMinimal » Fri Mar 13, 2020 1:21 pm

Hi!

I have been a FlightGear user for about 6 years now and really love the project.
It has been my no. 1 inspiration to become an open source developer in the first place.
What I also am is a Godot game developer and patreon.
In my spare time I am working on flight simulator prototypes to test the capabilites of the engine.
So far I have tried:
    - physically based rendering
    - VR support
    - multi-platform support
    - multiplayer
    - controller support
    - audio
    - GUI
    - Shaders
All of that in a visual editor, creating logic using scripting Rust, C# and C++.

Reading the FlightGear source code I can see that a lot of these things are also contained in FG.
It's very impressive that the developers basically wrote an entire game engine and put a flight simulation on top.

Looking into the future though, I wonder if maintaining the "game engine part" of FlightGear makes sense if open source solutions can be used.
Battle for wesnoth, a popular open source game which exists since 2005, is currently migrating to Godot.
The effort put into maintaining the "game engine part" could be used elsewhere, possibly increasing the development velocity.

Some images of my experiements with Godot as a flightsim:
Image
Image
Image
Image



What is your opinion on this topic?
Do you think it would be feasable to migrate parts of FG to an open source game engine such as Godot?
Are there parts of FlightGear that absolutely require to write a customized game engine?
Got any Godot related questions?

I want FlightGear to succeed in the future and be fun for everyone to contribute to.
And I really want to hear your thoughs on this.


Greetings from Germany

Tom
MrMinimal
 
Posts: 16
Joined: Fri Sep 19, 2014 1:29 pm

Re: Using a game engine for FlightGear

Postby Johan G » Fri Mar 13, 2020 1:54 pm

Similar concepts have been brought up in the past. There are some important aspects that differ from a typical game engine, and I am sorry if I sound pessimistic here. From the top of my head, and to the best of my recollection, some of those differences are:

  • Scenes rendered in a flight simulator are on a completely different scale than in a typical game engine. We are talking several orders of magnitude longer distances and likely amount of objects. You are not seeing to the next city block or even the next hilltop. You are seeing to the next city and the one beyond. Keep in mind that scene complexity increases with area, in essence not linearly with view distance, but exponentially. FlightGear uses a big bag of tricks to make it look as good as it does, and even allow for orbital views.
  • The physics modeling, albeit largely handled by the flight dynamics modeling (FDM) portions of the software (basically YASim and JSBSim), is more involved and usually end up making large parts, if not all, of a flight simulator into a huge main loop running as a single thread.
  • Doing big engine changes sometimes do not work out that well. FlightGear is maintained and developed by a loosely knit group of developers spending some of their spare time on this. About 10 years ago now FlightGear switched its rendering engine from PLIB to OSG, and there are notable features, such as shadows that got reintroduced just in the last years.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6020
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.2
OS: Windows 10, 64 bit

Re: Using a game engine for FlightGear

Postby MrMinimal » Fri Mar 13, 2020 3:57 pm

Thanks Johan you bring up great points! That was exactly why I asked on this forum, the years of experience are invaluable.

1. Scene rendering
There are multiple performance optimizations available such as multimeshes that utilize geometry instancing.
Timestamped example: https://youtu.be/pmyOYInhlkI?t=689
I can't give an example that renders an entire world but it doesn't seem impossible to do so.
At the same time, I don't know all tricks FG uses to look as good as it does, most should still be applicable.

2. 100% agree with you. I have used JSBSim in multiple projects of mine individually because interfacing with it is pretty simple. Built als a library, I have a Godot project that uses it successfully.

3. Agreed. Large changes only work if everyone wants to do them. No point in forcing anyone to do it, which is why I'm asking in this format.
Really I'm just gauging interest if anybody would like to head in this direction or ever thought the same.

Really appreciate the discussion, cheers!
MrMinimal
 
Posts: 16
Joined: Fri Sep 19, 2014 1:29 pm

Re: Using a game engine for FlightGear

Postby Hooray » Fri Mar 13, 2020 4:49 pm

Hi !

This looks fascinating !

May I suggest to look up the postings made by "chriscalef" on this forum, and maybe his wiki contributions, too ?
Given your background, I think you will find his work highly interesting:


http://wiki.flightgear.org/FlightGear_W ... Box_Server
Image

Helicopter harassment... or, things you've never seen in FG.
chriscalef wrote:Just thought I'd drop in to share, apologies for the framerate and the terrible rotor effects, this is a live video capture with VirtualDub, from Torque3D, while running FlightGear and also rendering a separate movie in Blender, so my CPU was a bit occupied at the time. But my Ka50 (thank you @Emmanuel Baranger!) can now interact with my human actors. And it's surprisingly fun. :twisted:




Flightgear and Unity3D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11960
Joined: Tue Mar 25, 2008 8:40 am

Re: Using a game engine for FlightGear

Postby chriscalef » Fri Mar 13, 2020 7:48 pm

Nice work, MrMinimal! Hooray mentioned this thread to me, thought I'd drop in and say hi. For my own project I've gone the route of leaving FG alone and building my game in an external engine which talks to a (headless) FG instance over sockets. This has the advantage of being vastly less work than any other approach, IMHO. It has the disadvantage of some parallel functionality and wasted resources, but I am endeavoring to snip as many of those away on the FG side as possible (like texture loading, since none of them will ever be seen in my application.)

I am building a project with a significantly limited flight area, so I don't have as many worries as I would otherwise about unlimited view distances.

Good luck with your work though, I'll be monitoring your progress!
chriscalef
 
Posts: 279
Joined: Wed Feb 20, 2013 9:28 pm

Re: Using a game engine for FlightGear

Postby Thorsten » Sat Mar 14, 2020 7:50 am

Looking into the future though, I wonder if maintaining the "game engine part" of FlightGear makes sense if open source solutions can be used.


I don't actually think a game engine provides an environment suitable for a flightsim.

Take weather - does a game engine provide a halfway realistic pattern of updrafts under clouds? Does it provide the tell-tale turbulence around the thermals?

Usually game engines are concerned with providing the cool visuals of some types of weather, not a full simulation of vertical atmosphere profiles for any (even boring) types of weather. Whereas we want this integrated, e.g. weather affects what we see just as well as what the FDM feels - it affects rendering on your cockpit (droplets hitting the windshield), rendering on the scenery (snow and wet ground, windsocks,...), the FDM (gusts and turbulence, icing,...), the instrumentation (weather radar,...)

(There's other special areas like the whole radio navigation issue...)

So what FG needs is imo not a game engine, it is a flightsim environment, and this is what it provides. In some areas that is similar to the needs of a game engine, but in many areas it actually is rather different.
Thorsten
 
Posts: 11746
Joined: Mon Nov 02, 2009 8:33 am

Re: Using a game engine for FlightGear

Postby Icecode GL » Sat Mar 14, 2020 1:38 pm

Both games and flight simulators are inherently real time, so of course some of the functionalities required in a game overlap those required in a flight simulator, mainly the ones related to rendering and user input. The problem is that game engines have the issue of (obviously) being made to create games. They are tailored towards making the job easier to the developer wanting to implement something that has been implemented a million times before in other games. FG could definitely take advantage of some of those systems as you said, but in the long run FG will require more flexibility. At the end of the day you'll end up zig-zagging the game engine, trying to get around some of its assumptions and re-implementing some features that didn't do things exactly as you wanted.

I can see why those open source games are moving to Godot if they have the resources: they are basically offloading a huge part of their game to other developers so they can concentrate on the game itself. FG does something similar with OpenSceneGraph, but in this case OSG is more flexible at the expense of requiring more effort to get going. It's a matter of choosing the right balance between flexibility and development effort. If you tip the scales too much in favor of reducing the development time by, in this case, using a game engine, it will backfire on you as the reduced flexibility will make you spend more time getting around the limitations of the engine.
Icecode GL
 
Posts: 633
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Fedora

Re: Using a game engine for FlightGear

Postby MrMinimal » Sat Mar 14, 2020 1:39 pm

I agree that a simulator has very specific requirements, the ones that you listed being the most important.
At the same time I am also confident, that these can be implemented in a game engine as well or carried over from FG.

I'd be interested in trying it out and I will keep you posted on the progress.

Thanks for your input Thorsten!
MrMinimal
 
Posts: 16
Joined: Fri Sep 19, 2014 1:29 pm

Re: Using a game engine for FlightGear

Postby Parnikkapore » Mon May 04, 2020 1:02 pm

I personally think that using a more modern game engine in place of OSG might make sense - they'll provide loading management, culling etc, and we provide Advanced Weather, JSBSim, etc.

But Icecode may also have a point - the game engine might be doing too much for our purposes.
There are free alternatives to every program you encounter. You just have to find them.
Parnikkapore
 
Posts: 831
Joined: Thu Oct 29, 2015 10:16 am
Callsign: HS-FGS
Version: next [PPA]
OS: Mint 18

Re: Using a game engine for FlightGear

Postby stuart » Mon May 04, 2020 3:26 pm

Hi Folks,

It is almost certain that we will migrate to a new graphics platform in the next 5 years. OSG is moving to a maintenance mode and OpenGL support is beginning to be deprecated on some platforms (IIRC on some Macs?).

As other posters have mentioned, there are a variety of specific requirements for a flight simulator that aren't fulfilled in a more typical game engine. So it is exceedingly unlike we'd move to Godot or any other game engine, as there would be an innate tension between our requirements and that of a game.

Much more likely is a migration to Vulkan Scene Graph, which is a project being run by the same team that wrote OSG. That will have similar characteristics as OSG, operate at a similar integration level and we can hope for some commonality to make migration easier.

I say "migration" intentionally. Moving to a new graphics engine is not just going to be a case of a drop-in replacement for OSG at a core code level. It's highly likely that there will be implications on a whole range of areas - scenery, trees, clouds, buildings, Effects, Canvas, animations, aircraft.

The two main drivers of the migration from plib to OSG (Tim and Matthias) are no longer active as FG developers, but I was moderately involved (along with Erik and James IIRC). It's a huge amount of work, and requires some fairly deep knowledge of how graphics pipelines and scenegraphs work to design something that scales to our needs.

-Stuart

PS:

Parnikkapore wrote in Mon May 04, 2020 1:02 pm:I personally think that using a more modern game engine in place of OSG might make sense - they'll provide loading management, culling etc, and we provide Advanced Weather, JSBSim, etc.

This is exactly what OSG provides today - loading management, culling, LoD.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1603
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Using a game engine for FlightGear

Postby Hooray » Sun May 10, 2020 6:55 am

right, it's also worth noting that the original plib/osg migration was initated back in 2006, and still never fully completed - at the time, it also caused quite a bit of irritation among community members, even long term contributors, who were not happy with the degree of regressions introduced by the "port".

Back then, the idea was that important features would be ported/re-implemented "over time", but like Stuart said people originally involved in the OSG migration are no longer involved in the project due to RL taking precedence. This, too, caused some friction so that people began back-porting features to the non-OSG port.

All of which is to say, this will take time - and it's likely that there will need to be a discussion to define a cut-off date, and form a consensus to do away with certain legacy features/code for which nobody is around to offer handling porting/maintenance.

Even now, there still is a ton of legacy code that is complicating matters for people interested in certain new rendering features, e.g. there are features like the effects system, canvas and the compositor that are not compatible with certain legacy code, so that it will make sense to have a "stable" version to carry around legacy functionality, and then start from scratch with a build that excludes certain problematic code (think 2D panels, HUD, osgText and PUI, legacy ND or other OD_gauge based avionics like agradar, wxradar)

This will entail discussing and defining a subset of legacy features that are to be disabled sooner or later (i.e. excluded from compilation), because we're lacking volunteers to help with porting/maintaining such code, so that more modern functionality can be implemented using the remaining technology stack.

Some of this is going to happen once the compositor is becoming the default renderer, which willl also mean that legacy rendering code cannot just be disabled via cmake build options, but over time it will probably removed from the build tree.

For the compositor specifically, this will also mean adapting the existing view manager and camera group code, so that it plays nicely with the new way pipelines can be defined in XML space - at which point, the long-standing idea of using CompositeViewer will also become a possibility.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11960
Joined: Tue Mar 25, 2008 8:40 am


Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 1 guest