I have a smoke sim that flickers throughout and am trying to identify what will reduce it, so any suggestions?
As a side note I’m using Embergen, so I can in fact get a superb result by outputting frames from there to composite, although I
would like the option to use it as a vdb too.
At their default sim settings for this of maybe 4mil cells, the quality of the result is orders of magnitude better than an exported vray vdb with a much higher, around 40mil voxel count.
So, is there nothing that Vray can do to match that output? It seems odd that the quality is so drastically different. Reasons?
I’ve had to move on considering deadlines, so I just stuck with the rendered output from Embergen, as the quality is so far above what I could hope to get using Vray’s vdb, plus it’s so
lightning quick to render scores of millions of voxels that there’s simply no contest, so I deleted all the massive vdb files and can complete the project without issues.
If I have time in the next few days then I’ll create an example, though it should be pretty simple to test even with one of their presets I think.
I’m happy to be proved wrong but think the differences in how the two outputs are made means that there’ll be an inherent big mismatch between the two.
Okay, we managed to get very close results with some simple adjustments in the settings. We tested with the Small Campfire preset from here. What we did:
1. Imported the .vdb files into a VRayVolumeGrid (preset: none)
2. We manually adjusted the channel mappings (VolumeGrid > Input > Browse button in the Render Cache Path > 3rd Party channel mappings). We used Embergen’s density channel for Smoke and the flames channel for Fuel.
3. Next, in the Volumetric Options, under the Fire Rollout, we set the Fire to be based on Fuel and set the Physically Based parameter to 0 -- this is necessary for caches with low temperature (under 2000) such as the one in the sample.
4. We also remapped the fire’s range to be between 0 and 1 via the Remap Grid Channel Color and Intensity Curve Editor. Note that Embergen seems to have its own curves, which modify the results, so to get close results, you need to play around with the curves.
Attaching a video rendered in V-Ray and a screenshot from the sample for comparison.
If there’s still flickering on your end, it’s usually caused by the Volume Light Cache (Volumetric Render Settings > Smoke Color). Disabling it should resolve the issue, but rendering may become slower. embergen_vdb.7z (3.33 MB)
Looking at a quick test I just did, the culprit was definitely the volume light cache. This defaults to on and I assumed becasue of the slowdown warning that it’s meant as
an improvement, which for me isn’t the case.
I render progressive for the most part, and maybe it’s only meant for the bucket method it mentions, but
just having it on makes the render an unuseable quality, and putting in any other values than the default 0.9 makes it so slow
that it’s hard to see a use right now, though I’m sure I’m missing its purpose somehow.
Turning it off, however, not only sees an immediate 100x jump in quality but a speed that is just a few seconds, compared to the cache which takes 30 secs for a crappy low res crop.
I haven’t time to render a sequence to check for flicker but judging by the frame I don’t think it’ll suffer, as it was the cache method that created the little visible dots of the voxels.
So anyway, I have my solution when I need it, though I’ll still use Embergen’s output for now, as it contains more detail in small wispy parts
and is just quicker to render (first image is Embergen) for what I need at the moment.
The sims I’m doing are really very simple, so in relation to this:
‘‘In general, for lower-resolution simulations, the Volume Grid Light Cache will significantly speed up the rendering.’’
…it just isn’t the case with what I did. The sim was I think only 4mil voxels, so tiny relatively, no?
Regardless I thought to leave it at default and it didn’t work for me, while disabling it made the difference.
So it worked out in the end and I have multiple solutions for what I may need to do.
no, 4mil voxels is not tiny and, if you render progressive, it’s clear it needs turning off (we stop you from rendering and have you click the “ok” button on purpose.).
We’ll see if it makes more sense to have it off by default instead.
I think I just got spoiled by Embergen’s pretty effortless workflow with millions of voxels, with the render results being so smooth, quick and immediately tuneable
to my liking. I haven’t played much with vdbs using Vray so it caught me off guard a bit.
It’s an awesome app if what it does is what you need: if you want conserving fluids you’re out of luck, f.e., and you will need to resort to the tried and tested engines that will take their time to ensure their preservation.
They are wise to offload the complexities of fluid shading to third parties via VDB, as well: one thing is to make a viewport preview to look (even very) decent, another is to bounce light 100 times inside a volume (i.e. a strongly divergent task.).
Which is what pushed into creating the volume lightcache in the first place, long before we had probabilistic volume shading that mostly made it redundant.
I’ve asked, no plans on changing anything currently, there will be bigger changes further down the line (but i have no ETA) which will help with that part.
As a general rule, if you want to match the likes of Embergen, for looks and to a degree for speed, you’ll need to severely restrain the default way V-Ray would like to go about fluid rendering, to make it more similar to that of realtime apps.
So, low to no GI bounces, low to no bounce count inside the volume, emissive or very dense volumes will work the quickest.
Likewise, the use of point lights (no area or Domelights) and very well delimited volume field will lead to major speedups.
Yeah I’ve enjoyed using it, especially for this project, as it’s exactly the sort of thing I need - not super-real, just indicative yet good looking.
Mostly I wanted quick and simple and that’s what I got.
I was initially worried about collisions and other stuff, meaning the workflow would be a hassle, but it’s just not - it had no issues with complex geo, the camera import works fine.
