Hello. I downloaded few examples of VDB animation sequences from free downloads to test my renderer and all of them could not be loaded using latest OpenVDB 7.1.0. Then I installed latest version of EmberGen beta, exported animation from one of examples with compression checked off and this still cannot be loaded!
The OpenVDB library sends exception when reading metadata “file_delayed_load”. The wrong thing is in the BLOSC processing.
The examples from openvdb.org are all OK - I can read them and render.
Line 179 of DelayedMetadata.cc
compression::bloscDecompress(reinterpret_cast<char*>(mMask.data()), count*sizeof(MaskType), mMask.capacity()*sizeof(MaskType), compressedBuffer.get());
The exception message says: RuntimeError: Expected to decompress 144 bytes, got 18446744073709551611 bytes
Thank you for this report. I will have a look and see if this is something breaking about for the latest OpenVDB, or if it’s something deeper. We haven’t had any similar issues with other DCCs yet, so this is a bit surprising.
It seems a bit strange that it complains about blosc when compression is off?
I’ll get back to you after some more testing later this week.
So I have tried reproducing this.
I manually compiled the latest commit (5056f85726cca1d63e1960f16e83079408a00d57), i.e. version 7.1.1, from the OpenVDB Github repository as per their instructions for Windows and wrote a simple program to load some VDB files. I tried exporting a snapshot from the latest EmberGen version, i.e. version 0.5.5.2, with and without compression, and I exported only density and flames, which was the default settings. I also tried a snapshot from our “Simple Fire” preset on our website.
They all read fine without any issues, and from what I can tell there’s no unhandled exceptions either if I try running it through a debugger and making sure it’s set to break on any exception.
You can find my files setup here if you want to cross-check: https://cdn.discordapp.com/attachments/366731224116363264/748161749051506718/vdb_7_1_1.zip
As long you have a 64-bit command prompt in Windows you should be able to use the build.bat script and hopefully have it just work.
One thing I noticed was that during compilation of OpenVDB it fired a suspicious warning about Blosc version differences:
– Found Blosc: Z:/JangaFX/vcpkg/installed/x64-windows/debug/lib/blosc.lib (found suitable version “1.18.1”, minimum required is “1.5.0”)
CMake Warning at openvdb/CMakeLists.txt:89 (message):
The version of Blosc located is greater than 1.5.0. There have been
reported issues with using later versions of Blosc with OpenVDB. OpenVDB
has been tested fully against Blosc 1.5.0, it is recommended that you use
this version where possible.
Which version of Blosc have you been using?
Hmm, I realize I’m not actually decoding anything here, so I’ll give that a try.
I use this version of BLOSC:
#define BLOSC_VERSION_MAJOR 1 /* for major interface/format changes /
#define BLOSC_VERSION_MINOR 20 / for minor interface/format changes /
#define BLOSC_VERSION_RELEASE 1 / for tweaks, bug-fixes, or development */
#define BLOSC_VERSION_STRING “1.20.1.dev” /* string version. Sync with above! /
#define BLOSC_VERSION_REVISION “Rev” / revision version /
#define BLOSC_VERSION_DATE “Date:: 2020-07-25 #” / date version */
#define BLOSCLZ_VERSION_STRING “2.3.0” /* the internal compressor version */
The exception is for metadata with
name==“file_delayed_load”
typeName=="__delayedload"
Even for the file WITHOUT blosc from your archive, the blosc decompressor is executing for this metadata.
The compression type is BLOSC_LZ4_FORMAT
Unfortunately, my version of sources were compiled without this support (only the standard BLOSC_BLOSCLZ_FORMAT was enabled by default).
I will try to enable this LZ4.
Finally, I am able to read OpenVDB files with extended compression. Thank you for your response!
One question about values: the Fire Tornado example contains temperature values in range [0, ~37000].
If I use this as input to BlackBody radiation, it generates ultraviolet that is outside of CIE range. So what is the physical units in this channel?
Just to be clear, the goal of EmberGen is not the be physically correct in all aspects, and a lot of physical correctness is sacrificed in favor of being able to author and tweak effects to artists’ liking. The built-in blackbody function is sort of based on a discretization of Planck’s law with fixed frequencies for the R-G-B triplets, but it’s fudged by some scaling factors. The fire (and smoke) colors can also be overridde by arbitrary gradients that map temperatures or densities to colors.
The built in blackbody function could be summarized as:
vec3 blackbody_color(float temperature)
{
// Based on Planck's law for the frequencies of 400, 600 and 800 THz
float T = min(color_max_temp, color_temp_adj * temperature);
float A = 11.0 / 750000.0; // 2 * (1e9) * (6.6e-34) * (1e12)^3 / (3e8)^2
float B = 330.0 / 7.0; // (6.6e-34) * (1e12) / (1.4e-23)
vec3 f = vec3(400.0, 600.0, 800.0);
return blackbody_intensity * A * (f * f * f) / (exp(B * f / T) - 1.0);
}
The way the combustion works also isn’t entirely based on chemistry and physics, but is a simple approximation. It could technically result in unbounded temperatures locally, but likely the temperature cools quite quickly to never let it get too hot.