Cloth UI redesign #49145

New Issue

Luca Rood · 2016-08-23T09:07:05+02:00

Luca Rood commented

2016-08-23 09:07:05 +02:00

Currently the cloth settings UI suffers from great inconsistencies and design flaws, caused mainly by the great amount of independently developed features added over time, causing the UI to be "patched together" in an unorderly fashion.

I think we are now at a point in time where we have a good view of what is required for the cloth UI to work properly. We can now make a new design, considering all the features that already exist, and organizing things with a mind on what is yet to come. This would not only benefit users, allowing them to find features more easily, but also developers who want to add new features to the cloth simulator, and currently don't have even a remotely logical place to put them in the UI in most cases.

Here is what I have found wrong with the current UI (this includes both objective issues and somewhat personal opinions):

Settings are not categorized properly (related settings are spread across panels, and panels contain unrelated settings, we even have entire panels dedicated to a single feature):
The panel actually called "Cloth" contains all the physical properties (mass, stiffness, damping...), but also a few settings that control vertex positions and shape (pinning, rest shape key, and the recent dynamic mesh feature).
Other shape related settings (shrinking and sewing springs), are located in another panel, entitled "Cloth Sewing Springs", which is misleading seeing as shrinking isn't really related to sewing springs per se.
Redundant check-boxes and check-boxes that control unrelated features (this is somewhat subjective):
Check-boxes for pinning and for stiffness scaling are unnecessary, as simply not specifying a vertex group is enough to disable these features.
Shrinking shouldn't depend on having sewing springs checked.
It should be possible to have self-collision active without having object collision active, as those are not mutually dependant (this is probably the most debatable thing I am proposing).
Inconsistent UI design for things that have the same behaviour:
It is possible to "modulate" structural and bending stiffnesses with a vertex group, by means of the stiffness scaling feature (located in a separate panel from the modulated settings)
Similarly, it is also possible to modulate shrinking with a vertex group, however the UI design for that is totally different, having min and max shrink values right next to each other, beside a vertex group field.

I have fixed all the mentioned issues by reorganizing the UI, and making some actual behaviour changes to the cloth logic code. Here I'll show my proposed design (patch of the implementation, for actual testing, is attached at the end), and of course I would appreciate it if all of you would chip in with your opinions on what is good about it and what you think should be changed.

Here is an image showing all the changes with my cloth UI proposal:

Finally, here is the diff you can apply onto master to test the new UI (I, of course, have all the changes neatly separated into individual commits, so if anything is to be merged, I can supply a separate diff for a specific change):
cloth-ui-redesign.diff

Currently the cloth settings UI suffers from great inconsistencies and design flaws, caused mainly by the great amount of independently developed features added over time, causing the UI to be "patched together" in an unorderly fashion. I think we are now at a point in time where we have a good view of what is required for the cloth UI to work properly. We can now make a new design, considering all the features that already exist, and organizing things with a mind on what is yet to come. This would not only benefit users, allowing them to find features more easily, but also developers who want to add new features to the cloth simulator, and currently don't have even a remotely logical place to put them in the UI in most cases. Here is what I have found wrong with the current UI (this includes both objective issues and somewhat personal opinions): - Settings are not categorized properly (related settings are spread across panels, and panels contain unrelated settings, we even have entire panels dedicated to a single feature): - The panel actually called "Cloth" contains all the physical properties (mass, stiffness, damping...), but also a few settings that control vertex positions and shape (pinning, rest shape key, and the recent dynamic mesh feature). - Other shape related settings (shrinking and sewing springs), are located in another panel, entitled "Cloth Sewing Springs", which is misleading seeing as shrinking isn't really related to sewing springs per se. - Redundant check-boxes and check-boxes that control unrelated features (this is somewhat subjective): - Check-boxes for pinning and for stiffness scaling are unnecessary, as simply not specifying a vertex group is enough to disable these features. - Shrinking shouldn't depend on having sewing springs checked. - It should be possible to have self-collision active without having object collision active, as those are not mutually dependant (this is probably the most debatable thing I am proposing). - Inconsistent UI design for things that have the same behaviour: - It is possible to "modulate" structural and bending stiffnesses with a vertex group, by means of the stiffness scaling feature (located in a separate panel from the modulated settings) - Similarly, it is also possible to modulate shrinking with a vertex group, however the UI design for that is totally different, having min and max shrink values right next to each other, beside a vertex group field. I have fixed all the mentioned issues by reorganizing the UI, and making some actual behaviour changes to the cloth logic code. Here I'll show my proposed design (patch of the implementation, for actual testing, is attached at the end), and of course I would appreciate it if all of you would chip in with your opinions on what is good about it and what you think should be changed. Here is an image showing all the changes with my cloth UI proposal: ![Comparison.png](https://archive.blender.org/developer/F341569/Comparison.png) Finally, here is the diff you can apply onto master to test the new UI (I, of course, have all the changes neatly separated into individual commits, so if anything is to be merged, I can supply a separate diff for a specific change): [cloth-ui-redesign.diff](https://archive.blender.org/developer/F341573/cloth-ui-redesign.diff)

Luca Rood commented

2016-08-23 09:07:05 +02:00

Changed status to: 'Open'

Luca Rood commented

2016-08-23 09:07:05 +02:00

Added subscriber: @LucaRood-3

Aaron Carlisle commented

2016-09-05 01:55:39 +02:00

Added subscribers: @JulianEisel, @PawelLyczkowski-1

Brecht Van Lommel commented

2016-09-11 02:47:34 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2016-09-11 02:47:34 +02:00

Perhaps it's better to submit this as a differential for easier code review?

I agree with most of the points, but some comments:

This seems to be breaking backwards compatibility in some ways, if it's removing options or changing how they work. Ideally the patch would include versioning to keep compatibility.
For the collision panel, it is against UI conventions to use such boxes for organizing options. Some object collision options also seem to be shared with self collision, like repel distance. I also noticed there exists a self_friction property that is not used in the UI or simulation code.
I agree it can be useful to have self collision without object collision, for example a flag blowing in the wind. Perhaps there could be two columns, one for object and one for self collision, and then the shared properties below that?
Cloth shape panel looks a bit disorganized, I would try to organize it into columns more.

Perhaps it's better to submit this as a differential for easier code review? I agree with most of the points, but some comments: * This seems to be breaking backwards compatibility in some ways, if it's removing options or changing how they work. Ideally the patch would include versioning to keep compatibility. * For the collision panel, it is against UI conventions to use such boxes for organizing options. Some object collision options also seem to be shared with self collision, like repel distance. I also noticed there exists a `self_friction` property that is not used in the UI or simulation code. * I agree it can be useful to have self collision without object collision, for example a flag blowing in the wind. Perhaps there could be two columns, one for object and one for self collision, and then the shared properties below that? * Cloth shape panel looks a bit disorganized, I would try to organize it into columns more.

Luca Rood commented

2016-09-21 22:01:43 +02:00

Sorry for my late reply, for some reason my email app didn't notify me.

I posted it here, as it is more of a proposal, and I thought that it would allow for better discussion. Once everything is agreed upon, I'll submit a diff.

Backwards compatibility: The lack of versioning has been a deliberate choice, as in this case we have to weigh the pros and cons. As far as I can see, the only thing that breaks compatibility here, is the case where one has a file wherein one of the removed flags is disabled, but a vertex group is specified in the corresponding field, in which case the previously disabled option will become enabled in the new version of Blender. Versioning in this case would mean emptying all the vertex group fields whose corresponding checkboxes are unchecked, which could be undesirable if the person temporarily disabled the checkbox, and has many vertex groups while not necessarily remembering which one should be there. So it is a case of deciding between data integrity (keeping the vertex groups) or complete behavioural consistency (removing vertex groups of unchecked features).
Collision panel: I didn't know about that convention, I'll remove the boxes then (why do they even exist?). As far as I can tell, no options are shared between the collision and self collision, I could be wrong though. Regarding the self_friction property, I don't know anything about that, probably something someone was going to implement later, should I remove it then?
Cloth Shape panel: I do indeed agree that it looks disorganized, I almost pointed that out in my proposal. I have tried multiple layouts for this panel, but never got to a satisfactory result. The main issue being that if I organize it neatly in columns, the "Sewing" and "Dynamic Mesh" checkboxes look too similar, and might confuse the user into thinking "Dynamic Mesh" is related to "Shrinking", in the same way "Sewing" is to "Sewing Force", despite the colon and the graying out behaviour existent in sewing. What do you think?

Sorry for my late reply, for some reason my email app didn't notify me. I posted it here, as it is more of a proposal, and I thought that it would allow for better discussion. Once everything is agreed upon, I'll submit a diff. * **Backwards compatibility:** The lack of versioning has been a deliberate choice, as in this case we have to weigh the pros and cons. As far as I can see, the only thing that breaks compatibility here, is the case where one has a file wherein one of the removed flags is disabled, but a vertex group is specified in the corresponding field, in which case the previously disabled option will become enabled in the new version of Blender. Versioning in this case would mean emptying all the vertex group fields whose corresponding checkboxes are unchecked, which could be undesirable if the person temporarily disabled the checkbox, and has many vertex groups while not necessarily remembering which one should be there. So it is a case of deciding between data integrity (keeping the vertex groups) or complete behavioural consistency (removing vertex groups of unchecked features). * **Collision panel:** I didn't know about that convention, I'll remove the boxes then (why do they even exist?). As far as I can tell, no options are shared between the collision and self collision, I could be wrong though. Regarding the `self_friction` property, I don't know anything about that, probably something someone was going to implement later, should I remove it then? * **Cloth Shape panel:** I do indeed agree that it looks disorganized, I almost pointed that out in my proposal. I have tried multiple layouts for this panel, but never got to a satisfactory result. The main issue being that if I organize it neatly in columns, the "Sewing" and "Dynamic Mesh" checkboxes look too similar, and might confuse the user into thinking "Dynamic Mesh" is related to "Shrinking", in the same way "Sewing" is to "Sewing Force", despite the colon and the graying out behaviour existent in sewing. What do you think?

Brecht Van Lommel commented

2016-09-21 23:22:08 +02:00

In #49145#393015, @LucaRood-3 wrote:

Backwards compatibility: The lack of versioning has been a deliberate choice, as in this case we have to weigh the pros and cons. As far as I can see, the only thing that breaks compatibility here, is the case where one has a file wherein one of the removed flags is disabled, but a vertex group is specified in the corresponding field, in which case the previously disabled option will become enabled in the new version of Blender. Versioning in this case would mean emptying all the vertex group fields whose corresponding checkboxes are unchecked, which could be undesirable if the person temporarily disabled the checkbox, and has many vertex groups while not necessarily remembering which one should be there. So it is a case of deciding between data integrity (keeping the vertex groups) or complete behavioural consistency (removing vertex groups of unchecked features).

If this goes into 2.8 it's not really an issue, otherwise would suggest to empty the vertex groups anyway.

Collision panel: I didn't know about that convention, I'll remove the boxes then (why do they even exist?). As far as I can tell, no options are shared between the collision and self collision, I could be wrong though. Regarding the self_friction property, I don't know anything about that, probably something someone was going to implement later, should I remove it then?

The boxes exist for modifiers, constraints, vertex groups, etc.

You're right, I don't think anything is shared. I didn't see there was both a bvhtree and bvhselftree that have different settings. The unused self_friction is just something I noticed while looking at the code, you can remove it if you want.

Cloth Shape panel: I do indeed agree that it looks disorganized, I almost pointed that out in my proposal. I have tried multiple layouts for this panel, but never got to a satisfactory result. The main issue being that if I organize it neatly in columns, the "Sewing" and "Dynamic Mesh" checkboxes look too similar, and might confuse the user into thinking "Dynamic Mesh" is related to "Shrinking", in the same way "Sewing" is to "Sewing Force", despite the colon and the graying out behaviour existent in sewing. What do you think?

Normally you'd jus add an extra separator() so there's some extra spacing between the buttons. If that's not clear enough perhaps you can add a "Shrinking:" label and have a "Shrinking Force: " button below?

> In #49145#393015, @LucaRood-3 wrote: > * **Backwards compatibility:** The lack of versioning has been a deliberate choice, as in this case we have to weigh the pros and cons. As far as I can see, the only thing that breaks compatibility here, is the case where one has a file wherein one of the removed flags is disabled, but a vertex group is specified in the corresponding field, in which case the previously disabled option will become enabled in the new version of Blender. Versioning in this case would mean emptying all the vertex group fields whose corresponding checkboxes are unchecked, which could be undesirable if the person temporarily disabled the checkbox, and has many vertex groups while not necessarily remembering which one should be there. So it is a case of deciding between data integrity (keeping the vertex groups) or complete behavioural consistency (removing vertex groups of unchecked features). If this goes into 2.8 it's not really an issue, otherwise would suggest to empty the vertex groups anyway. > * **Collision panel:** I didn't know about that convention, I'll remove the boxes then (why do they even exist?). As far as I can tell, no options are shared between the collision and self collision, I could be wrong though. Regarding the `self_friction` property, I don't know anything about that, probably something someone was going to implement later, should I remove it then? The boxes exist for modifiers, constraints, vertex groups, etc. You're right, I don't think anything is shared. I didn't see there was both a `bvhtree` and `bvhselftree` that have different settings. The unused `self_friction` is just something I noticed while looking at the code, you can remove it if you want. > * **Cloth Shape panel:** I do indeed agree that it looks disorganized, I almost pointed that out in my proposal. I have tried multiple layouts for this panel, but never got to a satisfactory result. The main issue being that if I organize it neatly in columns, the "Sewing" and "Dynamic Mesh" checkboxes look too similar, and might confuse the user into thinking "Dynamic Mesh" is related to "Shrinking", in the same way "Sewing" is to "Sewing Force", despite the colon and the graying out behaviour existent in sewing. What do you think? Normally you'd jus add an extra `separator()` so there's some extra spacing between the buttons. If that's not clear enough perhaps you can add a "Shrinking:" label and have a "Shrinking Force: " button below?

Luca Rood commented

2016-09-22 15:53:22 +02:00

So I'll empty the vertex groups (regardless of 2.79 or 2.8 I guess...).

Thanks for the clarification on the boxes, I had forgotten about those cases. I'll remove those, and perhaps separate the collision options with a separator(), or should I create individual panels for "object collision" and "self collision"?

And lastly, I'll try to better organize the "Cloth Shape" panel.

Then I'll create a differential for final review.

So I'll empty the vertex groups (regardless of 2.79 or 2.8 I guess...). Thanks for the clarification on the boxes, I had forgotten about those cases. I'll remove those, and perhaps separate the collision options with a `separator()`, or should I create individual panels for "object collision" and "self collision"? And lastly, I'll try to better organize the "Cloth Shape" panel. Then I'll create a differential for final review.

JT Nelson commented

2016-12-03 18:26:34 +01:00

Added subscriber: @jta