Smoke simulator moving collision object deletes density rather than displacing it
Open, ConfirmedPublic

Description

System Information
Win7 x64

Blender Version
Broken: Official release
Worked: I guess never

Short description of error
With a moving collision mesh smoke won't be displaced as it would naturally be the case, instead the collider will act more like an outflow. This prevents one from using the smoke sim for typical wind channel like effects because all smoke which directly hits the surface will just disappear.

Effects where smoke is flowing around objects such as in this example are quite difficult to accomplish with Blender for that reason:
https://youtu.be/pX4Z-_zCRmk?t=3m20s

Exact steps for others to reproduce the error
Just load the .blend file and run animation playback, you should see how the moving sphere will eradicate the smoke trails.

Details

Type
Bug
ronan ducluzeau (zeauro) triaged this task as Confirmed priority.Sat, Nov 11, 10:49 PM

I can confirm that smoke is dissapearing.
I also think that support of moving obstacles has never been different since it exists. So, it is probably a known limitation.
Behaviour of smoke is defined to have straight lines made by a smoke that is not moving.
So, here, movement should come from collision only.

You can increase time scale and frame rate. That wil help for flows like the one on the middle that have an angle with normal of obstacle surface.
But it does not work with frontal collision.

Intitially, smoke feature have been created with particles only as emitter.
You can create a particle flow that will collide and follow obstacle surface and then re-use it as a smoke emitter.
But of course, particles cache will take memory that would not be available for smokes.

Thanks. Particles unfortunately won't follow the air flow, so the desired effect that the smoke flows around the sphere to its backside will still be difficult to accomplish. Instead the space above the sphere will be polluted with more smoke.

The collision settings for particle obstacles are also a limiting factor for this idea. They lack a setting for variation from the perfect angle of reflection which makes particles colliding in a right angle just bouncing away into the direction they came from - forward instead of to the sides - or staying in place.

(Speaking of particles as smoke emitter I wonder what the reason was to define the emission size in number of cells instead of Blender units. Using actual particle sizes would have been more useful.)

The collision settings for particle obstacles are also a limiting factor for this idea. They lack a setting for variation from the perfect angle of reflection which makes particles colliding in a right angle just bouncing away into the direction they came from - forward instead of to the sides - or staying in place.

In fact, it requires to use particles with physics that will restitute the idea of a dense flow. So, particles with forces between them. We can do it with molecular add-on or particles with Fluid physic type.

(Speaking of particles as smoke emitter I wonder what the reason was to define the emission size in number of cells instead of Blender units. Using actual particle sizes would have been more useful.)

I suppose that is more direct than converting an arbitrary BU to a potentialy scaled domain cell size.
And particle size is used by particles physics. Blend file is always easier to manage if you don't need to resize particles after baking for another purpose.
A size for emission often have to be adjusted to gap between particles or between a collider and particles. So, often, it can be greater or smaller than particles size used for physic behaviour.

In fact, it requires to use particles with physics that will restitute the idea of a dense flow. So, particles with forces between them.

This actually wouldn't cover this case because our SPH particle physics can't simulate the effect of negative pressure and flow of the surrounding (empty) air. You know there is nothing behind the sphere that would pull the particles into this direction. Just for clarification, I would expect this type of smoke flow for a correctly working smoke simulator: https://youtu.be/6qEaz4U0MvM

A size for emission often have to be adjusted to gap between particles or between a collider and particles. So, often, it can be greater or smaller than particles size used for physic behaviour.

In practice you would want to be flexible with the resolution of the domain, as in designing a behavior with a low res domain and for the final render you would simulate it with high res settings. But for now you have to adjust the size of the emission particles each time to compensate for a changed resolution.

I think it's a good practice trying to keep quality parameters as independent from design parameters as possible, a simulation should be easily scaleable. Anyways, this is more of a usability hurdle one can cope with.