Page MenuHome

Multires modifier not reading data from external files
Closed, ResolvedPublic


System Information
Operating system: Both MacOS 10.14.2 (Mojave) and Windows 10
Graphics card: GTX 1080Ti, Radeon Pro 560X 4096 MB

Blender Version
Broken: 2.8 branch (daily build as of Jan 3, 2019)

Short description of error
When using "Save External..." with the multires modifier, a file is saved, but it is not loaded when the associated .blend file is reopened.

Exact steps for others to reproduce the error
1 - Create an object
2 - Create a multires modifier on the object
3 - Subdivide a few levels
4 - Sculpt some detail on the object
5 - Save the .blend file with a name (note the size of the .blend file)
6 - File->Revert to reload the .blend file and observe that the detail is still there
7 - In the modifier panel, click on the multires "Save External..." button and create the file
8 - Note that the .btx file has been created and is an appropriate size and the .blend file has shrunk by approximately this amount. e.g.

$ ls -latr
total 2976
drwxr-xr-x  4 chuck  staff     128 Jan  3 10:17 ..
-rw-r--r--  1 chuck  staff  733248 Jan  3 11:11 MultiResTest.blend1
-rw-r--r--  1 chuck  staff   83344 Jan  3 11:12 Cube.btx
-rw-r--r--  1 chuck  staff  655116 Jan  3 11:12 MultiResTest.blend
drwxr-xr-x  5 chuck  staff     160 Jan  3 11:12 .

9 - File->Revert to reload the .blend file and observe that the multires detail is not present

Additional notes
I tried to debug this a bit but I am still learning my way around the blender code base. What I did notice is that the original "Save External..." workflow ends up invoking CustomData_external_write() in customdata.c. This is also invoked when saving the .blend file as expected. Tracing through it does seem to be writing out real data.

However, I would have expected that loading the .blend file or doing File->Revert would have invoked CustomData_external_read(). The only time that appears to be called is when I click on "Pack External" in the multires modifier. If you use this carefully you can get your external data back. But if you File->Revert when the data is saved externally, and you save the .blend file again, it appears to overwrite the .btx file and the detail is lost forever.

Event Timeline

Bastien Montagne (mont29) lowered the priority of this task from Needs Triage by Developer to Needs Information from User.Jan 3 2019, 6:08 PM

Most likely again the CoW issue (working with eval modifier vs. orig one…).

But Please always attach a small and simple .blend file to help reproducing the issue, always saves us a tremendous of time.

I am adding a sample .blend and the associated .btx file. From debugging it looks like the .btx file is referenced with a relative path so just putting them in the same directory and opening the .blend should demonstrate the problem. Remember, saving the .blend file might overwrite the .btx file. So copy Cube.btx to Cube.btx.sav or something so you can keep trying as you debug.

Minor point... This came up as a result of SculptJanuary. Tons of people are trying out Blender 2.8 for this and a bunch of people have responded that they've experienced this bug. I published a tip last year about using external multires data so that we can keep all of the files on GitHub. If you pack all the data internally, then .blend files generally grow too large for vanilla GitHub. But with external multires you get a bunch of files that don't go beyond their file limits. So we're going back to 2.79 for detail sculpt passes/baking until this is fixed.

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Confirmed, Medium.

Thanks. In fact, think this is missing piece from whole multires changes related to new subdiv code (in 2.7/DM area, that external data is read from multires_make_derived_from_derived(), which is part of multires dead code in 2.8x. @Sergey Sharybin (sergey) assigning to you since am not exactly sure how to do that with new code.

Not sure if I should put this here. But I created a new bug report because even though the issue here was fixed quickly (thanks!) and closed, it introduced new problems. So this mechanism is still not very usable.

This is always good to open a new report about new issues.

P.S. Technically, the fix didn't introduce new issues, it just made other issues obvious..

Yes. Good point. Anyway, I'm grateful for the quick fix here. And hope we can get the newly encountered problems sorted too. This is especially painful for me since the 2.79 branch does not work at all on my MacBook Pro anymore at this point, which means I can only run 2.79 on WIndows, which I don't have on a laptop.