When you unwrap UVs the interpolation issue is taken care of. The UV map accounts for it.
It's only for tessellation like subdivision surfaces where something like this would be nifty That is to say, this is mainly nifty for the DCC tool renderer itself to render slightly faster.
It's not really that simple, barycentric coordinate access is relatively recent. It's asking the rasterizer for information and transforming that information into barycentric coordinates, and the correspondence of barycentric coordinates to vertices is unstable without further hardware support or further shader trickery. In the case of AMD gpus, it's only RDNA2 and later that have hardware support for stable barycentrics.
And you're right that this has been thought of. There are other approaches for bilinearly interpolating quads that have been historically used, but they require passing extra data through the vertex shader and thus often splitting vertices.
I am currently making a r7rs scheme derivative that compiles to C. The lofty goal is parallel fibers.
It's in extreme early stages, and I don't expect anyone will use it other than me, but I already like it. The compiler has been self hosted for a few months now. It has a cool FFI that you can see in use in the demos folder. Working on adding header generation to the module system.
While Chicken Scheme is cool, I don't think it'll be parallel, and not in the way I want it to be, and I am willing to make a lot of compromises Chicken isn't to get there. As mentioned, I am willing to settle with fibers for parallelism, and heavily eschewing side effects, making changes from r7rs to get there. For example, there will be no dynamic-wind provided and parameter objects will have different, thread friendlier, semantics.
----
My main reason for choosing C as a transpile is that it's easier to lean on gcc and C11 than it is to write my own codegen, and LLVM is too unstable for me to handle. I started writing this in June 2022, and since then LLVM has had 3 backwards compatibility breaking major release and millions of lines of code changed.
Well, a rotation matrix doesn't require doing 2 half rotations, and doesn't require reaching into the 4th dimension in such a way that it gets perfectly cancelled out. It doesn't require abstract analogies about cubes with strings glued to them or people holding coffee cups.
With some familiarity with linear algebra, it's easy to derive the formula for constructing a rotation matrix. You just have to think about what the operation does to the axes. The derivation for quaternion rotation is far more abstract, by virtue of the operation we actually care about involving a sandwich of multiplications with unclear 4 dimensional meaning. There's no hyperspheres with a rotation matrix.
Augmenting your space to handle not just rotations & scaling, but translations is easy for matrices, just requires a homogeneous coordinate and you get 4x4 matrices with intuitive columns.
Augmenting quaternions to handle translations requires the 8 dimensional dual-quaternions.
I definitely like geometric algebra, it's a very nice continuation of topics in linear algebra and makes it clear why things like normals behave differently from standard vectors. But I don't use it every day. I use standard linear algebra every day.
To add to your comment, quaternions predate rotational matrix operators by a considerable amount (1843 vs not exactly clear, ~1900 with Peano or ~1920 with Weyl), despite quaternions being much more challenging to manipulate. There are definitely simpler ways to view the same things.
There was a cottage industry of exotic hypercomplex numbers that disappeared when linear algebra matured to eclipse them.
In fact, Maxwell's Equations were originally derived with quaternions.
It's only for tessellation like subdivision surfaces where something like this would be nifty That is to say, this is mainly nifty for the DCC tool renderer itself to render slightly faster.