Page MenuHome

Undo steps with texture paint break across memfile steps
Closed, ResolvedPublic

Description

Texture paint undo steps don't work properly when mixed with memfile undo (object mode operations).

  • Default cube.
  • Set texture paint mode, add 'Base Color' slot for painting.
  • Make one stroke.

  • Undo everything, redo everything.
  • All correct.

Now switch to object mode and undo, notice the image has been cleared.


Note that this is more of a limit in how image undo works than some mistake in the code. since 2.7x never supported this.

Image painting is an exception that needs special handling since it has undo data that exists outside global undo.

Reporting because this should be fixed before 2.8x release, or worse case we could limit texture paint undo/redo to the current painting session as 2.7x (would be a shame, but better then loosing the users work).

Event Timeline

Campbell Barton (campbellbarton) renamed this task from Texture paint steps break across memfile steps to Undo steps with texture paint break across memfile steps.Feb 7 2019, 12:45 AM
Campbell Barton (campbellbarton) lowered the priority of this task from Needs Triage by Developer to Confirmed, High.
Campbell Barton (campbellbarton) updated the task description. (Show Details)

Strange that if I do UNDO again after object mode + UNDO, the image is back. For the records, tested with rBeff3728db912.

Has this bug already been fixed? I can't reproduce with the described steps.

Looked into this recently, the painting undo stack now works across mem-file undo steps in some situations (resolved rB1d7be99ba4886dcf95a72a8597098e109dc10f95), however there is still a problem.

Even though mem-file undo attempts to keep Image.cache between undo steps, there are still times when it's cleared.

This clears the ImBuf which is the current in-memory state of the image.

I'm not sure why this only happens in some cases, needs further investigation.

Can't reproduce this with Blender 2.81 build from 14th August later build and with Blender 2.80 last build

Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: Radeon RX 580 Series ATI Technologies Inc. 4.5.13570 Core Profile Context 19.8.1 26.20.13001.29010

Thanks for checking.

This problem happens far less often then it used to, but it can still happen, so keeping this open.

@Campbell Barton (campbellbarton) : I have added this to 2.81 milestone (since it was set to "High"), mind checking again?

The issue is the image cache sometimes gets freed by memfile undo, the image then gets reloaded and the undo tiles are applied on-top of the wrong image data.

I looked into memfile undo image cache pointer map and it doesn't look like some mistake in the code causing this, in fact this works in most cases.

It turns out it's not enough just to correctly remap the images through memfile-undo - because the user can undo to a state before the image existed (which currently frees the image cache).

This test patch shows how keeping the image cache stored as part of the undo system can fix the issue, P1103. This adds ID / undo users to MovieCache. There might be better ways to keep the data around between memfile undo's though.

Note, talked to @Brecht Van Lommel (brecht) and @Sergey Sharybin (sergey) - P1103 is too fragile.

I'm working on making the undo system store all image data, since the image cache isn't reliable enough to apply changes to.