-Integration with Bullet physics for rigid and softbody simulation
-New expressions properties for physics parameters
-Improved IK system named Connections
-Bongo gumball for simpler keyframing of objects
Rhino versions supported: Beta testing Bongo 3.0 is limited to Bongo 2.0 users. Bongo 3.0 requires a Bongo 2.0 CD key. Rhino 6.0 is required to install Bongo 2.0 and can be downloaded from http://www.rhino3d.com/download.htm
Notes: This is the current work-in-progress release of Bongo 3.0 for Rhino. The product is in the very early stages of development any will probably change a great deal before release. This may include the file format, so please do not rely on Bongo 3.0 models working in the future. Bongo 3.0 will read Bongo 2.0 files, but will save Bongo 3.0 data only. This data cannot be read by Bongo 2.0, so please backup any files before using them in Bongo 3.0.
This is kind of UI tricks is a big leap forwards with Bongo! Very good, very good.
I tried the first “linked lines” example but I had some issues with the connections breaking down when doing changes to the geometry or moving the first Pivot etc. (I understand that this is an early release though so no panic). I’ll try some more to find out exactly when the connections broke.
One thing that would be of immense value would be to be able to move a connected structure. Here for example I had drawn and rigged the linked lines along the Y-axis and then I dressed the lines with pipes, and then I manually moved the whole thing (all bits and pieces selected and then moved) I in the X- direction (along the yellow arrow). Then the whole thing went bananas (pictured).
It is very cumbersome if something has been rigged and then later you find out that you should have placed it a little elsewhere and then only ending up with a pile of crap if moving it.
The links are still (logically) connected in the “hinges” but the pieces ended up departing from each other:
Another thing which makes working with Bongo very tiresome is the fact that the “Utilities” buttons scrolls up and out of reach when scrolling further down in the properties panel, since one has to scroll up to the top again before being able to press any of the buttons (not all of there buttons are available in the other “main” panel (like setting parent, and rotating the pivot, etc).
Very much extra scrolling up and down which is frustrating. It may seem like a small detail, but it really disrupts the workflow.
I believe that all software projects should begin with documentation. If there is no documentation, there is chaos. I was the main tester of Bongo 2. It was frustrating work because there was no documentation before commercial version of Bongo 2 was released.
I understand that this is WIP, but not sure of which kind of response is useful for you in this stage, but I’ll report some issues I found trying some specific things. Let me know if it’s too early to report the kind of mishaps I’m seeing:
Moving the Pivot on one of two connected items. This will either remove the connection or even delete the objects (in my attempts both happened at different attempts).
_ Fig 1. Here I connected the two lines, and only then I tried to move the Pivot of the left line (to 0,0,0):
Unfortunately, I have not began work on any animation export yet.
Yes. This is an issue. Good find. The world connection points are a bit tricky. I think you’re right that if you move the whole structure the world connection moves as well. I think that if you only transform a single part of it though such as the animated “driver” of the mechanism it should stay put. I’ll log an issue. https://mcneel.myjetbrains.com/youtrack/issue/BO-3032
I understand. This is also on my radar. I think things are still very fluid right now and as we figure out what stays and goes this should be cleared up.
Has McNeel actively decided that having two gumball in Rhino for users of Rhino + Bongo is a better user experience? …or are you all doing this for your internal practical reasons, lack of planning of integrating your own plugins, and therefore choosing to provide us a worse user experience?
I personally find having two gumballs completely absurd, but maybe I’m just confused on why this is so much better for me. I’d love to know more.
Gumball features for Bongo was something I wanted and a rather recent development. I don’t think it was poor planning but rather that this is a new idea. To me it was obtuse that Bongo could only handle a translation from Rhinos gumball and had to go through its own rotate and scale commands. Gumball like features could help with this.
A plugin using Rhinos gumball isn’t possible. Rhino exposes the gumball functionality in the SDK but the actual instance of the gumball is hidden. Rhinos gumball is responsible for quite a bit and allowing plugins to hijack it could break modeling functionality. Rhinos gumball also can be relocated and cause transformations that Bongo doesn’t support.
I made the decision to add similar functionality to Bongos pivot in a way that was friendlier with Bongo. I thought keeping it’s look different would help also differentiate it from Rhino to prevent confusion.
I’m glad for the feedback though! It seems like I messed up and I’ll see about trying to bridge the two more closely. There’s also potential that the SDK could be extended in V7 to help remediate this.
Hi Joshua, what you describe makes sense. I’m not so sure you have messed up. I (and probably others) just wanted to understand the logic.
It has taken quite a bit of work and time for us users to get familiar with Rhino’s gumball, its design and its limitations. So maybe that’s why I don’t love the idea of having yet another gumball that behaves differently.
I also think that having clarity when you are doing a model transform vs. a Bongo (animation) transform makes sense. I have to think more about this, but I’m pretty sure that single-gumball in Modo was never confusing. A transform is a transform. We just need clarity that it’s happening at a global level or as an animation channel.
This is a problem that already exists beyond Bongo. Snapshots has the same problem. There’s no UI that’s clearly and unequivocally letting us know if we are making a transform as a global edit to a model, or as a recorded snapshot ‘named position’. So maybe the gumball needs to have a ’modal’ appearance, instead of being a different widget with different controls and different learning curve? same goes to any transform tools like Move/Rotate/Scale without gumball.
What about using different colours… keeping the graphic look of the Gumball the same as Rhino’s but using different shades of green red and blue. that system works well in other places to denote change in functionality [of the same tool from the user perspective]
I want the Bongo gumball to be fairly limited in scope. Just easily create the rotation, scale, translation keyframes. I think I made the mistake of making it too different though. It also will probably morph a bit as we find out how best to bring these types of features to Bongo.