When I make a scattering volume, I always run into step size artifacts, and after seeing them, I’ve begin to notice it on other people’s renders too. I’m confident it happens because the edge of the volume gets sliced at a grazing angle by a sphere(the various step lengths). What I don’t know, is why it has such obvious artifacts. can anyone help me understand and get rid of them?
It’s likely that your smoke domain resolution is too low:
that’s just it, though. This is a problem attributed to the rendering engine, not the scene. Increasing the resolution only makes the edges of the smoke finer. It can disrupt the visual pattern of the artifact in still images, but not in animated ones. to more accurately explain what’s going on, I found a video from someone afflicted with the same limitation.
OK - have you tried increasing the volume step size on the Geometry tab of the Render settings.
The default is 0.1, you could try decreasing it to say 0.05 or lower (it will dramatically increase your render time though)
that zoomed in image, the third down, is at .005.
turning up the step size only makes the smoke thicker per distance traveled into it, which is meaningless without units of density or scale. Not only does it not remove artifacts, at times, it can make them worse (when smoke just barely glances a step). I think the only way to fix this may be a change to step sampling. I took a little trip into the code, and waay back in 2008, there was actually a commit made to give you 3 volume stepping options. constant (what we have), random (each ray gets its own step length within the step, or inherits a unique step size within a range, both of which would fix this), adaptive (a complete mystery to me)
so there was a fix planned, but it was broken and never brought up again.
2008? Which render engine are you using blender internal? If the issue is because of the render engine, then it is worth testing this in cycles. Blender internal is being removed in 2.8.
Also that video you linked to was rendered in eevee. Issues there could be because of its alpha status. There are a lot of issues that still need to be resolved in eevee.
I understand, but I’m using cycles by default and I only included that to show how the issue looks. Whatever is happening here is probably affecting both in almost exacly the same way, though it’s more apparent in eevee.
I haven’t noticed this type of artifact before. I’m not sure if this is a glitch or technical limitation. It would be a good idea to ask some of the cycles developers on https://devtalk.blender.org/c/cycles about this.
https://youtu.be/iw8hj2Uycvk?t=903 in case you want someone else who noticed this, though his project could do without a fix because his camera was still. I’ll try to contact them, see what’s up. it should be homogeneous, but it forms concentric rings of dark and light in the volume, something other volume renderers do not have trouble with.
I’m not a developer, so I could be entirely wrong about this, but I don’t think it’s an issue with the renderer. I think it has something to do with the volume data itself, or at least with how blender passes this info to the rendering engine. If both eevee and cycles have this same issue, then it has to be something outside of those two causing it.
well, it could certainly be two instances of the same issue. the thing is, there are only so many ways to quickly compute volumes, especially realtime. Both the viewport and cycles use a stepping algorithm, and I’m willing to bet blender internal and eevee do as well. I believe there is some fundamental flaw with how blender steps through volumes. besides, if you crank up the density, and look…
it also affects the viewport,
and the viewport doesn’t even support density remapping or shader stuff for volumes. for some reason, it’s like every other step, or half of every step gets ignored, in blender.