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.

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?

In T49145#393015, @Luca Rood (LucaRood) 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?

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.

Committed rBc4ef2e2f2ebcd9967aa5d4b283ac7abe51156d51