Inconsistent normal N in OSL for material output with displacement. #42051

New Issue

bithunter · 2014-10-02T22:02:04+02:00

bithunter commented

2014-10-02 22:02:04 +02:00

System Information
Ubuntu 14.04 64, Windows 7 64, Geforce GTX 760, Compute Device CPU

Blender Version
Broken: since 2.70
Worked: 2.65-2.69 (partially)

Short description of error

When using OSL to access the surface normal N, indirect vs. direct access produces inconsistent output. The value of N - when using displacement - depends on the OSL code path and on the BSDF used. It ignores surface changes introduced by displacement when accessed indirectly, but uses the displacement normals when accessed directly. Note that versions <= 2.69 always use the normals produced by the displacement and the output does not depend on the code path. Also, N depends on the BSDF used. Using an Emission BSDF for example, completely ignores the displacement normals. For 2.72 RC the following occurs (tested with Windows and Linux builds):

Color = color(N);

works with displaced normals, while

normal x = N;
Color = color(x);

Color = color(N- [x],N- [x],N[2]);

Color = color(normal(N))

Color = color(vector(N))

uses only per face normals.

disp_normals.blend

Exact steps for others to reproduce the error
See attached images and .blend

**System Information** Ubuntu 14.04 64, Windows 7 64, Geforce GTX 760, Compute Device CPU **Blender Version** Broken: since 2.70 Worked: 2.65-2.69 (partially) **Short description of error** When using OSL to access the surface normal N, indirect vs. direct access produces inconsistent output. The value of N - when using displacement - depends on the OSL code path and on the BSDF used. It ignores surface changes introduced by displacement when accessed indirectly, but uses the displacement normals when accessed directly. Note that versions <= 2.69 always use the normals produced by the displacement and the output does not depend on the code path. Also, N depends on the BSDF used. Using an Emission BSDF for example, completely ignores the displacement normals. For 2.72 RC the following occurs (tested with Windows and Linux builds): Color = color(N); works with displaced normals, while normal x = N; Color = color(x); Color = color(N- [x],N- [x],N[2]); Color = color(normal(N)) Color = color(vector(N)) uses only per face normals.![disp_normals.png](https://archive.blender.org/developer/F114218/disp_normals.png) ![nondisp_normals.png](https://archive.blender.org/developer/F114220/nondisp_normals.png) [disp_normals.blend](https://archive.blender.org/developer/F114222/disp_normals.blend) **Exact steps for others to reproduce the error** See attached images and .blend

bithunter commented

2014-10-02 22:02:04 +02:00

Changed status to: 'Open'

bithunter commented

2014-10-02 22:02:04 +02:00

Added subscriber: @bithunter64

Sergey Sharybin commented

2014-10-03 08:49:51 +02:00

Added subscriber: @Sergey

Sergey Sharybin self-assigned this 2014-10-03 08:49:57 +02:00

bithunter commented

2014-10-03 21:36:09 +02:00

I noticed another issue, which might be related. There seems to be no displacement at all, when using compiled OSL code. I used blender/intern/cycles/kernel/shaders/node_wave_texture.osl to compare and compiled it from within Blender. The standard wave texture node works as espected, while the compiled shader code does not (for displacement). Using it for color input of a Diffuse BSDF works with both. See attached images.

I noticed another issue, which might be related. There seems to be no displacement at all, when using compiled OSL code. I used blender/intern/cycles/kernel/shaders/node_wave_texture.osl to compare and compiled it from within Blender. The standard wave texture node works as espected, while the compiled shader code does not (**for displacement**). Using it for color input of a Diffuse BSDF works with both. See attached images. ![osl_displace.png](https://archive.blender.org/developer/F114482/osl_displace.png) ![intern_displace.png](https://archive.blender.org/developer/F114484/intern_displace.png) ![osl_color.png](https://archive.blender.org/developer/F114486/osl_color.png)

Brecht Van Lommel commented

2015-05-03 15:10:54 +02:00

Closed as duplicate of #36368

Brecht Van Lommel closed this issue

2015-05-03 15:10:54 +02:00

Brecht Van Lommel commented

2015-05-03 15:15:02 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2015-05-03 15:15:02 +02:00

This is a limitation of the current system, and a proper solution basically needs a major overhaul of the way displacement is computing in OSL or SVM nodes. Right now the OSL system is designed to be compatible with SVM, but that relies on some special shader graph modification code which doesn't work with custom OSL nodes.

Either this system needs to be changed so custom OSL nodes can properly make use of it, or SVM needs to support OSL style automatic differentials (which is very complicated to implement). This has been on the todo list for a while, not considered a bug.

This is a limitation of the current system, and a proper solution basically needs a major overhaul of the way displacement is computing in OSL or SVM nodes. Right now the OSL system is designed to be compatible with SVM, but that relies on some special shader graph modification code which doesn't work with custom OSL nodes. Either this system needs to be changed so custom OSL nodes can properly make use of it, or SVM needs to support OSL style automatic differentials (which is very complicated to implement). This has been on the todo list for a while, not considered a bug.

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

Inconsistent normal N in OSL for material output with displacement. #42051