Repository navigation
Proposal for EXT_mesh_opacity_micromap - #2623
Open
pixeljetstream wants to merge 14 commits into
Open
pixeljetstream wants to merge 14 commits into
pixeljetstream wants to merge 14 commits into
Conversation
Co-authored-by: Nia Bickford <nbickford@nvidia.com> Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com> Co-authored-by: Pyarelal Knowles <pknowles@nvidia.com>
- Use GitHub-renderable math delimiters ($...$, $$...$$) instead of \(...\) and \[...\] - Fix @pknowlesnv contributor handle; add Martin-Karl Lefrançois as contributor - Refer to the core glTF definition of triangle count for micromapIndices - Add a Known Implementations section - Clarify that API micromap fields in the mapping table refer to the built micromap object - Mark informative references as non-normative; link the OMM SDK on GitHub
README - Define base triangle vertices v0/v1/v2 from TRIANGLES index order and the (u, v) barycentric convention; note that reordering or rotating triangles invalidates the association - Limit subdivision levels to [0, 12] (DirectX 12 maximum) - Define valid lookup values: signed elements >= -4, unsigned special-index bit patterns, and the record range including the no-accessor case - Remove byteStride support for data, triangles and micromapIndices (core glTF only allows it for vertex attributes); triangles byteLength is a multiple of 8 - Require normalized == false on micromapIndices - State usage entries per (level, format) pair as a data constraint - Add Interaction with Materials (non-normative), Interaction with Other Extensions, and Optional vs. Required sections - Make the reference function the normative ordering definition; keep the traversal description and figure as non-normative illustration - Rework the API mapping into a non-normative Graphics API Correspondence table; use docs.vulkan.org links - Use Khronos-style property tables and section order Schema - Move micromap objects to micromap.schema.json based on glTFChildOfRootProperty (adds name) - Add maximum 12 to usageLevels; tighten descriptions
- Overview:
- Made it clearer that micromaps contain micromap triangles
- Reduced some repetition between paragraphs 2 and 3, and cleaned up some clunkiness when we mention how this works well with graphics APIs
- Don't claim binary-compatibility, because JSON will treat things like floats
- Hardware can use OMMs; it's not required to (although it should, it helps quite a bit)
- Reference function now uses pseudocode that is in no particular language; additional code around clamping to the triangle edges has been removed; added more comments, although the magic of this function is still rather unexplained here.
- More links
- More LaTeX
- Moved the graphical description of the space-filling curve up to Subdivision and Micromap Order
- Changed 'typically created' to 'often created'; we do see format 1 and it's not that atypical.
- Some 'have to' -> 'must' replacements for concision
- Define the space-filling curve order normatively as a recursion with explicit vertex order for each of the four sub-triangles, so the definition no longer depends on the reference function or the figure. - Add figures/micromap-split-rule.svg illustrating the split rule (vertex order of each sub-triangle, flipped winding marked), redrawn in spec notation from the "Bird curve recursive splitting rule" slide of NVIDIA's Micro-Mesh Basics deck. - Restore the subdivision figure legend (vertex placement, blue/red arrows). - Mark Appendix A non-normative and note equivalence with the VK_KHR_opacity_micromap reference code. - Restore clamping in the pseudocode so points on the triangle edges and slightly outside return a valid index (matches the Vulkan reference). - Pseudocode: parenthesize shifts inside XOR, define << and u32 wrap, use (1 << L) instead of exp2(L) for the integer mask. - Fix the copyright appendix link after the rename to Appendix B. - Overview: usage arrays count triangles per level/format combination.
…, v) is within the closed base triangle
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello,
with the standardization of Vulkan
VK_KHR_opacity_micromapas well asMicrosoft DirectX Raytracing — opacity micromaps we are proposing this extension to allow providing micromap data as part of a glTF.
Because the data is typically mesh-specific (micromaps operate in barycentric space) we added a mesh prefix to the extension name, also so that it doesn't clash with the Vulkan extension on searches.
We are looking forward to your feedback.