Best Practices for Clouds

[Joelaff]

We are about to embark on a project involving a lot of clouds. For the most parts the clouds are static volumes generated with Phoenix.

I am wondering if we should be getting faster rendering results with PhoenixFD or with VRayVolumeGrid.

We are finding the previews are pretty slow with either method. The viewport slows way down when multiple grids are added, even if the detail reduction is set to drastically simplify the preview.

Turning off the bounding box (or at least the grid resolution ticks) helps.

GPU preview would be nice, but may be too slow anyway.

Also, what version of Phoenix would you suggest? We are on the release version right now, but could update to something later.

I noticed the PhoenixFDTextmap does not seem to let me select a VRayVolumeGrid. So if we need that to do any displacement we might have to use PhoenixSmoke/Fire nodes instead of VolumeGrids. Of course displacement may be too slow to render anyway.

VolumeGrids seem faster in the viewport, but the main thing that slows things down is keeping the settings tab selected in the command panel. This makes selecting either note VERY slow. Considering how slow these things are in the viewport I am temped to export a scaled down mesh and import that as a proxy.

Is there any way to decimate a grid with distance, like a LOD effect short of having separate grids for distant clouds?

Any hint/tips appreciated. Thanks.

[squintnic]

also interested here
from what i ahve read its faster for them to be loaded into Volume Grids as .AUR vs a .VBD if you are using ones coming from Houdini

this script we made for a job with clouds in vray a few years ago might be useful for mass select operations
https://www.dropbox.com/s/qdjzbembcg...dtools.ms?dl=0

there is also some good ways of scattering them with tyflow, but id need to dig back thopugh my example files




some threads of mine (trying to work with clouds and volumes (going back 4 years now lol) - some of these issues have been fixed since but these jobs ended up with volume passes in redshift and using a compositing approach

https://forums.chaosgroup.com/forum/...to-speed-it-up
https://forums.chaosgroup.com/forum/...sparency-issue

[Joelaff]

Thanks! Will check this out.

[Svetlin.Nikolov]

Hey, we are setting up a scene with many grid so we can see if there is something we can optimize.

Indeed selecting the VolumeGrid is quicker than the Simulator because 3ds Max cannot create all the controls the Simulator has that fast.

Otherwise, everything else is exactly the same between the VolumeGrid and the Simulator, except for one default value - the Use Probabilistic Shading option in the Atmosphere settings.

As for the version - grab the latest nightly, it's working correctly as far as we know. Older versions are by definition slower.

There is no viewport LOD for simulators or volume grids, apart from the reduction control.

Will check if it would be possible to pick a VolumeGrid in the Grid Texture, but most likely the answer will be NO, because you can install any combination of Phoenix and V-Ray versions and if they mismatch and something gets added, the result will most likely be a crash.

Will get back to you with any news on viewport optimization. If you have a scene you are using for testing, please do share so we'd not be working on something you don't need.

Cheers!

[Joelaff]

Thanks for the reply.

Will get the latest nightly.

We have been playing with reducing the samples in probabilistic shading to 8 and 1 for gi. Not seeing a lot of drawbacks.

Finding that vedenoiser, the standalone denoiser, works very well and can even let us increase the light cache speed up. This generally looks bad above 0.4 or so, but you can get away with more with the denoiser. This softens the image only somewhat, but seems to help such that we can get away with the linear sampler, even though the spherical is nicer.

With static clouds (direct cache index) and moving camera we don’t seem to be getting any additional artifacts from the volume light cache other than the usual noise it causes. This is excellent because the volume light cache speeds it up a ton.

Dome lights are terribly slow compared with VRayAmbientLight, which gives a nice result for obtaining very white clouds. The shot requires very bright white clouds. I was amazed at how slow one dome light (with a sun) made it, adaptive sampling on the dome on or off.

For a test scene I just instanced the same volume grid about 10 times. Seemed like it shouldn’t have been heavy. But was very Slow.

The aur files are over the network. Does Phoenix need to stat() those frequently or something? Even when not changing frames?

[Joelaff]

Cheers to you guys on the latest nightly! Now the viewport performance seems MUCH improved vs the release. Testing rendering speed now.

(Or perhaps it was that I second copy of Max running in the BG. Sometimes that will have no effect, but sometimes it seems to slow both copies down to a crawl.)

But cheers either way!

[Svetlin.Nikolov]

Hey,

Once the aur cache is loaded, Phoenix does need to query the cache file unless the frame or some options change (eg. Time Bend settings).

Dome lights are the slowest light that could possibly exist because rays come in from all around, while ambient is the quickest because... it has not direction whatsoever

I think I know what's causing the slow viewport despite the auto reduction. Will think about how I can change the auto reduction algorithm to make this better and will ping you. I'm on in right now.

Cheers!

[Joelaff]

Hey,

Dome lights are the slowest light that could possibly exist because rays come in from all around, while ambient is the quickest because... it has not direction whatsoever

No doubt. That was why I switched.

I think I know what's causing the slow viewport despite the auto reduction. Will think about how I can change the auto reduction algorithm to make this better and will ping you. I'm on in right now.

Amazing, Thanks.

[Joelaff]

Oh, the other thing that would be useful is if we could get the GPU preview in all views, not just the selected view. Or the ability to have the triangles preview in all the other views with the GPU preview in the active view.

Thanks,

[Svetlin.Nikolov]

For the first one, maybe you mean the Active View Only option near the top of the Preview rollout?

[Joelaff]

For the first one, maybe you mean the Active View Only option near the top of the Preview rollout?

I mean that, but for GPU Preview. I could never get the CPU Preview (the more realistic one, not the triangles) to show up in all four views. It only shows in the selected view. In fact, right now it seems have a bug where the previews have disappeared completely.

I thought maybe it had to do with the Grids being instances, but when I deinstanced them all the GPU previews vanished.

Yeah, I am not having any luck with the GPU Previews. They come and go seemingly at random. Sometimes I will see part of the preview in the other windows, but it looks like a single slice on a polygon with the poly facing the sun (not the camera).

Let me know if you need a scene.

[Joelaff]

Oh, with regard to the GPU previews. Looks like they are working OK in perspective views, but all wonky in orthographic views like TOP or FRONT.

[Svetlin.Nikolov]

Ah yes, this is a known limitation - not sure if we have any of the gpu previews working on ortho anywhere (we have about 7-8 implementations - old gpu in max, viewport nitrous 9, viewport nitrous 11, 3 more for the maya viewport and an opengl one for saving images, and one more in the sdk examples). Will add one more vote to it, it might not be a big deal to get it working, but had the impression that nobody is using ortho

[Joelaff]

I rarely use the navigatable ortho view, but I do prefer a quad view with top, front or one side, perspective, and camera.

Perhaps the GPU preview could work in perspective based views, and have the triangle preview in the ortho views.

[Joelaff]

Also, a few questions that would help us optimize things...

Say I have a cache that has Smoke, Temperature, Velocity, and Advection.

When I load that into a VolumeGrid do ALL those channel get loaded, even if my Rendering Volume Options are set to only use Smoke? I am trying to figure out if additional channel which we don't end up making use of are taking up memory, or slowing the file reads.

Also, when using the compression, we had discussed before that this was the number of bits used to store the data. Is that the number of bits used to store the data in memory as well, or just on disk? In other words, do caches with a lower storage quality take up less memory once loaded? Or just less disk space?

I seem to recall some method you had for this, but what is the easiest way to strip out unused channels form a cache? Or is there no easy way? Say we decide we don't need advection, or velocity, but want to make the files smaller and the memory usage lower, etc.

oh, also, what about the backup interval files which contain all the extra data. Do those frames take longer to load and/or use more memory when loaded into Volume Grid?

Thanks.