I have multiple VDBs in the same data stream, and I'd like to combine them all into one single VDB volume, as my source program (Vray/C4D) wants it like that.

I feel like this is a VOP/Wrangle situation, but I'm not sure how to accomplish what I'd like.

Thoughts?

Thanks!
Luke

Assuming they are all density vdb, you can use the combine vdb sop set to max or add. Use the option “merge all B into A”, and resample A to match B. Then connect an empty vdb into A, and your multiple vdb stream into B.

I think it's working, but I don't know for sure because my RAM climbs from 12 GB used to 64+, crashing all my programs before I get a result in the viewport. Probably Windows memory management?

It's weird too, because I was able to generate each of these meshes with a For/each setup easily under 16 GB of RAM for my whole system (even as I rendered out another project at the same time). But jeez, try to merge them together and the RAM goes through the roof.

I guess I'll just stick with multiple volumes in the data stream, and try to figure out a workaround…

Maybe one of your volumes is too high res for all of them to be that resolution. Try switching the resample setting to “Resample Highest to Lowest” to use the lowest common denominator as the shared resolution. You can also use “resample B to match A” and then explicitly set the resolution on the empty vdb used in the A input (disconnect the reference input if you are using my example).


Edit:

looking at the geometry info of you screenshot, one of the volumes has 4x the resolution, which would increase the number of active voxels by 64 times if you were to resample all of the volumes to that resolution.

Let me give some background, as that will help to explain go I got here:

The idea was to take the client's 3D text & run it through the cloud tool. However, when I fed the entire block of text through as one model, I either (A) ran out of 64 GB RAM in ~30-60 seconds, or (B) didn't get a quality result (dramatic aliasing around the text edges).

However, if I fed just a single letter through the cloud rig, I could get a much higher quality volume very quickly without breaking a sweat RAM wise (the performance monitor RAM graph barely budged, staying around 16 GB).

Since this was working well, I broke the text up into pieces using an Assemble node, and placed the cloud rig nodes within a For/Each block. This setup generated high quality volumes for each letter, and accomplished all I needed without hurting my RAM in the slightest.

I'll either be using the resulting VDBs by themselves in the final project, or I'll feed them into a DOPnet & to some sim work. In either case, it'd be convenient to merge all the VDBs into a single volume; though it appears that it's noticeably more RAM efficient to keep them as separate volumes.

Sample scene with different text:


With that in mind - when you say resolution, are you referring to the overall voxel quantity of a volume (perhaps due to a larger letter in the sequence) or are you referring to a volume that appears to have a smaller voxel size that results in a higher resolution mesh?

Since each volume is created using the same exact nodes, it just seems odd for one letter to come out with 4x higher resolution. Perhaps I just don't understand how the cloud rig is working under the hood.

Thanks for the help!
Luke

When I say resolution, I mean voxel size; the diameter of a voxel. One of your volumes has a much narrower pitch than the rest. The cloud rig would do this because it doesn't take voxel size as an argument. Instead it uses a max axis voxel count. If all your pieces are equally sized will produce the same result. However a smaller piece would end up with a much higher resolution as it stuffs the same number of voxels into a smaller space.

Ah, I understand now; must be that period between 2 and 0.

To remedy this, I went into the cloud rig, and changed the uniform sampling to ‘By Size’, adjusted the voxel size to .001, and got a result that is virtually identical to what I had previously:




I then combined them using the aforementioned technique - which worked successfully this time - but resulted in a much lower quality volume:




The numbers displayed in the node info panel look correct, but the result doesn't appear as good as I would expect.

check a Mantra render to see if the detail is really there and if it is then your 3d Texture limit res in Display Options/texture is killing your viewport fidelity.

There's no way to display a 3D texture with that much resolution in the viewport. The default max 3D texture size is 256^3, which is a small fraction of your volume's 4058 voxels along it's longest axis, that's why it looks bad in the scene viewer. If you have a lot of vram, you can try going to 512^3, but it probably won't look that much better.

aRtye
check a Mantra render to see if the detail is really there

DOH! Should have done that to begin with. Detail is all there.

I wouldn't recommend combining them, it's unnecessary and less flexible

Just separate your densities into multiple objects (one per object) if using hengine or export .vdb per density volume, can't imagine C4D having problem with that

tamte
export .vdb per density volume

Could you elaborate?

C4D doesn't natively work with volumes at all (much to many users chagrin) but 3rd party render engines offer varied kinds of support for VDBs. The Vray volume rendering is still in beta, so their volume importer still isn't totally up to snuff, and when I did a simple generic export of a VDB, only one of the volumes was actually recognized & rendered.

Not with H at the moment, just on the phone, but you can try following options :

- append blast SOP where group will be $F, Delete Nonselected
To just keep primitive whose number equals current frame
Then append ROP Output driver and export frames 0-10 for your 11 volume primitives

OR

- in per primitive Foreach SOP Loop you can use File Sop to export each primitive as vdb, just vary output name per iteration

OR

Depending on robustness of Hengine for C4D, which i haven't tried, following options may work:

- create object per each volume and objectmerge your geo into them, each object's object merge can have different group to get different volume
Package those objects including original into an asset and load in C4D

OR

- make asset that allows you to specify your text and enter index of the number
Keep just index-th letter and make cloud of it
Then in C4D use instance of this asset to create each letter, just specify the same text as input, just different index

Thanks for sharing these Tamte - the first two options are probably the most compatible of the ones mentioned.

The Hengine integration with C4D is developed by Maxon (not SideFx), and since there's no volume support natively in C4D, there's no volume integration whatsoever with HEngine in terms of rendering. So while an H-asset could make use of a volume for internal purposes, it can't do much beyond that.

And since the C4D/Vray integration (also developed by a 3rd party, rather than Maxon or Chaos Group) is still very primitive, I may end up just merging all the volumes anyway so that I only need a single volume object in my scene rather than a separate volume object for each letter (which just provides more opportunity for crashing and scene failure).

jsmack
ge all B i

thanks man It was useful. Combining multiple smoke sims reduced time to First pixel for Renderman from 90s to 50s for me + first pass was muuuuuuch quicker.