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?
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
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
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.
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?
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.)
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.
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.
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.
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).
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
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?
Ack! I just created a bunch of AUR files with the latest nightly (11/23) and they cannot be read into VRayVolumeGrid. They work fine in Phoenix nodes, but not in VolumeGrid nodes. They do not preview, and do not render, though the bounding box does update in size.
So when you load a cache, it might not use any RAM at all if all your previews are disabled, so it would only read the info you see in the Simulation rollout’s Cache File Content box.
Otherwise, if any previews are loaded, the compressed grid data will go into RAM, and only the channels that need to be shown in the viewport will be decompressed. If your storage quality is highest and the data is uncompressed, then you will actually use less peak RAM because the data does not have to go in RAM in order to be decompressed. Apart from this - yes, it’s about hard disk storage, it was never about RAM usage in the first place because it’s assumed that in order for you to simulate these caches in the first place, you gotta have as much RAM plus more for all of the solver data that does not get written.
Right now there’s no way to strip out channels from a cache via the Cache Converter, though it would be very easy to add one.
The backup fames will load a bit slower because of the storage reading time, but if any of the extra data is not used for restoring a simulation, it won’t be slowing down the previews.
Sounds like you have an older volume grid. Check the changelog here and the previous ones too: 4.30.00. We did several extensions to the AUR format, so older code does not know what to do with the new files.
There is no difference between the official Phoenix 4.30 and the nightly Phoenix though. Which V-Ray version do you use? Do you have the latest stable V-Ray?
Meanwhile, I’m working on improving the auto reduction of the voxel and particle previews with a ton of grids in the viewport. A lot of interesting roadblocks popped up in the process, but now I seem to have something which works well and reduces properly when there are up to around 30-40 grids. Interestingly, just having 128 empty grids with no loaded cache is already pretty heavy on the viewport, so gotta see what’s up there as well.
Alrighty, so in tomorrow’s nightlies there will be one of a series of changes - if you just create a bunch of empty grids, they will still clog the viewport because each one will be asking Max about its parameters and will draw a bounding box, etc. So on my machine I could get 128 empty grids in Max drawing at 1 FPS, and now I have them drawing at 5 FPS. This would speed up drawing of grids with very high detail reduction that you could achieve via the Volume Grid Tools from earlier in this thread. Now to make auto reduction handle many grids as well…
