I’m working on a patch where the leap motion is controlling the 3d-position of a lightsource and I’m experiencing some poor performance.
When I first did the patch I discovered that the previous mac mini (2012) was unable to run the leap motion in my patch. The rest of the patch worked, with three separate moving lightsources; no problems. But the leap part of the patch did not respond. On my 2013 macbook pro retina it works, but not on the mac mini.
I recently bought the new mac mini and the whole patch works, though not well.
In the patch there is a “Fire perodically” trigger of a count wich controlls the moving lights. For the patch to work I have to set it to 0,2sec which gives the whole visualization a choppy result.
Is there a work around? A way to set leap motions refreshrate to correspond?
Also: is it possible to juice up the leap motion to make it work better trough a second layer of glass?
Birk
PS: I will upload the file, on this computer I don’t have the right version.
Hi, @bnvisuals. You mentioned you were going to upload your composition. Could you upload it, so we can review it to help you figure out how to improve the performance?
If the Leap nodes aren’t responding at all, it might be due to issues with the Leap drivers. If you still have the old (2012) Mac Mini, could you try downloading and installing the latest Leap drivers and see if that fixes it? Vuo requires Leap driver version 2.0.5 or later.
Hi @smokris, sorry, I can’t get to the file right now since it is inside of a window installation. I will post it when I get to it at the end of the month. Thanks
I am having a similar problem (maybe because i’m on a late 2011 macbook? i’ve attached a screenshot of specs). The leap motion works fine but when I try to control a wave with either a fire periodically, fire on on display rate or the requested frame it dropped 95% of events. Is there a way around this or is it just the my specs?
Thanks for the composition. When I deleted the “Receive Leap Frame” node the performance on my computer didn’t change. I am seeing dropped events from the “Requested Frame” output port of the “Render Layers to Window”, but not 95%. Changing the mode to “Enqueue Events” didn’t change the performance on my computer, but you might want to try that. We’ll do some more investigation and get back to you. Could you let us know what OS X version you are running?
Thanks for the quick reply! With enqueue i’m getting roughly 4fps so not really usable as I want a smooth color change. I am on OSX 10.10.2
What I can do is publish the value and use the composition within COGE if i don’t get better performance.
Hi, Bertie. I looked into your composition to see where exactly it was slow, and it turned out to be the part where it’s doing Shade with Color to change the color of the cube. Darn, that shouldn’t be so slow. It seems to be an issue with some graphics cards and not others. I created a bug report: Many events dropped by composition that changes the color of a 3D object. Sorry I can’t suggest a good workaround at the moment, but we’ll try to get this fixed in an upcoming release.
Hi guys and sorry for the late reply. Here’s my document. Just replace the 3d-scene. Tried different objects but the more complex the shape the less likely the scene would start correctly, not to mention the leap.
Do you think there is any way of making the program less heavy?
Do you think there is any way of making the program less heavy?
Sure. You mentioned earlier that you had to change the Fire Periodically to 0.2 seconds and that made the animation choppy. As you probably noticed, the events from Fire Periodically and Receive Leap Frame are competing with each other. Imagine them jostling each other as they each try to get to the nodes that create the scene. Not very efficient. It’s more efficient if the two event sources can cooperate by getting in sync. The attached composition does that by replacing the Fire Periodically with a Fire on Display Refresh (to get a nice framerate for animation, though you could also do that with Fire Periodically) and getting the events in sync by adding a Hold Value after Receive Leap Frame. That way, there’s just one stream of events (from Fire on Display Refresh) flowing through the nodes to create the scene. It’s more efficient and not choppy.
Concerning the fact to sync 2 different event sources and prevent them from competing @Smokris helped me here and uploaded a modified composition with that Hold Value trick. Thought I could mention this here too
Hmm, besides being on a different computer, has anything else changed since you last tried? Are you on a different version of Vuo? Have you updated your Leap Motion drivers? Are you testing with a different Vuo composition than before?
The computer is new, and everything is reinstalled. New Vuo and the Leap-driver is probably updated. It is not the developer-version this time around. Straight of the shelves at Leap motion.
I tried different Vuo projects, with the same result.
