Seems like .vdb can do upres and restore - possible to use it by default with a preference?

[joconnell]

Hi folks!

We'll render vdb files made with phoenix in a lot of different apps so we'll have to use .vdb files for this. It seems like it supports both wavelet upres / resim and also the restore function to restart sims. I presume .aur has some benefits on things like size but we'd be better served with flexibility. Is there a preference we can set to always sim to vdb?

Just on a side note, the backup interval seems to be slightly offset in the 3.11.04 nightly I'm using - my scene starts at frame 1001 and with a backup interval of 15 I get a resim cache at frame 1005, 1020, 1035 and so on rather than 1001, 1015, 1030 - no biggy but just reporting it! Likewise the various toolbar presets are using the old method of making scene scale smaller for bigger sims rather than larger with the new ui controls!

[joconnell]

Ah, on a simple upres test just for speed, .aur comes out 4 times quicker on our network for the same settings

I know we've had some major speed increases internally by tweaking some of the settings in exocortex crate for alembic, I wonder are there similar gains to be found with vdb?

[joconnell]

So I just had a brief look at post conversion too, doing a conversion on a local disk or in a network folder seems to be only a few seconds a frame regardless of where the files reside so it's definitely the way to go. I notice a slight discrepancy in size between the two though with the post converted vdb being a tiny bit smaller - is there anything in the method of compression / saving between the sim saving and post conversion saving that'd account for the massive difference in speed?

[Svetlin.Nikolov]

Ah, will check the difference with high priority.

Otherwise, the differences between aur and vdb are the lossy aur compression that allows caches to be loaded faster. Also operating with aur caches is faster than vdbs because of some overhead related to the layout of sparse grids in the vdb library. Thus vdb is good for rendering huge sparse data in the viscinity of tens or hundreds of billions of voxels but aur is faster for rendering everyday caches in the tens or hundreds of millions voxels.

Will think about a quick preference for the output format, this has been bugging me for a while so there are already a few requirements for how it woild work...

Cheers!

[joconnell]

Fume used to do it in it's preferences ini which were a bit fiddly when you wanted to sim on a network machine that wasn't opening the max ui, could we have that preference saved in the object as well as whatever default you save so we can set locally and the render farm machines respect it?

We got network simming working in here if the output is using a hard coded path rather than macro, I've to do the same with network rendering of a phoenix grid (I'd to use a volume grid instead last time) so it'd be great to have the new instancing support and see can we swing all the rendering over to the vray side!

[Svetlin.Nikolov]

Ah yes, the macros expand to the directory and name of the scene, so as per https://docs.chaosgroup.com/display/...eSmoke+Output:

$(scene_path)

becomes

$(dir)\$(scene)_Phoenix_frames\$(nodename)_####.au r

This way a default scene sent for network sim cannot find its caches when it gets copied because the Phoenix caches are not registered into the asset tracker yet and do not arrive at the network machine where the scene executes from.

[joconnell]

Plus we pre process our files and make a temp version when they get sent to the farm as part of our layers system so the $(scene_path) thing is screwed for us either way. For what we're doing right now though we'll always be using single frame files and likely manually loaded so it's not too much of an issue. Just checking here but it seems like the latest nightly's .aur cache files won't render or preview in the vray 3.6 volume grid - just did a quick sim here and 3.05 output is fine and previews immediately on load, 3.11.04 will set the right boundary box in the volume grid but it won't make any voxel data visible in the viewports or renderable!

[joconnell]

Further to that, the shader diagram of the volume grid is picking up what seems like a normal 0 - 1 range for smoke data but if you use the auto range feature in the preview section it's setting it to max 0.00 min 0.0001!

[Svetlin.Nikolov]

Oh yes - it's very important to grab a latest stable nightly of V-Ray 3.6 - compatibility with older aur files is there, an important compatibility change for ffx5's vdb adaptive grid transforms is there, and a few important vrscene export changes and fixes as well. The V-Ray guys will soon have new official 3.6 builds on the website with these fixes.

Does Phoenix 3.11 have the same auto-range issue as the VVG? It's possible that we didn't backport a fix or a change and this causes it...

Cheers!

[joconnell]

Yeah it's the newer 3.11 caches causing all the probs in vray 3.60.04 vvg, the 3.05 caches are fine. We've a bit more to do on this side, I don't think we have 3.11 phoenix grids (with their lovely instancing) rendering on the farm but again our setup is bananas - more testing today!

[joconnell]

Here ya go:

Left side is a sim in the 3.05 phoenix grid and in the 3.60.04 grid in front of it, then a 3.11 phx grid on the right and the same cache in the 3.60.04 vvg - in both cases I've used the explosion shelf preset and saved whatever render preset was on the phx grid and applies that to it's matching vvg. The modify panel is showing the 3.11.04 cache loaded into a 3.60.04 vvg and it seems like auto range is okay here, not sure what caused the issue on my last one!

[joconnell]

Selfishly, do you think the volume instancing will make it back into the 3.6 builds?

[Svetlin.Nikolov]

Ah, sorry, maybe I didn't explain this right - you must get a latest vray 3.6 stable nightly - 3.60.04 does not have the support for the new aur cache format, only the stable nightlies do.

It really is not realistic to backport volume instancing to vray 3 I'm afraid - there are too many drastic architectural changes that made it possible. The time it would take should better be invested in fixing and implementing.

[joconnell]

That's another entry into the case for vray 4 column