Hello there!
I’m having an issue whith VDB export (around 2000 frames) on my current project for a client, I could export my VDB sequence but only partially, at some point I have an error message “An error occured when trying to export the VDB: Make sure the export filepath is valid and that the file is not open in another application”.
Of course the filepath is valid and the file is not opened in another application.
I tried to render again, shutting down all other app (discord, web browsers, etc) just in case but it can’t save the VDB sequence from the start now.
I tried to export a vdb sequence from the default fire scene, it works but it creates 0Kb files and at some points, when I type a large number of frame to be computed, the render crashes with the same error message.
Thinking of a RAM issue (icore i9 + 4090 RTX GPU) I started my computer again to empty the cache but the issue is still there. While running my scene in Embergen, it barrely uses 50% of the GPU.
Do you have any idea what could cause this issue?
Here is the image of the error:
Please don’t mind my error, I misread the availble space on my had drives 
Let’s transform this topic, I edited the title, is there a way to use the compression option when exporting the VDBs like we had in the earlier version of Embergen?
Or is there a way to export at 24Hz instead of 48Hz, as example to make the files leass heavy?
I tried the Frame stride option set to 2 but it expands trumenduously the size of each frame of the vdb, is that a normal behaviour?
We have been talking about a new compression scheme for EmberGen 2.0 but no real traction on that internally yet but i’ve added a card for it here on our roadmap: https://jangafx.com/roadmap?feature=979d0dac-e526-48d4-88d4-9f59572690b7
Feel free to go upvote on that and if you have a JangaFX account, feel free to share your thoughts on that feature directly by submitting a comment on it.
I don’t think the Hz value or frame stride aren’t what is impacting the size of your VDBs. My guess is that your simulation is continuously emitting, and when you’re using a Frame stride of 2 this is increasing the amount of time that the simulation is running. Specifically, it is doubling the runtime of the simulation but only taking 1 out of every 2 frames. You can test this by setting the frame stride to 1 and then exporting twice as many frames. You should end up seeing VDB files that are similarly (if not exactly) as big towards the end
