As a new user I couldn’t attach two images in the same post, so I’ll attach the second one here:
This is the same FumeFX volume object in Eevee:
This should be fixed now.
1 Like
Thanks @brecht
I didn’t have the problem you just fixed because I always use zero padding.
I can see my vdb sequences in the viewport in all possible modes but if I try to F12 render the current frame it always renders the frame that I saved the blend file on.
This means if I go to e.g. frame 20, save the blend file and re-open it again it will always only render frame 20. If I move to frame 40 it will still render frame 20.
I didn’t try this on Windows, but it has been the case ever since the volume object was added to master.
System Information
Operating system: Linux-5.3.18-050318-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.64.00
Blender Version
Broken: version: 2.83 (sub 13), branch: master, commit date: 2020-04-12 12:48, hash: rBf16fcb5bd5ec
You d man 
Thanks very much.
Answer to myself:
I tried hard to reproduce my own problem in a simpler scene that I could submit as a bug report.
But all fresh scenes I started didn’t show the problem, even if I used the very same vdb sequence that didn’t work properly before.
So forget what I was trying to report above. I’ll submit a report as soon as the problem reoccurs.
I’m trying to simulate atmospheric light on a largish scale and recently discovered that the density for volume nodes doesn’t go sufficiently low to match real atmospheric fog. I made a right-click select proposal https://blender.community/c/rightclickselect/m2fbbc/ .
1 Like
+1 for pyopenvdb access to grids!
@jacqueslucke added new volume object features, testing and feedback on those is welcome in this topic.
- New Mesh to Volume modifier [5845c06a63].
- New Volume Displace modifier [1f50beb9f2].
- Support selection and outlines in viewport [e12767a035].
- Support lower resolution in viewport [365bf103d1].
There is now also a Python API function to save volume datablocks to a .vdb files on disk. Render engines can use this, though pyopenvdb support is still something we want to add.
5 Likes
Really nice, I will test it tonight 
This is so awesome! Looking forward to the future stuff coming!
The only comment I have so far is that in the Mesh to Volume modifier the minimum voxel size is limited to 0.1 (which might be much too large in most cases):
2 Likes
A buste, step size 0 and denoised with intel denoiser
as @SteffenD suggested 0.100 is too large
Couldn’t understand why the volume stay linked to the original mesh when moving or rotating it, can’t apply the modifier either, what if i want the mesh beside his volume representation ?
It could be handy to have a voxel size for the viewport and another one for the render, in this example i have been playing with the texture that displaced the volume at 0.100 size to have a smooth viewport and then i ll put between 0.300-0.500 before rendering
Good work guys and i can t wait to be able to convert volume to mesh 
5 Likes
Hi everyone,
First thank you @jacqueslucke for your work 
Here are a few renders :
- You can see on the head model, there are some flat area (center and bottom)
- On third and fourth picture, I compare the same texture with a normal displace modifier and the new volume displace… Texture use is the same (cloud)
It seem as the volume displace is kind of ‘‘missing’’ one axis of displacement with a sphere. So it is stretch instead of displace in every axis.
Voxel amount 500 / 25 density
Voxel amount 500 / 100 density
Normal sphere with displace modifier… 3 axis of displacement
Same displace texture on a volume object… 2 axis of displacement
Thx a lot !
3 Likes
The opposite behavior could be just as confusing, because then the volume would be in some different place most of the time. In fact, we had the behavior you describe in master already, but reverted back to the current behavior.
The good thing is, you can put the volume object into a collection and create a collection instance that copy, move around, scale etc.
I agree. The issue is, a smaller minimal voxel size easily leads to crashes and slows Blender down, because the resolution becomes very large. That happened to me many times accidentally.
I was just thinking of an alternative way to specify the resolution:
Instead of having Voxel Size and Voxel Amount we could have Fixed and Adaptive.
In the Fixed mode, the given voxel amount would specify the number of voxels per unit of length. So instead of having the voxel size 0.1, one would have 10 voxels per meter.
In the Adaptive mode, the given voxel amount would not be per unit of length. Instead it would be the approximate number of voxels along one side of the volume (or maybe using the diagonal is a better idea).
That approach should solve the issue with a too minimal small voxel size.
The Volume Displace modifier uses the RGB values of the texture as XYZ displacement values. I guess that your texture is gray scale, i.e. the red, green and blue component are always the same. This is why you get stretching along the diagonal. You have to use a color texture.
1 Like
I want to suggest a render/viewport differentation for the resolution settings in the mesh-to-volume modifier
2 Likes
I did a quick test, just a modified cylinder with some volume displacement and a bit of shader work, nothing fancy. (Cycles)
Tornado_Cycles_C
5 Likes
Not a technical man, but is there anyway of getting this to work with greyscale? Most textures from blender internal are greyscale, and in the future if we can output our own textures from the shading workspace for modifiers and brushs etc, those would almost certainly all be greyscale as well. Right now that mostly limits us to clouds and voronoi.
1 Like
The problem with volumes is that they (usually) don’t have any normals that you can displace them along.
There is though the concept of a “gradient” inside signed distance fields which are a special form of volume and are also supported by VDB. The gradient field contains a vector pointing to the closest “point” on the boundary of the volume thus giving some sort of normal vector that could be used to displace, erode, dilate, … the volume.
I’m positive that support for this will come in the near future. Jacques Luckes already showed a “Volume to Mesh” modifier that under the hood makes use of this.
1 Like
I am not a fan of current modifiers workflow.
Mesh to Volume modifier is forcing to keep the mesh object around, to hide it when you want to see the result, and then, to reveal it to make an adjustment.
Modifier is relative only to one object.
Adding a second modifier will not add another object but just make the first modifier useless.
So, to change a collection into volume, user has to create one Volume Object per object or to fuse all meshes into a unique object.
And this modifier cannot be applied.
Fill Volume option is filling mesh volume and we have an exterior band.
Problem is that band is not clearly visible when displacement is used.
So, we have a mesh as a reference that gives no information on that band.
Things would be a lot easier to manage if we only have an Interior Margin setting that would grow from mesh boundaries to center of volume and an option to fill or keep empty what is inside interior boundary of margin.
Volume Displace modifier is referring to Blender Internal textures.
So, current problem of concordance with material textures that exist with meshes using displace modifier is extended to this new volume object.
We can not benefit of cube, sphere… projections or UVmapping for 2D textures.
Data is just pushed into one direction. We have no ability to shrink volume with a texture when Fill Volume option is not satisfying.
With Cycles, Displace modifier is displacing what is filled by Fill Volume option.
That is a different behavior than what EEVEE do. EEVEE is just displacing band and the interior stays homogeneous.
Overlapping of a mesh with a principled volume shader and a volume object using a displace modifier results in a blocky render.
So, original mesh can’t be an alternative. So, you end-up doubling amount of meshes and volume objects.
We have a new object type without manageable object data.
We could imagine to add a mesh data list panel in Object Data tab of volume, having same settings as current modifier displays and more.
That way, we could have only one volume object for several meshes. And it would be possible to use several materials instead of one, go in edit mode to translate, rotate or scale openvdb grid corresponding to mesh.
If we could simply convert mesh into an OpenVDB grid of Volume object, if we could modify some marks in edit mode : we would gain a lot in simplicity.
I know that modifiers will be replaced by nodes at the end. But during that time, workflow will stay very frustrating, inconsistent with the rest of software, overcomplicated and slow.
3 Likes