smoke color weird mixing

[ttdww]

Was color mixing improved from pfd3.x to 4.x? My white surface force smoke is quickly overpowering and taking over all other darker injected colors, so after mixing, the whole sim is white smoke.

[Svetlin.Nikolov]

Hey,

Phoenix's color mixing is extremely simple, so I'd guess it's not a problem with the mix, but rather something else causes this behavior, and thus it's not related to the Phoenix version. How can we make this issue happen here so we can find out what's up?

Thanks!

[ttdww]

Thx for the response Svetlin.

In words, I have a blast where there is some immediate injection of dark smoke that is born from a slight spread of particles and then the injection is shut off to allow those plumes to form and slow. Also there are white smoke trails surface-emitted from particles, however those keep emitting smoke as they arc over and die out. I have it setup where the white trails should punch through and out of the dark smoke, but when those 2 areas of voxels interact, the white smoke immediate permeates throughout the larger cloud of rolling dark smoke, almost unnaturally. It's making it hard to control because visually the white trails are very sparse looking, so it doesn't seem like the density of trails is greater.

[ttdww]

Here's a preview showing the issue: https://finalight.com/download/Blast...e02_Sim014.mp4

--around frame 5,we have 3 ejections of dark smoke - straight up, to lower left, and at an angle toward upper left - also surface force white smoke coming off of trails toward upper left
--as it plays out, by frame 15 the white smoke quickly mixes and overtakes the hue value of the dark smoke at upper left.
--by end it's overtaken all upper left and lower left smoke, mostly at upper left but still heavily at lower left

[ttdww]

In a render, the issue is more pronounced, making it almost unusable unfortunately. I would have to sim the trails separately to resolve unless there is a workaround, but then the trails won't respond to the other plumes movement/heat/buoyancy:
https://finalight.com/download/Blast...y_Slapcomp.mp4

Note that the brown smoke at the far left and intermixed grey smoke is hued in post with a Multimatte - just had this render already, so using it as an example.

[Svetlin.Nikolov]

Ah, so you have an explosion originating from one small volume and spreading out - in this case you're left to the mercy of the solver - the white smoke obviously comes from inside the plume, where velocities are chaotic and it's up to chance which color would dominate. There is one thing I can think of that might produce better color distribution without leaving it to chance - try the Forward Transfer advection method, but it will reduce the detail of the simulation. Alternatively, separate sims will be best for control. Or, if you can space the sources out so they don't intermix in the beginning, or if you can keep emitting from the particles a little longer in order to assert the colors more, this can also help keep the colors from mixing chaotically.

[ttdww]

I see - thx for those ideas and tips. I guess a question for down the road is, does the solver take into account the density. Because my presumption would be that since the white trails are so sparse they'd have less value than the brown plumes even though they slow down first and have less chaos.

For now I'll shoot for separate sims, though will need to fake the blast heat from the core pulling/warping the arms closer to the blast - I recall that being a hit/miss scenario as it can often feel disconnected.

[Svetlin.Nikolov]

Oh yes, the density is taken into account, but the way the transfer of the fluid in the grid-based fire/smoke solver might be the cause of the changing balance of colors. Basically modern grid solvers look at the velocities at all positions in the simulation and bring matter by tracing the velocity backwards. Meaning that if the core of the explosion has mostly bright smoke, the periphery will draw that smoke color to replace its own color. WARNING: MS Paint incoming:



Situations like that are the reason liquids are rarely simulated with grid solvers like Phoenix did in versions 1 and 2, and instead FLIP is used (or SPH for a more oldskool feel) - because grid solvers often look just fine, but sometimes they have big trouble preserving the amount of fluid and you might get more fluid coming seemingly out of nowhere, or the opposite - loss of fluid. There often is no direct way you can control this from the outside. In your setup, you could try adding more emission of darker RGB to the core of the explosion, or try animating the RGB of the trails in the Source to be dark at the beginning and getting brighter towards their tips - maybe this way you could compensate for the color shift...

Cheers!

[ttdww]

Ah, great explanation. Thanks for the technical info behind the 'why'. MS paint does fine ;D I have a few ideas for some RnD based on your suggestions. Thanks again Svetlin!