Cycles preview lockup / memory allocation loop while changing adaptive displacement parameters. #60379

New Issue

Gavin Scott · 2019-01-10T04:15:24+01:00

Gavin Scott commented

2019-01-10 04:15:24 +01:00

System Information
Windows 10, Nvidia 1060 6GB, also reproduced on a second Windows 10 system with Nvidia 1070.

Blender Version
Broken:
1/9 daily build blender-2.80-91a155833e59-win64.zip

Short description of error
Cycles preview (Workspace Rendered mode) of object with displacement goes into a loop allocating memory.

Exact steps for others to reproduce the error

CAUTION: You may lose control of the machine and require a hard system reset! I have reproduced this issue on two separate machines, and on one I was unable to get the Task Manager or CTRL-ALT-DEL to respond after locking up Cycles. (Edit: actually this was probably just because there was another minimized GPU intensive application running as well and the combination of that and Blender looping probably just prevented getting any resources to get at the task manager).

Open the attached .blend which contains the default box with an adaptive subdiv modifier.
Switch to Rendered mode in the 3dview. Object edges look a bit rough but otherwise ok.
In the Render Subdivision properties panel, change the Preview Dicing Rate to 2. Note that this does not trigger a preview refresh (it probably should I think?)
Click the wrench tab to switch to the Modifiers Properties tab.
Click on the Dicing Scale, type in 0.5 and hit enter. The preview refreshes correctly with the new settings.
Now Click the increase (>) button at the right-hand end of the Dicing Scale a few times (about a half second between clicks say). After a couple changes (value up to 0.56 usually) the object in the display will pixelate and the render thread will go 100% CPU busy and will start allocating memory without limit until you kill Blender.

This isn't the only way I've gotten it into this state while messing around with Displacement in this file, but the above sequence is 100% repeatable where otherwise it's pretty random. I've gotten it to go berserk like this while twiddling displacement options including view displacement level, the render Subdivision options, and switching back and forth between the different Workspace display modes (lookdev<->rendered etc.).

It will also sometimes do something else weird, where instead of the smooth, connected displaced surface, it seems to be displacing each face of the subdivided mesh independently. I haven't been able to reproduce this reliably.disptest.blend

**System Information** Windows 10, Nvidia 1060 6GB, also reproduced on a second Windows 10 system with Nvidia 1070. **Blender Version** Broken: 1/9 daily build blender-2.80-91a155833e59-win64.zip **Short description of error** Cycles preview (Workspace Rendered mode) of object with displacement goes into a loop allocating memory. **Exact steps for others to reproduce the error** CAUTION: You may lose control of the machine and require a hard system reset! I have reproduced this issue on two separate machines, and on one I was unable to get the Task Manager or CTRL-ALT-DEL to respond after locking up Cycles. (Edit: actually this was probably just because there was another minimized GPU intensive application running as well and the combination of that and Blender looping probably just prevented getting any resources to get at the task manager). 1) Open the attached .blend which contains the default box with an adaptive subdiv modifier. 2) Switch to Rendered mode in the 3dview. Object edges look a bit rough but otherwise ok. 3) In the Render Subdivision properties panel, change the Preview Dicing Rate to 2. Note that this does not trigger a preview refresh (it probably should I think?) 4) Click the wrench tab to switch to the Modifiers Properties tab. 5) Click on the Dicing Scale, type in 0.5 and hit enter. The preview refreshes correctly with the new settings. 6) Now Click the increase (>) button at the right-hand end of the Dicing Scale a few times (about a half second between clicks say). After a couple changes (value up to 0.56 usually) the object in the display will pixelate and the render thread will go 100% CPU busy and will start allocating memory without limit until you kill Blender. This isn't the only way I've gotten it into this state while messing around with Displacement in this file, but the above sequence is 100% repeatable where otherwise it's pretty random. I've gotten it to go berserk like this while twiddling displacement options including view displacement level, the render Subdivision options, and switching back and forth between the different Workspace display modes (lookdev<->rendered etc.). It will also sometimes do something else weird, where instead of the smooth, connected displaced surface, it seems to be displacing each face of the subdivided mesh independently. I haven't been able to reproduce this reliably.[disptest.blend](https://archive.blender.org/developer/F6236230/disptest.blend)

Gavin Scott commented

2019-01-10 04:15:24 +01:00

Added subscriber: @GavinScott

blender-admin commented

2019-01-10 04:15:24 +01:00

#63116 was marked as duplicate of this issue

Gavin Scott commented

2019-01-13 04:44:29 +01:00

I've been experimenting with adaptive-displacement some more today, and Cycles Preview rendering with Adaptive Displacement seems unprepared to deal with anything changing in terms of input or settings. It does not seem to know when it needs to actually calculate the adaptive displacement and even when it does, it usually fails to recalculate it if things change, which leads to an assortment of problems.

For example, if you are feeding input to a Vector Displacement node and you change the data coming in, sometimes the preview changes and sometimes it does not. Sometimes it seems to be using the render time dicing rate and ignoring the preview rate, and sometimes it will only show like 4x4 vertices across the whole displaced plane.

Switching from Rendered to Lookdev and back will sometimes cause it to wildly change how the displacement looks each time you do it.

There's also no delay, so it may just be failing to re-calculate the displacement when the input changes. And sometimes it goes into the same loop allocating memory as in my original post.

I have another example .blend I can attach with instructions if needed, but just about everything I try results in issues (across multiple computers and multiple 2.80 builds).

I've been experimenting with adaptive-displacement some more today, and Cycles Preview rendering with Adaptive Displacement seems unprepared to deal with anything changing in terms of input or settings. It does not seem to know when it needs to actually calculate the adaptive displacement and even when it does, it usually fails to recalculate it if things change, which leads to an assortment of problems. For example, if you are feeding input to a Vector Displacement node and you change the data coming in, sometimes the preview changes and sometimes it does not. Sometimes it seems to be using the render time dicing rate and ignoring the preview rate, and sometimes it will only show like 4x4 vertices across the whole displaced plane. Switching from Rendered to Lookdev and back will sometimes cause it to wildly change how the displacement looks each time you do it. There's also no delay, so it may just be failing to re-calculate the displacement when the input changes. And sometimes it goes into the same loop allocating memory as in my original post. I have another example .blend I can attach with instructions if needed, but just about everything I try results in issues (across multiple computers and multiple 2.80 builds).

Sebastian Parborg commented

2019-01-25 19:11:51 +01:00

Added subscriber: @ZedDB

Brecht Van Lommel was assigned by Sebastian Parborg

2019-01-25 19:11:51 +01:00

Sebastian Parborg commented

2019-01-25 19:11:51 +01:00

It took a bit longer for me to reproduce this on my end. I had to fool around on the last step a bit more (I went up to 1.0 and back down to 0.5 again before it locked up).

tom k commented

2019-03-26 22:45:15 +01:00

Added subscriber: @tomjk

tom k commented

2019-03-26 22:45:15 +01:00

It looks to me as though the memory allocation is not entirely runaway, rather blender is just going all the way up to max subdivisions (Properties -> Render tab -> Subdivision panel ->Max Subdivisions). At the default of 12 subdivisions for a simple cube, the required amount of memory is about 16gb (probably, I always pull the plug on it before it gets there though).

As a demonstration, set max subdivs to something like 3, then fiddle with node values. Memory use should stay fairly reasonable.

(I had some other observations I was going to add but Like Gavin Scott has shown, there's lots of other weirdness besides and I don't know well enough to disentangle it so I won't confuse things by trying to.)

It looks to me as though the memory allocation is not entirely runaway, rather blender is just going all the way up to max subdivisions (Properties -> Render tab -> Subdivision panel ->Max Subdivisions). At the default of 12 subdivisions for a simple cube, the required amount of memory is about 16gb (probably, I always pull the plug on it before it gets there though). As a demonstration, set max subdivs to something like 3, then fiddle with node values. Memory use should stay fairly reasonable. (I had some other observations I was going to add but Like Gavin Scott has shown, there's lots of other weirdness besides and I don't know well enough to disentangle it so I won't confuse things by trying to.)

Brecht Van Lommel commented

2019-03-30 09:55:54 +01:00

Added subscriber: @semaj-1

Jim C commented

2019-03-30 16:17:36 +01:00

Thank you Brecht! Yeah I first noticed this issue by using small displacement node values: .2 scale value did not freeze whereas turning it down to .1 did make it freeze. I didn't associate it with dicing until later (using larger dicing seems to allow for smaller displacement scale value).

Gavin Scott commented

2019-04-02 20:10:58 +02:00

Another simple example of displacement not staying in sync with the view etc:

Start with default scene.
Zoom out a bit so the cube is rather small (say 10% of the screen width).
Change to Cycles, enable Experimental features.
Add a Subdivision Surface to the Cube, Check the Adaptive box.
Switch the 3dview to Rendered mode.

The cube gets adaptive microdisplacement computed at its current screen size, and renders fine (the selected object outline still shows the non-adaptive View displacement level which maybe is not super ideal).

Use the mouse wheel to zoom in on the cube. Each zoom step the progressive preview render gets restarted (as expected).
Note that the outline of the object shows that the adaptive displacement is not getting recalculated as the view changes
Toggling the Adaptive checkbox for the subdiv modifier will (quite quickly) update the displacement to correct detail level.
At this point toggling the 3dview to Look Dev and back to Rendered usually sends it into the runaway memory allocation state.

Another simple example of displacement not staying in sync with the view etc: 1) Start with default scene. 2) Zoom out a bit so the cube is rather small (say 10% of the screen width). 3) Change to Cycles, enable Experimental features. 4) Add a Subdivision Surface to the Cube, Check the Adaptive box. 5) Switch the 3dview to Rendered mode. The cube gets adaptive microdisplacement computed at its current screen size, and renders fine (the selected object outline still shows the non-adaptive View displacement level which maybe is not super ideal). 6) Use the mouse wheel to zoom in on the cube. Each zoom step the progressive preview render gets restarted (as expected). 7) Note that the outline of the object shows that the **adaptive displacement is not getting recalculated as the view changes** 8) Toggling the Adaptive checkbox for the subdiv modifier will (quite quickly) update the displacement to correct detail level. 9) At this point toggling the 3dview to Look Dev and back to Rendered usually sends it into the runaway memory allocation state.

blender-admin commented

2019-04-04 20:06:22 +02:00

This issue was referenced by b2e2db94bd

This issue was referenced by b2e2db94bdae25b4505df563ae9e56a37d89cb7a

Brecht Van Lommel commented

2019-04-04 21:24:35 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-04-04 21:24:35 +02:00

Brecht Van Lommel commented

2019-04-04 21:25:22 +02:00

It was an intentional choice to not update adaptive subdivision everytime you navigate in the viewport. That would be very slow, instead we require a manual refresh. It's also somewhat useful to be able to inspect what the dicing looks like from another viewpoint.

The other issues should be fixed.

It was an intentional choice to not update adaptive subdivision everytime you navigate in the viewport. That would be very slow, instead we require a manual refresh. It's also somewhat useful to be able to inspect what the dicing looks like from another viewpoint. The other issues should be fixed.

Jim C commented

2019-04-06 18:09:56 +02:00

Thank you so much for your fast work on this Brecht! Works wonderfully. Now I can play with 2.8 again, weeeeee! :P

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles preview lockup / memory allocation loop while changing adaptive displacement parameters. #60379