PhoenixFD + Vray issues

VrayNext + Phoenix:

1. When rendering Phoenix in volumetric mode, a frame takes about 3 minutes, see attached screenshots. But it doesn’t work with Vray atmospheric fog, doesn’t produce zdepth or other useful channels to tweak it’s color to fit the foggy environment in post production.
2. When turning volumetric geometry on and setting relatively low (150) transparency levels in vray, the same frame takes more than an hour on i9 7940x and 128gb ram. Actually it seems it takes day per frame, so I couldn’t wait till over of rendering.

This way I am in serious trouble, because there is no way to extract zdepth or anything from volumetric render mode (zdepth is just plain white on phoenix objects). I can’t afford for rendertimes skyrocket tenfold because of switching into volumetric geo mode only to have proper fog occlusion, or zdepth required to create fog in post.
Can we expect for better integration of vray with phoenix? Or at least some phoenix render elements as PhoenixZdepth/PhoenixSmoke etc (as in fumefx)?
Is there any workaround to resolve this problem? Right now I am in a very unpleasant situation - hoping for devs to implement something or “hotfix” to be able to continue work isn’t the realistic idea. Switching to other plugin or renderer - not possible at this stage of film development. What solution do you propose, guys?

(I also wrote to vray support with the same issue)



Hey,

Let’s start with all your Phoenix and V-Ray rendering settings. Before talking about improving integration, let’s make sure your settings are optimal.

Thank you!

Apart from the Rendering rollout and all Volumetric Options, since you are rendering with Progressive, it’s very important to know if you are using Phoenix’s ‘Use Probabilistic Shading’ in the Phoenix atmosphere settings, and how many subdivs you use there.

Of course I use Probalistic shading with extremelly low settings in order to speed up things: Samples: 2, GI Samples 4. It helps with volumetric render times (3 mins) but not with volumetric geometry render times (above hour or more)

Convert to vdb and render with fume, if the speed is THAT important… Btw, what happens if you lo render steps?

For some caches turning off Phoenix’s Light cache option speeds things up. Note that when using V-Ray progressive rendering, if the Phoenix Light cache is on it might slow down rendering startup or the overall render speed.

There is something specific to that setup that causes such a huge difference in render times. If you create a large smoke preset in a new scene, you will see that the difference is less than two times slower in volumetric geometry. We gotta deconstruct the scene and find what is causing the slowdown.

Start turning off important options in order to isolate what causes the slowdown. At first, please compare rendering only the smoke without any other geometry in the scene and without the aerial perspective, but with the same lighting. Is the huge difference still there? After that, you could also try disabling all lights and adding just a sun; leaving the entire scene as it is and disabling only the aerial perspective; disabling all lights and using just a sun with all the geometry and the aerial perspective. And finally, reset the V-Ray settings to default and comparing volumetric vs vol. geom.

This would be the process of pinning down exactly which component causes the issue, because it’s not there in a simple scene.

Have no problems at all…
geovol.rar (57.1 KB)

It might be possible to work around the issue, or it might need a change in the code, but first we have to narrow down on the factors that cause it so we’d know where to look at. If you can route the scene through Support to us, we’d be able to profile it and see what is taking so long, or if you can try to simplify it yourself, it would help us reproduce the slowdown here as well.

Okay, I will try to pin down the issue and send you the lightest scene possible that still causes the problem. The cache files are around 400mb in total per frame (4 grids with the same settings each)
Best,

After 4 hours of testing I was able to narrow down the problem to shadows type and opacity of the smoke in volumetric geometry mode. Also, two grids rendered at once in volumetric geometry mode makes render time skyrocket out of proportion. But lets start from scratch, render times visible at the vray frame buffer’s lower bar:

1. 1st render is without phoenix at all. Very good quality as for full hd 1 minute render time, 25 millions polygons, Forest Pack, Railclone, xmesh caches and stuff…

2. Turning on Phoenix with volumetric mode, with Aerial perspective on. No fading of smoke over distance and no zdepth extraction possible. Of coures slower, its expected, goes up from 1 minute to 5 minutes due to volumetrics involved.

3. Aerial perspective off with the same settings. Almost the same, 5 mins.

4. Deleting all objects from scene except phoenix grids and turning off GI. Now, instead of 5 mins we have 2 mins. With 25mil polys off and GI turned off it is normal speedup:

5. Now turning on Volumetric Geometry mode with exactly the same settings as above. Render time goes unnaturally apeshit, up to infinity (waited 30 mins and stopped it).

6. Turning off the sun at all. Big improvement - about 1 minute only, but no visible smoke.

6.5 Rendering every grid solo gives you normal render times (~2 mins each grid). Only after unhiding more than one grid, the render times go back to hour or more.

7. Deleting sun and inserting new Direct light with VrayShadowMap. Render and smoke is ugly, but mutliple grids’ time gets back to reality - 1 minute.

8. Conclusion: After more testing - increasing opacity cutoff threshold in vray settings to 0.2 (unrealistic and flicking smoke) decreases render time into 2-3 minutes range. As same as lowering opacity levels to crude 1 (!) in vray, but the look is full of artifacts then, useless.

Changing opacity curve for smoke to less transparent seems to help, slightly. Vray sun or Vray Shadows (except ShadowMap) existence doesn’t allow for fast render times at all, it has something to do with raytraced shadows and low opacity voxels. The scene geometry is not important in here, vray aerial perspective is not important either. Of course with two grids in scene already long rendertimes stretch even more, up to 6 hours… In this simple, empty scene with quite standard grids. Rendering any of the grids as solo (isolated) gives about 1min rendertime per grid, which is normal. But try to unhide 2 grids on-screen (overlaping or not) and time goes to 6 hours or more.

Any ideas? I can’t go forward or backward here, one day wasted right now and deadlines looming…

Thank you for the very detailed report! Does the VFB say estimated 0:00 at step 5 throughout the render? Does the progress bar not start moving at all?

Just upload empty scene. Will link my own caches.

Yes it doesn’t move at all. Sometimes it “catches” after one hour or so, but it goes one step more and another hour of work. But in general, if it doesn’t start after 15 minutes I cancel render…

And by the way - I rendered the smoke in Vray GPU with Aerial Perspective on… And it works well, even in volumetric mode. Lighting is different, so no direct compositing of GPU smoke with CPU city is possible.Too bad that GPU doesn’t like multiple 16k textures (128GB cpu ram vs 8GB gpu ram), because it would be the way to go. This is the first time that vray GPU has the feature that CPU doesn’t.

Yup, we are working on render elements for V-Ray GPU which will make the entire volumetric geometry thing obsolete one day.

I replicated all V-Ray settings visible in the screenshots, with GI off, and now render times with my caches are roughly proportional - 1 grid for 5 minutes, 3 grids for 18 minutes, but the progress bar manages to start filling up here.

Something else that I can think of would be that maybe there is something wrong with the opacity - can you check if setting all grids in simple smoke makes any difference? I can’t see the bottom of the smoke curve, but is the first leftmost point at 0,0? If so, can you try to move it a tiny bit to the right? On some CPUs this will add a small error and add some opacity in voxels where there isn’t any, so this might cause a slowdown.

If this doesn’t reveal any useful information, then the final thing I can ask about is what Paul said - please send over the scene in the state of point (5) - with just the simulators, and only one cache for that frame. You can also send it over to [my forum name] at chaosgroup dot com and I will see what you can do to work around this and catch your deadlines.

Cheers!

Okay, I am sending you a wetransfer with the scene (125kb) and with 4 grids cache single frames. Scene starts at frame 100, some caches have different timeline origin so don’t freak out - it should work just after loading. There are total 4 grids and the sun. Try to render it as it loaded, with current camera view. What I get now is render bar starts, but it is very slow in relation to what is visible onscreen (small puffs of smoke). Then switch to volumetric mode and see how fast it is. Then switch to volumetric geometry back, you can hide some grids and start testing on a heaviest grid (middle one). Higher opacities threshold render faster (“Minimum visible opacity” parameter works as expected) but it still doesn’t solve the problem. I need very thin smoke for real look :slight_smile:

Isn’t there an easy way to add zdepth element to volumetric mode as well as PhoenixFD element? It would solve all problems. FumeFx has this possibility, so I think it is possible to implement in phoenix as well.
best,
norman

One more thing: Just decreased the resolution to 320x180 to see if there is any improvement. Not really - the progress bar doesnt show up and rendertimes are still absurd for this resolution and content… I’ve canceled after 15 minutes. Your scene should look like this:

--------------------------------------
EDIT: This 320x180 render with volumetric geo on is still rendering after 1hour and 30min now. It is unbelievable. You should test this scene for sure.

Got the files and started experimenting with the scene as well. One of the simulators was in resimulation mode so the cache did not match, but I’m using the ‘newpc_corr’ cache in place of the LQ cache.

It should not be very hard to implement zdepth, but it won’t happen in a day or a week, so gotta figure what’s wrong ASAP and send you a workaround.

Will ping you as soon as I find anything!

Okay, here’s a thing I found - disable the Phoenix Light Cache for all Phoenix simulators - right now 2 of the 4 sims have it enabled. There is a warning message about using progressive sampler + Phoenix light cache but you might have muted it and forgotten about it.