Allow fluid.grid~ to work on 3d datasets

New Ideas
1

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!

2

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

3

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.

4

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.

5

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
6

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!

7

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

8

You guys. Well, my cursory reading of e.g. https://arxiv.org/pdf/1008.0390.pdf 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)?

9

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?

10

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

1 Like
11

67gy7x

1 Like
12

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.

2 Likes