3dConnexion for GH! ... somehow

Sadly, in cases where memory usage is high, I notice that this components makes the interface crawl.
I had to delete it.

1 Like

I’m sorry to hear that… but that was expected:

You surely used it more than me.
It’s only a proof of concept… you just gave me the definitive confirm. :man_shrugging:

1 Like

Non, no, it’s not definitive !
I’m sure you can somehow optimize this :slight_smile:

Suppose you made a compiled GH component out of this, wouldn’t it help ?

I still never tried to do more than scripting in c# inside gh.
I still have long way to learn how to make any plugin for rhino or gh.

Furthermore, here i would need to “suppress”/stop the connection of the 3dmouse plugin to the viewport.
I would need to edit it and/or re-implement a new service that read the raw data from the 3dmouse.
Even these assumptions can be wrong.

Currently it is creating a viewport as decoy… even compiling wouldn’t help at all.
It’s not a matter of optimization, it need a complete rework from ground.

From the tutorials I followed and the training I got with Long Nguyen, it’s not a big deal.
I think you master the most important part which is to talk object oriented programming fluently (which is not my case AT ALL).

1 Like

This works well for me,


It is now part of my default template, thanks a lot, you should create a page for this component, I am sure a lot of people would find it useful.

Cheers

2 Likes

Works wonderfully! Thanks!

Works Beautifully!
didn’t have to close rhino, gh or my working files.

@maje90 I ran into one issue, using the “GH Zoom Preview” tool will point me to a random location on the GH canvas instead of showing me the object in Rhino.

image

1 Like

Any updates on this ? It still works pretty well but I was wondering if there had been any follow ups ?
3dconnexion and Mcneel should make this standard.

No, sorry, no updates.
I did this only for testing/challenge/boredom and proof of concept.
It is probably the perfect example of a bad implementation: it uses a “decoy” viewport to capture the 3dmouse inputs, it never uses the proper library from 3dconnexion. Worst efficiency, highest level of abstraction, errors like the one @tay.othman comment are expected and something worse might happen.

I personally never use it, I prefer move the GH canvas by mouse while simultaneously I’m able to move in the 3d space in the rhino viewport (like in other situations, like opening the option panel, or during a windows selection, 3dmouse still works!!)

I know way bigger (and much more expensive) 3d software that didn’t had a proper 3dconnexion plugin for long time.
We are lucky we have it for Rhino, we even have 2 options: the one shipped inside rhino installer, which is simpler and lighter (I prefer this one), and the one that results with the installation of the 3dmware driver (kind of different, have its own software that starts on pc boot… etc… ).

People who uses 3dmouse with rhino is already a small(?) percentage of rhino users, GH users are another small portion of total rhino users, the amount of people using Rhino(1), Grasshopper(2), having a 3dmouse(3) and wanting to use it for grasshopper(4), is probably very very small.
Who would want put effort in that? :sweat_smile:
It’s understandable if there are no follow ups…


btw, SDK is here Join the Software Developer Program at 3Dconnexion you just need to register…
The SDK works with the libraries installed by the 3dmware driver.

1 Like

No small group of people should be ignored just based on the size of the group. Hopefully this will be updated very soon. Do you know how to put a request to 3dconnexion ? Or maybe the Mcneel team ? I don’t really know where to start to ask for that.
Still works for me, I use every-time I use grasshopper, which is often.
The 3dmice will rule !

The support for 3Dconnexion devices in Rhino is developed by 3Dconnexion, not McNeel. The 3dxRhino plug-in, which controls 3Dconnexion devices, is distributed with Rhino on their behalf.

Requests for additional features should be directed towards 3Dconnexion.

Thanks,

– Dale

3 Likes

Will do

Here’s the answer from 3dconnexion:

" Ask the software vendor to integrate the 3DxWare SDK API into the software you paid the licence fee or subscription fee.
Tell them to visit here:

3Dconnexion UK

Join the Software Developer Program at 3Dconnexion

Get access to up-to-date 3Dconnexion developer tools. Simply join our Software Developer Program today.Enjoy exclusive support, latest SDKs, certification.

1 Like

If everybody keeps saying it’s the other person responsibility we’ll never get anywhere.
It feels like Mcneel could/is the one that needs to work on integrating 3dmouse for Grasshopper/GH2.
It would be super practical to move around the canvas with it.
Please give it a little bit of your time, power users will be grateful.

5 Likes

Quoting myself:

@thomas.lagarde how do you imagine it would work?
I personally prefer having the 3d mouse to control the rhino viewport all. the. times.
(for example, during print, the print UI “locks” you the acces to viewports, to change the camera position you have to exit and reenter, with 3d mouse you can correct the camera while the print UI is active…)

You would have the 3d mouse stop completely controlling Rhino viewport and controlling only Grasshopper canva?
Or, only when the cursor is above GH?
A toggle/button?

1 Like

I think it should just depend which window is in “focus”, just as for the stupid mouse pan/zoom/rotate.
Simple as that !

2 Likes

…while juggling with flaming hedgehogs.

1 Like

You have a decent point, while there are other CAD’s that allow the user to move both the 3D mouse and the 2D mouse simultaneously in a fluent manner with no glitches or hiccups whatsoever – the ‘redundant’ characteristics merely blend smoothly and other ‘complementary’ characteristics simply add to the fluency.

Rhino has always lacked in this regard.

While in the last several years they’ve dropped the ball on trying at all and did away with their drivers, as 3dconnexion has tried to pick up the ball and make better drivers.

And still 3dconnexion’s drivers are very much lacking various things.

All the while, other CAD’s don’t have these problems.

So is it 3dconnexion dropping the ball or is it Rhino.

‘Named rotation points’ would be great. :coffee:

Would it be 3dconnexion’s (logitech’s) job to invent a ‘named rotation point’ feature list? or would it be a good idea for Rhino to invent it? Such a thing could even work with the regular 2D mouse per say, but the 3D mouse is so much better, it might be funner to make the 2D mouse not benefit from such an idea. :face_holding_back_tears:

1 Like

I think Rhino does this too, and it’s more than decent for sure. Probably straight “good” too.

I’m not sure to follow you correctly, but if I’m not wrong, McNeel never developed a plugin for the 3dconnexion.
The “built in” plugin that is installed with Rhino installation, is still developed by 3dconnexion, it’s just shipped with rhino. (please devs correct me)
I prefer this simpler plugin over the resulting one if you actually install the 3dconnexion package.

I would say it’s normal that McNeel doesn’t want to involve themselves into developing the driver/plugin for an hardware that isn’t theirs.

3dconnexion should do it.
But it’s also true that “decent enough” might be their target, as we buy one 3d mouse from them and then it lasts for … 15 years? (mine is worn-out but still working perfectly)