Regression: Black block appears when using some parameters of the Multifractal Noise Texture #119797

New Issue

Closed

opened 2024-03-22 17:08:30 +01:00 by vp.gestaltung · 8 comments

vp.gestaltung commented

2024-03-22 17:08:30 +01:00

Blender Version
Broken: version: 4.1.0 Release Candidate, branch: blender-v4.1-release, commit date: 2024-03-18 20:43, hash: 51cdf665abd2
Worked: 4.0

Short description of error
When playing around with the Multifractal Noisetexture and using the Scale,
Detail and Lacunarity sliders some weird black block appears

Exact steps for others to reproduce the error

Open shader editor,
change parameters of the Multifractal Noise Texture

**Blender Version** Broken: version: 4.1.0 Release Candidate, branch: blender-v4.1-release, commit date: 2024-03-18 20:43, hash: `51cdf665abd2` Worked: 4.0 **Short description of error** When playing around with the Multifractal Noisetexture and using the Scale, Detail and Lacunarity sliders some weird black block appears ![](attachments/0221ce69-1c4a-467a-91ff-d533e22f2474) ![](attachments/a4548535-3a6a-4ee0-ba44-4b61d5b4d5fb) **Exact steps for others to reproduce the error** - Open shader editor, - change parameters of the Multifractal Noise Texture

blender_NMba9gPnBI.png

607 KiB

blender_yvqzdkjfT6.png

677 KiB

MultifractalBug.blend

1.1 MiB

vp.gestaltung added the

labels 2024-03-22 17:08:31 +01:00

Iliya Katushenock added the

Render & Cycles

label 2024-03-22 17:17:01 +01:00

Iliya Katushenock changed title from ~~Black block appears when using some parameters of the Multifractal Noise Texture~~ to Regression: Black block appears when using some parameters of the Multifractal Noise Texture

2024-03-22 17:26:50 +01:00

Iliya Katushenock commented

2024-03-22 17:40:48 +01:00

Member

I can not render this with OSL option enabled. Without OSL i can't confirm issue in 4.1 and 4.2.

I can not render this with OSL option enabled. Without OSL i can't confirm issue in 4.1 and 4.2.

Germano Cavalcante commented

2024-03-22 21:26:41 +01:00

Member

I can confirm.
The issue was introduced in 4.1 between ca9c6372c94c (Sep 28) and 09caf5969010 (Nov 28)

**System Information**
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 546.01

I can confirm. The issue was introduced in 4.1 between `ca9c6372c94c` (Sep 28) and `09caf5969010` (Nov 28) ``` **System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 546.01 ```

Germano Cavalcante added

Render & Cycles

and removed

Render & Cycles

labels 2024-03-22 21:27:09 +01:00

Iliya Katushenock added this to the 4.1 milestone 2024-03-22 21:51:44 +01:00

Alaska commented

2024-03-23 02:28:53 +01:00

Member

This was very likely caused by: 0b11c591ec

This was very likely caused by: https://projects.blender.org/blender/blender/commit/0b11c591ec62d4ff405108c453f4a34bf3eaee91

Alaska commented

2024-03-23 03:36:18 +01:00

Member

I did some digging into the issue.

The issue comes from the simplex/perlin noise implementations used, and how they differ between OSL and SVM.

In Cycles OSL rendering, I believe the simplex/perlin noise function offered by OSL is used. While if SVM is in use, then Cycles perlin noise function is used. They seem to produce the same result, until the sampled co-oridinate gets very large, then they start to differ. What's causing the co-ordinate to get very large? Two things:

Inside the OSL script for the noise node you start off with: p *= Scale;. So if the scale is large, you should have issues.

Then once it gets to processing the multi-fractual noise you enter node_noise.h and do this:

  float noise_multi_fractal(T co, float detail, float roughness, float lacunarity)
  {
    T p = co; /* This is our co-ordinate */
    float value = 1.0; 
    float pwr = 1.0; 

    for (int i = 0; i <= (int)detail; i++) { 
      value *= (pwr * safe_snoise(p) + 1.0); /* safe_snoise is a simplex noise function */
      pwr *= roughness; 
      p *= lacunarity; 
    } 

    float rmd = detail - floor(detail); 
    if (rmd != 0.0) { 
      value *= (rmd * pwr * safe_snoise(p) + 1.0); /* safe_snoise is a simplex noise function */
    }

    return value;
  }

As you can see, there is a for loop based on the detail input. And this constantly multiplies the co-ordinate by lacunarity, so if lacunarity is greater than 1, then the co-ordinate will grow, and if detail is high, the loop runs many times.

In our scene, let's take a co-ordinate of 1 as an example. By the time we're running the last simplex/perlin noise funciton in noise_multi_fractal, our co-ordinate is: 1 * 10 * (11.7 ^ 8) = 3,511,453,275.80.

So it's highly likely the issue we're seeing in OSL is something precision related in the noise function that Cycles own noise implementation handles better.

There's a bunch of things that could be done to try and reduce these issues, or make SVM/OSL match. For example clamping values, modifying OSL source code (preferably as a pull request up stream) to match Cycles SVM, adjust Cycles SVM to match OSL with all it's issues, Use Cycles own simplex/perlin noise function instead of OSLs, and other options. I'll leave the decision on what to do, and the code changes, to the Cycles developers.

I did some digging into the issue. The issue comes from the simplex/perlin noise implementations used, and how they differ between OSL and SVM. In Cycles OSL rendering, I believe the simplex/perlin noise function offered by OSL is used. While if SVM is in use, then Cycles perlin noise function is used. They seem to produce the same result, until the sampled co-oridinate gets very large, then they start to differ. What's causing the co-ordinate to get very large? Two things: Inside the OSL script for the noise node you start off with: `p *= Scale;`. So if the scale is large, you should have issues. Then once it gets to processing the multi-fractual noise you enter `node_noise.h` and do this: ``` float noise_multi_fractal(T co, float detail, float roughness, float lacunarity) { T p = co; /* This is our co-ordinate */ float value = 1.0; float pwr = 1.0; for (int i = 0; i <= (int)detail; i++) { value *= (pwr * safe_snoise(p) + 1.0); /* safe_snoise is a simplex noise function */ pwr *= roughness; p *= lacunarity; } float rmd = detail - floor(detail); if (rmd != 0.0) { value *= (rmd * pwr * safe_snoise(p) + 1.0); /* safe_snoise is a simplex noise function */ } return value; } ``` As you can see, there is a for loop based on the detail input. And this constantly multiplies the co-ordinate by lacunarity, so if lacunarity is greater than 1, then the co-ordinate will grow, and if detail is high, the loop runs many times. In our scene, let's take a co-ordinate of 1 as an example. By the time we're running the last simplex/perlin noise funciton in `noise_multi_fractal`, our co-ordinate is: `1 * 10 * (11.7 ^ 8) = 3,511,453,275.80`. So it's highly likely the issue we're seeing in OSL is something precision related in the noise function that Cycles own noise implementation handles better. There's a bunch of things that could be done to try and reduce these issues, or make SVM/OSL match. For example clamping values, modifying OSL source code (preferably as a pull request up stream) to match Cycles SVM, adjust Cycles SVM to match OSL with all it's issues, Use Cycles own simplex/perlin noise function instead of OSLs, and other options. I'll leave the decision on what to do, and the code changes, to the Cycles developers.

Brecht Van Lommel modified the milestone from 4.1 to 4.2 LTS

2024-03-25 10:32:33 +01:00

Brecht Van Lommel added

and removed

labels 2024-03-25 10:32:41 +01:00

Brecht Van Lommel commented

2024-03-25 10:33:22 +01:00

Owner

I don't think this is critical for 4.1.0, so postponing to 4.2 and potentially 4.1.1.

@Hoshinova, can you look into this?

I don't think this is critical for 4.1.0, so postponing to 4.2 and potentially 4.1.1. @Hoshinova, can you look into this?

Brecht Van Lommel commented

2024-03-25 10:34:42 +01:00

Owner

Note that in general, high detail values are slow to compute and indeed can run into these kinds of precision issues. Usually 9.0 is much higher than necessary.

Note that in general, high detail values are slow to compute and indeed can run into these kinds of precision issues. Usually 9.0 is much higher than necessary.

Hoshinova commented

2024-03-25 16:45:37 +01:00

Member

I can confirm.
The issue was introduced in 4.1 between ca9c6372c94c (Sep 28) and 09caf5969010 (Nov 28)
**System Information**
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 546.01

Not sure how you came to that conclusion. The issue is also present in the Mugrave Texture in 4.0.2 and prior when using the same inputs on my PC.

> I can confirm. > The issue was introduced in 4.1 between `ca9c6372c94c` (Sep 28) and `09caf5969010` (Nov 28) > > ``` > **System Information** > Operating system: Windows-10-10.0.22621-SP0 64 Bits > Graphics card: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 546.01 > ``` Not sure how you came to that conclusion. The issue is also present in the Mugrave Texture in 4.0.2 and prior when using the same inputs on my PC.

Hoshinova commented

2024-03-25 16:56:10 +01:00

Member

So it's highly likely the issue we're seeing in OSL is something precision related in the noise function that Cycles own noise implementation handles better.

Not really, both start to have precision related issue when one of the coordinates gets greater than about 250000. Cycles own noise implementation just hides it better by outputting 0.0 instead of a garbage value.

> So it's highly likely the issue we're seeing in OSL is something precision related in the noise function that Cycles own noise implementation handles better. Not really, both start to have precision related issue when one of the coordinates gets greater than about 250000. Cycles own noise implementation just hides it better by outputting 0.0 instead of a garbage value.

Hoshinova referenced a pull request that will close this issue

2024-03-25 17:23:13 +01:00

Fix #119797: Noise Texture Precision Issues #119884

Brecht Van Lommel referenced this issue from a commit

2024-03-29 16:12:35 +01:00

Fix #119797: Noise Texture Precision Issues

Brecht Van Lommel closed this issue

2024-03-29 16:12:36 +01:00

Blender Bot added

and removed

labels 2024-03-29 16:12:37 +01:00

~~Brecht Van Lommel referenced this issue 2024-03-29 16:13:06 +01:00~~

4.1: Candidates for corrective releases #119631

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

6 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#119797

No description provided.