For a while now, several months, I’ve been wrestling with experimental shaders and such in nodes, but none, nor the the general options seem to be able to fix this issue. If you want to see some examples of how it looks,
(my test, where I forced it to happen)
Nebula test render - YouTube
(the project Where I first ran into this issue)
Blender 2.8 Eevee Volumetric Shader Demo 2 - YouTube
(a very good sense of what it looks like… but it’s also affecting EEVEE so that’s weird, I’d say.)
Essentially, for some reason, light is not passing though volumes in a homogeneous way. instead, all the light is clumping near the beginning or end of steps (I can’t tell which is which), and “lowering the step size” just makes it render longer, and shrinks the effect. However, the effect still exists, and even at a step size of .01, it will show up in a 2-4k render.
I asked everyone, and no one who answered had any clue why it was happening, so I decided to look at commits, and found mention of randomized stepping, adaptive stepping, and constant stepping, though the 2008 commit was broken, it almost seemed like a fix.
You can report a bug with a .blend file to demonstrate the problem, then we can determine if it’s a bug or some deeper issues that need deeper changes besides a bugfix. It’s hard to say much from images alone.
In general though rendering such sharp surfaces as a volume is going to be inefficient in most renderers, it more seems like you’re trying to render an implicit surface.
that second link there is the final output of the project where I ran into it, and many people run into it when attempting to make large scale smoke sims, or dense things like ink drops. It wasn’t as sharply-edged as the famous ink drop tutorials, where they actually mention the artifact at the end, and if you look closely, it’s not always very sharp smoke, it can happen on just “rather defined” smoke in more casual renders, as seen here:
if something like https://developer.blender.org/rBACc0ddd5fd4914f7876cdf36225566d795e415bbf1 (not sure if it was for blender internal, or some early version of cycles) could work to eliminate this, it would make volumes just that much more powerful, and speed up volume rendering by reducing the need to set steps to such ridiculous numbers as .001 for a 4k render. I think it’ll need some kind of larger change. It’s probably not a bug, but an artifact, as people keep saying, and artifacts are usually evidence of some kind of code being a little oversimplified in my experience. This means that any “fix” would likely need to be a toggle or something, as it would probably make volume sampling slower in computation, but faster to resolve to a proper visual appearance.
I’ll put it up along with he blend file designed to make the issue as noticeable as possible. The goal, I think, should be to fix it to the point that step size essentially becomes a “feature definition and overall scale” function.
Oh, and here’s the file for here, in case anyone else wants to play with it. (yes, several things obscure or shrink the issue, but nothing actually eliminates it fully upon animation.)
–smaller subdiv simulation obscures it
–more bounces get rid of the shading, but only against solid objects, the bands persist on self-shading volumes
–smaller step sizes exponentially increase render time, but an HD render will still suffer from shrunken bands
–less sharp volumes still display this, just in a more subtle way
–animating the camera and rendering is a good way to check if it’s happening, because the pattern moves with the camera, “sweeping” over the edges of volumes.