Noise nodes in geometry nodes #91156

New Issue

Jacques Lucke · 2021-09-03T12:01:42+02:00

Jacques Lucke commented

2021-09-03 12:01:42 +02:00

For Blender 3.0 we intend to support at least one or two noise texture nodes in geometry nodes (probably Noise and Voronoi). There are a few user oriented and technical decisions we have to make.

UI

For geometry nodes we would probably want to have a vector output next to "Fac(tor)" and "Color". Contrary to the existing outputs, this output should probably be approximately in the [-1, 1] range instead of [0, 1]. Should this also be added to shader nodes?

Technical

We already have some noise functions in BLI_noise.h. However, those are not enough to fully implement the noise nodes.
Currently, the same noise functions are implemented in three places:

Cycles C++ (e.g. svm_noise.h).
Cycles OSL (e.g. node_noise_texture.osl).
Eevee GLSL (e.g. gpu_shader_material_tex_noise.glsl).

Unfortunately, none of these implementations can be used by Blender itself. The Cycles c++ implementation comes the closest, but given how tightly integrated it is with Cycles, it seems unlikely that we can use this.

Currently, the best option I can see is to add a new implementation of all the noise functions in blenlib. Maybe there is an option I'm not aware of.

For Blender 3.0 we intend to support at least one or two noise texture nodes in geometry nodes (probably Noise and Voronoi). There are a few user oriented and technical decisions we have to make. **UI** For geometry nodes we would probably want to have a vector output next to "Fac(tor)" and "Color". Contrary to the existing outputs, this output should probably be approximately in the [-1, 1] range instead of [0, 1]. Should this also be added to shader nodes? **Technical** We already have some noise functions in `BLI_noise.h`. However, those are not enough to fully implement the noise nodes. Currently, the same noise functions are implemented in three places: * Cycles C++ (e.g. `svm_noise.h`). * Cycles OSL (e.g. `node_noise_texture.osl`). * Eevee GLSL (e.g. `gpu_shader_material_tex_noise.glsl`). Unfortunately, none of these implementations can be used by Blender itself. The Cycles c++ implementation comes the closest, but given how tightly integrated it is with Cycles, it seems unlikely that we can use this. Currently, the best option I can see is to add a new implementation of all the noise functions in blenlib. Maybe there is an option I'm not aware of.

Jacques Lucke commented

2021-09-03 12:01:42 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-09-03 12:17:02 +02:00

Added subscriber: @brecht

Paul Larson commented

2021-09-04 00:46:50 +02:00

Added subscriber: @GeorgiaPacific

Gottfried Hofmann commented

2021-09-06 16:08:32 +02:00

Added subscriber: @GottfriedHofmann

Brecht Van Lommel commented

2021-09-06 18:12:12 +02:00

I think adding another implementation is the right solution, there's no good way to share the code unfortunately. This should eventually replace the current Blender texture nodes also, so it will allow removing that code eventually.

Adding a vector output to the current nodes seems fine to me, but maybe do that as a second step once you have the initial compatible implementation with color and factor?

Two points about that:

I thinking outputting a unit vector is probably most useful, but randomly generating those based on procedural noise is more complicated than just normalizing 3 numbers, since you don't get a uniform distribution that way. I'm not immediately sure what the best way to do it is.
Adding an equivalent to the Displacement and Vector Displacement nodes could be done also, and covers many of the same use cases.

I think adding another implementation is the right solution, there's no good way to share the code unfortunately. This should eventually replace the current Blender texture nodes also, so it will allow removing that code eventually. Adding a vector output to the current nodes seems fine to me, but maybe do that as a second step once you have the initial compatible implementation with color and factor? Two points about that: * I thinking outputting a unit vector is probably most useful, but randomly generating those based on procedural noise is more complicated than just normalizing 3 numbers, since you don't get a uniform distribution that way. I'm not immediately sure what the best way to do it is. * Adding an equivalent to the Displacement and Vector Displacement nodes could be done also, and covers many of the same use cases.

HEYPictures commented

2021-09-06 19:22:21 +02:00

Added subscriber: @Florian-10

HEYPictures commented

2021-09-06 19:22:21 +02:00

When the Noise gets a refactor. Maybe there is a way to make it better? I have currently no idea what could be better (Performance?). But if you touch it anyway? I mean it is an oppurtunity.

Jacques Lucke commented

2021-09-06 19:29:17 +02:00

Adding a vector output to the current nodes seems fine to me, but maybe do that as a second step once you have the initial compatible implementation with color and factor?

Doing that as a separate step is fine with me.

I thinking outputting a unit vector is probably most useful, but randomly generating those based on procedural noise is more complicated than just normalizing 3 numbers, since you don't get a uniform distribution that way. I'm not immediately sure what the best way to do it is.

I'm also not sure what's a good way to generated these unit vectors. Need to do some research.

Adding an equivalent to the Displacement and Vector Displacement nodes could be done also, and covers many of the same use cases.

I still have to check what those are doing exactly, but sounds reasonable.

When the Noise gets a refactor. Maybe there is a way to make it better? I have currently no idea what could be better (Performance?). But if you touch it anyway? I mean it is an oppurtunity.

We are not touching the existing code yet. Instead we want to make a compatible version available in geometry nodes. So the other noise implementations won't change. Also, given time constraints, we probably won't have highly optimized noise code in geometry nodes for 3.0, but we'll see. That's something that can be optimized in isolation relatively easily later on.

> Adding a vector output to the current nodes seems fine to me, but maybe do that as a second step once you have the initial compatible implementation with color and factor? Doing that as a separate step is fine with me. > I thinking outputting a unit vector is probably most useful, but randomly generating those based on procedural noise is more complicated than just normalizing 3 numbers, since you don't get a uniform distribution that way. I'm not immediately sure what the best way to do it is. I'm also not sure what's a good way to generated these unit vectors. Need to do some research. > Adding an equivalent to the Displacement and Vector Displacement nodes could be done also, and covers many of the same use cases. I still have to check what those are doing exactly, but sounds reasonable. > When the Noise gets a refactor. Maybe there is a way to make it better? I have currently no idea what could be better (Performance?). But if you touch it anyway? I mean it is an oppurtunity. We are not touching the existing code yet. Instead we want to make a compatible version available in geometry nodes. So the other noise implementations won't change. Also, given time constraints, we probably won't have highly optimized noise code in geometry nodes for 3.0, but we'll see. That's something that can be optimized in isolation relatively easily later on.

Brecht Van Lommel commented

2021-09-06 19:30:28 +02:00

In #91156#1216873, @Florian-10 wrote:
When the Noise gets a refactor. Maybe there is a way to make it better? I have currently no idea what could be better (Performance?). But if you touch it anyway? I mean it is an oppurtunity.

Let's not get side tracked with this kind of thing, the same opportunity is always there.

> In #91156#1216873, @Florian-10 wrote: > When the Noise gets a refactor. Maybe there is a way to make it better? I have currently no idea what could be better (Performance?). But if you touch it anyway? I mean it is an oppurtunity. Let's not get side tracked with this kind of thing, the same opportunity is always there.

Nabil Adel commented

2021-09-06 20:45:20 +02:00

Added subscriber: @myway880

Nabil Adel commented

2021-09-06 20:45:20 +02:00

Just in case, this is useful (https://github.com/Auburn/FastNoise2/). It's MIT licensed.

Zijun Zhou commented

2021-09-07 11:49:46 +02:00

Added subscriber: @Eary

Zijun Zhou commented

2021-09-07 11:49:46 +02:00

Is it going to have the same result as the material noise node with the same settings and the same mapping? Because the prototype noise produces different result from the material node even with same settings and mapping, not sure whether the official one will tackle this so I am asking.

Jacques Lucke commented

2021-09-07 12:13:45 +02:00

The computed noise should be that same as in cycles and eevee.
The noise node in the prototype used a different implementation which was not compatible with cycles, that's why this task exists.

The computed noise should be that same as in cycles and eevee. The noise node in the prototype used a different implementation which was not compatible with cycles, that's why this task exists.

Omar Emara commented

2021-09-08 11:51:23 +02:00

Added subscriber: @OmarEmaraDev

Charlie Jolly commented

2021-09-08 17:35:05 +02:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2021-09-08 17:35:05 +02:00

In #91156#1216803, @brecht wrote:
Two points about that:

I thinking outputting a unit vector is probably most useful, but randomly generating those based on procedural noise is more complicated than just normalizing 3 numbers, since you don't get a uniform distribution that way. I'm not immediately sure what the best way to do it is.

In #91156#1216877, @JacquesLucke wrote:
I'm also not sure what's a good way to generated these unit vectors. Need to do some research.

As an aside, the uniform distribution was tackled in this patch, needs updating when fields is merged D10883: Geometry Nodes: Attribute Randomize Spherical Node.

> In #91156#1216803, @brecht wrote: > Two points about that: > * I thinking outputting a unit vector is probably most useful, but randomly generating those based on procedural noise is more complicated than just normalizing 3 numbers, since you don't get a uniform distribution that way. I'm not immediately sure what the best way to do it is. > In #91156#1216877, @JacquesLucke wrote: > I'm also not sure what's a good way to generated these unit vectors. Need to do some research. As an aside, the uniform distribution was tackled in this patch, needs updating when fields is merged [D10883: Geometry Nodes: Attribute Randomize Spherical Node](https://archive.blender.org/developer/D10883).

Brecht Van Lommel commented

2021-09-08 18:11:04 +02:00

In #91156#1217613, @CharlieJolly wrote:
As an aside, the uniform distribution was tackled in this patch, needs updating when fields is merged D10883: Geometry Nodes: Attribute Randomize Spherical Node.

For random numbers a uniform mapping like that works. But for procedural texture patterns you would get distortion and/or discontinuities.

> In #91156#1217613, @CharlieJolly wrote: > As an aside, the uniform distribution was tackled in this patch, needs updating when fields is merged [D10883: Geometry Nodes: Attribute Randomize Spherical Node](https://archive.blender.org/developer/D10883). For random numbers a uniform mapping like that works. But for procedural texture patterns you would get distortion and/or discontinuities.

Jacques Lucke commented

2021-09-17 15:50:38 +02:00

Changed status from 'Needs Triage' to: 'Resolved'

Jacques Lucke closed this issue

2021-09-17 15:50:38 +02:00

Jacques Lucke self-assigned this 2021-09-17 15:50:38 +02:00

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

Noise nodes in geometry nodes #91156