Upon examination I think it looks like perhaps all they’ve done is place the HUD texture in front of the glass rather than on it, then culled the parts that don’t overlap. We see from the right shoulder position that the HUD imagery has seemingly shifted off the left edge.
With a parallax free hud (or even just a texture placed beyond the glass rather than infront) we would see it shift off the right edge when moving to the right (you can see this demonstrated in real time in the gif you linked in the other thread).
It is a mistake to claim Asobo for their poor SDK talking about collimation.
In the 787 HUD script (“\Asobo-vcockpits-instruments-b787-10\html_ui\Pages\VCockpit\Instruments\Airliners\B787_10\HUD\B787_10_HUD.js”) there is a code that calculate pilot viewpoint relative to HUD glass and move symbology to simulate collimation effect (updateProjection function). I have tried same trick on custom aircraft months ago and it worked pretty well.
But can 3rd parties also use this function?
I think this also could partially explain the somewhat weird looking of the 787 HUD…and in the video, it looks like the IAS and ALT bars are not moving.
And what about the “distance”/depth of the image? Is there any parameter can be played with? It appears very close to the glass instead of being in distance.
Interesting, and good on you for finding that. Could you possibly please post a video clip of what it looks like in one of these custom aircraft with this code modification (like hitting Win+G and using the capture->start recording function real quick)?
The newest Developer Q&A Twitch is out. Unfortunately, my questions about HUD (and windshield wiper) were not picked up. It is frustrated that these issues will still remain mysterious. I’ll try to post them again in the question collection of next dev Q&A.
Here’s a fun one - just been flying the updated milviz corsair, their gun sight is parallax free.
It is not quite perfect as they don’t cull it when it leaves the glass display, but in terms of the parallax free side of things it stays perfectly on target as you move your head from side to side or up and down.
Interesting. It sounds like some fsx-converted aircraft. The way they implement the HUD imagery is the same as in fsx/p3d, i.e. put the imagery in “another dimension (mirror world)” few meters in front of the cockpit, and make it only visible through the combiner glass. The only difference is, in the current MSFS, the imagery can’t be culled when it leaves the glass. And it doesn’t seem to be how the default 787 doing it per a thread above.
Sorry, so busy - had no chance to play with this script yet, hope soon.
That is correct - only difference, in FSX/P3D “HUD pyramid” crop the dynamic texture so you have proper illusion, but in MSFS it does not work that way. It’s weird devs still using this method.
Tutorial about how to reuse Asobo collimation script in 3rd party aircraft. Result far away from perfection because I haven’t tried to set precise head and HUD glass position, which should be not a problem for developer which have 3D model sources. Calculations can be easily improved as long as JS has rich math library.
This script sitting there for a long time. I don’t want to throw stones into fellow developers, but this is the case, when you should not follow the trend and investigate problem by yourself until the end. Several quotes:
# Lockheed Martin F-22A Raptor: Top Mach Studios Freeware Edition@evanburnsdev
Nice find. Yes the 787 hud code does point you in the right direction for collimation/parallax. I can tell you that even with the 3d models it is very difficult to get correct. There is also an option in the panel.cfg: the line that starts with hud= affects collimation as you adjust those values as well, but doing it within javascript gives you much more control over it.
The limitation that we’re currently running into is the hud glass is concave, so the image should skew along with shifting as the eypoint changes. This might be something we can emulate with wasm gauges, but I don’t think javascript has the functionality for this amount of detail.
And to respond to your statement about investigating problems: We do investigate on our own and have seen the 787 code you showed in your video(along with our code I might add). But we’re not going to make promises to users about finding a working solution for collimation until we have it tested and 100% functional.
I like the idea shown here in the video, but the problem remains:
the gauge render code updates at a lower fps than the game render code and therefore any code based solution meant to offsetting the drawing will always lag.
this technique doesn’t work in VR at all and is actually worse than a fixed drawing on the glass window.
The only solution for a true collimated HUD is simple:
draw at a longer distance so that it is collimated when in VR
don’t render the drawing when viewed outside a clipping plane (4 of them in a pyramidal fashion).
make the surface onto you’re drawing the HUD a special gbuffer render surface so that it doesn’t show objects passing between the surface and the viewpoint (in other words, draw far away but with write the depth buffer with the near clipping plane value for example so that nothing gets drawn over)
With the current SDK you can do the former already: just add a floating window far away like in the MilViz Corsair and draw onto it. The illusion is perfect and works in VR.
As for the latter, there is no “render clipping planes” support that I know of in the SDK, but you can still clip the drawing when viewed outside a clipping plane.
CptLucky8: the gauge render code updates at a lower fps than the game render code and therefore any code based solution meant to offsetting the drawing will always lag.
Any chance the July 27th update with putting various cockpit display rendering in a separate thread might help with that issue?
It would be nice if Asobo could write an official native function in the code for this so that all these back door workarounds aren’t necessary, but I’m not sure how easy it would be for us to convince them to get it in the queue of things to work on at this point…
Proper HUD collimation is still not possible in MSFS.
In a sim that now has multiple fighter jets and airliners that are HUD-equipped, not to mention a default airliner that is HUD-equipped, it makes no sense to not have a system implemented to allow it. Especially when it has been supported in legacy simulators like FSX.
I imagine PMDG won’t release the 737 until it is possible, so perhaps they found a way around it. But the Aerosoft CRJ HGS is basically unusable despite a pretty good implementation by Aerosoft, which is a real shame.
I don’t remember any collimated HUD in the default FSX aircraft in virtual cockpit. Maybe my memory is a little fuzzy since I last fly FSX 15 years ago.
Despite having 114 votes, fixing the HUD issue does NOT show up in the Snapshot Feedback list. It does appear that a number of issues with far fewer votes DO show up in the list. I’m not sure but I think Asobo shows this issue as resolved, despite the fact that it isn’t.
…
