1// Copyright 2022-2024 The Khronos Group Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_EXT_opacity_micromap.adoc[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2022-08-24 11*Interactions and External Dependencies*:: 12 - This extension provides API support for 13 {GLSLregistry}/ext/GLSL_EXT_opacity_micromap.txt[`GLSL_EXT_opacity_micromap`] 14*Contributors*:: 15 - Christoph Kubisch, NVIDIA 16 - Eric Werness, NVIDIA 17 - Josh Barczak, Intel 18 - Stu Smith, AMD 19 20=== Description 21 22When adding transparency to a ray traced scene, an application can choose 23between further tessellating the geometry or using an any-hit shader to 24allow the ray through specific parts of the geometry. 25These options have the downside of either significantly increasing memory 26consumption or adding runtime overhead to run shader code in the middle of 27traversal, respectively. 28 29This extension adds the ability to add an _opacity micromap_ to geometry 30when building an acceleration structure. 31The opacity micromap compactly encodes opacity information which can be read 32by the implementation to mark parts of triangles as opaque or transparent. 33The format is externally visible to allow the application to compress its 34internal geometry and surface representations into the compressed format 35ahead of time. 36The compressed format subdivides each triangle into a set of subtriangles, 37each of which can be assigned either two or four opacity values. 38These opacity values can control if a ray hitting that subtriangle is 39treated as an opaque hit, complete miss, or possible hit, depending on the 40controls described in <<ray-opacity-micromap,Ray Opacity Micromap>>. 41 42This extension provides: 43 44 * a slink:VkMicromapEXT structure to store the micromap, 45 * functions similar to acceleration structure build functions to build the 46 opacity micromap array, and 47 * a structure to extend 48 slink:VkAccelerationStructureGeometryTrianglesDataKHR to attach a 49 micromap to the geometry of the acceleration structure. 50 51include::{generated}/interfaces/VK_EXT_opacity_micromap.adoc[] 52 53=== Reference Code 54 55[source,c++] 56---- 57uint32_t BarycentricsToSpaceFillingCurveIndex(float u, float v, uint32_t level) 58{ 59 u = clamp(u, 0.0f, 1.0f); 60 v = clamp(v, 0.0f, 1.0f); 61 62 uint32_t iu, iv, iw; 63 64 // Quantize barycentric coordinates 65 float fu = u * (1u << level); 66 float fv = v * (1u << level); 67 68 iu = (uint32_t)fu; 69 iv = (uint32_t)fv; 70 71 float uf = fu - float(iu); 72 float vf = fv - float(iv); 73 74 if (iu >= (1u << level)) iu = (1u << level) - 1u; 75 if (iv >= (1u << level)) iv = (1u << level) - 1u; 76 77 uint32_t iuv = iu + iv; 78 79 if (iuv >= (1u << level)) 80 iu -= iuv - (1u << level) + 1u; 81 82 iw = ~(iu + iv); 83 84 if (uf + vf >= 1.0f && iuv < (1u << level) - 1u) --iw; 85 86 uint32_t b0 = ~(iu ^ iw); 87 b0 &= ((1u << level) - 1u); 88 uint32_t t = (iu ^ iv) & b0; 89 90 uint32_t f = t; 91 f ^= f >> 1u; 92 f ^= f >> 2u; 93 f ^= f >> 4u; 94 f ^= f >> 8u; 95 uint32_t b1 = ((f ^ iu) & ~b0) | t; 96 97 // Interleave bits 98 b0 = (b0 | (b0 << 8u)) & 0x00ff00ffu; 99 b0 = (b0 | (b0 << 4u)) & 0x0f0f0f0fu; 100 b0 = (b0 | (b0 << 2u)) & 0x33333333u; 101 b0 = (b0 | (b0 << 1u)) & 0x55555555u; 102 b1 = (b1 | (b1 << 8u)) & 0x00ff00ffu; 103 b1 = (b1 | (b1 << 4u)) & 0x0f0f0f0fu; 104 b1 = (b1 | (b1 << 2u)) & 0x33333333u; 105 b1 = (b1 | (b1 << 1u)) & 0x55555555u; 106 107 return b0 | (b1 << 1u); 108} 109---- 110 111=== Issues 112 113(1) Is the build actually similar to an acceleration structure build? 114-- 115 * Resolved: The build should be much lighter-weight than an acceleration 116 structure build, but the infrastructure is similar enough that it makes 117 sense to keep the concepts compatible. 118-- 119 120(2) Why does VkMicromapUsageEXT not have type/pNext? 121-- 122 * Resolved: There can be a very large number of these structures, so 123 doubling the size of these can be significant memory consumption. 124 Also, an application may be loading these directly from a file which is 125 more compatible with it being a flat structure. 126 The including structures are extensible and are probably a more suitable 127 place to add extensibility. 128-- 129 130(3) Why is there a SPIR-V extension? 131-- 132 * Resolved: There is a ray flag. 133 To be consistent with how the existing ray tracing extensions work that 134 ray flag needs its own extension. 135-- 136 137(4) Should there be indirect micromap build? 138-- 139 * Resolved: Not for now. 140 There is more in-depth usage metadata required and it seems less likely 141 that something like a GPU culling system would need to change the counts 142 for a micromap. 143-- 144 145(5) Should micromaps have a micromap device address? 146-- 147 * Resolved: There is no need right now (can just use the handle) but that 148 is a bit different from acceleration structures, though the two are not 149 completely parallel in their usage. 150-- 151 152(6) Why are the alignment requirements defined as a mix of hardcoded values 153and caps? 154-- 155 * Resolved: This is most parallel with the definition of 156 `apiext:VK_KHR_acceleration_structure` and maintaining commonality makes 157 it easier for applications to share memory. 158-- 159 160=== Version History 161 162 * Revision 2, 2022-06-22 (Eric Werness) 163 ** EXTify and clean up for discussion 164 * Revision 1, 2022-01-01 (Eric Werness) 165 ** Initial revision 166