[ad_1]
The fundamental concept is you could assemble a vector representing a place in clip house, after which “unproject” it to get that place in “world house”, then normalise that vector to get a route. World house is in quotes as a result of the digicam is at all times on the origin in stated “world house”. Maybe sky house can be a greater time period.
In the event you assemble the unprojected vector within the vertex shader for every vertex of the empty texture you are drawing, and set a various vec3 to it, you may then let the various variable be interpolated and normalise it within the fragment shader, reducing out probably a whole bunch of hundreds of fragment shader matrix multiplications and solely have them accomplished for the corners of the display screen.
The GLSL vertex shader code, the place VertexTexCoord is the UV coords on the stretched empty texture being drawn (a vec2, so it fills each x and y within the vec4 constructor) and clipToSky is the “unprojection matrix” defined under:
various vec3 directionPreNormalise;
// ...
vec3 directionPreNormalise = (
clipToSky * vec4(
VertexTexCoord * 2.0 - 1.0,
-1.0,
1.0
)
).xyz;
After which within the fragment shader, should you even have to normalise it:
vec3 route = normalize(directionPreNormalise);
VertexTexCoord‘s parts are within the vary 0 to 1, however we would like them within the vary -1 to 1, since that is what clip house has.
If you wish to perceive the impact of the z, and whether or not it needs to be -1.0 or 0.0 for you:
The -1.0 z coordinate could be something, and this nonetheless works. The XY-aligned aircraft in clip house based mostly in your stretched texture is reworked right into a (the place XYZ are aligned with the view frustum) XY-aligned aircraft within the view frustum, and the Z coordinate of that output aircraft relies on the Z coordinate in clip house pre-transformation. The connection is nonlinear. -1.0 corresponds to a place on the close to aircraft* (which I really feel is non-arbitrary), assuming your graphics API has clip house go from -1 to 1 on the z axis. Having a z of -2.0 pre-transform additionally works for -1 to 1 clip areas, so try to be OK to make use of no matter nonetheless, however 0.0 would extra possible correspond to your close to aircraft if you’d like one thing non-arbitrary (I have never used an API like that). The XY-aligned aircraft within the view frustum grows as you improve the pre-transform z, “sliding alongside the sides of the view frustum”, at such a fee that route within the code above would not change with the pre-transform z.
*Notice that using .xyz with no division by the w coordinate signifies that directionPreNormalise is now not a place on the close to aircraft, nevertheless it all nonetheless works advantageous.
The 1.0 w coordinate is only for homogenous coordinates. Altering it seems to have a FOV-changing impact.
The “unprojection matrix” can be, in Lua code utilizing my maths library:
mat4.inverse(projectionMatrix * cameraMatrixStationary)
The place projectionMatrix is the matrix that takes vectors from digicam house to clip house (which is the place FOV and side ratio are available) and cameraMatrixStationary is a world house -> digicam house matrix constructed out of your digicam orientation quaternion, however the place is about to the origin. Whether it is off the origin, the sky that will get rendered will get offset in a curious vogue.
Supply for the analysis: I made a matrix visualiser and I used it to attract numerous wireframe graphics representing matrices, planes, the clip house dice, and so on to see precisely what was occurring. (It was initially supposed for one thing else.)
[ad_2]
