jit.gl.picker when working with jit.gl.multiple ("selecting" a point in 3D space)
Howdie all.
Sorry if this is a simple question, but I've managed to build a 3D (5D with color/scale) visualizer for data plots and it's looking and working really nicely. Although having this kind of visualization is massively useful as it is, it would be even better if I could "select" a point in that space.
I came across jit.gl.picker, but that doesn't seem to work if I'm using jit.gl.multiple.
Below is a patch showing what I'm trying to do, but essentially, I will have a jit.pworld with an arbitrary amount of points (usually in the 500-3k range, although in this example it's 1715) and I would like to hover over any given point, know what point it is, and ideally change it's color/size so I know which one is being selected.
Is something like that possible when using jit.gl.multiple? Or is there another way to render the same idea, that can still let me know what point I'm hovering over.
see my 2 replies and example patch here - https://cycling74.com/forums/how-many-jit-gl-texture-objects/replies/1#reply-60340557480c08173d54c325
Oh awesome!
Ok, had a quick test. jitter is most definitely not my strong suit, so I'm not sure if I'm doing something wrong, or if this is the byproduct of incorporating jit.phys stuff into the mix, but my Max patch is now running around 1frame every 15seconds. As in, clicking on something, unlocking the patch, etc...
I *think* it's picking the point as I see output of "mouse u698006094_1310 0" from jit.phys.picker, which I would imagine corresponds to point 1310 (out of 1715 in this patch), but I can't actually zoom in or do anything because of how much Max is locked up.
Here's my patch modified to incorporate the jit.phys stuff (I think).
try reducing the number of data points in your initialization coll down to around 512 before banging through, just for your testing/development purposes to start with... pumping around 2k through seems to be what chokes it up for me.
also, for jit.phys.picker, i think the attribute "@hover" should be on('1') if you want to hover over points and see them register.
sorry reread your post and seeing the number of points you are dealing with, using physics is definitely not a viable solution. i don't think there is an easy answer for you for this type of hit testing that doesn't involve writing some custom algorithms and using some custom data structures (e.g. quad tree)
Ah right. Yeah it did seem to be working with the smaller amount of points (though it seemed to fight the jit.gl.handle where I seemed to get a handle or was able to select points, even if @hover was turned on), but the point count here can get quite high.
For a 2D version of this (where I was using jit.mgraphics) I was using the X/Y positions to query the data and nearest neighbors via a parallel KDtree which held all the "actual" data, but was hoping to be able to do something similar with this just to know that I'm hovering over any given point in whatever orientation the plot happens to be.
Actually wondering of the wordtoscreen/screentoworld could do the trick by scaling the position of my mouse in whatever the projected space is.
I found this thread:
https://cycling74.com/forums/screentoworld-and-worldtoscreen-messages
But I can't really see how to adapt this to what I'm doing since I'm using jit.pworld instead of jit.world (I don't want a floating window).
I'm also not married to drawing the points with jit.gl.gridshape/jit.gl.multiple, so if I can achieve the same results with another set of objects (jit.gl.mesh?) while still being able to hover/point/select each point, I'm open to that too.
here's my basic screentoworld example modified to use jit.pworld.
"sendrender" message is the trick for using this message with pworld.
Oooh, that's pretty nice.
I've modified the patch to return the world coordinates, but it seems to only return the X/Y, and not the Z of the points. Don't know if that's how the screentoworld->worldtoscreen stuff is supposed to work, but I imagined that it would mean whatever, um, "slice" of the 3D space I'm currently projecting onto the screen (jit.pworld) would return XYZ coordinates that correspond to the whole world.
I'm also using jit.gl.handle instead of jit.gl.camera, so don't know if that matters at all. In your example the Z isn't returned either, though the case there is kind of different as I'm not necessarily interested in "touching"/moving the points. Fundamentally just want to know what point I'm hovering or nearest to (which would then trigger playback of the corresponding audio file associated with that point).