Remove meta-ball settings synchronization
AbandonedPublic
Actions

Authored by Campbell Barton (campbellbarton) on Mar 6 2019, 3:42 AM.

Details

Reviewers

Bastien Montagne (mont29)
Sebastian Parborg (zeddb)

Summary

Attempting to copy object data settings around based on object naming and the active scene is error prone.

Currently 2.8x should work as it does in 2.79, so we could leave it as-is.

If we consider glitches reported in T61917 as bugs, it might be better to not give users the expectation that these values should be synchronized.

This patch makes the meta-ball panel show settings from the basis to avoid having to copy settings to the bases when editing.

While calling find_metaball_basis on panel draw isn't great, it avoids problems synchronizing settings.

Wary of making changes here, we can also leave this until we have more time to improve metaballs.

Diff Detail

Repository

rB Blender

Branch

TT (branched from master)

Build Status

Buildable 3057
Build 3057: arc lint + arc unit

Event Timeline

Campbell Barton (campbellbarton) created this revision.Mar 6 2019, 3:42 AM

Harbormaster completed remote builds in B3057: Diff 14016.Mar 6 2019, 3:42 AM

Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)Mar 6 2019, 4:09 AM

Campbell Barton (campbellbarton) added a project: BF Blender.

Campbell Barton (campbellbarton) mentioned this in T61917: Metaball family inherits wrong resolution by deleted metaobject, but new object don`t inherit settings by family.Mar 6 2019, 4:14 AM

This is probably fine in theory, but… not so happy about having to look into all objects' names of a scene in some panel draw code.

And as you said in your comment in D4398, mballs should really be refactored and use collections instead of object names.

So would not mind that patch going in, but personally I would just keep things as they are in 2.79.

source/blender/makesrna/intern/rna_object_api.c
621–624	Tsst, copy-pasted descriptions from above ;)

I think we should wait until we have rewritten metaballs first.

However, I don't think this method of not syncing settings is good as it will probably confuse users still why their metaball settings change if they delete the basis objects.
There is not indication in the UI of which object is the basis so to them, the metaballs will lose their settings if you delete, rename, or otherwise make the basis of the metaball group change.

I can take it upon myself to rewrite the metaballs to use the collection they are in to determine the basis. However, we still need a nice way to store and propagate the settings.
@Bastien Montagne (mont29) as they would now be collection based, perhaps we could store the metaball settings in the collection somehow?
Maybe not IN the collection but nonetheless just simply have a "settings per collection with metaballs lookup table".

Campbell Barton (campbellbarton) abandoned this revision.Mar 8 2019, 5:24 AM