Smoke simulator moving collision object deletes density rather than displacing it #53297

Closed
opened 2017-11-10 23:45:09 +01:00 by Kai Kostack · 10 comments

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.

smoke-domain-moving-test.blend

smoke-domain-moving-test.jpg

**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 ](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. [smoke-domain-moving-test.blend](https://archive.blender.org/developer/F1118828/smoke-domain-moving-test.blend) ![smoke-domain-moving-test.jpg](https://archive.blender.org/developer/F1118833/smoke-domain-moving-test.jpg)
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @KaiKostack-3

Added subscriber: @KaiKostack-3

Added subscriber: @zeauro

Added subscriber: @zeauro

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.

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.
Author

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.)

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.

> 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.
Author

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.

> 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 ](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.

Added subscriber: @mano-wii

Added subscriber: @mano-wii

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Germano Cavalcante self-assigned this 2020-01-20 16:42:19 +01:00

With the new system (Mantaflow), this problem is no longer seen.

With the new system (Mantaflow), this problem is no longer seen.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#53297
No description provided.