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".

@Omar Emara (OmarSquircleArt), you worked on this a while ago. What do you think? Bug or not?

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.

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.

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

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.

@Germano Cavalcante (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.

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

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.

@Russell (russ1642) Could it be that you're confusing the Noise and White Noise nodes?

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.

@Russell (russ1642) Yes, presumably for the reason @Omar Emara (OmarSquircleArt) explained. The Noise texture node is Perlin noise, not true random noise. If you want true random noise use the White Noise node.

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.

@Russell (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.

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.

@Russell (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 @Omar Emara (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.

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.

@Russell (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 @Omar Emara (OmarSquircleArt) 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 T83144#1066225, @Omar Emara (OmarSquircleArt) 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

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.

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

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 @Omar Emara (OmarSquircleArt) 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.

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).

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.