Closed colingeniet closed 3 years ago
The shader is pretty much done. There are still many things which broke in the canvas part, I'm afraid debugging that will be time consuming.
I actually have a major issue with the effect: the shader is disabled when ALS is turned off. This means that with ALS off, the HUD is rendered the normal way, and is not properly aligned.
Keeping the HUD aligned (at least in default head position) both with the shader off and on seems like a nightmare, and would not help with porting to other aircrafts. I wonder if it would be reasonable to have a low-spec version of the shader, which would be used with lower rendering settings.
Just let the shader work even when ALS is turned off and model shader is turned off.
You can set that in the <predicate>
I know how to do it from the technical point of view, this was more of a design philosophy question: is it acceptable to disregard the user shader quality settings for this shader, because it is for functionality, not just aesthetics?
I will raise that to the FG forums, and hopefully get the opinion of the shader gurus.
Well I sort of got an answer, while accidentally triggering a strong discussion about whether or not it is acceptable to make shaders mandatory in FG: https://forum.flightgear.org/viewtopic.php?f=47&t=37456&p=367891
What I will try is to keep the HUD in its old state (maybe slightly degraded) for users with ALS and shaders disabled. Essentially, have a couple of top-level canvas transformations for when the shader is disabled, and toggle them as required. Not as clean as I hopped...
Closing. I won't merge it in this state, but will reuse it as part of HUD rework.
Uses the shader to do a parallax effect, instead of applying a transformation in canvas. Advantages:
(a,b)
from the aircraft centerline (relative to the view position) is mapped to(tan(a), tan(b))
in the texture space. This continues to work no matter the shape of the object used as hud. In particular, a slanted surface can be used without deformation.To do:
-x
axis in the model space. Unless the hud object is rotated, this corresponds to the aircraft forward axis. I think it actually makes sense to use the model space here: rotations applied to the hud object will be taken into account. However I need to add parameters to tweak the axis (essentially an additional rotation matrix).hud.nas
, but of course they are messed up right now.(a,b)
-> coord(tan(a), tan(b))
on the texture). This is in part because it's the simplest to implement, and in part because it was what we had before. I'm not sure if this is really the correct choice. It would be easy to change it, for instance to use 'angle space' (angle(a,b)
-> coord(a,b)
on the texture). My main issue with the latter is that it is not euclidean, but I think it is still worth checking, it might actually result in less deformations.Regarding the implementation, there really is only one relevant line:
relPos
is the eye to fragment vector in the model space. This turns it into a texture coordinate.3
scales the image, it should depend on the texture angular size (cf. point 1 in to do list).vec2(0.5, 0.5)
is to center the texture.Once ready, I think this could be merged into FGData. I guess it would require to make it backward compatible, with an option to disable it.