Noise texture has repeating stripes in z axis #83144

New Issue

Russell · 2020-11-28T10:30:12+01:00

Russell commented

2020-11-28 10:30:12 +01:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30

Blender Version
Broken: version: 2.91.0, branch: master, commit date: 2020-11-25 08:34, hash: 0f45cab862
Worked: (newest version of Blender that worked as expected)

Short description of error
The noise texture is generating horizontal stripes. This happens with CPU and GPU rendering. Can't seem to reproduce it with the default cube so I pared down my model to make it a bit simpler to see.

See the attached image and blend file:

Noise Stripes.blend

Exact steps for others to reproduce the error
See attached image and blend file. View the texture with EEVEE or Cycles.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30 **Blender Version** Broken: version: 2.91.0, branch: master, commit date: 2020-11-25 08:34, hash: `0f45cab862` Worked: (newest version of Blender that worked as expected) **Short description of error** The noise texture is generating horizontal stripes. This happens with CPU and GPU rendering. Can't seem to reproduce it with the default cube so I pared down my model to make it a bit simpler to see. See the attached image and blend file: ![Screenshot (211).png](https://archive.blender.org/developer/F9397537/Screenshot__211_.png) [Noise Stripes.blend](https://archive.blender.org/developer/F9397540/Noise_Stripes.blend) **Exact steps for others to reproduce the error** See attached image and blend file. View the texture with EEVEE or Cycles.

Russell commented

2020-11-28 10:30:12 +01:00

Added subscriber: @Russ1642

Germano Cavalcante commented

2020-12-01 15:29:28 +01:00

Added subscribers: @OmarEmaraDev, @mano-wii

Germano Cavalcante commented

2020-12-01 15:29:28 +01:00

Object type mapping may not be what you expect.
See what it does with the Cheker texture for example:

Therefore, I believe that this is not a bug, but a result of the generated mapping.
Although we can see a repetitive pattern with noise 3D and 4D, it is still "noise".

@OmarEmaraDev, you worked on this a while ago. What do you think? Bug or not?

`Object` type mapping may not be what you expect. See what it does with the Cheker texture for example: ![image.png](https://archive.blender.org/developer/F9420048/image.png) Therefore, I believe that this is not a bug, but a result of the generated mapping. Although we can see a repetitive pattern with noise 3D and 4D, it is still "noise". @OmarEmaraDev, you worked on this a while ago. What do you think? Bug or not?

Russell commented

2020-12-01 15:35:43 +01:00

It does the same thing with Generated texture coordinates. Object coordinate space should work too. It will do this even if you set an empty as the object space to use. The checker texture not working properly doesn't men itc's not a bug but that the source of the bug isn't likely the noise texture itself.

Germano Cavalcante commented

2020-12-01 15:57:56 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2020-12-01 15:57:56 +01:00

Although I have not investigated the generated uv map in depth, here are some points that make me believe that it is not a bug:

This same result is seen in the very old versions of Blender.
Eevee and Cycles are written in different languages and simulate the same behavior through different code.
There are a lot of people making materials with very complex node trees. If the generated map was wrong, someone would surely have reported it (and they could even have made a simpler way of identifying the problem.).
Every day users make about 20 reports. Even if the minority is not really a bug, we can already get an idea of how much things are tested in Blender.

Anyway, since the bug is not in the noise texture, this report is not suitable for forwarding to the developers.
We require the bug reporter to narrow down the problem.

If you are sure that this is a bug, please simplify and further edit the file until the problem reveals itself more clearly.

Although I have not investigated the generated uv map in depth, here are some points that make me believe that it is not a bug: - This same result is seen in the very old versions of Blender. - Eevee and Cycles are written in different languages and simulate the same behavior through different code. - There are a lot of people making materials with very complex node trees. If the generated map was wrong, someone would surely have reported it (and they could even have made a simpler way of identifying the problem.). - Every day users make about 20 reports. Even if the minority is not really a bug, we can already get an idea of how much things are tested in Blender. Anyway, since the bug is not in the noise texture, this report is not suitable for forwarding to the developers. We require the bug reporter to narrow down the problem. If you are sure that this is a bug, please simplify and further edit the file until the problem reveals itself more clearly.

Russell commented

2020-12-01 16:12:55 +01:00

How can I narrow down the problem without going into the code? This obviously is a bug of some kind as there should be no patterns in the noise texture ever. Also the checker pattern should work fine as well. Something is up with the coordinate space here. My node tree is about as simple as they get with a texture node. Exactly how is a user supposed to fix this? I already did my best before simplifying the model and node tree down and creating this bug report.

Russell commented

2020-12-01 16:13:59 +01:00

I should also add that there's no uv mapping here.

Germano Cavalcante commented

2020-12-01 16:30:55 +01:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Germano Cavalcante commented

2020-12-01 16:30:55 +01:00

Okay, I can't confirm it as a bug, but I can forward it to the #render_cycles and #eevee_viewport team for the developers to check it out.
It's good to keep in mind that their task list is quite long and it may take a while for them to take a look.

Okay, I can't confirm it as a bug, but I can forward it to the #render_cycles and #eevee_viewport team for the developers to check it out. It's good to keep in mind that their task list is quite long and it may take a while for them to take a look.

Russell commented

2020-12-01 16:52:53 +01:00

Thanks. Can I also ask about the generated mapping? It should create a coordinate space that goes from 0 to 1 over the bounds of the object. That shouldn't create patterns in the noise texture. Also, if I use the object type mapping it should create a 3d coordinate space based on the object's origin and transformations. Again, no reason the noise texture should show patterns. If those assumptions are wrong please let me know because often with these nodes, and the thin documentation, people aren't confident on how things are supposed to work. I'm only pretty sure and you're obviously not because you thought that this had something to do with UV mapping.

Omar Emara commented

2020-12-01 17:47:57 +01:00

@mano-wii This happens due to very slight rotation along one of the axis. A simple way to replicate that is to add a plane and rotate it along the x axis with 0.5 degrees. Attached a minimal blend file for that. That's also why the checker texture appear as in your screenshot.

It is not a repetition of the texture. The pattern appear due to the plane crossing the noise cells along the perpendicular axis, so it will also happen to Voronoi and other textures that are computed through "cells". The number of crossings/strips per unit length is proportional to sine of the angle multiplied by the scale of the texture, so that's why it happens in those particular values. I am not sure if this can be avoided, and unfortunately I don't have the time to investigate this further for now. I will leave the classification of this report to you.

@Russ1642 To mitigate this issue, 1) you should flatten your polygons and 2) align the vertical edges with the z axis.

slightRotationNoise.blend

@mano-wii This happens due to very slight rotation along one of the axis. A simple way to replicate that is to add a plane and rotate it along the x axis with 0.5 degrees. Attached a minimal blend file for that. That's also why the checker texture appear as in your screenshot. It is not a repetition of the texture. The pattern appear due to the plane crossing the noise cells along the perpendicular axis, so it will also happen to Voronoi and other textures that are computed through "cells". The number of crossings/strips per unit length is proportional to sine of the angle multiplied by the scale of the texture, so that's why it happens in those particular values. I am not sure if this can be avoided, and unfortunately I don't have the time to investigate this further for now. I will leave the classification of this report to you. @Russ1642 To mitigate this issue, 1) you should flatten your polygons and 2) align the vertical edges with the z axis. ![20201201-182354.png](https://archive.blender.org/developer/F9420450/20201201-182354.png) [slightRotationNoise.blend](https://archive.blender.org/developer/F9420439/slightRotationNoise.blend)

Russell commented

2020-12-01 17:58:16 +01:00

The entire purpose of the noise node is to be random and free of patterns, and it's used in so many node trees to do just that. It's clearly a bug/known issue.

Robert Guetzkow commented

2020-12-01 18:57:20 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-12-01 18:57:20 +01:00

@Russ1642 Could it be that you're confusing the Noise and White Noise nodes?

@Russ1642 Could it be that you're confusing the *Noise* and *White Noise* nodes?

Russell commented

2020-12-01 19:06:41 +01:00

Are you suggesting that the visible banding pattern is correct? The noise node is supposed to do that? You're saying that I just don't understand the function of the node. I don't see any reference to banding patterns and such in the documentation. Noise is supposed to be random. And don't just correct me if I'm wrong, correct everyone because we're obviously mistaken about the Noise Texture node.

Robert Guetzkow commented

2020-12-01 19:12:03 +01:00

@Russ1642 Yes, presumably for the reason @OmarEmaraDev explained. The [Noise ]] texture node is https:*en.wikipedia.org/wiki/Perlin_noise , not true random noise. If you want true random noise use the [ https://docs.blender.org/manual/en/dev/render/shader_nodes/textures/white_noise.html | White Noise node.

@Russ1642 Yes, presumably for the reason @OmarEmaraDev explained. The [Noise ]] texture node is [[ https:*en.wikipedia.org/wiki/Perlin_noise | Perlin noise ]], not true random noise. If you want true random noise use the [[ https://docs.blender.org/manual/en/dev/render/shader_nodes/textures/white_noise.html | White Noise ](https:*docs.blender.org/manual/en/dev/render/shader_nodes/textures/noise.html) node.

Russell commented

2020-12-01 19:21:14 +01:00

The banding should not be there. It's a bug. I don't want white noise, which is noise at all frequencies. I want noise with controllable frequency and effect, which is what the noise node is used for. I don't want anything that has zero noise, such as the hard banding effect, to be generated by the node. I didn't think I'd need to get so technical about not wanting weird banding effects. Ask yourself if this is what the designers had in mind when they created the noise node.

Omar Emara commented

2020-12-01 20:18:08 +01:00

@Russ1642 We understand your frustration. Ideally, this banding pattern shouldn't occur. However, that's how it works, sometimes procedural textures behave unexpectedly in certain cases. We are typically able to workaround those issues one way or another. I am not sure if we will be able to workaround this particular issue, but we will certainly look into it.
Meanwhile, you may mitigate the issue as I described above. Alternatively, a much simpler approach would be to rotate the texture coordinates by a random amount as demonstrated below.

@Russ1642 We understand your frustration. Ideally, this banding pattern shouldn't occur. However, that's how it works, sometimes procedural textures behave unexpectedly in certain cases. We are typically able to workaround those issues one way or another. I am not sure if we will be able to workaround this particular issue, but we will certainly look into it. Meanwhile, you may mitigate the issue as I described above. Alternatively, a much simpler approach would be to rotate the texture coordinates by a random amount as demonstrated below. ![20201201-210737.png](https://archive.blender.org/developer/F9420934/20201201-210737.png)

Russell commented

2020-12-01 20:27:30 +01:00

Thank you for A, acknowledging the issue, and B, not telling me it's my fault. I will gladly work around the issue now that I know how.

I can see that there will be 'certain cases' where a procedural texture will fail, but this is a flat wall. I was constructing a model right off of engineering drawings. I didn't expect the slight slope of the wall would break things.

Thank you for A, acknowledging the issue, and B, not telling me it's my fault. I will gladly work around the issue now that I know how. I can see that there will be 'certain cases' where a procedural texture will fail, but this is a flat wall. I was constructing a model right off of engineering drawings. I didn't expect the slight slope of the wall would break things.

Robert Guetzkow commented

2020-12-01 20:41:33 +01:00

@Russ1642 I'm sorry if we were talking past each other. I was in no way saying that the banding is your fault, it is inherent in the way the procedural noise is generated according to @OmarSquircleArt. I just thought there might have been a misunderstanding what the noise node does, because it isn't random noise and the 2.79 noise texture used to be random noise.

Russell commented

2020-12-01 20:58:39 +01:00

In this thread I've been told that I just don't understand the Object or Generated texture coordinate spaces. I've been told that I'm wrong for expecting the Noise node to not have obvious non-randomness to it. I've been told that I'm confusing the Noise node with the White Noise node. All this because there's obvious banding in what's supposed to be a simple random noise texture on a flat wall. I'm honestly only trying to help. I shouldn't have to defend my bug submissions this much to keep them from being rejected.

In this thread I've been told that I just don't understand the Object or Generated texture coordinate spaces. I've been told that I'm wrong for expecting the Noise node to not have obvious non-randomness to it. I've been told that I'm confusing the Noise node with the White Noise node. All this because there's **obvious** banding in what's supposed to be a simple random noise texture on a flat wall. I'm honestly only trying to help. I shouldn't have to defend my bug submissions this much to keep them from being rejected.

Robert Guetzkow commented

2020-12-01 21:21:08 +01:00

@Russ1642 Nobody is denying that there is this banding-like effect. You don't have to defend yourself, this was all just discussion about technicalities. I'm sorry if we gave you the impression that this was somehow personal.

What @OmarEmaraDev tried to explain was how Perlin noise is generated (which is what the Noise node outputs) and that under certain conditions, like the slight rotation in your model, it becomes apparent that the procedural noise isn't quite as random as one might expect. This of course doesn't mean that the behavior isn't confusing for the user.

In #83144#1066225, @OmarEmaraDev wrote:
It is not a repetition of the texture. The pattern appear due to the plane crossing the noise cells along the perpendicular axis, so it will also happen to Voronoi and other textures that are computed through "cells". The number of crossings/strips per unit length is proportional to sine of the angle multiplied by the scale of the texture, so that's why it happens in those particular values

@Russ1642 Nobody is denying that there is this banding-like effect. You don't have to defend yourself, this was all just discussion about technicalities. I'm sorry if we gave you the impression that this was somehow personal. What @OmarEmaraDev tried to explain was how Perlin noise is generated (which is what the *Noise* node outputs) and that under certain conditions, like the slight rotation in your model, it becomes apparent that the procedural noise isn't quite as random as one might expect. This of course doesn't mean that the behavior isn't confusing for the user. > In #83144#1066225, @OmarEmaraDev wrote: > It is not a repetition of the texture. The pattern appear due to the plane crossing the noise cells along the perpendicular axis, so it will also happen to Voronoi and other textures that are computed through "cells". The number of crossings/strips per unit length is proportional to sine of the angle multiplied by the scale of the texture, so that's why it happens in those particular values

Russell commented

2020-12-01 21:35:54 +01:00

I'll bet 99.99% of users don't care how that noise is generated, but they don't want obvious artifacts to show up so easily. So YES, this is a bug in Blender. If Perlin noise, or whatever mathematical formula the developers decide to use, doesn't work for creating noise on a simple flat wall then it needs to be replaced or fixed. Is it a critical bug that needs work today? Obviously not, but it's still a bug. That node is used by a lot of users and it's the only noise node besides White Noise, which is used for other things entirely. There's just so much resistance to acknowledging that there's an issue here.

I'll bet 99.99% of users don't care how that noise is generated, but they don't want obvious artifacts to show up so easily. ***So YES, this is a bug in Blender***. If Perlin noise, or whatever mathematical formula the developers decide to use, doesn't work for creating noise on a simple flat wall then it needs to be replaced or fixed. Is it a critical bug that needs work today? Obviously not, but it's still a bug. That node is used by a lot of users and it's the only noise node besides White Noise, which is used for other things entirely. There's just so much resistance to acknowledging that there's an issue here.

Russell commented

2020-12-01 21:40:17 +01:00

Oh boy it's hard to respond if you completely edit your posts while I'm replying to them.

Germano Cavalcante commented

2020-12-01 22:45:00 +01:00

This report is already getting full of comments, which can hinder developers when they take a look :
Maybe I better create another one and use the example and description from Omar and merge this one?

Thanks @OmarEmaraDev for creating an even simpler file that highlights the problem.
The new file and the explanation helped me to understand what is going on.

Apparently the Noise implementation of Blender is not entirely "random". It follows a kind of (non-repetitive) pattern in horizontal, vertical and depth.

It is like a brick texture 3d with modified bricks.
Due to rotation, sometimes you see more "bricks" and sometimes more "mortar".

This can be confusing for the user, but I noticed that the value of "Distortion" can break that pattern and remove those waves.
So, does that value exist because of this limitation?

So the question that remains is:

Since this works as it was implemented, can it really be considered a bug?
If it is not a bug (but a request for improvement), is it worth it to devote time and resources for developers to work on it?
It is worth prioritizing this report to the detriment of others that may actually be a bug.

It is good to keep in mind that, even if the texture is "fixed"/redone, maybe the original implementation will have to continue to exist in order not to mess up the material from old files.
So I don't think it would be a fix, but the implementation of a new algorithm.

(Another thing to keep in mind is that the purpose of triaging is not to tell the bug reporters that they are wrong. It is more to discuss whether the report is really a bug in order to be classified. Sorry if I seemed to be rude).

This report is already getting full of comments, which can hinder developers when they take a look :\ Maybe I better create another one and use the example and description from Omar and merge this one? Thanks @OmarEmaraDev for creating an even simpler file that highlights the problem. The new file and the explanation helped me to understand what is going on. Apparently the Noise implementation of Blender is not entirely "random". It follows a kind of (non-repetitive) pattern in horizontal, vertical and depth. ![image.png](https://archive.blender.org/developer/F9421375/image.png) It is like a brick texture 3d with modified bricks. Due to rotation, sometimes you see more "bricks" and sometimes more "mortar". This can be confusing for the user, but I noticed that the value of `"Distortion"` can break that pattern and remove those waves. So, does that value exist because of this limitation? So the question that remains is: - Since this works as it was implemented, can it really be considered a bug? - If it is not a bug (but a request for improvement), is it worth it to devote time and resources for developers to work on it? - It is worth prioritizing this report to the detriment of others that may actually be a bug. It is good to keep in mind that, even if the texture is "fixed"/redone, maybe the original implementation will have to continue to exist in order not to mess up the material from old files. So I don't think it would be a fix, but the implementation of a new algorithm. --- (Another thing to keep in mind is that the purpose of triaging is not to tell the bug reporters that they are wrong. It is more to discuss whether the report is really a bug in order to be classified. Sorry if I seemed to be rude).

Robert Guetzkow commented

2020-12-01 22:51:57 +01:00

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

Robert Guetzkow closed this issue

2020-12-01 22:51:57 +01:00

Robert Guetzkow commented

2020-12-01 22:51:57 +01:00

I'll bet 99.99% of users don't care how that noise is generated, but they don't want obvious artifacts to show up so easily.

That is likely the case, I agree.

So YES, this is a bug in Blender.

It is a limitation of the method that is currently implemented. We have a very narrow definition of what we consider a bug, because many people have suggestion how Blender could be improved. These may be perfectly good ideas like yours, but in order to keep development organized we have to separate bugs (errors in Blender's code, feature doesn't work as designed) and improvement suggestions (current feature doesn't work as well as it could). Adding novel noise algorithms or changing how the current ones are calculated would be in the latter category and off-topic on the bug tracker. Right-click select is our website where feature requests can be posted. We don't do this because we are mean or disinterested in user's ideas. Actually, we may think it's a great idea. However, it's simply a necessity to keep feature requests, improvement suggestions and feedback off the bug tracker because otherwise we would have a hard time catching up and finding the actual bugs among the many posts. Since the rule applies to everyone, no matter the quality of the idea, we have to close this ticket too.

If Perlin noise, or whatever mathematical formula the developers decide to use, doesn't work for creating noise on a simple flat wall then it needs to be replaced or fixed.

There are different ways how you can make it work for your specific use case. For instance a Mapping node could be add to rotate the generated coordinates to compensate. The Noise node could switch to 4D and W varied. It would also be possible to add Distortion.

There are certainly even more ways to use the current node and get the desired effect.

Is it a critical bug that needs work today? Obviously not, but it's still a bug.

As explained above, we don't consider this a bug.

That node is used by a lot of users and it's the only noise node besides White Noise, which is used for other things entirely.

We also have [Musgrave ]] and [ https:*docs.blender.org/manual/en/dev/render/shader_nodes/textures/voronoi.html | Voronoi for procedural noise. However, they may also suffer from similar artifacts like @OmarEmaraDev described. This is the case for Musgrave in your project, while Voronoi seems to look fine.

There's just so much resistance to acknowledging that there's an issue here.

I think everyone who has commented so far agreed that banding happens and that this is not nice for the user. There are ways to get your intended result as my suggestion in this comment show.

In summary: Please don't be mad at us or take this personal. Changing the implementation entirely so that such artifacts can never occur is an improvement suggest/feature request as thus off-topic. The current implementation works as design according to the developer I've talked to.

> I'll bet 99.99% of users don't care how that noise is generated, but they don't want obvious artifacts to show up so easily. That is likely the case, I agree. > So YES, this is a bug in Blender. It is a limitation of the method that is currently implemented. We have a very narrow definition of what we consider a bug, because many people have suggestion how Blender could be improved. These may be perfectly good ideas like yours, but in order to keep development organized we have to separate bugs (errors in Blender's code, feature doesn't work as designed) and improvement suggestions (current feature doesn't work as well as it could). Adding novel noise algorithms or changing how the current ones are calculated would be in the latter category and off-topic on the bug tracker. [Right-click select ](https://blender.community/c/rightclickselect/) is our website where feature requests can be posted. We don't do this because we are mean or disinterested in user's ideas. Actually, we may think it's a great idea. However, it's simply a necessity to keep feature requests, improvement suggestions and feedback off the bug tracker because otherwise we would have a hard time catching up and finding the actual bugs among the many posts. Since the rule applies to everyone, no matter the quality of the idea, we have to close this ticket too. > If Perlin noise, or whatever mathematical formula the developers decide to use, doesn't work for creating noise on a simple flat wall then it needs to be replaced or fixed. There are different ways how you can make it work for your specific use case. For instance a *Mapping* node could be add to rotate the generated coordinates to compensate. The *Noise* node could switch to *4D* and *W* varied. It would also be possible to add *Distortion*. There are certainly even more ways to use the current node and get the desired effect. > Is it a critical bug that needs work today? Obviously not, but it's still a bug. As explained above, we don't consider this a bug. > That node is used by a lot of users and it's the only noise node besides White Noise, which is used for other things entirely. We also have [Musgrave ]] and [[ https:*docs.blender.org/manual/en/dev/render/shader_nodes/textures/voronoi.html | Voronoi ](https:*docs.blender.org/manual/en/dev/render/shader_nodes/textures/musgrave.html) for procedural noise. However, they may also suffer from similar artifacts like @OmarEmaraDev described. This is the case for *Musgrave* in your project, while Voronoi seems to look fine. > There's just so much resistance to acknowledging that there's an issue here. I think everyone who has commented so far agreed that banding happens and that this is not nice for the user. There are ways to get your intended result as my suggestion in this comment show. **In summary:** Please don't be mad at us or take this personal. Changing the implementation entirely so that such artifacts can never occur is an improvement suggest/feature request as thus off-topic. The current implementation works as design according to the developer I've talked to.

Russell commented

2020-12-01 23:03:30 +01:00

I think the standards for what is and isn't a bug should be based on the user experience, not whether the code implemented a mathematical formula nobody cares about correctly. Obvious banding patterns when texturing a very simple surface sure looks like a bug to me. I'm really getting sick of seeing obvious problems and having the developers deny that they're isssues at all. It's an attitude that's hostile to the advancement of the program. If this doesn't qualify as even the lowest priority bug type then there's a problem here.

Charlie Jolly commented

2021-02-16 17:19:53 +01:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2021-02-16 17:19:53 +01:00

Adding this comment for reference in case someone wants to look into this issue.
Note should be added to the manual that this is a known issue.
D5560 Original Noise patch
Link to article about alternative Wavelet noise where Perlin noise is mentioned as having banding issues.
https://graphics.pixar.com/library/WaveletNoise/paper.pdf

Adding this comment for reference in case someone wants to look into this issue. Note should be added to the manual that this is a known issue. [D5560](https://archive.blender.org/developer/D5560) Original Noise patch Link to article about alternative Wavelet noise where Perlin noise is mentioned as having banding issues. https://graphics.pixar.com/library/WaveletNoise/paper.pdf

Philipp Oeser commented

2021-08-20 11:12:12 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-08-20 11:12:12 +02:00

Just noting that we have #87781 (Noise Texture Fac output fails when using exact unit inputs and exact scale values) (that one is open as a Known Issue)

Just noting that we have #87781 (Noise Texture Fac output fails when using exact unit inputs and exact scale values) (that one is open as a `Known Issue`)

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 texture has repeating stripes in z axis #83144