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 );
}
Improve this question
$\endgroup$
5
  • $\begingroup$ Potentially related? blender.stackexchange.com/questions/69023/… $\endgroup$
    – JtheNinja
    May 15, 2018 at 23:24
  • 1
    $\begingroup$ Can you post your OSL code? $\endgroup$
    – Scott Milner
    May 16, 2018 at 0:12
  • $\begingroup$ Done. Anything else that would help? $\endgroup$
    – Linguini
    May 17, 2018 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, 2018 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$
    – Linguini
    May 19, 2018 at 16:49

1 Answer 1

Reset to default
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).

Improve this answer
$\endgroup$
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .