Jump to content

Recommended Posts

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:

p-51d_phnl.thumb.jpg.667b2f31ca55d255f1e18d207c7997b5.jpg

 

Cockpit view:

p-51d_phnl_cockpit.thumb.jpg.95f2a3f8eda16d9eb0e39bebfda1d538.jpg

  • Like 11

Share this post


Link to post
Share on other sites

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

The idea could give us the entire world.

  • Like 2

Share this post


Link to post
Share on other sites

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

maybe we have a new world awaiting us?

Edited by russouk2004
  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 4

Share this post


Link to post
Share on other sites

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.

  • Like 4

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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 by russouk2004

Share this post


Link to post
Share on other sites
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.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
21 hours ago, mue said:

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

 

image.jpeg.dec79942c8759f7c02f19215aa97db2e.jpeg

  • Haha 6

Share this post


Link to post
Share on other sites

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 by mue
embedded video
  • Like 5

Share this post


Link to post
Share on other sites

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 by russouk2004
  • Like 1

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

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.

 

 

  • Like 8
  • Thanks 2

Share this post


Link to post
Share on other sites

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 by russouk2004

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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 cZJg4fy.png

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
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...:smile:

 

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 by mue
added question about damage

Share this post


Link to post
Share on other sites
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 by RichardH
  • Like 2

Share this post


Link to post
Share on other sites

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.  

  • Like 3

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By VonS
      Recently I had an opportunity to re-install FlightGear (stable ver. 2020.3.19) on my 2013 Mac Pro and was pleasantly surprised - with no crashes, decent FPS for the most part, and various other improvements that were incorporated over the years. I had dabbled briefly in FlightGear a couple of times before (around 2013, and again around 2020) - but eventually removed the flight simulator from my hard drive on both of those occasions.
      Since my particular setup(s) are with dual AMD video cards, I thought I would post some (illustrative) tips below, as well as representative pics of the sim when at best, or very good, settings. I will this time around keep FlightGear on my hard drive - makes for a good, free flight simulator.
      For command line entries and tips that should be plugged into the "Additional Settings" option of FlightGear, see the info. immediately below. Make sure to remove the info. included in brackets if copying the commands into the relevant settings section.
      -----
      --prop:/sim/gui/current-style=0 (better GUI style for AMD cards)
      --prop:input/mice/mouse/mode/button[2]/binding/value=2 (gets rid of horrible mouse-as-yoke feature that sometimes automatically turns on)
      --prop:/sim/rendering/photoscenery/enabled=true (gives more photo-realistic scenery whenever possible; to be fully implemented in later FG versions)
      --prop:/sim/rendering/hdr/envmap/update-continuously=false (disables continuous siphoning and updating of terrains, to enable seconds command below)
      --prop:/sim/rendering/hdr/envmap/update-rate=5 (terrain refresh rate set in seconds; good values are 5 or 10, for minimal stuttering)
      --prop:/sim/rendering/max-paged-lod=1300 (stock max paged LOD no. is "200"; recommended is not to exceed about "1900" on AMD)
      --prop:/sim/rendering/plod-minimum-expiry-time-secs=60 (stock min expiry time is "180" secs.)
      --prop:/sim/rendering/multithreading-mode=DrawThreadPerContext (should improve multithreading capacity, at least slightly, and add a few extra FPS)
      --prop:/sim/rendering/database-pager/threads=12 (stock thread rendering no. is "4," with more threads improving ave. FPS; set as per your CPU threads no.)
      --prop:/sim/rendering/vsync-enable=false (force disables vsync to improve FPS)
      --prop:/sim/rendering/multi-sample-buffers=true (this is anti-aliasing; set to false to disable and remove entry immediately below it)
      --prop:/sim/rendering/multi-samples=2 (anti-aliasing value; lowest is 2, also good is 4; avoid 3)
      --compositor=Compositor/HDR/hdr (modern rendering pipeline for better graphics details and shaders; rarely breaks scenery; still mostly experimental on AMD vid. cards)
      --units-meters
      --disable-splash-screen
      --disable-horizon-effect
      --enable-distance-attenuation
      --enable-specular-highlight
      --enable-clouds3d
      --fog-nicest ("nicest" improves look of fog with more subtleties while "fastest" makes fog appear and disappear more quickly; no real impact on AMD FPS)
      --shading-flat ("smooth" apparently improves look or depth of shaders; preference is for "flat" since I have not noticed difference in quality on AMD)
      --texture-filtering=2 (this is anisotropic value; lowest is 1; also good is 4 or 2; avoid 3)
      --bpp=32 (can also use 24 but have not noticed an FPS improvement with 24; would say 32 is better for FPS overall)
      --terrain-engine=pagedLOD
      --lod-levels=3 2 5 3 1 (also good is 4 3 6 4 2 for best visual quality on AMD but still mostly FPS-friendly; recommended is 3 2 5 3 1 for balance between visual quality and solid FPS)
      --lod-res=2 (default is 1; also good is 3; avoid any other values besides 2)
      --lod-texturing=raster (better than "bluemarble" as far as I have been able to test, with smoother loading of textures)
      --lod-range-mult=3 (default is 2; also good is 1; avoid all other values besides 3)
      --enable-texture-cache
      -----
      On a broader note, it's important to tweak the rendering, shaders, and LOD range settings in FlightGear - to get the best experience on your AMD video rigs (be it a dual or single AMD setup).
      The frequencies, by the way, on my dual FireProD700s have been OC-ed, via MSI Afterburner, from a clock/memory of 850/1370 to 1024/1380 MHz.
      Be sensible with the rendering options - particularly with the maximum number of scenery and aircraft tiles - anything above a value of 1900 or so is both useless and an FPS hit. (The scenery/aircraft tiles no. may also be set via the relevant command line entry indicated above in this post.)
      Take note as well of cloud density and visibility values. Anything beyond a visibility of 35 km or so is questionable since it does not widen further the cloud carpet but is, once again, an FPS hit.

      Pic 1 - Sensible/Best Rendering Choices for AMD Video (in FlightGear)
      Next we look at the shader options that also require careful thinking and tweaking. Take note that "landmass," "urban," also "water" - give different visuals if they are set to the maximum level (of five). I personally prefer how the landscape/terrains look with those three settings at a value of four - with crisper graphics - but tweak according to taste. Also worth noting is that I always run the LOD value on my rig(s) at "-1," via the excellent little program "ATISetLod" that is available under the top post of this thread.

      Pic 2 - Sensible/Best Shader Options for AMD Video (for crisp and fairly realistic graphics)
      Also important is to tweak the LOD range settings to get a good balance between visual quality and decent FPS, with no stuttering or crashes. Focus in particular on the maximum distances for the detailed, rough and bare scenery ranges - I decided eventually on cutoffs of 3, 17.5 and nearly 45 km. Other cutoffs worth considering are 2.5, 15, and 40 (or so) km, as well as 3.5, 20, and 50 km. Anything beyond the latter values will, again, most likely not make much of a difference with the visuals but will contribute a noticeable FPS hit. Take note also of the "high detail" and "AI/MP interior" values. I'm getting good results with values of 250 - 260 pixels for those options; also good are values of 300 (or so) pixels. Those two values may be tweaked to taste, for the most part - but, again, be sensible since they may impact on FPS.

      Pic 3 - Sensible/Best LOD Range Values for AMD Video
      Last, let's not forget to tweak our custom FlightGear profile (in our AMD settings panel) as best we can, to minimize stuttering, pausing, or crashes. Take note in particular how the shader cache is set to "On," not to "AMD Optimized," and how, even though I have enabled CrossFire mode, frame pacing is set to "Off" (which eradicates stutters on my rig in FlightGear - had tried with frame pacing "On" and was not pleased with the results). If you have only a single AMD video card, experiment with leaving the CrossFire option on (set to "AFR compatible"), or turning it off entirely. (NOTE: I have not noticed any FPS downgrade with anti-aliasing set to 4EQ and edge-detect, anisotropic value at 8, and tessellation at 16. Tweak to taste obviously.)

      Pic 4 - Good AMD Settings for a Custom FlightGear Profile
      Recommended also, if having any instability with FlightGear on AMD video, is to stick with the "Pro" variant DLLs (drivers) for AMD, instead of the consumer/Adrenalin ones. I particularly like the ver. 19.x.x Pro series of drivers, as well as the venerable ver. 17.x.x ones (the latter of which I have installed on the 2013 Mac Pro). To find links to the Pro 19.Q3 DLLs (the last version of the Pro DLLs to support CrossFire, by the way), see this page.
      Below follow several representative pics with the settings illustrated above applied - FlightGear provides a nice selection of aircraft with usually very good monoplane FMs, especially for tricycle-gear (small) civilian aircraft such as Cessnas, also for airliners like the (classic) Boeing 707. For multi-wing contraptions on the other hand and more realistic/historical FMs for biplanes, triplanes, and the odd multiplane, the gold standard(s) remain heavily-modded First Eagles 2 and RoF, as well as recent iterations (UE edition onwards) of the excellent WoFF series.







      Happy flying,
      Von S 
×

Important Information

By using this site, you agree to our Terms of Use, Privacy Policy, and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..