LM AOT Spiral Inaccuracy about nassp HOT 8 CLOSED

Oh wow, this is something we have been issues with for quite a while. We just couldn't figure out what was wrong with the spirale code or the AOT view. Your solution sounds very plausible, thanks so much for working that all out! I'll get to work testing and implementing this.

from nassp.

Great find! Also does your monitor give any display issues with the LPD panel? It is 1080p vertical.

from nassp.

Initial test resulted in +000.06 star angle difference. I'm pretty rusty when it comes to P57s and that is much better than what I usually got with option 2 (two celestial bodies) before. The +000.70 you mentioned was about the error we were all getting before with P57. So I'm quite confident that you figured out this issue, which we've been having for a quite a while. Thanks again!

Feel free to drop by anytime in the NASSP IRC channel, #nassp on freenode. That's where NASSP developers and users are hanging out most of the time.

from nassp.

So one issue with the variable FOV are resolutions beyond 1050 pixels in height, like 1920x1080. The bitmap actually gets stretched in that case, so an maybe an upper limit for the aperture calculation has to be used in that case?

from nassp.

@jalexb88 Previously I've only thrown a few (semi)manual landing in P67 mode after pitchover, so I didn't care too much of the LPD. But as you asked, I played a bit with the Apollo 17 PDI scenario in the WIP section and let the PNGS do the job till touchdown. And yes, if I set the screen FOV to 57.39, to align the 1080p with the 60 degrees FOV then the LPD value on the DSKY is within a +-1 degree match with the future landing point seen on the LPD scale. I am quite surprised if not amazed on the accuracy of this whole stuff :)
Anyway I'd greatly appreciate if a similar adaptive FOV calculation for the LPD as I have made for the AOT reticle would be included in an upcoming release.

from nassp.

@indy91: yes, I considered that issue with stretching but I wasn't sure how Orbitersim handles the smaller-than-resolution bitmaps. But if it handles in the way you described then instead of
oapiCameraSetAperture(atan(tan(RAD * 30.0) * h/1050.0));
this could be used:
oapiCameraSetAperture(atan(tan(RAD * 30.0) * min(h/1050.0, 1.0) ));
and everybody will be happy :)

from nassp.

The code seems to work, even at very high resolution such as my UHD monitor (3840x2160) the AOT window is stretched to fill the entire height of the screen and FOV stays at 60. I also tried the new FOV handling on the LPD panel, but with oapiCameraSetAperture(atan(tan(RAD * 30.0) * min(h/1080.0, 1.0) )); as that bitmap is 1080p, then tried with lower then 1080p resolutions to see if FOV is lowered correctly and sure enough it works nicely.

from nassp.

Tested the a584212 commit and the AOT measurements are fine on my machine.

I've seen that the FOV calculation for the LPD window is not changed yet, and I suggest to leave as it is (contrary to my previous request). The reason is that I discovered in the LM Timeline checklist that the P52 has an LPD calibration feature, so the LGC should cure a few percent FOV deviance by itself.

I am happy to close this issue now. Thanks for your efforts put into this nice and enermous project!

from nassp.