Best Practices for Clouds

[Joelaff]

What if each grid (Phoenix or VolumeGrid) had an icon like a PHX Source has, we could roll over that icon and get a preview highlight of the triangle preview? So the hit detection could just be on the icon, but the user feedback would be seen as a highlight of the triangle preview (in the camera view).

I am just looking for some way to find a particular grid mesh (from a bunch of overlapping grids) in the camera view. It is not a big deal to roll over other icons to find them. Right now I have to turn them off and on, which is kinda a pain.

I figured hit detection on that triangle preview would be pretty slow. Honestly, for what you are dealing with data-wise the triangle preview is already pretty impressive. Another thought is what about some sort of Convex Hull (which are generally relatively fast to compute) to be used for hit detection, or even for preview.

[georgi.zhekov]

Is there some method to get shadows cast ON TO smoke from other objects to be less opaque? I can use two lights, one without a shadow, but this will of course be slower. Just didn't know if there was some shadow density I am missing.

Thanks.

There is no way to do that I'm afraid. Using two lights is the way to go.

[Joelaff]

There is no way to do that I'm afraid. Using two lights is the way to go.

Thanks for the reply. Please ad a vote for a "Shadow Density" control for VRay in general. Most renderers have had this setting for decades. I am surprised VRay doesn't have one. I get it's not physically accurate, but it is very helpful.

[georgi.zhekov]

It's already logged in the system - adding one more vote for it

[Svetlin.Nikolov]

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.

Hey, my colleague Kaloyan did some changes and they are already in the nightlies:

Now the cache converter has an option -exportchannels, after which you can list the channels you want to keep in the cache after conversion. If this option is not mentioned, all channels go into the cache. The syntax is like this:

cache_converter.exe -srcfile ND2_PhoenixFDFire001_####.aur -dstfile outFile_####.vdb -start 0 -end 10 -storagequality 14 -exportchannels Smoke_phx VelocityXYZ_phx -silent

The channel names in AUR caches are:
-Temperature_phx
-Smoke_phx
-Speed_phx
-VelocityX_phx
-VelocityY_phx
-VelocityZ_phx
-ColorR_phx
-ColorG_phx
-ColorB_phx
-Fuel_phx
-WaveletEnergy_phx
-AdvectionOriginX_phx
-AdvectionOriginY_phx
-AdvectionOriginZ_phx
-WaveletU_phx
-WaveletV_phx
-WaveletW_phx
-Viscosity_phx
-TexU_phx
-TexV_phx
-TexW_phx

... and you can also use these aliases for the 3 components of vector channels:
-VelocityXYZ_phx
-ColorRGB_phx
- AdvectionOriginXYZ_phx
- WaveletUVW_phx
- TexUVW_phx

Cheers

[Joelaff]

Man you guys are awesome! Thanks.

Oh, what about my question about loading and memory...

Are all channels loaded at the start of a frame, or does it only load the channels as needed? So if I am not referencing temperature will it still load temperature, for instance? You ever experiment with memory mapping the grid data? Would likely work better on linux, though.

[Svetlin.Nikolov]

Ah, here it is https://forums.chaosgroup.com/forum/...52#post1093652

[Joelaff]

Ah, here it is https://forums.chaosgroup.com/forum/...52#post1093652

Thanks. I completely missed that.

[Svetlin.Nikolov]

Paul Oblomov did some tests with memory mapping, but it wasn't a big hit, and it shouldn't be - we still have a couple of particle compression/decompression algorithms that we can optimize, so we do have things to improve in software before we resort to hardware...

[Joelaff]

One more...

Is there any way to decimate a grid? Like perhaps to take it to half its resolution to speed loading, and displacing, and RAM usage?

I have an existing cloud that was simmed pretty big, would like to use it smaller. Any thoughts? Somehow emit from the hi-res Grid into a low res grid?

Would a decimate option even be possible with the command line converter? Or would that be technically difficult? I was thinking just 1/2, 1/4, 1/8, etc. rather than any interpolation.

Also, it doesn't seem like the cutter geometry speeds up displacement. I was hoping that the unused cells would be trimmed first and only the visible cells would be displaced (for speed, since the displacement is so slow in Surface mode).

Any way to cut/trim a grid? Even being able to trim that to a different sized cube aligned with the grid would be very useful.

[Svetlin.Nikolov]

Yess, powers of two would be very easy to have in the cache converter, but I need to clean up some other ideas I have for the converter first, because this might interfere with them...

Adding one more vote to up/downsampling via the converter

[Svetlin.Nikolov]

Alrighty, one more thing went into the nightlies that are already out today - now Auto Reduction of voxel previews understands if there are many Simulators in the scene and reduces appropriately. It's not perfect and with 256 Simulator copies I'm already hitting 1FPS, while if the Simulators have no loaded caches, I'm running at about 2-3 FPS, so this is about as much Simulators as can be plugged into a viewport currently...

On a positive note for Maya users, instancing is not faster to preview than cloning for 3ds Max, but in Maya instances are much faster in the viewport than copies. The change for Auto Reduction will be in tomorrow's Maya nightlies as well...

[Joelaff]

Awesome! Thanks for the update.

Now if I could just find a way to get surface driven displacement to work faster... That is slowing us down right now. I wish it would honor the cutter geometry to act as a speedup (assuming that would speed it up). Or maybe there would be some way to cache the Surface driven displacement??? That would be pretty slick.

Or perhaps there is a way to decimate the grid internally and used the half res version to calc the displacement normals. Just thinking out loud here. Like some way to offer a slightly lower quality, but faster way to displace.

Thanks.

[Svetlin.Nikolov]

Oh, the volumetric displacement is terribly slow right now. I have it in the to-do list to check it, it's one of the places where no human has set foot since 2012...

[Joelaff]

The Surface Driven displacement is a really cool effect. It is just terribly slow. I think I had never actually used it because as soon as I saw how long it was going to take I cancelled it. But it the case of this particular project it is perfect to add some subtle motion to some existing cloud like volumes. (Scene is some people and objects on top of the clouds in "heaven") without changing the overall shape.

Now that I tried it, though. It is very slick, and just takes a lot of waiting for the render setup.