Board index FlightGear Development Aircraft

F-16 upgraded to 'production' status

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: F-16 upgraded to 'production' status

Postby xiii » Wed Aug 15, 2012 11:23 pm

Hi Philosopher, nice to see you on the f16 !

- Better use Git and work on a up-to-date model. Then you'll can file a merge request with you changes for faster integration in the project.
Most/all of the f16 development is discussed here or privately by mail. The devel list is interesting too, but it is yet another time consuming thing.
There is a nice TDL here: http://wiki.flightgear.org/F16/Development The guy who wrote that looks like gone now, but I think it's a good idea to use this wiki page.

- About the HUD: for symbology item (lines, dot and numbers) the contrast setting is not important, it is when the actual HUD displays ground images over the symbology, which is not possible yet in FG. DEPR will move the gun reticle up and down in the HUD, but there isn't a stock gun reticle available in the legacy HUD tools. I think the A-10 has a custom reticle as a 3D object aligned over FG HUD.
My best advice would be watch the Canvas development and wait to jump on the next/future implementation of the HUD using Canvas.

- About the f16 version: I'm not found of having a number of versions developed at the same time on an aircraft. It makes the work scattered on several projects, it also makes maintenance way more difficult. I don't know what other people think about this, Erik ? Anyway, if you have efficiency as a target, you'll consider working on existing versions (MLU, block 40 and 50) rather than adding a new one. Now, do you have good docs about the AFTI ?

- Nasal and pick animations: listeners are expensive. At run time it is lighter to call directly a nasal function from the XML binding. And yes it's a good idea to choose the used properties with care. I like sim/model/f16/controls/ICP/ and a name like depr-slider, gain-switch or num-8-button etc...

- The f16 has to be made compliant with Rembrandt for the next release (after 2.8, that is in 6 month) and it would be nice to have the liveries scaled to an affordable size, or even the model be properly remapped. If we decide to do so, this means some more work to do on each livery sets.

Cheers,
Alexis
If the engines are Pratt and Whitney, the seats best be Martin Baker
xiii
 
Posts: 472
Joined: Tue Jan 08, 2008 10:04 pm

Re: F-16 upgraded to 'production' status

Postby erik » Thu Aug 16, 2012 6:43 am

First of all It's nice to see others stepping up to update the F-16!
But there is already someone working on it:
http://wiki.flightgear.org/index.php?ti ... evelopment

Unfortunately he didn't announce it himself on the list or in the forums that I'm aware of. Which makes a collaborative effort a bit tricky.

To streamline things there is a git repository of the new model:
https://gitorious.org/flightgear-f-16

Please try to contact blackbird before going any further. it would be a pity to waste time on work that has already been done.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

Re: F-16 upgraded to 'production' status

Postby erik » Thu Aug 16, 2012 6:54 am

xiii wrote in Wed Aug 15, 2012 11:23 pm:- The f16 has to be made compliant with Rembrandt for the next release (after 2.8, that is in 6 month) and it would be nice to have the liveries scaled to an affordable size, or even the model be properly remapped. If we decide to do so, this means some more work to do on each livery sets.


Oh I did already remap the model, it's in Git. It indeed requires some of the textures to be adjusted accordingly.

Erik
erik
 
Posts: 1520
Joined: Thu Nov 01, 2007 1:41 pm

Re: F-16 upgraded to 'production' status

Postby Philosopher » Thu Aug 16, 2012 2:15 pm

Thanks for the replies, looking forward to doing this and my joystick stuff ;) (actually, developing is more fun than being bored).

xiii wrote in Wed Aug 15, 2012 11:23 pm:- About the f16 version: I'm not found of having a number of versions developed at the same time on an aircraft. It makes the work scattered on several projects, it also makes maintenance way more difficult. I don't know what other people think about this, Erik ? Anyway, if you have efficiency as a target, you'll consider working on existing versions (MLU, block 40 and 50) rather than adding a new one. Now, do you have good docs about the AFTI ?


I agree completely, this is not a case of divide-and-conquer. Especially since I really don't have much on the AFTI as it wasn't well documented. I do have some stats like 5 degrees of sideslip were possible in decoupled mode, but other than that it'd be mostly pure conjecture. Especially since there's A/A mode, A/A decoupled, A/G mode, A/G decoupled, etc., then there's the problem of vertical (relative to airframe) movement being managed.

I downloaded the Git version, and whereas it ran fine (40 fps) after a short wait when switching to external view for the first, it now drops to 3 fps any time I'm looking at the model from outside, even if I drop down all the effects. Could this be caused by the fact that I don't have Rembrandt? I might have jetways enabled, though ;). That might cost 4 fps ;). EDIT: this seems to be something in 2.6, I have previously used 2.4 and that's where the 40 fps was from, but in 2.4 it's the same outside and inside. Also, the MFDs don't work, and the only error I have (it's actually very clean compared to what I'm used to), is this:
Code: Select all
FlightRecorder: Cannot find file '/Aircraft/Generic/flightrecorder/generic-piston-propeller-4.xml'.
FlightRecorder: Configuration is invalid. Flight recorder disabled.
FGPropertyManager::GetNode() No node found for /gear/gear/wow
Nasal runtime error: undefined symbol: setlistener
  at /Applications/FlightGear.app/Contents/Resources/data/Nasal/aar_jsbsim.nas, line 48


I'll have to ask my parents for a Git account soon, so that I can contact blackbird and put in my changes.

In the meantime, I'll work on some smaller stuff, for example I saw an icp.xml in Models/Cockpit/Panels/ and one in Panels/ so I'll probably clean that up and see if it breaks something. I'll also add movement and thicken the buttons, especially the top row of circular ones, they should be at least a half-inch not 1/5 to 1/6 of an inch. Speaking of the ICP, I don't like how blackbird has it doing a update every 0.1 seconds, as this might be causing some lag issues especially with all those setprops :shock:. I would rather change it to an OOP where you say icp.com1(); or icp.update("COM1"); instead of updating and writing props. Do I have your permission to do this? Also, if I have an object icp in the file icp.nas that goes into the namespace f16, would I access the function foo in it with f16.icp.foo();? Or would it just be icp.foo();?
Last edited by Philosopher on Thu Aug 16, 2012 2:39 pm, edited 2 times in total.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: F-16 upgraded to 'production' status

Postby Hooray » Thu Aug 16, 2012 2:29 pm

xiii wrote in Wed Aug 15, 2012 11:23 pm:About the HUD: for symbology item (lines, dot and numbers) the contrast setting is not important, it is when the actual HUD displays ground images over the symbology, which is not possible yet in FG. DEPR will move the gun reticle up and down in the HUD, but there isn't a stock gun reticle available in the legacy HUD tools. I think the A-10 has a custom reticle as a 3D object aligned over FG HUD.
My best advice would be watch the Canvas development and wait to jump on the next/future implementation of the HUD using Canvas.


Yes, that's exactly what I was going to suggest, too - the Canvas system can already be used for implementing HUDs. And if your roadmap is targeting FG 3.0 in 6+months (i.e. Rembrandt), then most things for Canvas HUDs should be available already by then.

Now, regarding terrain overlays:
About the HUD: for symbology item (lines, dot and numbers) the contrast setting is not important, it is when the actual HUD displays ground images over the symbology, which is not possible yet in FG.


If I am understanding correctly, that would require an additional scenery camera rendering to a canvas texture, right?

If so, then that's been requested by a number of users, so it will probably be considered, but it may take a while (the original focus of the canvas was 2D drawing after all) - also, it would involve using OSG's CompositeViewer for multiple scenery cameras: http://wiki.flightgear.org/Howto:Use_a_ ... siteViewer

Currently, Tom is working on making the Canvas fully usable as a GUI replacement. As far as I know, nobody started playing around with the CompositeViewer yet, even though it's been a long-standing request on the devel list apparently.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: F-16 upgraded to 'production' status

Postby Philosopher » Fri Aug 17, 2012 3:28 pm

Two observations:

First, the canvas system should allow for a "real" 3D HUD, as the position will never change on the splitter screen. Second, the canvas should allow for more flexibility, as there as some things we can't do, as well as some things we haven't done. Namely, we don't have the negative bar angle (which the pictures on xflight.de have) that we could implement, as well as some angular things and symbols that we can't implement. The canvas will also need a symbol for a box w/ pointer so we aren't stuck using > and < for arrows and a three sided box for the rest. Here's the picture, so tell me why we don't have the negative bar angle? :raises eyebrow:
Image
Image
http://2004.uploaded.fresh.co.il/2004/08/25/926343.jpg (too big to post)

According to this video, the HUD has some interesting behavior, like how the heading angular instrument drops down with the flight path marker (note how the pilot is pulling 4 G's on the turns regularly). The ladder has dynamic origin as well. Then there's this circle with a line leading out of it, no idea what that is. (Note, the angular tape below the heading, with the arrow, in the picture above is bank angle)
http://www.youtube.com/watch?v=BHx-OWdHqf8

Also, when I've been flying today, I've noticed that the rudder seems to be broken. Doesn't move in external view nor do I see any effect when flying. On the quick view-over I didn't notice any issues, nor were there any on the console, but I'm short on time and hafta go.
Last edited by Philosopher on Sat Aug 18, 2012 1:03 am, edited 4 times in total.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: F-16 upgraded to 'production' status

Postby Hooray » Fri Aug 17, 2012 3:34 pm

Just briefly, like you say: the first two images should definitely already be doable with the current canvas implementation. Now, to implement what's seen in the 3rd image, we would probably benefit from being able to render scenery views still.

That being said, it might be possible to get a plausible effect by using some custom effects/shaders, such as Fred's night vision effect - it would only need to be enabled for the HUD obviously.

Also, the canvas system is not currently in any way integrated with the effects/shader framework as far as I know.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: F-16 upgraded to 'production' status

Postby Philosopher » Fri Aug 17, 2012 7:15 pm

Also, don't forget that we have to compensate for perspective. The F-15 with the radar HUD in fg doesn't do that, so the circles only line up with the aircraft at the center of the HUD. Also, with canvas we could do this: http://www.youtube.com/watch?v=oOa9eWgFllE. Just have to figure out how it works first. It does look rather complicated.... and notice how it is different from the other HUD, crazy greeks perhaps ;)?

P.S. Sorry for changing the post on you, I had hit submit too early: "Philosopher has edited this post 3 times"
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: F-16 upgraded to 'production' status

Postby Hooray » Fri Aug 17, 2012 7:21 pm


Regarding the video, I don't even know what all the lines and symbols are meant to show there... but from a functional point of view, it would be entirely possible to implement all that using Nasal scripting and the Canvas system.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: F-16 upgraded to 'production' status

Postby TheTom » Fri Aug 17, 2012 7:53 pm

I've put the code of my basic HUD into the Wiki. Maybe it can be useful as a base for more advanced HUDs:

Image
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: F-16 upgraded to 'production' status

Postby Hooray » Fri Aug 17, 2012 8:10 pm

TheTom wrote in Fri Aug 17, 2012 7:53 pm:I've put the code of my basic HUD into the Wiki. Maybe it can be useful as a base for more advanced HUDs:


Your Nasal code is really some of the clearest and most readable and comprehensible code that I have ever seen!
If we'll ever have a Nasal style guide, you should write it! :D

BTW: This is one of these cases where being able to set up canvas/group "defaults" would make the code even shorter, even if it's just implemented as a Nasal-space wrapper which copies props nodes.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: F-16 upgraded to 'production' status

Postby Hooray » Fri Aug 17, 2012 8:25 pm

Also, if I have an object icp in the file icp.nas that goes into the namespace f16, would I access the function foo in it with f16.icp.foo();? Or would it just be icp.foo();?


  • a file loaded into a namespace via the aircraft-set.xml file will be loaded into the specified namespace
  • if the file contains a top level (enclosing) hash/namespace, you'll still need to specify that

In other words:

  • a function "foo" in icp.nas will be available as f16.foo (because it's loaded into the f16 namespace)
  • a method/member "foo" in an "icp" hash in icp.nas will be loaded into the f16 namespace and available as f16.icp.foo()

For some more details, see:
http://wiki.flightgear.org/Creating_new ... Nasal_code
http://wiki.flightgear.org/Nasal_Namespaces
http://wiki.flightgear.org/Howto:Unders ... nd_Methods
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: F-16 upgraded to 'production' status

Postby Johan G » Fri Aug 17, 2012 10:05 pm

Philosopher wrote in Fri Aug 17, 2012 3:28 pm:...the canvas system should allow for a "real" 3D HUD, as the position will never change on the splitter screen...

As a HUD usually is a collimated device, showing the HUD image as if it was at infinite distance, the image will actually move around if you are moving around.

In practical terms that means that if you for example are using head tracking software, dynamic cockpit view or just adjusts your seat height, the HUD image should move in relation to the HUD combiner frame, but stay fixed in relation to a fixed point at infinite distance, say the horizon.

Short glimpse of the effect in a YouTube clip. Caution: LOUD

EDIT: The HUD image will also change size in relation to the combiner frame if you move away from it or closer to it.
Last edited by Johan G on Fri Aug 17, 2012 10:49 pm, edited 1 time in total.
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: 5509
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: F-16 upgraded to 'production' status

Postby mr_no » Fri Aug 17, 2012 10:18 pm

You may have noticed I created right MFD posted here. Use it if you want, or improve or change it. It's not nice to see the right MFD not working at all.
Mosquito-XE JT-5B-autogyro Extra-300s STOL-Ch701
User avatar
mr_no
 
Posts: 362
Joined: Thu Jan 19, 2012 2:20 pm

Re: F-16 upgraded to 'production' status

Postby Philosopher » Sat Aug 18, 2012 12:59 am

Very nice HUD,

And the answer is: of COURSE it can be used. And +1 to style guide, with you (helping) write it. I particularly like the comment style where there's a space after the # than a capital, e.g. # Hello world. I do most of mine as #hello world, but I'll change it now!

One thing I forgot to mention in the earlier post is that there's this function in the existing HUD that takes the input and applies a EWMA filter to it to reduce jitter, each correction takes the old, de-jitter-ized value and adds a factor of he new value to it, each update. This would be really helpful to have in the new HUD. Something like this (composed on my iPod, so no guarantees):

Code: Select all
# EWMA function
#usage: prop is the property to fetch and apply EWMA to; gain is the amount of jitter reduction, higher is more; damped is the previous return of this function
var getDampedProp = func(prop, gain=0, damped=0) {
    var coeff = 10^gain;
    if (getprop(prop) == nil) {
        return 0; #jut in case it doesn't like nil as a value
    } elsif (gain = 0 or damped = 0 or damped = nil) {
        return getprop(prop);
    } else {
        var damped = (1-coeff)*damped + coeff*getprop(prop);
        return damped;
    }
}
# Usage
agl = getDampedProp(prop, 2, agl);

The problem is that the Original Code was written in c++ and uses internal (private) properties, instead I have to use the previous returned value.

Thanks for the reply Hooray. It's better than trial-and-error, which is most of how I program ;).

Sorry for that, Johan G, I just knew I was going to be wrong as soon as I posted it, but I ignored my sub-conscious saying "Don't talk about things that you don't know!" Well, as I said before after forgetting my brother's music for him, at least we learn from our mistakes :P. Thanks for the correction. I stand corrected, and stand down. I'll keep my mouth on things I can test, like Nasal ;).
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: AhrefsBot [Bot], slawekmikula and 16 guests