So apparently there is a hard crash during final render that I was too distracted to notice (I was almost exclusively doing viewport renders this patch). The crash occurs because the Blender volume is freed by the dependency graph before we get to generate the mesh, so trying to reload the volume grid makes us dereference a freed pointer. I don't know what the best solution would be here. The only thing that works is to not free the OpenVDB grid in the BlenderVolumeLoader (as I did as a quick hack), but also we cannot call VDBImageLoader::cleanup() after generating the mesh because it will go through BlenderVolumeLoader::cleanup() which will dereference the freed pointer via find_grid (and the pointer is not null so we cannot check it).

In D8401#205618, @Kévin Dietrich (kevindietrich) wrote:

So apparently there is a hard crash during final render that I was too distracted to notice (I was almost exclusively doing viewport renders this patch). The crash occurs because the Blender volume is freed by the dependency graph before we get to generate the mesh, so trying to reload the volume grid makes us dereference a freed pointer. I don't know what the best solution would be here. The only thing that works is to not free the OpenVDB grid in the BlenderVolumeLoader (as I did as a quick hack), but also we cannot call VDBImageLoader::cleanup() after generating the mesh because it will go through BlenderVolumeLoader::cleanup() which will dereference the freed pointer via find_grid (and the pointer is not null so we cannot check it).

Hi,

Need to ask, because I'm the one who report that bug. I don't sadly understand programming stuff, so need to ask directly from Artist point of view.
Was testing VDB today, don't know if in 2.91 Alpha, this patch is added, but now, random frames are of, so nothing in them, only when rendered (so I assume this is what are You writing about), and in one file FIRE is present, and in another, with the same sequence and shader not.
Can You please confirm? I just really am in need for this to work, and worrying, and just like to know.

Regards

@Kamil Adamski (adrian2608), this patch is not yet in 2.91 (or 2.90) so the issue is not yet fixed. It will be committed probably in the next few when the remaining issue in this patch is fixed. What I talked about in my previous message is an issue introduced in this patch, so it does not affect Blender currently. As for you new problem, either it is the same as the bug report or it is a new problem, I would need the file to know.

In D8401#205809, @Kévin Dietrich (kevindietrich) wrote:

@Kamil Adamski (adrian2608), this patch is not yet in 2.91 (or 2.90) so the issue is not yet fixed. It will be committed probably in the next few when the remaining issue in this patch is fixed. What I talked about in my previous message is an issue introduced in this patch, so it does not affect Blender currently. As for you new problem, either it is the same as the bug report or it is a new problem, I would need the file to know.

I believe the one which I already attached in the original bug report will have the same behaviour. But need to be tested rendered. So when You assume this patch will be in 2.91 alpha? Apologize for that type of question, but I really am standing against the wall...
Regards

Hi again,

I was trying to patch Blender yesterday, with no luck. Is this patch "patchable" for normal user like Me?
You mention Kevin that this will be commited in next few, but days, weeks? One more time apologize, but I'm using EmberGen for client work, and can't render the animation, because of this bug.

Regards,
Kamil.

In D8401#206500, @Kamil Adamski (adrian2608) wrote:

Hi again,

I was trying to patch Blender yesterday, with no luck. Is this patch "patchable" for normal user like Me?

The patch can be applied but has one remaining issue for final render where it crashes, it works in preview render though. If you can patch Blender, then you can use this other patch to try to render :

It is a hack but it works, here's a render from your bug report file :

Since the fire is not disappearing, I think this issue was the same as the bug.

You mention Kevin that this will be commited in next few, but days, weeks?

Sorry, I forgot a word, I meant the next few days.

@Kévin Dietrich (kevindietrich), I did some changes in blender-v2.90-release along with updates to this patch, which should ensure the OpenVDB grids are available when building the bounding mesh.

The volume smoke tests are stilling failing though. The dense -> sparse code seems like it wasn't tested, I did some work towards getting that functional but it's still not quite working, you can take it further from here.

The patch can be applied but has one remaining issue for final render where it crashes, it works in preview render though. If you can patch Blender, then you can use this other patch to try to render :

It is a hack but it works, here's a render from your bug report file :

Sadly it doesn't work, can You please help? Or maybe build it for Me with Optix? I really apologize, I know, that You have much more to work on, than this bug, and that You're not mentioned to build something for Artists Blender users, but I'm really in a bad situtation because of that bug.
I like better to know what I'm doing wrong, any help will be good. Really sorry, normally I will not ask for anything, but the client is pushing me as hell, to finish the animation.

That is what I get from the console (master branch)

C:\blender-git\blender>git apply <patch.diff

error: patch failed: intern/cycles/blender/blender_volume.cpp:265
error: intern/cycles/blender/blender_volume.cpp: patch does not apply

We may need to update the test images. However I noticed that the bounds are a bit larger now, which would be a bit worse for performance.

You can see this when you add e.g. a diffuse BSDF in the openvdb_smoke.blend test. There may be a logical reason for this, but it's not obvious to me from the code why the bounds should be larger?

I do use the diffuse BSDF trick, to see if the mesh is properly generated.

I cannot really explain the larger bounds, it depends what you are seeing/meaning. To me it seems fine. By comparing a quick smoke simulation (with resolution of 64) between master and this patch, they have about the same topology, give or take some leaf nodes introduced by padding.

The patch has more leaf nodes in some areas, master has some more in others (in the lower left in this image).

I would say that this OpenVDB approach is more accurate than my previous algorithm, at least for padding.

Perhaps the voxel dilation for padding is not right (though I do believe that iteration = 1, means only 1 voxel of dilation in every direction).

Or, you have a (color) grid which has information (value > volume_clipping) over the entire domain and it results in having leaf nodes everywhere so the bounds of the domain are the bounds of the OpenVDB grid, and adding padding then adds too big a buffer around the domain (then the fix would be for the fluid solver to premultiply the color based on the density field, I think).

Sorry I posted the comment too fast, but yeah, I see a few more leaf nodes in the openvdb_smoke.blend as compared to master, I'd say this is caused by the padding which is more accurate in this method.

Sorry for the spam, but I just realized, I am not using the volume clipping parameter for OpenVDB grids coming from Blender volume objects, maybe that's why padding is more aggressive.

Hi Kevin,

When do You think it will be in Master? Or can You share a working build?

In D8401#207619, @Kamil Adamski (adrian2608) wrote:

Hi Kevin,

When do You think it will be in Master? Or can You share a working build?

I cannot share a working build (maybe for Linux). However I have to update the patch because I forgot something, then the patch will be committed hopefully tomorrow or the next day, but for sure this week, as this fix is needed for the 2.90 release.

Works fine for me now.

Hi again,

So it's in master now?

@Kamil Adamski (adrian2608) yes it is in master now

Thank You for Your hard work Kevin, and Brecht :)
Best Regards