Cascade setup for smoke

[TomGore]

1. Hello. I have a problem with setting up a cascade for smoke. One huge collapse smoke with large grid res (already simulated, 1TB in size) and some smaller debris trails, localized for speed. How to approach it? Is there a necessity to do the 24hours long sim again? I'd be happy to get a very simple .max scene file with Large Smoke preset emitting some trails of debri. These smaller trails would be a separate sim.

2. Does mesh representation of smoke ("Show Mesh" in preview) contain velocity data in it's geometry? Can this surface be used to push other sim's smoke around without need of cascade sim setup?

[Svetlin.Nikolov]

Hmm, if the particle trails will be laid over the smoke sim, sounds like you don't need a cascade sim - the cascade simulation is needed only when you need the fluid to move from one domain to another, but if the two would overlap, maybe it would be best to just place a second simulator on top the first one and even exclude both from interacting with each other (you have to put one sim in exclude list mode and the second one in include list mode, or Max won't allow both sims pointing at one another).

If one sim interacts with another, you could use the interacting sim in a source and check "motion velocity", so the velocities would be transferred. You need to have velocities in the cache files of the simulator that should affect the other though. Also, just like regular geometry, a sim can be put in a Solid (by default) or non-solid mode, so it won't obstruct the movement of the fluid of the other sim, but only introduce velocities or emit in brush or inject mode.

Cheers!

[TomGore]

Great, thanks. I will try on a simple scene first.

[TomGore]

Also, one more thing. I dont use vray but octane, but I have a question regarding vray - does it new features like volumetric fog and aerial perspective affect Phoenix volumetric rendering? This was always an issue with cpu rendered fog system in max, the order of environment volumetric effect can affect or distort the layers of overlaping volumetrics. In gpu renderer like octane voxels are just real, bruteforce voxels, so there is no problem with mixing volumetric systems as long as these are vdb-like grids. I wonder how it goes with phoenix and vray?

[Svetlin.Nikolov]

Yup, Max atmospheres just stack on top of one another, however you can put Phoenix in Volumetric Geometry mode and it won't render as an atmosphere/volumetric, but as dynamic semi-transparent geometry, so it would blend with atmospheres correctly. However, the Approximate scattering which is by default won't work with Volumetric Geometry modes so you might get darker smoke. We added a section for this in the Tips on the docs because the question's been coming up more often lately https://docs.chaosgroup.com/display/...VRayVolumeGrid

[TomGore]

Okay, today I discovered that octane renderer stopped recognize phoenix aur files after Phoenix 3.05 hotfix. I had to revert back to 3.04.02. What have you changed that could make it non-accessible for octane vdb/aur reader?

[Svetlin.Nikolov]

We changed the Phoenix SDK - I'll ping the Octane guys.

[TomGore]

Hmm, if the particle trails will be laid over the smoke sim, sounds like you don't need a cascade sim - the cascade simulation is needed only when you need the fluid to move from one domain to another, but if the two would overlap, maybe it would be best to just place a second simulator on top the first one and even exclude both from interacting with each other (you have to put one sim in exclude list mode and the second one in include list mode, or Max won't allow both sims pointing at one another).

If one sim interacts with another, you could use the interacting sim in a source and check "motion velocity", so the velocities would be transferred. You need to have velocities in the cache files of the simulator that should affect the other though. Also, just like regular geometry, a sim can be put in a Solid (by default) or non-solid mode, so it won't obstruct the movement of the fluid of the other sim, but only introduce velocities or emit in brush or inject mode.

Cheers!

I've tried that, but it creates a situation where blue smoke affects red smoke (for example) only after selecting it in the red smoke source. But the problem is the red smoke source is set to emit from object (small sphere, because I want to make a slim trail of red smoke) and when blue smoke enters the red smoke grid, then red source is assuming it is a new entering surface that is supposed to emit red smoke. All I get is blue emitting more red. When tried to include/exclude playaround, only thing I got is Circular Reference Error. Are you sure for that in practice?

[Svetlin.Nikolov]

Sounds like you should separate the sources for the red and blue simulators - each simulator should include only the sources that should affect it and not the sources of the other simulator.

If you have both simulators in exclude mode, you'll get circular reference error as one cannot point to the other while the other points to the first one. If you put the red sim in exclude mode and the blue sim in include mode, then you should pick the blue simulator and the blue sources in the red one (excluding them), and you should pick the blue sources and all the interacting geometry for the blue simulator in it (including these sources and this geometry). If you are getting a circular reference error from Max, you need to be sure the node you are picking at the moment of the error message does not already point to the simulator that picks it directly, or indirectly - through another node.

If this is hard to set up with a complex scene, you could just as well put both simulators in include mode - this will be easier to verify and each simulator should pick manually all the geometry and sources it interacts with.

Cheers!

[TomGore]

Thanks. I will try that, but I used Stoke Mx for creating a custom space warp with velocity field from Pflow Phoenix Follow hack. This space warp can be used with second Phoenix sim to deflect it as standard Wind or other space warp does. By the way, except Octane, the 3.05 hotfix made Thinkbox Stoke MX uncompatible. Stoke doesn't recognize Phoenix as a valid velocity source. More to this: Wavelet resim started in 3.05 cannot be successfuly finished after reverting to 3.04. Just sayin'...

[Svetlin.Nikolov]

Ah yes, we already contacted the guys at Thinkbox about the SDK change, so hopefully in their next version they would support 3.05 as well.

There were issues with resims in 3.04, but in general a simulation made with a newer version is not expected to be compatible with older versions, so this is expected...