Allow fluid.grid~ to work on 3d datasets

It would be great to be able to apply the fluid.grid~ transformation on 3d datasets (or even nd datasets really).

A good use case would be transforming a 3d (UMAP’d) dataset into a space that can be mapped onto a velocity-sensitive/MPE’d controller (e.g. XY + pressure/velocity).

The vanilla fluid.plotter only shows 2d (so it seems), but the pimped out fluid.datasetplot~ can show up to 5d, though the usability for this would be more in terms of how it interfaces with controllers and/or external input.

I was trying to think if there’s a way to “fake” it by grid-ing XY and then YZ separately, then merge-ing the results or something, but that starts getting a bit clunky.

Don’t know if the underlying algorithm is exclusively a 2d thing, but it would make for a great added feature!

I was thinking this yesterday. I haven’t been able to play with grid yet, but I am following…

I don’t know the algorithm in any great detail, but a quick journal dive seems to suggest that 2D is where most of the attention is, and that even then the algorithms are in cubic complexity (which is a lot), so maybe they’re just intractable in higher dimensions. I’ll see if I can do more reading at some point.

n grid-ing would obviously great, but even just a meagre 3d, a lowly 3d, a humble 3d, if you will, would be amazing.

That would align real nicely with most (available) controller paradigms. Beyond that gets quite niche I think.

If we make a 3D one next you’ll be asking for a 4D grid to project into your AR headset neuro-link. Where does the line get drawn Rodrigo? 5D? 6D?

1 Like

Hey I’m a 3d kind of guy all the way. The one you have to watch out for is @spluta with his 8d joystick thing!

Lol. But I really just want the 3d because the joystick thing would finally work correctly with it.

You guys. Well, my cursory reading of e.g. suggests that even actual mathematicians are unsure if practical algorithms with guaranteed solutions for > 2D can be found in the general case, so that’s a definite above-my-pay-grade case. However, you could perhaps approach it as a supervised learning problem with KNN Regressor (and find some way to deal with duplicates / clashes)?

Obviously I have no idea what’s going on under the hood, but I would have thought that a pseudo-normalization + equal-distance-ification would do the trick (albeit likely not as fancily as whatever fluid.grid~ is doing mathematically).

I’m not quite somewhere for having a use case with this, but do you mean like doing vanilla regression for taking 3d input and mapping it to a 2d output space? If so, what would be ‘duplicates’ and ‘clashes’ in that context?

I think mathematicians need to get on it and figure it out is what I think…whose with me?

1 Like


1 Like

Although it’s not useful for a 3d control space, an ok workaround I’m doing is using fluid.umap~ to get down to 3d, then slicing off the first 2d to feed to fluid.grid~ then taking the 3rd D to use to project the color space.

Still gives me a nice timbral space to work with, but also has a bit of 3d panache.