Feature Request: TDZ Lights

[Jeroen Hoppenbrouwers]

The positions of these squares, are they calculated every frame by an algorithm that knows how to paint a pattern given a runway begin/end point, or is this pattern calculated once as the runway gets nearly in sight and then stupidly dropped in a table for stupid, but fast repainting every frame?

The distance-dependent size and alpha of course remains a heavy burden for each frame.

I think this is going to be a dead end. But if not, it opens up a slew of creative possibilities  :-)

[Hardy Heinlin]

When a nearby runway is loaded from the nav database, PSX generates dot objects (squares) for that runway; every dot object gets planet related, static lat/lon/alt values (in the program, not on the screen). These will be continuously retransformed to 2D-windshield projection coordinates in every time frame, referring to the current flightdeck lat/lon/alt, heading and attitude. The transformation happens in PSX, not in the graphics card -- in case that's what you are thinking about.

So there are 3 actions:

1. Generate 3D dot position data for the planet (whenever the aircraft has travelled some miles)
2. Calculate 2D monitor projection objects (in every time frame)
3. Send the projection objects to the 2D graphics card

(Note that "2D" in this context means what it is: 2D. All our eyes look at 2D screens, even within Virtual Reality helmets. We are not on Star Trek Holodecks yet.)

|-|

[Jeroen Hoppenbrouwers]

Ok, this is what I thought you had done. It means that theoretically it could be possible to extend the system with one more step and then theoretically have freedom to paint whatever until the CPU blows up.

Step 1 could get a step 1b:

1b. Look up which Special Dot Files are within range and if within range, load the individual dots specified in that file, by lat/lon/alt/colour, into the same table as the 3D planet dots.

I have absolutely no idea what impact this would have on steps 2 and 3. Maybe you could for fun add a large flat plane of dots, like 5 km by 5 km with a dot every 10 meters, that would be 250 000 dots, and see what that does to the frame rate.

It won't solve the PAPI challenge but for static approach lighting it may offer a DIY option.


Hoppie

[G-CIVA]

Or we could give HH a break & home build another PC as a scenery generator & run the academic version of something like p3Dv4/5 integrate it with PSX on its own PC 

Only joking 🙃 

[Tom Gorzenski]

The scenery loader just scans the runway database, not the ILS database which has the G/S position. So it would require an additional database scan and matching algorithm solely for the purpose of adding two further cosmetic dots in an already extremely simplified "dot scenery". -- I want to keep the style of the simplification consistent. As soon as one object looks 100% realistic, all other objects will look like errors. Like a photo-realistic ear on a picasso-esque face abstration. I doubt anyway that your landings will improve just because you see 4 instead of 2 dots.

I believe it would - just like in real life, where PAPI allows for a more precise descent along the glide path, as it allows for gradual signaling of deviations from the glide path. Moreover Hardy, please note, it is not unusual, especially on short final, to observe that PAPI indications differ from the ILS glideslope indications - for some runways they do not coincide precisely (they are supposed to coincide to the maximum possible extent, but due to variety of reasons, they not always do). So there is nothing to worry about. Why not tie the generic 3.00 deg PAPI more or less rigidly to the distance (1000 feet) from the runway threshold? So, the runway database would be sufficient to scan. Basically we would get 4 lights instead of 2, that's all what is proposed.
However I am not familiar with software challenges to meet this goal - please excuse my ignorance.

[Hardy Heinlin]

Why not tie the generic 3.00 deg PAPI more or less rigidly to the distance (1000 feet) from the runway threshold?

This is already implemented. Most real life systems refer to a threshold overflight at 50 ft AGL at 3°, and that's also the standard in the PSX visual "PAPI" simplification.

As I explained above, I want to keep the style of the simplification consistent in the entire windshield. None of the runway light rows are complete (edge lights, center lights, stop lights etc.). Either all or nothing.

[evaamo]

1b. Look up which Special Dot Files are within range and if within range, load the individual dots specified in that file, by lat/lon/alt/colour, into the same table as the 3D planet dots.

I have absolutely no idea what impact this would have on steps 2 and 3. Maybe you could for fun add a large flat plane of dots, like 5 km by 5 km with a dot every 10 meters, that would be 250 000 dots, and see what that does to the frame rate.

I remember writing back in 2018 something along the lines in this forum:

"- A modification in PSX that would allow reading from a (set of) file(s) a format comprised of a set of points (lat/lon coordinates, altitude, color, blinking or not...something of sorts) that could become part of the scenery and be displayed by PSX graphics engine natively. Then, it being an open format, we could develop a 2D editor for building taxiways, beacons, obstructions, even gates or parking stands not shown on the actual gates DB.  Maybe even read a BGL file (not too difficult) and generating the necessary taxiway lines in PSX format. "

<nudge nudge>  Hardy!!!

Have a great new year, guys!
-E

[Hardy Heinlin]

By the way, did you guys notice that the 2-lamp PAPI lights in PSX cannot only be white or red but also rosy?

So there are 5 levels:

white - white
rosy - white
red - white
red - rosy
red - red

But the rosy sector is very small. It's just to get a smooth transition between white and red. I could make that rosy sector larger according to the real PAPI sectors, so that the sectors are equally separated.

[United744]

By the way, did you guys notice that the 2-lamp PAPI lights in PSX cannot only be white or red but also rosy?

So there are 5 levels:

white - white
rosy - white
red - white
red - rosy
red - red

But the rosy sector is very small. It's just to get a smooth transition between white and red. I could make that rosy sector larger according to the real PAPI sectors, so that the sectors are equally separated.

Yes I had. I thought it was related to blending artifacts between red/white rather than a defined segment though.

[Tom Gorzenski]

By the way, did you guys notice that the 2-lamp PAPI lights in PSX cannot only be white or red but also rosy?

So there are 5 levels:

white - white
rosy - white
red - white
red - rosy
red - red

But the rosy sector is very small. It's just to get a smooth transition between white and red. I could make that rosy sector larger according to the real PAPI sectors, so that the sectors are equally separated.

Interesting, good to be finally sure what that phenomena is, but there is no real life equivalent of such system. I mean, what we have now in PSX is actually APAPI system (modified with an additional rosy color as a substitute of more precise guidance delivered by 4 PAPI units).

I.a.w. ICAO Annex 14, APAPI can be used only for instrument runways with reference code digit of 3 and 4 (reference takeoff distance 1200-1799m for "3" and 1800m and more for "4") with non-precision approach only. If there is a precision approach, no matter what runway lenght, a more precise guidance systems than APAPI or straight VASI is required, like T-VASIS or AT-VASIS, with PAPI being preferred worldwide, however. This is why I don't feel happy with APAPI in PSX, even though now you have explained that it is a PSX-only modified APAPI in order to deliver more precise guidance than 2 units of a straight APAPI.

I understand that the only reason we don't have PAPI in PSX is your personal preference of such greatly simplified outside world representation, and this is not about any software issue, or increased computing power requirements. If we can't get PAPI, then yes - please make the rosy sectors larger to match PAPI's 3 reds/1 white and 1 red/3 whites sectors. Alternatively, please use amber instead of rosy.

BTW, you can make it even more simplified - why not to use PVASI or tricolor VASI? Advantage is, both of them are real life systems used at smaller U.S. airports. And computing power needed would be even lower.

PAPI and APAPI sectors (4 and 2 light units respectively):
https://www.easa.europa.eu/sites/default/files/online-publications/EasyAccessRulesforAerodromesRegulationEUNo1392014Revisionfro-75.png

AT-VASIS (10 light units):
https://www.dst.defence.gov.au/innovation/tee-visual-approach-slope-indicator-system-t-vasis
https://youtu.be/3LRF_fJLNq4

PVASI (Pulsating VASI) (single light unit)
https://www.faa.gov/air_traffic/publications/atpubs/aim_html/images/aim_img_98ac7.jpg

Tricolor VASI (single light unit)
https://www.faa.gov/air_traffic/publications/atpubs/aim_html/images/aim_img_eee93.jpeg

[Hardy Heinlin]

modified with an additional rosy color as a substitute of more precise guidance delivered by 4 PAPI units

No, it's not for more precision. It's just an anti-flicker intermediate step, only 0.0001° wide. The real thing must have a (tiny) transition zone as well as its size is greater than zero.


Well, OK, guys ... I'm in the mood for a little cosmetic work today. I'll try to add two more lamps for a 4-lamp PAPI today. But that's all. No TDZ etc.

And I'll remove that rosy transition as I guess it's of no use anyway.

[United744]

modified with an additional rosy color as a substitute of more precise guidance delivered by 4 PAPI units

No, it's not for more precision. It's just an anti-flicker intermediate step, only 0.0001° wide. The real thing must have a (tiny) transition zone as well as its size is greater than zero.


Well, OK, guys ... I'm in the mood for a little cosmetic work today. I'll try to add two more lamps for a 4-lamp PAPI today. But that's all. No TDZ etc.

And I'll remove that rosy transition as I guess it's of no use anyway.

Thank you!!

[Jeroen Hoppenbrouwers]

No, it's not for more precision. It's just an anti-flicker intermediate step, only 0.0001° wide. The real thing must have a (tiny) transition zone as well as its size is greater than zero.

"not more than three arc minutes" I believe on the real thing.

[simonijs]

PAPI - or any other (simplified) visual approach guidance system - is not to be used for landing the aircraft, it is there to stay away from (obscured) obstacles in the approach path. Once the aircraft is within the obstacle free airport perimeters - and by the latest overhead the threshold - the pilot will start focussing on the runway aiming point itself. (S)He won't be looking that much at PAPI lights anymore.

If you look at the picture below, with a 747 exactly following the electronic glidepath, the pilot of this 747 will see a completely different "image" of the PAPI lights than the pilot of a C-172 or B-737 following the exact same electronic beam. If I recall correctly, PAPI's are set to show the correct 3 degrees "two white-two red" eye level path for the type of aircraft that most frequently lands at that particular airport.

Source: KLM's (obsolete) AOM

Flaring the aircraft will change the perspective of what you see from the PAPI, i.e. if you keep focussing on those lights. Touchdown will occur with the cockpit already passed the PAPI lights. PAPI and TDZ lighting are two different topics. By the way...: some airports have a 3 degrees electronic glide slope, but a 3,2 degrees PAPI system (which is worth some attention in the approach briefing).

Another picture for a non-precision approach below; in this case KLM recommended to choose an aiming point some 600 meters from the runway threshold. No word in the manual on how to interpret PAPI lights, since the aircraft already is overhead the threshold.

Same source

Regards,
Simon

[Will]

The scientist in me wants to get some pilots and a NASA-level simulator(*) and test this empirically. Let's look at 100 landings made using all possible visual cues, and then start removing the visual cues singly and in combination, until we determine what part(s) of the sight picture really contribute to good, safe landings.

(We could also poll the pilots to see what contributes most to a sense of "immersion" in the simulator environment, and it would not surprise me at all if "immersion" and "safety" are goals that are best met in different ways.)

*) Does NASA have good simulators?

[Jeroen Hoppenbrouwers]

*) Does NASA have good simulators?

At least one.
https://www.nasa.gov/mission_pages/shuttle/behindscenes/shuttletrainingaircraft.html

[Tom Gorzenski]

modified with an additional rosy color as a substitute of more precise guidance delivered by 4 PAPI units

No, it's not for more precision. It's just an anti-flicker intermediate step, only 0.0001° wide. The real thing must have a (tiny) transition zone as well as its size is greater than zero.

Well, OK, guys ... I'm in the mood for a little cosmetic work today. I'll try to add two more lamps for a 4-lamp PAPI today. But that's all. No TDZ etc.

And I'll remove that rosy transition as I guess it's of no use anyway.

Thank you Hardy! Having PAPI instead of APAPI will make visual portions of those pesky NPAs, circling finals, and visual approaches easier and better stabilized by detecting vertical deviations faster that requires less elevator and power adjustments, since the PAPI's "on glidepath" (2 reds/2 whites) sector is 1/3 narrower than that of APAPI - 20' vs. 30'. Additionally, PAPI provides significant deviation warning, while APAPI does not.

And yes, of course - my mistake - I intended to write about the POTENTIAL use of those rosy (or better yet - amber) sectors, as equivalent of 3 reds/1 white and 1 red/3 whites sectors of PAPI by making them equally wide, 20 arc minutes to be exact.

[Hardy Heinlin]

And I'll remove that rosy transition as I guess it's of no use anyway.

I've changed my mind; I'm keeping that rosy transition in the 4-lamp PAPI as well which I just implemented. With that smooth transition it looks more realistic, even if the rosy sector is just 3 arc minutes wide.

[alcannata]

I agree: excellent idea (IMHO)!
Thank you Hardy for each development of PSX.

Aldo

[Tom Gorzenski]

And I'll remove that rosy transition as I guess it's of no use anyway.

I've changed my mind; I'm keeping that rosy transition in the 4-lamp PAPI as well which I just implemented. With that smooth transition it looks more realistic, even if the rosy sector is just 3 arc minutes wide.

Perfectly fine with me. Many thanks Hardy.

P.S. that rosy thing reminds me of FedEx Flight 1478 crash. Despite putting all the blame on FO's deficient color vision and crew fatigue by the NTSB, not everybody got convinced - there was a certain issue with the PAPI lights involved in the crash, due to their design (or a malfunction) and high humidity which caused condensation of water on the PAPI front lens inner surfaces, resulting in significant PAPI color characteristics change - if I remember correctly. And there were two other crew members in the cockpit - nobody said a word, even though they got low enough for the PAPI to display 4 reds for quite a long time.
https://www.cvdpa.com/images/news/uploads/Pape_and_Crassini_2013_The_Puzzle.pdf