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
I see only a Pivot point, both in Cycles or in Eevee and in any shading mode. Adding a cloud volume material does nothing.
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.
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âŚ
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.
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:
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
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
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.
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:
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.
How I can convert a mesh object to a volume and a volume object to mesh one?
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.
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.
