Page MenuHome

Visual glitches when undo after reload multiple images by script (in Material Preview)
Closed, ResolvedPublicKNOWN ISSUE


System Information
Operating system: Windows 10 1909
Graphics card: Radeon RX 570

Blender Version
Broken: 2.90.0 Alpha, branch: arcpatch-D7884, commit date: 2020-06-15 14:16, hash: rB81fcf23d7cec
Worked: Probably never, 2.82 and earlier will crash, but that may be different bug.

Short description of error
So I'm currently making an add-on to support Substance, it will generate texture based on inputs and save them to disk, it will also generate material and assign texture generated before.
However on Version 2.82a with Material Preview mode after update a property, the add-on generate the texture, and auto reload the images, the press ctrl+z, normally it would undo the property, but it either crashs directly with EXCEPTION_ACCESS_VIOLATION, or ends up with a weird 3d preview. (below it's the normal one)

The weird thing is that it doesn't crash(2.82) if I run blender with blender_debug_log.cmd

Exact steps for others to reproduce the error

  1. Open File
  2. Run script
  3. In 3D viewport side panel click on Toggle option and undo
  4. Repeat until you see glitch in material

Revisions and Commits

Event Timeline

Forget to say, it seems to behavior a little normal on 2.83 beta. it does not crash, but weird preview might occur. (Hope the information is enough)

Richard Antalik (ISS) changed the task status from Needs Triage to Needs Information from User.May 25 2020, 1:37 PM

The description of this report is quite vague.

Can you prepare a simple script in .blend file that you can run and undo that would cause crash? Goal is to minimize time it takes to confirm bug as well as for developer to debug and fix the issue.

Hey,I made a simple project now. so here I uploaded 2 file, the contains the test images in 1K reso. After unzip it, you might want to update the image texture node in material, and variable image_dir in script, it just reload the image from disk. After you run the script, simply check to Toggle Option, then redo/undo (just play around), it should crash. I also got a video with 3 times crashing.

Campbell Barton (campbellbarton) changed the task status from Needs Information from User to Needs Information from Developers.Jun 10 2020, 5:04 AM
Richard Antalik (ISS) renamed this task from Blender 2.82a crash randomly when undo after reload multiple images by script (in Material Preview) to Visual glitches when undo after reload multiple images by script (in Material Preview).Jun 15 2020, 9:07 PM
Richard Antalik (ISS) changed the task status from Needs Information from Developers to Confirmed.
Richard Antalik (ISS) updated the task description. (Show Details)

Better file with relative paths and textures in one zip.

  • Open file.
  • Run the script in the scripting area.
  • Click multiple time on the new Toggle button in the Viewport sidef panel.
  • Undo until you can see the texture change.

The issue comes from the UNDO system that seems to shuffle the Image Textures. (the data does not correspond to the original data but they seem intact)

This affects GPUTexture but also the imbuf since it affects the UVImage editor (which does not use GPUTextures).

This also comes with a memory leak with GPUTextures not freed. I could not locate where/why this happens.

@Bastien Montagne (mont29) I'll leave it to you.

Clément Foucault (fclem) changed the subtype of this task from "Report" to "Bug".Jun 30 2020, 7:29 PM

Cannot really reproduce this, besides a few memleaks that happen once in a while... Will double check how we deal with runtime gputexture thing, but besides that I cannot do much here unless I can reproduce it.

OK, so spent some more time investigating things and trying to understand what happens, with little success since I cannot even reliably reproduce any issue. But I think we might face one or both of following issues while trying to re-use runtime caches:

  1. race condition.
  2. pointer collisions across undo steps.

Not sure how #1 could happen, since both cache freeing and re-generation on-demand from draw code should happen in main thread, i.e. in a consistent order?
#2 Is also quiet difficult to follow, but since issue happen after repetitive cache freeing (triggered by the reload() RNA code): different caches being re-allocated at the same memory address as another one from a previous undo step.

But before losing more time on that wild goose chase, I'd like to hear from @Brecht Van Lommel (brecht) about that radical solution: since with new undo we re-use fully unchanged datablocks, can't we simply get fully rid of those imamap, movieclipmap, etc. ? Yes, it means that in some cases we'd regenerate the caches when it would not be needed, but I would not expect many changes to image of movieclip IDs to not require a cache reload anyway? And it would seriously simply code in readfile.c. Because right now we end up with some kind of double layer of remapping, makes things really hard to follow...

We can't get rid of imamap and similar. This is not only a cache, texture painted images and render results must be preserved.

Bastien Montagne (mont29) changed the subtype of this task from "Bug" to "Known Issue".Jul 1 2020, 5:20 PM

Then am moving this to known issues, as this is for sure going to be a huge pain to fully understand and fix, and might very well require a complete redesign of how we preserve those caches (as a reminder, we had to add the session uuid thing ti IDs to precisely address that pointer collision issue...).