[WISH] adding tooltips with short description

@Joshua_Kennedy ,

Is it possible to add short description of these sliders and check boxes.


Also what does the change of the slider means quantitative value, is it a percentage of some sort does it have a unit value?

As long as you do not want use the Physic attributies of objects (like gravity and collision), so when you only use Connections, you do not have to worry about these setting.

You know what one of the Bongo 2 problems was? It was unclear what’s what and what does what. Everything was trial and error. Waste of time unknowing if the result will be even close to what you expect. Not knowing even if it was possible to be done with Bongo.
I do want to use the physics engine, of course, that is I believe your best selling point, but if people are unable to understand how things work and predict how each slider and value will affect their “animation”, before the actual calculation is run, version 3 will suffer the same major issue of version 2.

Users need to know even reminded before clicking or sliding some setting. There are so many software out there, and very few people focus on just one, and you can’t know everything. You go use some software to complete a task then go on to another, go back and forth. Especially with the niche that Bongo is targeting, you don’t use this kind of simulations very often. People forget.

What kind of answer is that? What if the user DOES want to use Physics?

I don’t think Ivelin wanted help on the specific window. I think he was making a general observation about Bongo’s usability and a suggestion for improvement. He subsequently made that quite clear.

Tooltips everywhere a field is available for input is a good suggestion. Even better might be McNeel’s dynamic help as used in Rhino. Both would be best.

As long as Bongo is a “figure it out for yourself with no available clues” experimental app it will not - cannot - be a successful usable product.



I logged a bug here for adding tooltips and making it a bit clearer. Please understand this is still a WIP and these settings are likely to change. As a result documentation is not a priority. We want to stabilize the software before we begin the documentation process.

As for your question, here’s a quick overview.

  1. When “Preview physics shape” is set the objects physics mesh/box/sphere is drawn in the viewport to help visualize the objects shape.
  2. Restitution refers to the objects coefficient of restitution between 0 and 1.
  3. Friction and rolling friction are both coefficients as well. This issue among others are open to help explain it and make the results more interpretable.
  4. The softbody stiffness is also a coefficient that helps determine how stiff the shape is.
  5. The margin is padding added around the physics shape for simulation stability. It helps prevent collisions from being missed since small, fast moving objects may clip through other objects. It also helps determine the angle collisions occurred at so they can bounce away correctly. I would suggest keeping the default. Setting it to 0 is possible but there is potential objects may behave poorly. This is in model units.
  6. Offsetting the shape acts like the offset command. This is used to hide the margin since parts may be tight fitting. The offset amount is the same as the margin by default.
  7. The shape should be self explanatory. The mesh quality attempts to tessellate the original object more or less. Bullet, the underlying physics engine, has some requirements for the physics mesh that need met. So modifying this may not always have a strong effect.
1 Like

I totally understand that @Joshua_Kennedy , but if I’m unable to understand what’s what I am unable to test, in that case what is the purpose of WIP access?

1 Like

I know this is a catch 22, but I’m more than happy to clarify these things when you ask. I appreciate the fact that you’re testing these features and reporting bugs, giving feedback, and asking questions.

1 Like

For starters, could we get more videos with some explanations and not just clicking. Even not talking but some labels on the screen will be enough.

I can try to whip something up. Is there a specific feature you’d like me to go over?

maybe make this one work as in the video with the latest release of the WIP?

Excuse me for the annoyance, yesterday night I was:
a. kind of in a hurry and not sure I had some time left today for an extensive reply (I’m leaving for a week holiday in Berlin).
b. from Jansen's linkage - #11 by Luc under the impression that Ivelin was trying to animate the Jansen’s linkage, nothing more.

Sorry and goodbye. I have a plane to catch.

I will try to do that in the coming few days. I logged a bug to remind myself.

1 Like

I presume that you mean they could be removed entirely and maybe even reinserted later, rather than just that the value ranges, data entry method, or cosmetics might change.

In either case, however, a potential feature tester needs to know what it’s for and generally what the program expects for data. Remember: users know very well whether a feature is likely to do them any good or not but may not have a clue how the magic happens, what he/she needs to supply as data to make it work, nor even what exactly a certain piece of data represents and why it’s needed or what it does. So the WIP needs to do a certain level of education about the details of your particular implementation, even if it presupposes the tester has an elementary (or even sophisticated) knowledge of what the feature is trying to do.

As a sometime developer/programmer I understand that proper detailed documentation and help takes time and effort so any possible way it can be delayed until design is finalized is very tempting. But I also know how easy it is to include a tooltip - essentially no harder than putting in a debugging msg box or print statement - so IMHO I think it should be standard practice for every new data entry thing included for tryout in a WIP. I think it would be a significant lowering of the barriers to testing for many users and would likely generate much more user input for you to consider. If done with the requirement in mind, it should be straightforward to devise a script that would go through the source and turn them off, back on or completely remove them for release, though I’m not sure that removal would be good for any other reason but company policy.

1 Like

that reminds me how much I struggled at first to figure out what all subd commands do.