Volume Object Feedback

I just committed the new volume object to 2.83, for rendering OpenVDB volumes. This is a topic for user feedback on that functionality.

The main limitations are these, which we are aware of and working on:

  • No sparse grid rendering yet in Cycles and Eevee, so uses more memory than it could.
  • Loading big volume datasets in solid display mode can be problematic. We intend to add a way to load them at lower resolution (by default when above a certain resolution?).
  • Selection in the viewport is only possible with the center point or wireframe.

For more details and future plans see the task T73201.


This is awesome, everything works great. The only feedback I’d have is regarding selection. If bounds display is not on, there doesn’t seem to be a way to select volume objects in the viewport, or see whether they are selected, so perhaps that could be on by default for volume objects?


This is definitely awesome, but nothing works here :sweat_smile:
I see only a Pivot point, both in Cycles or in Eevee and in any shading mode. Adding a cloud volume material does nothing.

Blender version

version: 2.83 (sub 10), branch: master, commit date: 2020-03-19 07:26, hash: fd48ff1296f4, type: Release
build date: 2020-03-19, 07:50:50
platform: Linux

1 Like

This is on the list to be added still.

This was done initially but I found it go in the way as well, especially in Material and Rendered mode. Perhaps we could display the bounds only when the object is selected.

You need to load a .vdb file, otherwise there will be nothing.


It works as expected with external OpenVDB and smoke simulations from Blender previous releases older than 2.82.

But that does not work with .vdb files from a mantaflow simulation.
If I load a density.vdb file, smoke is visible in Viewport in Solid Display mode.
But that is the only display mode satisfying. Wireframe display are not working as expected.
It is rendered by EEVEE or Cycles.
Although there is no way to load multiple grids of a mantaflow simulation into one object, yet or an output in mantaflow cache to contain all the attributes into one .vdb file ; that is weird that grid is correct in solid view but cannot be rendered or displayed as a wireframe.
Especially, when you see that Sequence Playback mode is working.

Except that, AndrewC is right about selection in Viewport.
IMO, support to origin repositioning would be welcomed, too.

Is it planned to add stuff to Grids list ?
Eye icons to display only one Grid at a time and not just the final result would be necessary for Workbench even before it is possible for Cycles or EEVEE.
If Grids are corresponding to different attributes in the shader, user have to know where there starts, where they ends when previewing the sequence in Viewport In Solid or Wireframe mode.

It will be improved, there is an item for that in the task.

It can be rendered, from the release notes:

By default the Principled Volume shader is used for rendering volume objects. It will use grids named density , color and temperature by default. If these are not available, another grid name must be chosen in the shader nodes.

Mantaflow does not follow these conventions, when it does this will work without manual setup.

Workbench only displays one grid at a time.

1 Like

Oops. Sorry. I let too much time between testing and reporting.
That was what I wanted for render when I tested but that is planned.
And I confused myself.

Thank you. I confirm that if I enter correct name of grid in material. It works.

Just a quick question, but what version of VDB is Blender supporting with this implementation?
It’s good to know, when people start to export VDB files from application -XYZ-.
Some versions might be exporting files in an older format, and I’m not sure how upward compatible VDB is… :wink:

It was approved to align OpenVDB library to VFX platform reference.

So, a current master build is using OpenVDB 7.

I tested the Volume Object with files from openvdb.org that are 7 years old. And it works.
So, I suppose that OpenVDB is rather upward compatible.


I was being curious here, and didn’t find anything on this yet. :wink:

cheers, and stay safe!

Couple of problems.

  1. The sequence option doesn’t work unless all files have the same number of digits, for example if you import a vdb sequence from ‘explosion_1’ to ‘explosion_100’, then it fails with error ‘explosion_001’ not found when you choose the shift + a import vdb option, or if you use an empty volume and navigate using the file explorer from the volume properties, it doesn’t return an error, it just doesn’t work.

  2. Doesn’t appear to be any way of reading which attributes the vdb file contains, I think density, flames and temperature are just defaults rather than necessarily what the actual file contains?

I’m testing with the CCO gasoline explosion from embergen:



  1. Your frame numbering is to blame here, not Blender. That scenario will fail in a lot of applications.
    Always use 3 or 4 digit numbering and you’ll be fine :wink:

  2. We need some kind of extra node in the shading environment to extract additional information from the VDB if it’s in there. Especially with Houdini you can add a lot of extra information in a VDB or Alembic, but for now there’s no real way to extract that data from a file besides the defaults.

But… Having VDB in Blender opens up a whole new set of possibilities, or trips to other applications :slight_smile:

For 1, it’s indeed convention to have leading zeros for such animation sequences, this is the same as for image sequences. We may be able to support reading them anyway.

For 2, are you referring to OpenVDB metadata? Currently we provide access to the grids in the files with whatever names they have, typically “density”, “temperature”, … but it can be anything.

There is also metadata per-file and per-grid, providing access to that is on the list. This may be a float value, vector, string, etc. I’m not sure what “defaults” refers to in this context.

1 Like

Awesome thanks. I mean it’s easy enough to batch rename the files with python prior to import, or even re-generate them in Houdini, but a lot of people might not know how to do that, so I’m sure it would be welcome for many.

Thanks to You for return old good functionality into Blender. It is great news!

I see great future of Volume Object, and there are several questions:

  1. Can I load density of volume object from a image sequence, or a movie (as it was in old Blender versions)? A lot of sources is in such formats. Of course, OpenVDB is rich capability format, but in most cases we need simple images or avi/mp4.

  2. How I can convert a mesh object to a volume and a volume object to mesh one?

  3. Can I use volume mesh as 3d-texture?

1 Like

It’s not supported, the primary use case we are targetting right now is animation / VFX, not so much e.g. scientific visualization which may use different file formats.

It will be possible for someone to implement a modifier that creates a volume object from images.

It’s not possible yet, that will come when we add volume modifiers.

Not currently. We may support that in the future, but for best performance this should be avoided as it prevents the renderer from doing optimizations for sparse volume datasets.


Do You mean the modifier on level of C/C++ inside blender’s core? Or it is possible on level of Python? If second, i want to try one. Is there some Python API to volume object?

Apart from future file formats and methods supported to get volume data into Blender, the underlying volume data structure is more or less 1:1 the OpenVDB sparse tree representing a rectangular grid, right?

This would have to be done in C++. We plan to add pyopenvdb in the future to provide access to the volume grids, but writing modifiers in Python is not supported.



Thanks for the volume object! It’s very useful!
I’m here with a bug report and a request for what I think it would be an important feature. Let’s start with the bug. When Importing a FumeFX volume generated in 3ds Max, Eevee shows it correctly in the viewport on rendered mode, while Cycles shows it as a chaotic group of planes. The actual rendered image is the same.

This is Cycles

Another user on BlenderArtists posted a similar image of a “blocky” volume imported from Phoenix FD for Maya. I imported succesfully a volume from Phoenix FD for 3ds Max.
This is the link of his post:

As for the feature request, I think it would be very useful to have somehow the possibility of generating a motion blur for the volume object itself, maybe using the velocity grids generated by this kind of physics simulation softwares.