To answer some of the questions here, the reason this has not been used before is because this technique requires being able to access the quad definitions (ie. which 4 vertices makeup each quad) within the gpu.<p>Up until recently with Mesh Shaders, there's really just been no good way to send this data <i>to</i> the GPU and read back the barycentric coordinates you need in the fragment shader for each pixel.<p>The article offers several options, to support older GPUs, like Geometry Shaders and Tesselation shaders. This is good, but these are really at best Terrible Hacks(tm). Proof of the ability to contort old extensions is not proof of reasonable performance!<p>Notably, geometry shaders are notorious for bad performance, so the fact that they list them as a viable strategy for older devices makes it pretty clear they aren't thinking much about performance, just possible compatibility.<p>Still, I think this is very cool, and now that GPUs are becoming much more of a generic computing device with the ability to execute arbitrary code on random buffers, I think we are nearly at the point of being able to break from the triangle and fix this! We hit this triangulation issue several times on the last project, and it's a real pain.
This is one of those things that feels like a broken/half-assed/oversimplified implementation got completely proliferated into the world a long time ago and it took several years for the right person to do a full-depth mathematical analysis to reveal what we should've been doing all along. Similar to antialiasing and sharpening, texture filtering, color spaces and gamma correction, etc.<p>It reminded me of this article specifically: <a href="https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8" rel="nofollow">https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f...</a>
How does this compare to <a href="https://jcgt.org/published/0011/03/04/paper.pdf" rel="nofollow">https://jcgt.org/published/0011/03/04/paper.pdf</a>? It seems superficially pretty similar.
/? Barycentric<p>From "Bridging coherence optics and classical mechanics: A generic light polarization-entanglement complementary relation" (2023)
<a href="https://journals.aps.org/prresearch/abstract/10.1103/PhysRevResearch.5.033110" rel="nofollow">https://journals.aps.org/prresearch/abstract/10.1103/PhysRev...</a> :<p>> <i>More surprisingly, through the barycentric coordinate system, optical polarization, entanglement, and their identity relation are shown to be quantitatively associated with the mechanical concepts of center of mass and moment of inertia via the Huygens-Steiner theorem for rigid body rotation. The obtained result bridges coherence wave optics and classical mechanics through the two theories of Huygens.</i><p>Phase from second order amplitude FWIU
Very interesting! This reminds me of how stumped I was learning about UV unwrapping for texturing. Even simple models are difficult to unwrap into easily editable textures. "Why can't I just draw on the model?"<p>Blender has a few plugins these days that make it a lot easier --- one that impressed me was Mio3 UV: <a href="https://extensions.blender.org/add-ons/mio3-uv/" rel="nofollow">https://extensions.blender.org/add-ons/mio3-uv/</a>
I am definitely not an expert in 3D graphics... but this looks such an astonishingly simple and effective method, it makes me to question why this wasn't already thought of and picked up?<p>I get that with fixed-pipeline GPUs you do what the hardware and driver make you do, but with the advent of programmable pipelines, you'd though improving stuff like this would be the first things people do?<p>Anyway, gotta run and implement this in my toy Metal renderer.
This actually seems quite easy to implement. Any thoughts on the performance hit a program takes when going this route instead of using one of the workarounds?