Conversation
Add meshopt_opacityMap* functions to experimental list
The comments should now be sufficient to use all of the functions; after measure, the user is responsble for doing the micromap entry layout whereas compact does it automatically, which is perhaps a little confusing, but other alternatives seem worse.
Add opacity micromap documentation.
Fix a few typos and a few logical issues in the code samples.
Add a note about index/meshlet compression adjusting the corner order. For meshlet compression, this might be revised in the future via changes to `optimizeMeshlet`, but for now it's required to compress/decompress these too.
Wrap code samples to avoid vertical scrolling.
Improve wording.
For subdivision levels of OMM entries, we only need a 0..12 range, and we don't need any sentinel values; even if source triangles need to be marked as invalid in the future, this can be done via special indices instead of invalid levels in the OMM level list.
While measure doesn't generate any special indices, it's possible to use compaction multiple times; for example, in some cases it might be preferable to always compact within the mesh, and then compact a group of meshes - which would previously fail because the input OMM indices would be negative. We now support this transparently which makes compaction idempotent.
While triangle-adaptive mips for rasterization work reasonably well, in practice fixed mips are a better tool for reducing the time OMM data takes to generate - because reducing the mip resolution globally also saves most of the texture loading/decompression time too. At the same time, it's not fully clear if rasterizing from mip data requires adjusting the threshold. We might add this function back in the future more or less as is, but for now in the spirit of minimal viable functionality, the caller can decide which mip to use when instead of meshopt having a preference.
Remove mentions of preferred mip and adjust the recommendation to use mip 0 for 4-state OMMs or mips 1/2 for 2-state or if the input texture is higher resolution.
0.75 is derived from the fact that edge length is ~1.5 sqrt(uvarea) for equilateral triangles, but it was not obvious from the code.
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
1 participant
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.
levels[]type tounsigned char*; we only need ~4 bits of data and levels can never be negativePreferredMipfor now; it works fine but it complicates the interface somewhat and it can be non-trivial to use in some cases; we might add it back as is if there's demand for it but for now it seems easier to recommend fixed-mip downsampling as a quality-time tradeoff.This contribution is sponsored by Valve.