In the surflets examples it feels like a trajectory/barycenter based approach almost like OT, and in these examples it feels much more like traditional SDF blending. If your source and target objects aren't right on top of each other would this blending still look reasonable? Really neat stuff!!

I appreciate the kind words!!! I really enjoyed hanging out with you and the jangafx team!!! Y'all are absolutely wizards 🧙‍♂️🧙‍♂️🧙‍♂️🧙‍♂️

The github repo also includes links to some shader toy demos, so check those out! Here's one for noise on an SDF surface :)

shadertoy.com/view/WXdXzj

The least obvious part of all of this is how to construct that metric tensor G from a given vector, but it turns out it's super straight forward. The attached example shows how to do so for a 3D metric tensor. In our paper we outline specific bounds for the sizing of this metric.

Just to elucidate the idea a bit more, on the left we have the original perlin noise algorithm, and on the right we have the steerable version, with the changes underlined in red. We simply add a second set of weights, and incorporate our metric into the original dot product step

Hehehehehehe thanks for posting this Karl and for all the support on the paper!!! ❤️

In anisotropic meshing the metric is defined at all points in space and you use something like fast marching (basically a fancy dijkstras) to generate anisotropic distances. The hacky version would be to give each voronoi pt a metric and swap the euclidean distance calc for the metric equivalent.

For anisotropic voronoi M will be some metric tensor or in easier terms just a positive definite matrix (non zero positive eigenvalues).

One way of generating that matrix is by following the steps outlined in this paper (eq. 9): bougleux.users.greyc.fr/articles/bou...

Yeah, I'm finding that as the resolution of the 3d grid increases the precision issues really start to compound specifically for the SAT computation. I'll stick with 64bit precision in that case! Either way the results are so cool, really amazing work!!!!

If I naively clamp the magnitude of velocity to be at most 1, with 100 timesteps it seems to converge, however if I drop the time steps to something like 10, it no longer converges. So I guess I was curious if there was some way to intuit what a good upper bound for vel magnitudes would be?

Such a cool paper! I tried implementing this with 32 bit precision and it seems much more noisy in the output (which makes sense). I was curious if you had any thoughts with respect to clamping/limiting velocity values? Almost like a cfl condition of sorts...

I do love that true solutions never have crossing edges leaving you with a nice simple polygon.

Assuming I understand the question correctly:
www.geometry.caltech.edu/BlueNoise/

And then there's a linear time algorithm for it using a paper from this year's siggraph:
perso.liris.cnrs.fr/david.coeurj...

The painting app rebelle is super fun to play with. I know Craig Mullins (the GOAT) has some a cool time lapse on Instagram where he used it.
www.instagram.com/reel/CzXYoAA...