It led me to open up a composition in order to check a few things out…and now I have a question.
I cannot seem to get any vec2 coordinate out of this mouse patch.
Should I be expecting to have to press down on the trackpad? Whether I do or not, I still can’t seem to get a position out of it. I also tried the input ports to the mouse patch at various settings.
mouse question.vuo (3.48 KB)
I have position returning with a different node…
Is there a reason that I don’t see the Field of View value update when I move the slider for it? It seems like I have everything hooked up in a way that it should evaluate. I also do see the updated FOV value coming out of the output of the camera node.
mouse snake spheres.vuo (5.71 KB)
ohhhh a camera is an object, momentarily forgot.
hmm. I wonder how to join a single camera object to this group of mesh objects…
This seems like the proper way to attach the objects from the enqueue as well as the camera to the object graph.
But now I have the rendering of the spheres stop after a few mouse moves…I go from seeing the spheres to blank rendering and can’t really figure out why. And on one start, I was hovering over the objects node at the window input port, and couldn’t see any rendering after I went to “draw” spheres at mouse position.
Is this all hooked up correctly?
mouse snake spheres 2.vuo (5.91 KB)
Moving the camera node to second place in the objects drawer seems to solve the problem of the render window going black.
Is this a bug? I think the camera/object and blackout scenario is a bug. Can this thread be spun into a bug report with admin tools here or should I file it manually?
If one gtoledo3 writes up a bug in the middle of the forest and no one is there to read it, was it really ever a bug at all?
I guess this one person conversation quickly morphed to a different topic than “mouse”. But I am still wondering about the initial question as well.
mouse snake spheres 3.vuo (5.49 KB)
It’s not the order of the camera that leads to a black screen, but the fact that in the “mouse snake spheres 2.vuo” the minimum distance for camera is set at > 2, where “mouse snake spheres 3.vuo” is set back to 0,1 minimum ;)
Distance min isn’t the front clip point of the camera?
I thought it would be the front clip, and I thought the max would be the rear z clip.
Thanks for the head’s up. I do not understand what is actually going on there yet, but hopefully it will become clear after looking. I guess this makes plenty of sense because I wasn’t getting expected results there in general, it seemed like something is wrong with the projection space.
Since camera position = 1 and objects further then 2,8 from the camera are visible,
Distance Max set to 10 : Z = -9
. (visible space)
. (visible space)
. (visible space)
Distance Min set to 2,8 : Z = -1,8
Your Spheres Z = 0
The camera Z = 1
1 - 2,8 = -1,8 so objects further then Z = -1,8 are visible no ?
Oh. I guess I was confused about how the parameters mapped out.
To join your discussions and bug reports regarding mouse stuff (this discussion + Mouse Events Bug + Mouse click bool/int/float discussion) I patched together a composition regrouping and displaying the different mouse related nodes (leaving the scroll, deltas, drags and trackpad nodes out).
It’s true there are quite several mouse related nodes and usually when I want to get something done, I go through some of them until I find the node I need, not knowing in advance from the Node names which one I’ll need.
What I learned is :
I didn’t know either
Check Mouse Status (second node in violet) had to have an external event cable attached to it to work (your first comment on this discussion). It’s showcased on the Vuo sample composition linked below that node description from the node library, but not in the node description itself. It doesn’t work even on mouse clicks (at least trackpad clicks, didn’t test with a mouse but all the other nodes seem to behave like for mice).
Receive Mouse Clicks (forth node in green) delayed the results to give it time to analyse if it’s a single, double or triple click. Since that node also outputs mouse coordinates on clicks, I remember I made a composition that copy / enqueued 3D objects in space on mouse clicks, but I wondered why there was such a delay, now I wonder if I simply had not been using this node instead of
Receive Mouse Buttons for instant reaction. But my bad I guess, I didn’t read the node description.
I guess at this point the several mouse nodes where split into several ones for efficiency reasons (f.e. not having to update a node on display refresh if you only need pressed info or click coordinates).
Seeing the names these nodes were given, some use “Receive” and some use “Check”. What does it mean, the “Receive” ones automatically send data whenever a related action is executed, whereas the “Check” ones need an extra external event, for when efficiency is needed ?
I don’t really understand what you and Martinus where discussing regarding system wide boolean pressed / unpressed in Mouse click bool/int/float. Why has the
Check Mouse Status a “pressed” boolean and
Receive Mouse Buttons does not ? Because it needs a “Fire On Display” event refresher to be observed ? Or because it would make too much Output Ports on the node ? Or because the answer is the solution Martinus suggested with some
Select Latest nodes, allowing more flexibility as you said ?
Anyway, starting this discussion I thought there were too many mouse related nodes and wanted to come up with a suggestion to regroup them, but now that I’ve analysed them deeper, I wouldn’t know and guess they’re alright, although some fine tuning and some extra functions could maybe still be added.
Regarding the names now that I know them better, I guess I would understand them better if
Receive Mouse Buttons was named
Receive Mouse Button Coordinates depending on their States :)
Receive Mouse Clicks was
Received Mouse Click Types
But that would make them longer :)
Mouse Nodes 1.2.vuo (10.6 KB)
I appreciate all this, and do not really comprehend it all yet! :-) I’m glad you seemed to experience some of the same glitches I was. Well, not GLAD, but…
I am not sure about answers to some of the questions at this point.
I can say that it seems to me that in this case vuo is kind of granularly exposing what the macos framework for this does, as direct output data. Just from having browsed the apple docs for mouse events earlier this week, to refresh my memory. I think this is probably the reason the methods are split across so many nodes.
It is funny, because with something like the lists, the choice to use 1 instead of zero is aimed at appealing to the layperson to make it easier…and it winds up being vexing to me. Here, it’s just the raw data, no attempt to wrap it up in a user friendly way really. And it is vexing :-)
I find myself thinking “is this one where it has been user friendly-fied, or things are really raw?”. I think that I got turned around on that camera issue I was having from trying to out think that.
There is no real perfect decision in this department, so I don’t mean this as a criticism about what is here, but more as an expression of sympathy that it’s just how it goes in these situations. VUO team has put in a lot of effort and it shows.
I do wish there was a 1:1 analog for the QC mouse patch functionality constructed out of these nodes, and then things could be swapped out as needed. I know there have been a couple/few compositions posted after my questioning about this, which I have not yet looked at…and they may do this exact thing.
Haven’t used QC for years, moved it to the trash back then ;)
You mean this node ?
Ah so this was like a
Receive Mouse Moves +
Check Mouse Status all in one, with the “buttons” output sending “pressed” booleans ?
Yeah to mimic the first 4 output ports of that, you can do it with 5 nodes (see joined composition file).
Mouse Patch 1.1.vuo (5.28 KB)