After swapping the basis shape key to another one, the former basis key still affects the new one #79892

New Issue

David Kozma · 2020-08-18T19:14:54+02:00

David Kozma commented

2020-08-18 19:14:54 +02:00

Blender Version
2.91.0

What I try to do: I would like to make a later created shape key the basis one.
I can do it with moving it to the top, and setting the former basis key's "Relative To" setting to this new basis one.
It works as expected until I'd like to make further changes in the old basis key (now just a regular shape key)
It affects the current basis, where - by definition - there's no "relative to" setting, so it shouldn't be affected by anything.

I noticed that it does work as expected if I'm using the "shape key in edit mode" option - BUT it only behaves well until I come back to object mode. Then the new basis key instantaneously gets all the modifications I just made on the old basis.

The steps are below on an image with descriptions, but I attached the blend file too. Just change the shape key called "starting basis" and check what happens with the real basis one.

shapekey_error.blend

Note: there was one time when I created a shape key pair where this whole thing worked as intended. But out of (literally) 6 tries, only one worked and I couldn't pinpoint what I did differently in that case.

**Blender Version** 2.91.0 What I try to do: I would like to make a later created shape key the basis one. I can do it with moving it to the top, and setting the former basis key's "Relative To" setting to this new basis one. It works as expected until I'd like to make further changes in the old basis key (now just a regular shape key) It affects the current basis, where - by definition - there's no "relative to" setting, so it shouldn't be affected by anything. I noticed that it does work as expected if I'm using the "shape key in edit mode" option - BUT it only behaves well until I come back to object mode. Then the new basis key instantaneously gets all the modifications I just made on the old basis. The steps are below on an image with descriptions, but I attached the blend file too. Just change the shape key called "starting basis" and check what happens with the real basis one. ![shapekeybug.png](https://archive.blender.org/developer/F8791471/shapekeybug.png) [shapekey_error.blend](https://archive.blender.org/developer/F8791474/shapekey_error.blend) Note: there was one time when I created a shape key pair where this whole thing worked as intended. But out of (literally) 6 tries, only one worked and I couldn't pinpoint what I did differently in that case.

David Kozma commented

2020-08-18 19:14:54 +02:00

Added subscriber: @DavidKozma

blender-admin commented

2020-08-18 19:14:54 +02:00

#81644 was marked as duplicate of this issue

Richard Antalik commented

2020-08-21 04:06:29 +02:00

Added subscribers: @mano-wii, @ideasman42, @iss

Richard Antalik commented

2020-08-21 04:06:29 +02:00

I can reproduce this, but I am not sure if this is a bug. @mano-wii or @ideasman42, do you know?

Germano Cavalcante commented

2020-08-21 04:36:06 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2020-08-21 04:36:06 +02:00

I'm not sure, either.
Bmesh updates/edits shape keys when exiting edit mode.
It is quite possible that it is updating the wrong shapekey.
So I risk confirming it as a bug for now. Further investigation is needed.

I'm not sure, either. Bmesh updates/edits shape keys when exiting edit mode. It is quite possible that it is updating the wrong shapekey. So I risk confirming it as a bug for now. Further investigation is needed.

Joe Larson commented

2020-08-22 06:06:02 +02:00

Added subscriber: @3dpprofessor

Joe Larson commented

2020-08-22 06:06:02 +02:00

Is this the same problem I found?

https://youtu.be/xSGake54S-8

If it's not a bug, it's at least inconstant behavior. I'd like to be able to animate the duplicates independently.

Is this the same problem I found? https://youtu.be/xSGake54S-8 If it's not a bug, it's at least inconstant behavior. I'd like to be able to animate the duplicates independently.

Richard Antalik commented

2020-08-25 04:04:56 +02:00

In #79892#1000527, @3dpprofessor wrote:
Is this the same problem I found?

https://youtu.be/xSGake54S-8

If it's not a bug, it's at least inconstant behavior. I'd like to be able to animate the duplicates independently.

Not sure if that is bug, but it is definitely unrelated to this report.
Duplicating object should duplicate it's data unless you choose to not do it. with own data what you posted shouldn't happen

> In #79892#1000527, @3dpprofessor wrote: > Is this the same problem I found? > > https://youtu.be/xSGake54S-8 > > If it's not a bug, it's at least inconstant behavior. I'd like to be able to animate the duplicates independently. Not sure if that is bug, but it is definitely unrelated to this report. Duplicating object should duplicate it's data unless you choose to not do it. with own data what you posted shouldn't happen

Germano Cavalcante commented

2020-10-13 19:28:06 +02:00

Added subscriber: @lukostello

Mysteryem commented

2022-01-16 18:14:57 +01:00

Added subscriber: @Mysteryem-2

Mysteryem commented

2022-01-16 18:14:57 +01:00

What happens with this setup is that the first shape key ends up relative to the second shape key, which happens to be relative to the first shape key. Editing either shape key will affect the other which is the behaviour I expect when two shape keys are relative to one another.

If, before step 3, in this example, you change "wannabe basis" so that it's relative to itself instead of "starting basis". When editing "starting basis" in step 5, it will no longer also affect "wannabe basis" because we made sure that "wannabe basis" was relative to itself instead of "starting basis".

The main issue here in my opinion is that Blender hides the key that the first shape key is relative to from the UI, despite the fact that it still has an effect as seen here, which can lead to confusing situations.

I think that either the first shape key should always be forced to be relative to itself, always act like it's relative to itself or its relative key should be made visible and modifiable in the UI.
The latter is probably the easiest and simplest since it doesn't change any existing behaviour and only requires a modification of the UI file properties_data_mesh.py.

What happens with this setup is that the first shape key ends up relative to the second shape key, which happens to be relative to the first shape key. Editing either shape key will affect the other which is the behaviour I expect when two shape keys are relative to one another. If, before step 3, in this example, you change "wannabe basis" so that it's relative to itself instead of "starting basis". When editing "starting basis" in step 5, it will no longer also affect "wannabe basis" because we made sure that "wannabe basis" was relative to itself instead of "starting basis". The main issue here in my opinion is that Blender hides the key that the first shape key is relative to from the UI, despite the fact that it still has an effect as seen here, which can lead to confusing situations. I think that either the first shape key should always be forced to be relative to itself, always act like it's relative to itself or its relative key should be made visible and modifiable in the UI. The latter is probably the easiest and simplest since it doesn't change any existing behaviour and only requires a modification of the UI file properties_data_mesh.py.

Adam Janz commented

2022-02-15 20:54:48 +01:00

Added subscriber: @AdamJanz

Roman commented

2022-02-16 07:12:54 +01:00

Added subscriber: @rwman

Campbell Barton self-assigned this 2022-02-16 13:01:06 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

After swapping the basis shape key to another one, the former basis key still affects the new one #79892