[Bf-committers] Simple Deform modifier setting removed?

Campbell Barton ideasman42 at gmail.com
Thu Nov 21 01:02:44 CET 2013

On Wed, Nov 20, 2013 at 11:55 AM, Linus Wiklander
<linus.wiklander at gmail.com> wrote:
> I can't say I miss the functionality, if it had never been there I would
> have been fine with that. I think there are a lot of better stuff to focus
> on than to try to bring this back.
> What annoyed me was that models in my files broke due to the change. The
> reason I asked was to see if there was a workaround or way to re-enable the
> setting somehow.
> If this is not possible, I will have to write a script to solve it.
> However,
> There might be a need to work out how to manage these type of changes in
> modifiers and other areas as well?
> I don't know how this is addressed today among the developers, or how
> important compatibility issues are in general and how they are handled.
> In this particular case (since there is no real change in how the modifier
> itself behaves) it could have been solved by leaving the functionality
> working under the hood, remove the option from the modifier interface and
> replace it with a 'convert/adapt to new modifier' button if the removed
> setting is used. Clicking the button would adjust settings to keep the
> model intact (as much as possible) and then remove the button from the
> interface. This perhaps does not solve all possible issues with the change,
> but could save a majority from a lot of extra work.
> This would allow obsolete features to be gracefully removed from the
> program. Once in a while the converter functionality could be removed to
> clean things up but break compatibility in a controlled manner.

The problem with this is...

* you have files that can't be upgraded (old feature gets 'stuck').
* 2+ objects can behave differently with no user visible reason why.
* theres no way to control the option (whereas the old blender could
control it).
* Theres features in blender which can't be tested (without first
creating files in an older version).

Sometimes removing access to features in the UI but not the code
happens (by accident I think), and we get bug reports that a file
loaded from an old blender has different behavor then a new file with
the same settings,
such issues take investigation from the user and developer to figure
out the cause of the problem.

So I dont think it works to half remove features like this, the only
thing I can think to improve feature removal is to deprecate features
and give warnings, then remove in the next release.

> I don't know how general this type of solution is to other compatibility
> issues, or if it is even plausible. I think the discussion is interesting
> though.
> / Linus
> *Campbell Barton* ideasman42 at gmail.com
> <bf-committers%40blender.org?Subject=%5BBf-committers%5D%20Simple%20Deform%20modifier%20setting%20removed%3F&In-Reply-To=528B8F75.9040004%40gmail.com>
> *Tue Nov 19 19:42:53 CET 2013*
>> Ah, I mis-remembered how the option was used, your correct that this
>> is only for objects.
>> Even in this case though I think its quite arbitrary to have this
>> option for simple-deform, it could just as easily apply to
>> cast/warp/wave/array/mirror/hook/screw.
>> IMHO theres a real advantage to having the point of interest
>> (pivot/center) being WYSIWYG, even when that means you need to parent
>> the object.
>> If this ability is really useful, then we miss it for all the other modifiers.
>> We could have a XYZ center point offset (to be applied in object
>> localspace), then if you really wanted to control with an objects
>> absolute coords, the XYZ values could be driven.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

- Campbell

More information about the Bf-committers mailing list