**diff options**

Diffstat (limited to 'doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt')

-rw-r--r-- | doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt | 53 |

1 files changed, 27 insertions, 26 deletions

diff --git a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt index f299f00..e55a05d 100644 --- a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt +++ b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt @@ -20,10 +20,10 @@ single-pass cubemap rendering (broadcasting a primitive to multiple faces and reorienting the vertex position for each face) and voxel rasterization. The per-viewport component remapping and negation provided by the swizzle allows application code to re-orient three-dimensional geometry with a view -along any of the X, Y, or Z axes. -If a perspective projection and depth buffering is required, 1/W buffering -should be used, as described in the single-pass cubemap rendering example in the "Issues" section below. +along any of the *X*, *Y*, or *Z* axes. +If a perspective projection and depth buffering is required, [eq]#1/W# +buffering should be used, as described in the single-pass cubemap rendering example in === New Object Types @@ -74,8 +74,8 @@ rendering to a cubemap. In this example, the application would attach a cubemap texture to a layered FBO where the six cube faces are treated as layers. Vertices are sent through the vertex shader without applying a projection -matrix, where the gl_Position output is (x,y,z,1) and the center of the -cubemap is at (0,0,0). +matrix, where the code:gl_Position output is [eq]#(x,y,z,1)# and the center +of the cubemap is at [eq]#(0,0,0)#. With unextended Vulkan, one could have a conventional instanced geometry shader that looks something like the following: @@ -184,39 +184,40 @@ not need to be modified as part of this coordinate transformation. Note that while the rotate() operation in the regular geometry shader above could include an arbitrary post-rotation projection matrix, the viewport swizzle does not support arbitrary math. -To get proper projection, 1/W buffering should be used. +To get proper projection, [eq]#1/W# buffering should be used. To do this: 1. -Program the viewport swizzles to move the pre-projection W eye coordinate -(typically 1.0) into the Z coordinate of the swizzle output and the eye -coordinate component used for depth into the W coordinate. -For example, the viewport corresponding to the +Z face might use a swizzle -of (+X, -Y, +W, +Z). -The Z normalized device coordinate computed after swizzling would then be -z'/w' = 1/Z_eye. +Program the viewport swizzles to move the pre-projection [eq]#W# eye +coordinate (typically 1.0) into the [eq]#Z# coordinate of the swizzle output +and the eye coordinate component used for depth into the [eq]#W# coordinate. +For example, the viewport corresponding to the [eq]#+Z# face might use a +swizzle of [eq]#(+X, -Y, +W, +Z)#. +The [eq]#Z# normalized device coordinate computed after swizzling would then +be [eq]#z'/w' = 1/Z~eye~#. 2. On NVIDIA implementations supporting floating-point depth buffers with -values outside [0,1], prevent unwanted near plane clipping by enabling +values outside [eq]#[0,1]#, prevent unwanted near plane clipping by enabling DEPTH_CLAMP. Ensure that the depth clamp doesn't mess up depth testing by programming the -depth range to very large values, such as minDepthBounds=-z, -maxDepthBounds=+z), where z == 2^127. -It should be possible to use IEEE infinity encodings also (0xFF800000 for --INF, 0x7F800000 for +INF). +depth range to very large values, such as [eq]#pname:minDepthBounds=-z#, +[eq]#pname:maxDepthBounds=+z#, where [eq]#z = 2^127^#. +It should be possible to use IEEE infinity encodings also (`0xFF800000` for +`-INF`, `0x7F800000` for `+INF`). Even when near/far clipping is disabled, primitives extending behind the eye -will still be clipped because one or more vertices will have a negative W -coordinate and fail X/Y clipping tests. +will still be clipped because one or more vertices will have a negative +[eq]#W# coordinate and fail [eq]#X#/[eq]#Y# clipping tests. -On other implementations, scale X, Y, and Z eye coordinates so that vertices -on the near plane have a post-swizzle W coordinate of 1.0. -For example, if the near plane is at Z_eye = 1/256, scale X, Y, and Z by -256. +On other implementations, scale [eq]#X#, [eq]#Y#, and [eq]#Z# eye +coordinates so that vertices on the near plane have a post-swizzle [eq]#W# +coordinate of 1.0. +For example, if the near plane is at [eq]#Z~eye~ = 1/256#, scale [eq]#X#, +[eq]#Y#, and [eq]#Z# by 256. 3. -Adjust depth testing to reflect the fact that 1/W values are large near the -eye and small away from the eye. +Adjust depth testing to reflect the fact that [eq]#1/W# values are large +near the eye and small away from the eye. Clear the depth buffer to zero (infinitely far away) and use a depth test of GREATER instead of LESS. |