OpenVDB read into Bifrost extension Channels not showing

[steve]

OpenVDB read into Bifrost extension - from sample OpenVDB and Embergen export sample not showing temperature channels

Hi all - I have been importing openVDB files that deffo have temperature, density, flame etc from different sources into Maya Bifrost extension and the only channel that I see is denisty. Opening a watchpoint on the Open VDB node only shows ‘size’. Is there another step that i should be looking at, remapping channels option seems to have no effect. But.. writing an OpenVDB and the reading in has all the correct channels. Is it a channel naming issue - if so is there a way to interrogate the VDB to see what channels are in the file.

Working on 2020 with Mac OSX 

[steve]

Hi all - I have been importing openVDB files that deffo have temperature, density, flame etc from different sources into Maya Bifrost extension and the only channel that I see is denisty. Opening a watchpoint on the Open VDB node only shows ‘size’. Is there another step that i should be looking at, remapping channels option seems to have no effect. But.. writing an OpenVDB and the reading in has all the correct channels. Is it a channel naming issue - if so is there a way to interrogate the VDB to see what channels are in the file.

Working on 2020 with Mac OSX 

[morten.bojsen-hansen]

The reason you are only seeing 'size' is because the output from read_OpenVDB is an array (i.e. a list of volumes, in this case a list with size one). You can just first_in_array to extract the first (and only) volume. Then you should be able to use watchpoints to see which properties exist on the volume.

[steve]

Thats excellent - i will try this, explains a lot thanks. Thanks you so much.

[steve]

I can now see the channels if I take each channel out. But some VDB volumes have all the channels in one array and some have separate arrays. Is this common? Is there a way to merge? all those openVDB arrays into an output that would have all the values in one channel?

This is what I have done so far - just seems awkward that some have all the channels in one array - and other software 'Embergen' seems to have each channel in a separate array. I'm obv confused about this. And help most appreciated.

[steve]

Unless of course I just connect them to the output?

[calibrix · Accepted solution]

Not sure if this works for object arrays containing volumes, but you could try the merge_geometry node. That should combine an object array into a single object.

[steve]

Ok - there's a merge volumes node and this exposed the channels in the watchpoint - unusual. Yes this is what i have to do with the OpenVDB demo fire. If i saved a vdb out it would work ok im sure - i shall try

[steve]

Yes its true. Sometimes I need to merge volumes, sometimes I don't how odd so I assume it looks like the following. At least I understand - its odd

 

[morten.bojsen-hansen]

That probably has something to do with whether you saved the VDB with Bifrost or some other package like Houdini. If you saved the VDB with Bifrost, when you load it back in everything will be in the same volume (your first picture).

[steve]

Yes - thats what I’m finding ... but why? I assume that the OpenVDB specification has something about this nut i cant find out how to read a header in the file to show number of grids, volumes names and so on. Just seems weird that there isn’t some sort of standard.

Thanks for the info though - i will look deeper into the file structure and if its the compression method.

Regards

[morten.bojsen-hansen · Accepted solution]

The reason for the difference is that Bifrost volumes and OpenVDB grids tend to work a bit differently. When you are using e.g. read_OpenVDB in Bifrost, the output is not actually a VDB grid but rather a VDB grid converted to a Bifrost volume. This is not a lossless step, which is why we would always recommend using our native format by using e.g. write_Bifrost_object if you plan to stay entirely within the Bifrost ecosystem.

OpenVDB grids tend to all have their own "topology" (i.e. voxel structure) whereas Bifrost volumes tend to share their topology. When you write a Bifrost volume to a VDB file, we write metadata to recover this grouping of voxel properties into Bifrost volumes. If you try to read in a volume written by another package, it will not have this metadata and so we have to assume that the VDB grids do not share topology and that's why we load them in as separate volumes.

Note, you can always use merge_volumes if you prefer to have all the voxel properties in one Bifrost volume. Just note that this can require more voxels to be allocated and thus increase your memory usage, especially if you merge narrow-band level sets with fog volumes or vector fieds.

[steve]

Excellent stuff. I see now thanks. Other packages don’t seem to need that metadata - but thats great.

Sorted now thanks.

You could have a tick box i guess to allow straight forward input - but no thats great thanks