Page MenuHome

(Certain) shapekeys stopped working in 2.8
Closed, ResolvedPublic


System Information
Operating system: Windows 10 64
Graphics card: GTX 1080

Blender Version
Broken: dc3b5024be1a

Short description of error
Recent builds broke shapekeys on this object. If you delete all shapekeys including base and add a new shapekey it will work.

Exact steps for others to reproduce the error
Open provided blend file and change value of shapekey 01. Nothing will happen even when the shapekey should show a deformation

Event Timeline

Philipp Oeser (lichtwerk) triaged this task as Confirmed, Medium priority.

Not sure if this has the same roots as T60401, T60249
There was also the fix by @Bastien Montagne (mont29) (rB47be4e9a3379)

But I can confirm example file is not working in 2.8 (if you append this into 2.79 it is working though...)

Philipp Oeser (lichtwerk) renamed this task from Shapekeys stopped working in 2.8 to (Certain) shapekeys stopped working in 2.8.
Bastien Montagne (mont29) lowered the priority of this task from Confirmed, Medium to Needs Information from User.Jan 24 2019, 2:41 PM

This is kind of expected, since this mesh's shpaekey does not have the 'user' ('from') pointer set properly. This makes it a corrupted file, so what we need here is a way to reproduce such error.

(If you remove all shapekeys and add new one, everything works as expected).

just out of pure interest: are we stricter here in 2.8? (since 2.79 handles the appended ob nicely?)

Yes, since shapekeys are now often evaluated in CoW context (i.e. with IDs that are not orig ones), the 'fix' that was setting 'from' pointer to correct ID when it was NULL is no more valid, and had to be removed (rB47be4e9a3379).

In any case, doing that sort of on-the-fly fixes is very, very bad practice, since it allows real bug(s) to remain unnoticed forever. So now we need to know how that bloody pointer can get NULLified.

Oh boy.. we where using a blender build from about 2 weeks or so, that's all I can think of

@Bastien Montagne (mont29), from might be NULL if it was saved with a COW id.

Can we do a version patch to fix such broken from pointers?

@Brecht Van Lommel (brecht) actually, was thinking about doing a systematic check on load for that, and also add a check for that issue on write (in our optional 'check file validity' that was also used to track down the library issue at the studio).

Not sure which one is best, doing do_version only, or systematic check (at least for now), at read time?

@Bastien Montagne (mont29), always doing it as part of lib linking seems fine too.

At some point we should really make Key not a datablock anymore, it makes no sense, but it's probably somewhat tricky.