A couple issues with subdivision and displacement

[FakeShamus]

Hi, so the first thing I noticed is if you are working on an ISL shader for the displacement slot you get an annoying pop-up window for any errors that must be clicked to close, instead of the regular error notification that happens in other slots (color, bump, etc.)

the next thing is some weird subdivision behavior, where subdiv levels up to 7 work as expected, but when when pushed to 8 generates more poly's than expected. I'm using view-dependent subdivision (doesn't seem to matter what pixel threshold it's set to) starting with a plane pre-subdivided in Blender to about 65,000 quads. with subdivision set to 6 or 7 levels I end up in the 4 to 4.5 million poly range after all subdiv levels. when I set it to 8 levels it leaps up to 16.7 mil poly's after subdivision level 3 and then it tapers off and ends up at 17.4 mil when finished.

this is using v3.8.26 on OSX 10.10.2

thanks!

[CTZn]

hi fakeshamus, I would recommend adapting the pixel threshold when changing the final subdivision level. However I do not re.ember experiencing such an issue, could you please come up with a precise case to work out on to ? A pigs would be best.

as for that window... argh I'm with you ! The workaround is to disable displacement while performing heavy editing, but I would not call this a solution either. plus one.

[Zom-B]

Enable "view dependence" for subdiv, so only polygones inside the camera angle get subdived, also only then the Pixel threshold works

The mighty pixel threshold aims on the Frame Buffer, so you need to adjust it to your Super Sampling value (as CTZn already mentioned).
A scene with SS3 needs a Pixel Threshold of 3 to have 1 (!!) pixel of Threshold in the finally rendered image.
For a Pixel Threshold of 3 you would need to set the value up to 9 on SS3...

[FakeShamus]

well, right - as stated, I'm using view-dependent subdivision already. it's just that the pixel threshold doesn't seem to factor in to the problem.

the issue is, when I have the levels set to 6 or 7, the behavior is normal and the poly count tapers off consistent with the view-dependent division. But bump the levels up to 8 and instead of just getting one more level of division at the end, the poly count jumps up to way more poly's at around level 3 and then tapers off as you would expect, but with the result being about 4X as many total poly's as with level 7.

so with 8 levels of division it almost seems like the view-dependent setting doesn't kick in until after the 3rd level, does that make more sense?

the pigs is here if you want to try it:
https://drive.google.com/file/d/0Bzv6Hd ... sp=sharing

thanks!

[CTZn]

thanks for the file, that will help us a great deal in catching your issue.

you know that basically, adding one subdivided level will split each face in 2x2=4 ? I bet you do fakeshamus

PS: Caught the file on nomad wifi, I might not be the fastest to answer at all. cheers.

[FakeShamus]

right, but because of the view-dependent subdivision, each new level should not be generating 4X the poly's, it tapers off, as expected, as it hits that threshold. an extra level of subdiv at the end should not quadruple the poly's. and in fact it doesn't - the big jump in poly count happens after subdiv level 3 when subdivision is set to 8, but not when set to 7 or lower.

[CTZn]

After I tried your scene, I remembered myself that I already had been concerned with that same issue and that I used to ignore it nevertheless.

Specially, it is weird that the polycount of 16777216 is hit in plain even though triangles in the background seem clearly below the pixel threshold.

My pronostic: the default subdivision count applied automatically to triangles outside the view frustum is also enforced to triangles within that view frustum, in which case that would be an unwanted behaviour.

May I suggest also that the outside level could be a fraction of the user level instead of a fixed value...