-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.
I also created three videos of how to make some simple animations in the Bongo 3 WIP. Thereās a lot more more going on than what I show but this should at least get you started.
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):
After moving the Pivot, the two connected lines disappeared, or just became invisible.
_ Fig 2. The two lines seems to still exist, but they are no longer visible, not even if trying to unhide::
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.
Perhaps instead of looking exactly the same they should look different as to differentiate the change occurring? I think disabling one when the other is active is a good idea.
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.
This is an option Iām thinking about. Weāll see.
