Board index FlightGear Development Aircraft

More realistic Blackout/Redout

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

Re: More realistic Blackout/Redout

Postby Necolatis » Thu Nov 17, 2016 3:50 pm

Actually 2 parameters might not be enough, just found in paper something about vertical FOV narrowing faster than horizontal. Hmm..
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 2233
Joined: Mon Oct 29, 2012 1:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2020.3.19
OS: Windows 10

Re: More realistic Blackout/Redout

Postby Thorsten » Thu Nov 17, 2016 4:33 pm

Btw. Richard has made a canvas HUD, you just need to update from FGAddon.


:oops: Sorry about the noise then... I'll update to most recent (there's actually no particular reason I've rendered the demo with the F-16 except that I like it a lot and it seemed to have the right style)

Actually 2 parameters might not be enough, just found in paper something about vertical FOV narrowing faster than horizontal. Hmm..


If there's a fixed function connecting them so that when you know horizontal FOV if you know vertical (aka, if the shape has no time history), then we can still hard-code this with one parameter.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: More realistic Blackout/Redout

Postby Thorsten » Thu Nov 17, 2016 6:58 pm

@Necolatis: Next branch is open for development - how are we doing with the menu update? I suggest getting a version utilizing the default redout/blackout visuals on the server first and then working on the more fancy version.

I am ready to handle this tomorrow if we have something committable by then :-)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: More realistic Blackout/Redout

Postby Johan G » Thu Nov 17, 2016 8:09 pm

Necolatis wrote in Thu Nov 17, 2016 2:55 pm:I have to see if the paper has some good hints to how this should relate to blackout, Gs and time spent there, I am thinking this comes first and I can delay blackout compared to when your filter is not active. That also might make blackout more scary as it will come less gradual. Something is in appendix that seem to hint that tunnel vision should relate rather directly to Gs (page 429, but its for relaxed subject, so I guess not someone doing anti-G breathing). I will have to read it more closely.

Regarding Gs and time spent there vs. that tunnel vision would relate directly to Gz, there is a slightly obscure diagram on p. A-22 (p. 241 in the pdf) sometimes known as a Stoll diagram.* A much more legible diagram can be found in the article G-induced Impairment and the Risk Of G-LOC at EUROCONTROL's SkyBrary.

It would seem that the onset of grayout, blackout and unconsciousness is dependent on how fast the Gs rises. In essence a very high but short burst of Gs can easily be handled, while a more prolonged exposure to acceleration can not, even if is applied slowly.

If one consider that this mostly is about the lack of oxygen that would seem rather logical (in fact lack of oxygen specifically from vertical acceleration is sometimes called stagnant hypoxia). IIRC the effects of hypoxic/altitude hypoxia in is pretty much identical to the effects caused by vertical acceleration (which is my way to give a hint that the greyout and blackout filters could be reused if there would be a framework simulating hypoxic hypoxia, for example caused by flying too high without oxygen or due to decompression).

A more in depth description of that curve is this paper: On the Theory of Acceleration Tolerance.

Necolatis wrote in Thu Nov 17, 2016 3:50 pm:Actually 2 parameters might not be enough, just found in paper something about vertical FOV narrowing faster than horizontal. Hmm..

That was my impression as well from the diagram on p. 65 (p. 81 in the pdf).
Thorsten wrote in Thu Nov 17, 2016 4:33 pm:If there's a fixed function connecting them so that when you know horizontal FOV if you know vertical (aka, if the shape has no time history), then we can still hard-code this with one parameter.

That is most probably a fixed function.

* I am a bit annoyed that I seem unable to find the original paper, though I see it often referenced.
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)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: More realistic Blackout/Redout

Postby Hooray » Thu Nov 17, 2016 8:13 pm

Regarding the code, you may also want to overload getprop() at the module level to make sure that it always returns a numerical value (i.e. 0.00) because it's used in tons of places to do calculations without them checking if the value is NaN, see the section on defaulting at: http://wiki.flightgear.org/Nasal_Conditionals

Besides, I am not sure if the instructions should suggest to copy the file to the aircraft directory, it would seem to make more sense to get this commited to the Generic folder and provide a stub for including it via the -set.xml file

PS: To check if any of your loops are getting called unnecessarily, add log/print statements to the corresponding functions/loops.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: More realistic Blackout/Redout

Postby Johan G » Thu Nov 17, 2016 8:19 pm

Just found this paper that may come in handy: Thomas W. Moore, Dov Jaron, Leonid Hrebien, and David Bender, A mathematical model of G time-tolerance, 1993. :wink: :D

Edit: This paper have some interesting conclusions towards the end in respect to the Stoll curve. Neither their model, nor their accelerator experiments seem to indicate that there is such a thing as the dip apparent in the classic Stoll curve. They also point to other research with the same conclusions (i.e. no dip). They give a hint that it may be an artefact from a simple human error when graphing (and cargo cult science?)...
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)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: More realistic Blackout/Redout

Postby Thorsten » Fri Nov 18, 2016 7:08 am

Besides, I am not sure if the instructions should suggest to copy the file to the aircraft directory, it would seem to make more sense to get this commited to the Generic folder and provide a stub for including it via the -set.xml file


Why don't you read the thread... The plan is to commit a property-rule based version to FGData to replace the current system.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: More realistic Blackout/Redout

Postby Necolatis » Fri Nov 18, 2016 8:00 am

Nice finds Johan G. :)

As for the ratio of tunnel vision, it would seem from a quick glance on one of those pictures that maybe around 6:5 (width:height) would be reasonable. It seems though at a very narrow field that two islands should be visible, one for each eye, but I think that can approximated by still just having 1 circle (or oval rather) and therefore blind spot not need to be modeled in my opinion.
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 2233
Joined: Mon Oct 29, 2012 1:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2020.3.19
OS: Windows 10

Re: More realistic Blackout/Redout

Postby Thorsten » Fri Nov 18, 2016 8:27 am

We are technically limited to a 'simple' shape that we can describe with a fast 'distance from center' function. A circle is trivial, an ellipse will do, two islands may be too tricky.

(It's not that I can't code more complex functions, but they get progressively slow to evaluate, and we will have the filter run over every pixel on the screen, usually there's a lot of them...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: More realistic Blackout/Redout

Postby Johan G » Fri Nov 18, 2016 8:51 pm

Necolatis wrote in Fri Nov 18, 2016 8:00 am:It seems though at a very narrow field that two islands should be visible, one for each eye, but I think that can approximated by still just having 1 circle (or oval rather) [...]

While I am not 100% sure I think that in real life one would quite possibly be a bit cross-eyed at that point without consciously thinking about it, so I think just a circle would be quite ok.
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)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: More realistic Blackout/Redout

Postby Necolatis » Sun Nov 20, 2016 8:06 am

Thorsten wrote in Thu Nov 17, 2016 6:58 pm:@Necolatis: Next branch is open for development - how are we doing with the menu update? I suggest getting a version utilizing the default redout/blackout visuals on the server first and then working on the more fancy version.

I am ready to handle this tomorrow if we have something committable by then :-)


Sorry, I completely missed this post.

The menu don't have to be changed. I am using the old parameters plus some new.

For me to test it though, I would like to know where to place the property-rule file, and where to mount it into the system?

Edit: I see some other rules mounted inside preferences.xml, I could mount it there.
Last edited by Necolatis on Sun Nov 20, 2016 8:34 am, edited 1 time in total.
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 2233
Joined: Mon Oct 29, 2012 1:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2020.3.19
OS: Windows 10

Re: More realistic Blackout/Redout

Postby Thorsten » Sun Nov 20, 2016 8:34 am

Sorry, I completely missed this post.


No stress - I was in maintenance mode with everything anyway, so it would have been quick to do, but it's not a problem, whenever you're ready with it.


So: In preferences.xml is the section

Code: Select all
    <systems>
      <path>Aircraft/Generic/generic-systems.xml</path>
      <autopilot>
        <name>generic autopilot</name>
        <path>Aircraft/Generic/generic-autopilot.xml</path>
      </autopilot>
      <autopilot>
        <name>autopilot helpers</name>
        <path>Aircraft/Generic/generic-autopilot-helper.xml</path>
      </autopilot>
      <property-rule>
        <name>Environment METAR Interpolation Rule</name>
        <path>Environment/metarinterpolator.xml</path>
      </property-rule>
      <property-rule>
        <name>Environment Interpolation Rule</name>
        <path>Environment/interpolator.xml</path>
      </property-rule>
      <property-rule>
        <name>Local Weather Rules </name>
        <path>Environment/local-weather-rules.xml</path>
      </property-rule>
    </systems>



is where the property rules are initialized. You'd add yours as

Code: Select all
      <property-rule>
        <name>g force effects</name>
        <path>Aircraft/Generic/g-forces.xml</path>
      </property-rule>


(I think Aircraft/Generic/ is a good location for this). Any additional parameters you define also get declared in preferences.xml at the appropriate depth in the hierarchy - if there's many of them, you can put them into an extra file and do an <include= >.

Finally, I think to avoid possible interferences, Nasal/redout.nas has to be removed or at least disabled.

And that should be it.


With regard to the filtered version, I can quickly give you a test setup in which the radii of inner and outer terminus are passed via a hack (i.e. by overriding filter brightness and gamma) so that you can play with it and change settings for visuals runtime, and then we can have a clear idea what actual set of changes I need to make. Similarly to the way the night vision works, we can also add some noise to the center portion to see whether that gives a credible impression of blurriness.

For efficiency reasons, I'd like to have the actual number of parameters passed to the shader as low as feasible without flooring performance - so whenever there's a simple way to encode two things into one parameter, I'd prefer to do that.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: More realistic Blackout/Redout

Postby Necolatis » Sun Nov 20, 2016 8:38 am

Thank you.

redout.nas, cannot be removed, it also contains the headshake. But I have factored out the blackout/redout parts.

A test setup would be nice. In meantime, I am going to test the code I have, and check that everything works as it should.
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 2233
Joined: Mon Oct 29, 2012 1:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2020.3.19
OS: Windows 10

Re: More realistic Blackout/Redout

Postby Necolatis » Sun Nov 20, 2016 10:22 am

It seems to work. When its time to get it committed will you do that, or shall I make a merge request?

It is here if you want to take a look/tryout:

https://drive.google.com/open?id=0B49qitQsNy34aHl1OWZTcEdsbFE
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 2233
Joined: Mon Oct 29, 2012 1:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2020.3.19
OS: Windows 10

Re: More realistic Blackout/Redout

Postby Thorsten » Sun Nov 20, 2016 10:42 am

When its time to get it committed will you do that, or shall I make a merge request?


Either works for me (and I need to test it in either case anyway) - so the linked package will do for me.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 14 guests