What I’m doing wrong?
Musgrave texture appears with strange glitch tiles (depends on dimension & lacunarity parameters)
Problem only in cycles
Glitch appears only with object mapping mode
That’s very similar to a bug that was fixed some time ago.
https://developer.blender.org/T77681
Lower your texture detail and this should fix your issue.
1 Like
well, increasing the detail parameter takes away the glitch, but it will be a different texture. OSL on/off also didn`t help
I cannot reproduce that problem.
Which version you use?
tried in 2.93 and got the same
Doesn’t glitch on Linux 3.5 alpha (a few days old) running on CPU supported feature set.
No problems here, check if CPU works, then you should try update your gfx drivers.
I`ve tried already in GPU and CPU mode, also installed latest gaming driver from nvidia
Well, noise texture also glitches when turned radically high scale, with fine glowing lines.
What if you turn Lacunarity down a bit?
I am not sure these are necessarily “glitches”. Can it not simply be the math going too crazy in there? These are formulas, after all, you can make them look crazy 
1 Like
As musgrave can have some “weird” issues depending on mode and parameters (extreme values leading to floating point issues), distance from origo (floating point issues), and how it functions around origo (lacunarity is centered around origo), I suggest adjusting/previewing it using microdisplacement (adaptive subdivision). And/or test with less than/greater than nodes to see what the output minimums/maximums are compared to where you want them.
Here is a node group setup I use that is very useful with musgrave. It’s pretty much the same as Map Range in Linear mode (I had a separate one for step functions), but it has a preview mode to see if output is within 0-1 range. If the measured controls needs to be in the realm of ridiculous (10,000+), then maybe the musgrave parameters should be looked at. The setup:
Maybe the internal Map Range node could get preview functionality (or dedicated output socket) one day? It’s just stupid useful, to me at least.
With the OP settings, I got measured values to be plus/minus 1.8’ish, so should be well outside the realm of stupid. And thus safe (wrt floating point issues). Check that your version does the same, and possibly submit a bug report.
2 Likes
I’m not sure I understood what you did.
Could you show the closed nodes in more detail and explain how to connect them with Musgrave?
Just connect the musgrave output to the “Input Value” socket. Now you can easily, using the preview feature, adjust the minimum and maximum until the whole range - whatever it may be - fits nicely within 0-1 which is far easier to manipulate further down the tree.
should it fix the glitch somehow?
Probably not in this case, as plus/minus 1.8’ish should be safe from extreme value outputs that could be a cause for issues. Here is what it does, from left to right:
- The setup shown in the nodes with preview off.
- The setup shown in the nodes with preview on. Black and white indicates values outside 0-1 range.
- Default color ramp (which clips outside 0-1 range) going through a bump node without normalization.
- Default color ramp going through a bump node using the leftmost output (with normalization). Doesn’t clip.