Page MenuHome

Dicing scale doesn't work
Closed, ArchivedPublic


System Information
Operating system: Linux-3.10.0-957.10.1.el7.x86_64-x86_64-with-centos-7.6.1810-Core 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 418.56

Blender Version
Broken: version: 2.82 (sub 4), branch: master, commit date: 2019-12-08 18:49, hash: rB761111efb8e4
Worked: 2.79 the last one

Short description of error
Changing dicing scale to extreme values (1 - 32) does nothing, as well as changing render properties -> subdivisions -> max subdivisions / offscreen scale.
The smoothing of the mesh and memory consumption stays the same.
There's a bit different behavior in 2.81a. Dicing scale works about between 1-4, >4 does nothing and max subdivisions / offscreen scale don't work either.

Exact steps for others to reproduce the error
Open the file, hit render.
With 32px of subd scale you must see jagged surface, but it'll be perfectly smooth.

Event Timeline

Yegor (Yegor) updated the task description. (Show Details)Dec 9 2019, 6:00 PM

You have two levels of non-adaptive smoothing that are getting applied first. Disable the 'adaptive' checkbox on the modifier to see and set it to zero, then turn adaptive back on. You'll get your 32px subdiv.

It's unclear to me that this is a bug, though the UI does suggest that the mesh should be subdivided with either one or the other method, not both in sequence. Can't really think of any use case for this either.

Yegor (Yegor) added a comment.EditedDec 10 2019, 12:07 PM

Oh, thanks to you I found that adaptive is not working at all. I've unchecked adaptive, set to 0, checked back and got jagged mesh on render, but now it's clear that changing dicing scale whether it's 1 or 64 does absolutely nothing. It stays jagged no matter what I set. Try it!

You have also set max subdivisions to 1 in the render properties, which prevents the adaptive subdivision from dicing the mesh finer than that.

Oh damn, you're right. I fooled myself. So the only thing left is the hidden render subdiv. If it's by design then we can call it a day.

Jacques Lucke (JacquesLucke) claimed this task.

Closing because the issue seems to be resolved.

At the very least, we should not hide that levels setting until the underlying issue (if it actually is an issue) is resolved. I just got bitten by this in a way that was very hard to find. I really only happened to do a close enough render to actually see what was happening by pure chance, but had wasted several hours of render time wondering why I was getting slightly different results in final renders from the viewport. And it took a damned lucky Google search to find this or I'd still be scratching my head.

To sum up: not invalid, as behavior is not at all what is expected, and one of two possible solutions, the easiest of which being simply to show the field (perhaps with a TODO in the code for later).