KhronosGroup
KHR_parallax_mapping
Hi, before I continue working on this, I would like to know if there is any chance that this will be accepted. There is this thread (5yrs old by the way) that ends up in every google search and people are still asking, but it doesn't look like anything has been done.
The thread also mixes parallax mapping and actual displacement mapping. While I think both is nice to have, I don't think we want to have one extension that does everything. And since I'm more interested in parallax mapping, I went for it.
I'm doing this without being attached to any company, I hope this is not a problem. Any help is welcome!
I too would be interested in such an extension as a way to greatly increase apparent model detail without a large increase in model size/complexity.
The approach in GPU Gems 2 and many other places is not without caveats, but provides PM in a lightweight way: https://developer.nvidia.com/gpugems/gpugems2/part-i-geometric-complexity/chapter-8-pixel-displacement-mapping-distance-functions
The "Relaxed Cone Stepping for Relief Mapping” in GPU Gems 3 is also interesting as a “cheap” displacement map technique: https://developer.nvidia.com/gpugems/gpugems3/part-iii-rendering/chapter-18-relaxed-cone-stepping-relief-mapping
Also interesting is the "Tessellation-Free Displacement Mapping for Ray Tracing” technique presented at SIGGRAPH Asia 2021, although more difficult to implement and not suitable for all backends: https://perso.telecom-paristech.fr/boubek/papers/TFDM/
Cheers, Bruce
On Aug 18, 2022, at 8:32 AM, Lars Maier @.@.>> wrote:
Hi, before I continue working on this, I would like to know if there is any chance that this will be accepted. There is thishttps://github.com/KhronosGroup/glTF/issues/948 thread (5yrs old by the way) that ends up in every google search and people are still asking, but it doesn't look like anything has been done.
The thread also mixes parallax mapping and actual displacement mapping. While I think both is nice to have, I don't think we want to have one extension that does everything. And since I'm more interested in parallax mapping, I went for it.
I'm doing this as a private person, I hope this is not a problem. Any help is welcome!
You can view, comment on, or merge this pull request online at:
https://github.com/KhronosGroup/glTF/pull/2196
Commit Summary
- 0f08674https://github.com/KhronosGroup/glTF/pull/2196/commits/0f08674d165198976d7b83d61c8f87d17af51a6c First draft.
File Changes
(2 fileshttps://github.com/KhronosGroup/glTF/pull/2196/files)
- A extensions/2.0/Khronos/KHR_materials_parallax_mapping/README.mdhttps://github.com/KhronosGroup/glTF/pull/2196/files#diff-0f8b396663224e5db193eef38ab2355027f243757f7849ae62127dcb679589fb (56)
- A extensions/2.0/Khronos/KHR_materials_parallax_mapping/schema/parallaxMapping.schema.jsonhttps://github.com/KhronosGroup/glTF/pull/2196/files#diff-6e1f8d3244eea8899049b8fe49458e8384d174728164f7f0d6ceaee85cbc637f (23)
Patch Links:
- https://github.com/KhronosGroup/glTF/pull/2196.patch
- https://github.com/KhronosGroup/glTF/pull/2196.diff
— Reply to this email directly, view it on GitHubhttps://github.com/KhronosGroup/glTF/pull/2196, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPU2VBOBKEUU6IUSF7ZSF3VZY3QVANCNFSM565HIFHQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Almost 3 weeks later. How do we proceed with this pull request? @UX3D-nopper is there an internal discussion about this? Is there anything I can provide to you?
There is a dedicated group at Khronos, called PBR TSG, which is taking care of material extensions. As there are currently so much pull requests and suggestions, this will probably take a while.
I'd just add — one helpful way to contribute on proposed extensions can be to research the relevant feature support in (1) authoring tools, and (2) viewing engines. Standards are typically not designed "from scratch". Knowing the similarities and differences among popular existing or upcoming software helps to move things forward.
Engine Support:
In fact, if an engine provides support for custom shaders, parallax occlusion mapping is only limited by the rendering backend.
Authoring Tools:
- Substance Designer outputs a heightmap by default.
- Most texture packs available only usually come with a height map.
- Blender supports baking height maps.
I think, that this is a common technique and is widely supported.
As #948 can attest, there is a lot of interest for the addition of height maps to the standard PBR material. As noted earlier in this discussion, parallax mapping is widely supported in existing engines, furthermore, modelling tools like Blender are well capable of exporting height maps (in any case, if a tool is capable of exporting a normal map, it is likely capable of exporting a height map), so the implementation burden for API consumers seem minimal.
Some additional context from #948:
- There's more uses you can do out of a height/bump channel, such as calculating more accurate occlusion and shadowing.
- I now think that in the long run, as hardware improves, displacement mapping may "win" over parallax mapping, for most cases. So we might only need a displacement extension, but we should consider whether that extension is asking viewers to subdivide or tessellate the base mesh, and whether that can be combined with subdivision surfaces.
- To that end, the burden of converting all bump maps to tangent-space normal maps is intentionally placed on the glTF creation/export toolchain, not on the receiving client implementation.
Note that all the questions around the materials_displacement extension was about the specific displacement mapping implementation which is not relevant for this proposition. Here, we are talking about parallax mapping, a technique that doesn't require any additional geometry.
If the gltf rust crate were to support this as an extension, would it be enough of a proof of concept to start turning the gears of getting this into the standard?
I've looked in depth at mmoeller's implementation for Blender and I have one additional comment:
heightFactoris a bad name, I know it follows the gltf established convention, but it doesn't make sense. It should express the units of displacements (probably world units I guess?)
Another 1.5 yrs later. Does anyone know if there is something going on inside khronos with respect to parallax mapping? Has this proposal or any variant of it been considered?