general my impression of the IK usage is, that it is not user friendly and intuitive. It’s difficult to get started with IK. I wished the IK system could redone. Some years before I used Pro/Desktop, a great little parametric modeler from PTC. Assemblies was easy created by assigning constrains like axial, mate, align, fix, … . Easy to understand, quick to setup. Finally the user was able to pick one part and move it and the other parts follows. If there was enough constrains, the mechanic was moving like in the real world. Very simple and intuitive, like a toy software for childrens, very powerful.
For example for a robot arm I would select the cylindrical axis and made it axial, fix the ground part and add a constrain to the pick. Ready. I think RhinoWorks works this way, only an automatic update instead the update button is needed to make it like at Pro/Desktop.
Couldn’t Bongo not work like RhinoWorks, more intuitive? Working with Pro/D was fun, Bongo IK is brain jogging.
Here an example, two parts with holes. Lower part is set to “fix component”, next step, two cylindrical faces are selected and set to “center axis”.
Than the two red selected surfaces are set “mate”
Now, if the upper component is selected and moved, the constrains are active, the component can be rotated only.
On this way several parts can be connected without to think about IK chains and pivot points. Per Bongo it’s very difficult to connect several parts that are not organized in a chain, objects with several connections like here.
I think Bongo IK will not find much users because the difficult usage. My example shows how good an intuitive workflow was more than 10 years in the past.
Thank you for your feedback. I added this discussion to the wishlist for Bongo 3.0: http://mcneel.myjetbrains.com/youtrack/issue/BO-2785
If you have more ideas about hos to improve the IK UI, please feel free to add them to this discussion.
Well the people who wrote it might, but they’re not sharing with anyone else. Not only isn’t it very intuitive for most people, even the limited knowledge available needs to be dug out laboriously. And then it doesn’t make much sense. The whole thing must be based on a mental model that seems intuitive to one developer, but not so much to anyone else. I don’t think anyone else has figured out what that mental model is.
[quote=“Andrew_Nowicki, post:7, topic:19300”]
Bongo 2 is useless
[/quote] Bongo deals with Animation, and IK is only a slice of it. Even if IK is hard to grasp it doesn’t make the whole of Bongo 2 ‘useless’.
For this scissor-mechanism-item e.g. – although it offers a great challenge to find a IK structure to deal with it, IK certainly isn’t the most obvious way to animate it. This goes for quite some mechanical structures. Bongo has other assets, like its Expressions, that are worthwhile. I’m planning a video on it.
[quote=“Andrew_Nowicki, post:7, topic:19300”]
nobody understands how it works
[/quote] I for one do understand perfectly how it works, and I’m just a simple retired architect/teacher, not some gifted developer. I didn’t take any course on the matter. Purely intuitive auto training.
Anyway thinking out an Inverse Kinematics structure is seldom easy. A profound understanding of Forward Kinematics based on Hierarchical Linking is fundamental. I hope you have seen my video on the basic Whys of IK (http://bongo.rhino3d.com/video/whys-of-ik). Further on I’ll use terms introduced in it.
I do agree to:
There is little documentation provided by the developers. The Help file, the Support pages on the website or their few tutorials are a bit poor (to put it mildly).
That’s why I have put in the effort of making tutorials my one, and plan to keep on doing.
Bongo’s conception of Forward as well as Inverse Kinematics is rather academic instead of applied. I feel it thereby offers a far greater range of possibilities and freedom to the user. Indeed it invokes some intelligence.
The Animation Manager is hardly suitable to reflect the structure of extensive or complex chains. I’m reflecting on a suggestion in this regard towards version 3.0.
This particular model is truly hard to understand.
To start with; it is always hard to see the structure in an IK chain conceived by some else.
Secondly the model unfortunately has 2 unnecessary constraints.
Finally the leadscrew is in fact an addition but it isn’t playing any part in the functioning of the scissor (although it could) making things appear even more complex.
In scissortable2x_Ik 002.3dm (5.3 MB) I deleted all superfluous elements keeping only those essential for the IK.
The basic structure is a chain formed by objects 1, 2, 3 and 4 hierarchically linked and made hinges according to their Y-axis.
Point object 5 marks the end of the chain and is constrained to a ‘driver’ outside the IK-chain: point 7 being part (child) of the downward moving table. ‘The snake is shaken by its tail’ – as I call it.
Operating this system however will not give the wanted result.
To make the central parallelogram stable a kind of mega structure is formed by constraining the end of rod 4 (marked by point 12) to the end of rod 1 (marked by point 11).
And that’s it.
The upper and lower horizontal constraints in the original model are an alternative way. Functioning both together they will also stabilize the scissor. In that case the central link can be omitted. But I prefer simple solutions.
The leadscrew forms a separate little chain hung up on the basis structure. It can better be done with a Simple ‘LookAt’ constraint instead of IK.
I hope, despite all your annoyances, you can enjoy the study of this model, to take you a step further in grasping the mental model of Forward and Inverse Kinematic.
Luc
the problem of Bongo is, if you use it a few times every year only, I feel like start at the beginning, if I try to use IK. Did you read my first post? Your example would be very easy to setup, if the way of Pro/Desktop or RhinoWorks would be gone. It would be a simple play for children, like playing Lego - align all axis and fix some points - ready. I hope this thread will not be a thread of frustration and the team starts to think in this direction of intuitive usage.
Bongo 2 is forcing us to draw one line and two points in seemingly random locations to define one constraint. I have seen all kinds of crazy software, but Bongo 2 certainly deserves Rube Goldberg award. Why is Bongo 2 freezing all the time? Why does it scatter animated objects?
As posted before, this conversation is being monitored so all improvement ideas will be taking in countered when we start to work on Bongo 3.
It would help us to improve the software if you could give us an example when you feel like this is happening? An example model would be great.
Without more information it’s hard to tell. What are you doing when this happens? Can you send us an example model including steps how to reproduce the problem?
Bongo - simple roller coaster.3dm Bongo - simple roller coaster.3dm (92.5 KB) was posted on the Bongo website. It is good example of this problem. The roller coaster is a train made of 3 identical wagons. Each wagon is made of 1 rectangle, 1 or 2 lines, and 2 points. (When I copy any wagon, all copies of rectangles, lines, and points are doubled for no good reason.) The lines and the points are used to define constraints. Each wagon is constrained to same (curved) path and to the position of adjacent wagon. In other words, there are only two constraints for each wagon. In this Rhino file all the lines and all the points constrain each wagon/rectangle. It is impossible to deduce from the Rhino file how these constraints are applied, and why so many constraints are necessary.
It seems that Bongo 2 freezes due to its buggy “precalculation” feature. The slightest error freezes Bongo and there is no way to recover from this calamity.
When I add new animated objects unrelated to the roller coaster, the components of the roller coaster are scattered in random directions.
What command are you using to copy the wagon? BongoCopyChain?
The BongoCopyChain at least copies the whole chain of objects, the children of the object you copy. This is by design. With the normal copy command I don’t see the behavior you describe.
Bongo - simple roller coaster 001.3dm (78.4 KB)
^ here’s a simplified model. That doesn’t have the lines.
The lines between the wagons are there to symbolize the chain that would go between the wagons in real life and how you could go about to animate that chain.
I’m unable to reproduce the freeze nor the scattered components.
Could you please give some more information on what exactly you’re doing to make these problems show up?
For complex mechanisms it is often hard to figure out who is child of who. A more explicit pedigree diagram would help.
I sometimes use the display-color of object (Object Properties), or a separate layer (hence different display-color), in order to differentiate objects in a specific function (is faster done than figuring out some name). It would help to distinguish them if their display-color would likewise be used in the Animation manager.
I think I understand what Andrew means. Indeed when a complex or a pretty long IK chain is manipulated into dissolvability it takes quite a while before the IK solver finds out. The Windows window turns pail and it looks as if everything freezes. But luckily patience always brings salvation –although it can take long, certainly when your computer hasn’t a powerful processor. When handling tricky chains I mostly turn of the IK solver.
A (slight) improvement would be if the _BongoPreCalculateIk command would keep on functioning even when IK is off, hence allowing to have a calculation-attempt without having to turn on IK first, and off afterwards.
We need graphical illustration of all relationships between the parent and its child. It may be good idea to define new Bongo widget: link between animated objects.
My thoughts exactly. The current IK view (in the Animation manager is hardly informative.
I amused myself by working out an idea I was chewing on for some time. The widget (as Andrew calls its) could replace IK view in the Animation manager.
The basic concept is a graphic organizer similar to Grasshopper’s interface, consisting of a canvas on which every animated object (or related ones) occurs as an entity. Every component presents its name and its object type (point, curve, (poly-)surface, block, group) by means of icons. Additionally IK data (hinge, telescope, rubber band, ball, and/or constraint) is displayed through icons, as well as ‘energy’ info (object moves, turns, scales of is active via a Simple Constraint).
Initially the tree (hierarchy) is presented by Bongo in a traditional ‘Pedigree’-way. (the illustration shows the elements of the scissorarm in my video The conception of an IK-chain)
Then the user can arrange the components (just like Grasshopper’s element) to support the ‘logic’ of his system. Alignment tools can help in the organization (cfr Grasshopper). (illustration shows the elements in scissor-arm scissortable2x Ik 002.3dm above)
Some features:
Unanimated object to which an constraint is set up are in display as well (in distinct graphics). (the illustration shows the elements of Bongo - simple roller coaster.3dm above)
Objects (with no significant role) can be shrunken to get out of the way. Grandfather with his granddaughter while father is momentary out of site.
A selected object reveals (highlights) all relationships and related objects (cfr. Grashopper).
The display can be zoomed (in, out, extends …).
Mouse-over (or clicking) the various icons can display supplemental information (list of Simple constraints, axis used by IK-joints, relax of constraints etc…)
Clicking (or double-click, or right-click…) an icon opens the concerning window for editing (Simple constraint dialog, Ik-joint type or axis, kind of constraint of relax/constraint…)
Parent/child connection can be initiated, deleted and/or rearranged just like in Grasshopper’s GUI.
Secondly, supplementary to the previous, a Bongo-display-mode for Rhino’s viewports could be interesting. Just like Neon has its own View-mode.
This concept is based upon the illustrations in my tutorial-videos.
The display would show not only hierarchy links and joints (somewhat more explicit than the current ‘decoration’) but also constraints, and whether an object is ‘energized’ (by keyframe-entries) or not. (illustration shows again the elements in scissor-arm scissortable2x Ik 002.3dm above)
Some features:
A grayed out display of the actual objects can be optional.
The size of the icons can follow the pivot-size (and/or adjustable in Options).
Unanimated object to which an constraint is set up are shown as well.
A selected object reveals (highlights) all relationships and related objects
If anything like this schematic representation ever comes to pass, I think a very important feature to include would be that when one of the symbols is moused over the corresponding geometric object in the geometry viewport would be highlighted. This would be a big help in keeping the modeler’s geometric model focus mentally in sync with where he is in the IK representation. Probably should work in the other direction too (mouse geometry object=>hi light associated IK icon).
In GH, the geometry created/referenced by each module is highlighted in Rhino when you select the module in GH… In this case it needs a click on the module, not a mouse-over, but that does allow selecting multiple components with shift+click or window.
Good point. Design choice between mouse-over or multiple clicks comes down to whether the feature is primarily used to quickly confirm user-focus sync between representations, or analyzing connections in either realm. Kind of like looking at sound in amplitude-time view or frequency-time view. Maybe default mouse-over, but click with a modifier key.
