Strike Fighters 2 meets FlightGear

[+mue 715]

Mainly to motivate myself, I made an initial test regarding using 3D assets from SF2 in the open source flight simulator FlightGear.
Since FlightGear uses the same 3D graphics library (OpenSceneGraph) that I also use in the LODViewer, I could easily reuse my LOD file loader plugin with only minor modification.
This is only an initial test. There are still a lot things to do regarding 3D models: animations, shader adaption, .... not to mention reimplementing the SF2 FDM in FlightGear. But maybe some day...

TWs P-51D at Honolulu International (the current FlightGear default airport). Note the missing landing gear caused by nonworking animations:

 

Cockpit view:

[Stratos 3,188]

What about the combat part? enemy AI, bombs, guns, missiles?

The idea could give us the entire world.

[+russouk2004 6,958]

What format to import models into this ?...guess they are 3ds max compatible ?

maybe we have a new world awaiting us?

Edited September 25, 2019 by russouk2004

[+daddyairplanes 10,216]

given all the effort i put into Buffs recently (and plans for Bones and Switchblades) it would be cool to take off from KI Sawyer or Pease and fly all the way to Russia

watching with some interest

[+streakeagle 871]

Flight Gear is open source. What it doesn't have, can be added. If more people worked on flight gear voluntarily, it could have already passed up the payware sims. I periodically download and try it ever couple of years, especially after major releases. But the available library is a motley crew. Some aircraft are up-to-date examples of what can be done with the current release, most are old with poor visual quality and/or poor systems/flight modeling. Flight Gear is proof of what can be accomplished with open source and all-volunteer labor... a solid sim with tons of potential. But it is also proof of what cannot be done: its present form is far behind in visual quality to its payware competitors like FSX, P3d, and X-Plane. But with some real support from combat flight sim fans, it could quickly evolve to be better than SF2 in terms of the aircraft and systems modeling. But like FSX/P3d with TacPack, it is a long road to becoming a decent combat flight sim with lots of AI controlled objects that interact and fight with realistic sensors, weapons, etc.

Since it is free, everyone who likes flight sims should try Flight Gear. It can be a paradise for modders.

[+russouk2004 6,958]

very long winded a\c model creation and importing...must say...take longer to add than make .

[+mue 715]

9 hours ago, Stratos said:

What about the combat part? enemy AI, bombs, guns, missiles?

As streakeagle wrote: "Flight Gear is open source. What it doesn't have, can be added."
Of course, FlightGear is mainly a civilian flight sim and the core (C++) developers are not that interested in combat stuff (means they won't implement themselves), but a C++ skilled combat flight sim fan can of course do it.
Besides, there exists already a combat "addon" for FlightGear: Bombable. It's implemented in FlightGears own scripting language "NASAL". But I haven't used it myself yet. There is also a military flight sim community: http://opredflag.com/. I think they use special adapted aircraft and the normal FlightGear multiplayer network.

 

9 hours ago, russouk2004 said:

What format to import models into this ?...guess they are 3ds max compatible ?

Via my LOD file loader plugin, the LOD files can be read directly without conversion.

 

1 hour ago, russouk2004 said:

very long winded a\c model creation and importing...must say...take longer to add than make .

Sorry, I don't understand that?

[Stratos 3,188]

3 hours ago, mue said:

As streakeagle wrote: "Flight Gear is open source. What it doesn't have, can be added."
Of course, FlightGear is mainly a civilian flight sim and the core (C++) developers are not that interested in combat stuff (means they won't implement themselves), but a C++ skilled combat flight sim fan can of course do it.
Besides, there exists already a combat "addon" for FlightGear: Bombable. It's implemented in FlightGears own scripting language "NASAL". But I haven't used it myself yet. There is also a military flight sim community: http://opredflag.com/. I think they use special adapted aircraft and the normal FlightGear multiplayer network.

Pretty interesting, wondering If we can found that C++ skilled modder. But that makes me think, wouldn't be easier to HACK Sf2 and release our own patches?

I'm a total noob regarding hacking games, but for example, imagine we want to add Air to Air Refuelling, with the source code (or the pertinent part of it) would be overly hard to add such a feature?

[+russouk2004 6,958]

I mean Mue....process of making the 3d models seems so long a procedure...and adding 3d models the way they do it is a long process too...would take longer to get it in game with all the data you need...than actually making the model...I like the terrains etc and weather....models aint  any better than what ive seen our modders here do...so....its a thiought though...

I may look more into game and how actual it is to get model in it...

Edited September 26, 2019 by russouk2004

[+streakeagle 871]

15 hours ago, Stratos said:

Pretty interesting, wondering If we can found that C++ skilled modder. But that makes me think, wouldn't be easier to HACK Sf2 and release our own patches?

I'm a total noob regarding hacking games, but for example, imagine we want to add Air to Air Refuelling, with the source code (or the pertinent part of it) would be overly hard to add such a feature?

Major programs are written using text based files, which are then compiled into compact efficient binary code files that are very efficient in size and speed. It can be painful and extremely time consuming extrapolating those exe's and dll's back into useful, comprehensible source code that will successfully re-compile back into a files that are nearly identical to the original files. There are people that can do that, but why? It is easier to start over with your own new source code if you understand programming and flight simulation enough to reverse engineer the compiled files.

[+Paladrian 11]

[+Paladrian 11]

21 hours ago, mue said:

... but a C++ skilled combat flight sim fan can of course do it.

 

[+mue 715]

Minor update:
-Creation of a generic prop taildragger flight model. It really doesn't resemble a P-51D!
-Animation of (primary) control surfaces
-Animation of gauges (although some gauges need some tuning)
-Animation of the propeller

Test flight video:

This can be achieved *without* patching FlightGear. I only had to add the LOD file loader plugin DLL to the plugin directory.
However for the planned support of the LOD keyframe animations (landing gear, ...), FlightGear must be patched.

If anyone wants to know, how the configuration files in FlightGear look like:
p-51d-model.xml contains the control surface and propeller animations. In SF2 that data is in the <aircraft>_data.ini.
vc.xml contains the gauge animations. In SF2 that data is in the <aircraft>_cockpit.ini.

My todo list for the SF2-FG project:
-Re-creation of the SF2 systems and flight model
-Support of keyframe animations
-Gunsight
-Weapons
-Decal support
-Normal and specular map support

Edited October 2, 2019 by mue
embedded video

[+russouk2004 6,958]

basic model information seems very over complicated...saying that any sim looks confusing until you dig deeper and run it often

mue...you reckon we can make txt file version data files as of sf2 style and then convert to xml ?   

looking at cockpit xml...its a bit like binary they use 1 for on 0 for off  to select an axis for a needle..

starting to see what they are doing...

<entry> <ind>-1000.0</ind> <dep>-138.5</dep>

for a gauge  1000 ind is I think indicator (needle)     DEP NOT SURE BUT ITS THE ROTATION IN DEGREES OF THE 1000 MARK 

soz for caps.

Edited October 1, 2019 by russouk2004

[+mue 715]

8 hours ago, russouk2004 said:

basic model information seems very over complicated...

Maybe it seems complicated and verbose but it's very flexible. It's documented there: http://wiki.flightgear.org/Howto:Animate_models

8 hours ago, russouk2004 said:

mue...you reckon we can make txt file version data files as of sf2 style and then convert to xml ?

I think it should be possible to automatically convert SF2 ini files into FlightGear xml files.

8 hours ago, russouk2004 said:

looking at cockpit xml...its a bit like binary they use 1 for on 0 for off  to select an axis for a needle..

No, the axis definition is not binary. The axis component values x,y,z are floating point values. In this case 1.0 and 0.0.

8 hours ago, russouk2004 said:

<entry> <ind>-1000.0</ind> <dep>-138.5</dep>

for a gauge  1000 ind is I think indicator (needle)     DEP NOT SURE BUT ITS THE ROTATION IN DEGREES OF THE 1000 MARK

Those data are entries of an interpolation table:

        <interpolation>
            <entry>
                <ind>-6000.0</ind>
                <dep>-258.6</dep>
            </entry>
            <entry>
                <ind>-4000.0</ind>
                <dep>-219.3</dep>
            </entry>
            <entry>
                <ind>-3000.0</ind>
                <dep>-198.0</dep>
            </entry>
            <entry>
                <ind>-2000.0</ind>
                <dep>-172.2</dep>
            </entry>
            <entry>
                <ind>-1000.0</ind>
                <dep>-138.5</dep>
            </entry>
            <entry>
                <ind>-500.0</ind>
                <dep>-116.7</dep>
            </entry>
            <entry>
                <ind>0.0</ind>
                <dep>-90</dep>
            </entry>
            <entry>
                <ind>500.0</ind>
                <dep>-63.3</dep>
            </entry>
            <entry>
                <ind>1000.0</ind>
                <dep>-41.5</dep>
            </entry>
            <entry>
                <ind>2000.0</ind>
                <dep>-7.8</dep>
            </entry>
            <entry>
                <ind>3000.0</ind>
                <dep>18.0</dep>
            </entry>
            <entry>
                <ind>4000.0</ind>
                <dep>39.3</dep>
            </entry>
            <entry>
                <ind>6000.0</ind>
                <dep>78.6</dep>
            </entry>
        </interpolation>

In SF2 this interpolation table is defined with:

Set[01].Position=-258.6
Set[01].Value=-6000.0
Set[02].Position=-219.3
Set[02].Value=-4000.0
Set[03].Position=-198.0
Set[03].Value=-3000.0
Set[04].Position=-172.2
Set[04].Value=-2000.0
Set[05].Position=-138.5
Set[05].Value=-1000.0
Set[06].Position=-116.7
Set[06].Value=-500.0
Set[07].Position=-90.0
Set[07].Value=0.0
Set[08].Position=-63.3
Set[08].Value=500.0
Set[09].Position=-41.5
Set[09].Value=1000.0
Set[10].Position=-7.8
Set[10].Value=2000.0
Set[11].Position=18.0
Set[11].Value=3000.0
Set[12].Position=39.3
Set[12].Value=4000.0
Set[13].Position=78.6
Set[13].Value=6000.0

 

[+russouk2004 6,958]

yep

[RichardH 16]

I'm a core contributor to FlightGear, responsible for the the F-15, F-14 in FlightGear, have made aero models for the Mirage2000, Tornado F2, SupermarineSwift and a member of OPRF (opredflag) which is the biggest FlightGear military community.

OPRF aircraft can damage each other, we have automated enemy aircraft, SAMS and we have work in progress that will hopefully one day allow a full combat scenario.

I've also got experience building computational aerodynamics models for FG using the excellent OpenVSP

http://chateau-logic.com/content/using-vspaero-generate-aerodynamic-model-jsbsim-flightgear and https://forum.flightgear.org/viewtopic.php?f=49&t=30832

http://zaretto.com/f-14
http://zaretto.com/f-15
http://zaretto.com/a320
http://zaretto.com/Panavia-Tornado

https://github.com/Zaretto/fg-aircraft
https://github.com/Zaretto/Supermarine-Swift
https://github.com/Zaretto/Aircraft/tree/master/Mirage-2000

http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
http://chateau-logic.com/content/deferred-rendering-rembrandt-performance
http://chateau-logic.com/content/flightgear-using-canvas-3d-instrument
 

I'm posting here to state my interest in assisting with anything FlightGear military related; and I can also provide assistance on "how things work" In FG.

 

 

[+russouk2004 6,958]

I dont mind making hi def models if someone who is used to getting them in game does that bit...must say...some of our modders models look far better quality so would benefit flightgear community too

Richard...you think,someone new to flightgear would take to doing the data files for models easy?...how long would you say it takes to do the data files for a newly completed 3d model.?

cheers  need to know if its worth me studying the method of importing models etc.

Edited October 14, 2019 by russouk2004

[+mue 715]

Richard, thank you for coming to CombatAce and offering assistance regarding (military) FlightGear.
I'm fascinated by the flexibility of FlightGear and JSBSim.
Currently I'm implementing the Strike Fighters 2 FDM  and the (very light) systems in JSBSim. The developer of SF2 has an aerodynamic engineering background and therefore his FDM uses "standardized" aerocoefficients (My notes about the SF2 FDM: sf2_fdm_notes.pdf). Because of the "openness" of SF2 the aerocoefficients of each component (LeftWing, RightWing, LeftOuterWing, RightOuterWing, LeftStab, ...) are easily accessible from aircrafts data text (*.ini) files. Currently I'm doing the FDM/systems "conversion" to FlightGear/JSBSim manually, but I think this could be done later automatically by a tool.

As I wrote, I haven't looked in detail at the combat stuff in FlightGear yet. Maybe you can give a short overview of the features of the "OPRF" combat system (and maybe "Bombable")?
What weapons are supported (guns, rockets, (guided) missiles, bombs)?
I assume it works in multiplayer?
How is the damage modelling?
Since you mentioned SAMs, do you support AAA/Flak too?
How sophisticated are the automated (AI?) enemy aircraft?

[PeacePuma 569]

 

[RichardH 16]

23 hours ago, russouk2004 said:

I dont mind making hi def models if someone who is used to getting them in game does that bit...must say...some of our modders models look far better quality so would benefit flightgear community too

Richard...you think,someone new to flightgear would take to doing the data files for models easy?...how long would you say it takes to do the data files for a newly completed 3d model.?

cheers  need to know if its worth me studying the method of importing models etc.

To answer this first I need to break down the aircraft development tasks

1. Create 3d model in the right format (.ac)

This can take anything from a few seconds to many hours depending on the original format, the conversion tools and the modelling package being used. Generally Blender -> AC3d works best, 3ds max often needs to go through another format (e.g. DAE, .OBJ)

2. Create animation XMLs

Initially this is going to take a while; however once familiar with FlightGear's property tree it is a lot easier. Also we have the ability to use 3d objects (two-vertex lines) as animation axis which removes the need for coordinate entry; complex cockpits take longer

3. Create Flight Model

Using Aeromatic++ it is possible to get a flying model in a matter of a few minutes. A complex aero model using real data (wind tunnel, flight) or CFD data (OpenVSP, OpenFoam) can take months.

4. Avionics (Radar, Displays etc)

The most time consuming aspect of developing in FG are the avionics and cockpit displays (CRT). OPRF has modules that can be integrated into aircraft to help.

5. Integrate with combat

Bombable is OK but really you need to look at the OPRF aircraft (F-14, F-15, F-16, Mirage-2000) (http://opredflag.com/forum_threads/2412191) as these have the armaments, damage code and radar. Viggen is probably the most complete example.

 

However given that SF2 aircraft are standard I'd recommend looking at writing some sort of importer / converter / loader that will do most of the work. 

Expect to invest a fair amount of time on 2, 4, 5 in the above list - unless there is an importer or some sort of conversion tool.

 

10 hours ago, mue said:

Richard, thank you for coming to CombatAce and offering assistance regarding (military) FlightGear.
I'm fascinated by the flexibility of FlightGear and JSBSim.
Currently I'm implementing the Strike Fighters 2 FDM  and the (very light) systems in JSBSim. The developer of SF2 has an aerodynamic engineering background and therefore his FDM uses "standardized" aerocoefficients (My notes about the SF2 FDM: sf2_fdm_notes.pdf). Because of the "openness" of SF2 the aerocoefficients of each component (LeftWing, RightWing, LeftOuterWing, RightOuterWing, LeftStab, ...) are easily accessible from aircrafts data text (*.ini) files. Currently I'm doing the FDM/systems "conversion" to FlightGear/JSBSim manually, but I think this could be done later automatically by a tool.

As I wrote, I haven't looked in detail at the combat stuff in FlightGear yet. Maybe you can give a short overview of the features of the "OPRF" combat system (and maybe "Bombable")?
What weapons are supported (guns, rockets, (guided) missiles, bombs)?
I assume it works in multiplayer?
How is the damage modelling?
Since you mentioned SAMs, do you support AAA/Flak too?
How sophisticated are the automated (AI?) enemy aircraft?

Looking at the aero notes[1] if you have these coefficients it should be relatively easy to put together a JSBSim model - as that's what JSBSim is designed for; it's fortunate that SF2 uses the 'standard' way of doing things.

Making an importer is the best way of converting SF2 models to FlightGear.

The way that OPRF aircraft work is to do all of the combat simulation within the aircraft model; with the hit notifications being transmitted over the multiplayer system  OPRF aircraft must have radar simulation that has correct ranges and can't see through terrain; accurate weapons simulation, damage modelling. Most of this is implemented in FlightGear's Nasal scripting language.  Damage works over MP and currently uses the MP text chat to inflict damage. AAA/Flak could be simulated using the same system - but what we don't have (yet) in the OPRF is much in the way of missions or automated enemies - but this area is under development. The automat aircraft opponents are reasonable and work is ongoing. Remember that OPRF was originally about enabling dogfights between people, then we had organised events - and now we're moving towards more AI and hopefully one day we'll have missions and even campaigns. The development is slow - but because it's all opensource we can pretty much do anything that we have the time to implement. There is a python AI system under development that integrates with the Multiplay and provides targets and will provide opponents.

Bombable is an alternative way of giving and receiving damage, but it also provides AI opponents; however it isn't as fully featured as OPRF.

----------------------

[1] Although some of what you refer to as derivatives are in fact just coefficients; the real derivatives are those that are due to the output from the aero model (p,q,r, alphadot, betadot) I've highlighted the derivates in green

[+mue 715]

6 hours ago, RichardH said:

Looking at the aero notes[1] if you have these coefficients it should be relatively easy to put together a JSBSim model - as that's what JSBSim is designed for; it's fortunate that SF2 uses the 'standard' way of doing things.

Yes...if engineers make games...

 

6 hours ago, RichardH said:

Making an importer is the best way of converting SF2 models to FlightGear.

I've  implemented an OSG file loader plugin for the SF2 3D model file format (*.lod). So the SF2 3D models can be directly loaded into FlighGear.
I'm still not sure if I should make the LOD loader plugin open source. I myself wouldn't mind, but I don't know what the game developer and the 3D modders would think about it.
In the past (Sep 2007) the game developer himself wrote in a forum post after he was asked about documentation about the LOD format:
"...although we didn't publish LOD format, we also don't stop people form reverse engineering it either ;) Its not encrpyted or anything, so its fairly straight forward to figure out..."
Unfortunately later LOD format versions contain some obfuscation, so maybe his opinion has changed? I also think the 3D modders consider the (non published) LOD format as a kind of intellectual property protection.
But keeping it closed source would mean it can not be officially distributed/supported by FlightGear and it would only work with FlighGear versions/platforms for which I compile/release the binary (e.g. Windows).

 

6 hours ago, RichardH said:

The way that OPRF aircraft work is to do all of the combat simulation within the aircraft model; with the hit notifications being transmitted over the multiplayer system  OPRF aircraft must have radar simulation that has correct ranges and can't see through terrain; accurate weapons simulation, damage modelling. Most of this is implemented in FlightGear's Nasal scripting language.  Damage works over MP and currently uses the MP text chat to inflict damage. AAA/Flak could be simulated using the same system - but what we don't have (yet) in the OPRF is much in the way of missions or automated enemies - but this area is under development. The automat aircraft opponents are reasonable and work is ongoing. Remember that OPRF was originally about enabling dogfights between people, then we had organised events - and now we're moving towards more AI and hopefully one day we'll have missions and even campaigns. The development is slow - but because it's all opensource we can pretty much do anything that we have the time to implement. There is a python AI system under development that integrates with the Multiplay and provides targets and will provide opponents.

If I understand correctly, only hit notifications are transmitted, but no bullet or missile positions? Does that mean, that no tracers or missiles from other aircraft are visible?
Is damage calculated by the "receiver" or "sender"?
Do you have a link or pointer to the "automated enemy" code and the Python AI system?

 

6 hours ago, RichardH said:

[1] Although some of what you refer to as derivatives are in fact just coefficients; the real derivatives are those that are due to the output from the aero model (p,q,r, alphadot, betadot) I've highlighted the derivates in green

Thank you for the clarification.

Edited October 15, 2019 by mue
added question about damage

[RichardH 16]

8 hours ago, mue said:

I've  implemented an OSG file loader plugin for the SF2 3D model file format (*.lod). So the SF2 3D models can be directly loaded into FlighGear.
I'm still not sure if I should make the LOD loader plugin open source.

If I understand correctly, only hit notifications are transmitted, but no bullet or missile positions? Does that mean, that no tracers or missiles from other aircraft are visible?
Is damage calculated by the "receiver" or "sender"?
Do you have a link or pointer to the "automated enemy" code and the Python AI system?

In my opinion the OSG file loader should be OpenSource; 

1. OpenSource is really the only way to guarantee the future availability of the plugin and therefore anything that depends on it. This is particularly important for community projects as it protects everyone's investment from becoming obsolete. 
2. FlightGear is multi platform (Windows, OSX, Linux) and this becomes hard when working with binary distributions.
3. The rest of FlightGear is, and always has been OpenSource. This is tens of thousands of hours of effort - so it is only fair to keep with this philosophy.
4. The copy protection offered by having a file format that can be reverse engineered isn't worth that much and in any case cannot protect against the use of a DirectX  ripper to grab the geometry.

I can understand the argument that it provides (limited) copy protection for the artwork and assets - but realistically most of us give our work away for no charge so the main use is to stop evil people from making money off our hard work; and realistically proper licencing is the best approach to this (e.g. CC NC). 

The OPRF current version only transmits release / hit / miss notifications - however I have a nearly finished WIP that will transmit in flight position messages for missiles and shells (subject to bandwidth limitations)

Damage is calculated by the recipient based on the distance with a sprinkling of randomness.

The python code isn't generally available (due to the risk of griefing)

Edited October 15, 2019 by RichardH

[+swambast 721]

In my opinion, I could not disagree more and hate the way this is heading...The Developer of this Sim created an encrypted .LOD file format for a reason - to prevent theft and unauthorized distribution.  I have never seen a post where the Developer has made a claim about not caring about reverse engineering - why do you think he ended up locking certain .LODs and other game components away then if he didn't care?  Anyone can justify anything if they want, but it doesn't make it right.  I'd personally prefer to see Thirdwire continue to go on it's own way and FlightGear do the same - I don't see what benefit Thirdwire or the community has in this arrangement - for example, do we suddenly get access to FlightGear assets?  But I'm sure I'm again in the minority - seems to be just a free for all these days.  

[+russouk2004 6,958]

Im sticking with SF2 too....flightgear has some good terrains and features,but too long and complcated method of importing a model...think I will stick to what I know lol