@Sergey Sharybin (sergey) it's cool to get a review early on, but, as you somewhat noted, this patch is definitely not near to be finished, or near its final state. Actually, in the past days few I added a couple of stuff and made some changes... I just uploaded it here on requests from @Martijn Berger (juicyfruit) and @Thomas Dinges (dingto). In the case of Cycles, I'd like to make use of OpenVDB's own ray intersectors to skip empty space and those need to be per thread (because they are not thread safe), is it possible to do so (having per thread instances)? The same goes for the samplers, for now they use the VDB tree itself but for faster sampling I'd suggest using ValueAccessors (and therefore will need to be per thread).

But then, if we can ensure thread safety, it is not clear to me how to plug in the ray intersectors. I mean, they would need to be created in the "OpenVDBManager" class (or whatever it will be called) from the grids, just like the samplers, then we'll have an array of those (also in KernelGlobals?) but how to check the right intersector? We could iterate over the whole array in scene_intersect(), but we'll need the right one for the actual ray marching later on.

Maybe we could use a single object to subclass the samplers and the ray intersectors? What approach would you take here?

In D1308#25815, @Sergey Sharybin (sergey) wrote:

For now only mainly looked into Cycles part. All the rest is more about workflow definition and that part doesn't feel really finished -- it just hooks OpenVDB as some sort of side appendix without solving memory usage of simulation/viewport unless i'm missing something.

I thought the goal (suggested by @Lukas Tönne (lukastoenne)) was to use OpenVDB as a caching system here. Also I'm not sure what you mean by "solving memory usage of simulation/viewport", do you want me to reimplement the fluid solver using OpenVDB and rework the drawing code to use OpenVDB grids? (For the drawing code I have no real idea on how to properly send an OpenVDB grid, or its information, to the GPU). If so, then those are not goals of this patch, unless I'm missing something too.

From general notes:

• Don't silence exception unless it's _REALLY_ needed, and surely don't silence generic exception. You're just burring hell of a lot of dead cats doing that.
• I don't see why source/blender/openvdb need to be there. To be it more belongs to intern/openvdb.

About source/blender/openvdb, I feel like OpenVDB can be used in more ways than what is done in this here patch, I've done the same for the particle mesher (D1008). Well I feel like it could be close to where it is used. For instance, I am using a FluidDomainDescr struct to encode data on the simultion itself, the only difference between this struct and SmokeDomainSettings are two matrices, that could be added to SmokeDomainSettings and send this directly. That's my end of it, but if you intend to use VDB for e.g. hair stuff (creating a hair system from the volume of a mesh, using VDB as the grid definition, solving the simulation...), you might not want to go through the hassle of having to write and maintain an API for every single function present in VDB. I'm cool with both front (intern/ or source/), we just need to take possible future usage in consideration, and take a decision. I also feel like having some {DNA|BKE|rna}_openvdb* to put openvdb related stuff in (at least for the caching system for now), so it's more integrated and won't feel like a "side appendix". Finally I put it here, because I couldn't decide where else (like imbuf/intern/openexr/, or alembic directly included in source/blender/pointcache, at least in the dev branch).

In all, I consider that code to be more like a proof of concept, and needs proper rewrite or integration (for lack of better terms).

I'll update the patch shortly with some of the review points taken care of (the quick ones ;) ) and my latest changes (quick support to load file for the current frame, and ability to manipulate the coordinates of the shading point in Cycles node tree).

Also here's some rendering tests, including render times:

(The size/placement of the VDB grid is a bit off, I have yet to take some time to find where the error lays, it's on the Blender side though.)

The dense one was rendered with cubic interpolation, whilst the VDB version was using the box sampler, this makes me think that I could/should look into using the interpolation menu from the material properties panel instead of having a separate one in the node.

Hi Kevin,
The patch applies properly here but could you give some instructions for building with your patch? How and where to build OpenVDB so "python scons/scons.py" finds it in the compilation process?

@mathieu menuet (bliblubli) building OpenVDB is very straighforward, you should already have all its dependencies, I'll link to my Makefile for OpenVDB. Then to build in Blender with Scons simply add to your user-config.py:

WITH_BF_OPENVDB = True
BF_OPENVDB = '/opt/lib/openvdb'  # change this if needed

Here's the makefile for VDB: http://www.pasteall.org/58808/text

Adapt it to suit your needs, I'm on Linux here so I used the paths used by the install_deps.sh script (/opt/lib for libraries). Once this makefile is setup on your side simply use make and make install to compile and install the lib.

well, that may be the problem then, I'm on windows and it seems to be not as straight forward as on linux :( If someone manage to make a build for windows, I'll be happy.

Please continue this awesome patch :)

Hello
can someone create script and share it ?

always nobody help

Hi seghier, what do you mean with "create script"?
Download raw.diff, patch Blender source code, recompile (if the patch still apply).

Cheers, mib

Thanks Wolfgang Faehnle
i have no idea about recompile ; why they didn't simply create plugin and users install it ?

Guys, this is a developer differential, not a user discussion. Test builds will be available, as soon as the feature is ready for testing.

so we wait blender 2.8

I have just opened a new differential for the cache system, reason being that it's different than what is in this patch, and some Cycles related reviews already happened here (I'll reuse this differential when the Cycles code is ready). For the few non-developers paying attention here, if you want to test it, please grab the patch from D1721. And again, please avoid posting random non development related comments, this creates noise :)

for god sake we need this!
vdbs are an industry standard,
people dont have respect for blender because of basic features like this missing.

@Sam Mousa (Mrqozy) please keep the discussions here strictly on topic. This is a place for code review of this patch, anything else just adds noise to an already large patch discussion.