4
$\begingroup$

I created an OSL shader (a 4D noise texture) and connected it to the "Displacement" output of my shader. I wanted this to be a animated micropolygon / adaptive subdivision displacement, so I enabled "Experimental" of course.

When I go to make the Displacement type "true" though, Blender consistently crashes, probably due to memory overload. I don't have an especially high vertex count, though.

How can I work around / fix this?

This video shows the problem, it's through Google Drive.

Here is the Stackexchange question that help peed me create the OSL shader

And, finally, here is the video that was guiding me through the Micropolygon Displacement process.

EDIT: Here is my OSL code.

#include "stdosl.h"

shader simple_noise_texture4d(
float Scale = 1.0,
float Time = 0.0,
output color Color = 0.0
)
{
    Color = noise( "uperlin", P * Scale, Time );
}
$\endgroup$
  • $\begingroup$ Potentially related? blender.stackexchange.com/questions/69023/… $\endgroup$ – JtheNinja May 15 '18 at 23:24
  • 1
    $\begingroup$ Can you post your OSL code? $\endgroup$ – Scott Milner May 16 '18 at 0:12
  • $\begingroup$ Done. Anything else that would help? $\endgroup$ – Dr. Farquaad May 17 '18 at 3:14
  • 1
    $\begingroup$ Does it display an error message when you run "blender.exe --debug-memory" in the command prompt? $\endgroup$ – Michael Glen Montague May 18 '18 at 16:48
  • 1
    $\begingroup$ Just tried that, and no, no error message is displayed. I can open blender fine in memory debug mode. Then, when I try to switch it to 'True' it still crashes. So, probably not a memory leak. $\endgroup$ – Dr. Farquaad May 19 '18 at 16:49
2
+50
$\begingroup$

This doesn't explain the crash but does offer a way to work around the issue.

I noticed that your OSL script is generating a Color to pass into the Displacement. The Displacement is a Scalar value (at the moment - I believe the future incarnation of True Displacement will offer a Vector - much more versatile) and so there is no benefit in generating your displacement as a Color - it will be converted to and interpreted as a scalar value anyway.

By amending the OSL code to generate a float rather than Color, Blender no longer seems to crash :

image


Further to this, it appears to be specific to the type of noise used. For example, changing using 'usimplex' instead of 'uperlin' does not trigger the issue - also fine for 'cell', 'simplex', 'perlin' (without the 'u'), 'gabor', etc. all seem to work fine but for some reason 'uperlin' causes the crash - but only if you actually try to 'use' one of the elements of the color (eg, color c = noise('uperlin’, P*Scale, Time); Displacement = c[0]; causes it to crash).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.