Hi there
I am exporting vdb files of an explosion to blender. When I change the scale in the export node size unit controls from milimeters to centimeters or even to meters and re-export all three the sets of files look identical when imported into Blender - I would have expected a 10x scale difference between each one. Am I misunderstanding what this units control is for? Or is it broken?
thanks
I just found this old topic on this forum dated May 20 -
where Nick says that the vdbs sent to blender are “huge” and says it might be a bug.
The OP also says upscaling changes the scale again - I’m in the process of testing this.
It’s sort of a big deal as it is making it extremely difficult to match camera moves between blender and embergen. This sort of scaling issue is not uncommon with fbx (usually 10% or 1%) and most softwares have an option to rescale when importing/exporting which is what I assumed the unit length was for. Or am I just using it wrong?
Further info - although upscaling x2 doesn’t change the overall size at all in Embergen it does change the size of the exported vdb file, scaling it up by x2. This put most of my sim beyond the camera clipping planes of blender (already set at 6000 metres!) and confused me no end. It also makes using embergen for the sim render a bit tricky as what you are seeing in blender when you animate the camera isn’t what you will see in embergen. Changing the unit size in the export node seems to have no effect on the upscaled vdbs either.
Hopefully this info will be of some help in tracking it down. My next step will be to import the camera move back into embergen and see if the embergen render matches the default view (no x2 scaling) or the blender render (scaled up x2).
I think that all of this is still broken. Scales definitely don’t match yet and our VDB integration does some weird things. Upscaling keeps the same bounds size and merely adds more voxel detail.
Following a tutorial like this for rendering in embergen for compositing may be of better use for now: EmberGen Tutorial: Creating a Live Action Torch Shot with Animated Meshes and Camera Imports - YouTube
Hi Nick
Many thanks for the quick reply!
" Upscaling keeps the same bounds size and merely adds more voxel detail"
As per my post I do understand this - what I am saying is that this is how it behaves inside Emgergen which is fine, but when you export the upscaled .vdb file to Blender the size has been scaled by the upscaling factor. And if the size is already huge then this is not good as in Blender you run into all sorts of camera clipping and render sampling issues. Fortunately the size displayed in Embergen is the “non-upscaled” size so you can get around it by scaling down in Blender (and presumably in Maya, Houdini etc). In my case (2x upscaling) I scaled the .vdb down to .5 and it seemed to work in that the size and position seemed to match up to the embergen one. So I can work around it for now.
The fact that the size units scaling in the vdb export mode (millimetres, centimetres, meters etc) doesn’t work is, however, is a bigger issue. I have watched the excellent Tutorial you refer to a few times and useful though it was it doesn’t really help. In the tutorial he eye matches the positions using the global transform controls and even in the tutorial I believe he says it’s pretty difficult as you have only one viewport in Embergen and have to keep going between default view and the camera view to do this. It gets even more difficult with large scale vdb files and files I am using are exporting as massive vdbs.
I have been testing the camera import/export pipeline as I was hoping to use Embergen renders in a large vfx project that is just now going into post and this scaling problem makes it very difficult to make sure the camera matches for the large scale explosions that I am developing. I need to work out a reliable fbx export pipeline for camera moves to make this work. I can try and figure out a work around but do you have idea when this might be resolved at the Embergen end?
Thanks again.
Removed the double post 
Regardless, we hope to have this fixed in our next cycle dev cycle… so probably for a march/april release is my personal goal of when I want us to get this done, but there’s a lot of things riding on getting this fixed so I don’t know if we can fix it that quickly. Just know that it’s one of our top priorities as it’s the biggest workflow hinderance we currently face.
Thanks, good to know. Let me know if there’s any tests or whatever I can run to help. In the meantime I’ll try and find a work around.
More bad news, I’m afraid - just to let you know, the “set floor to 0,0,0” option in exportVDB controls also seems to be broken. The exported vdbs seem to have the origin (0,0,0) set to the centre of the volume boundaries, not the bottom centre, so the boundary box is half above and half below the floor plane. I assume this also means that the vertical position will change with different boundary box heights making it even more difficult to co-ordinate a camera move with multiple simulations coming from multiple embergen files as each sim will have its own “floor” location. This seems to happen whether the “set floor” option is ticked or not - my exported vdbs seem identical so it looks like that option doesn’t do anything either.