Page MenuHome

Fire does not render if flow object had disabled Show in Renders
Confirmed, NormalPublicBUG


System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19

Blender Version
Broken: version: 2.83 (sub 2), branch: master, commit date: 2020-02-10 13:21, hash: rBde09db6b4d13
Worked: (optional)

Short description of error
Fire does not render if flow object had disabled Show in Renders

Exact steps for others to reproduce the error

  1. Open file
  2. Bake domain cache
  3. Render

Event Timeline

Richard Antalik (ISS) renamed this task from In the last update for Windows when rendering the Fire if you deactivate the render of the Flow object it does not render to Fire does not render if flow object had disabled Show in Renders.Feb 11 2020, 7:59 PM
Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.
Richard Antalik (ISS) updated the task description. (Show Details)

I am not sure if this was reported already.

Jacques Lucke (JacquesLucke) changed the subtype of this task from "Report" to "Bug".Mar 27 2020, 2:18 PM
  • The fire is only rendered, when FLUID_DOMAIN_ACTIVE_FIRE is set in update_flowsflags.
  • This flag is only set, when the fluid code finds a fire inflow object using BKE_collision_objects_create.
  • It can only find such an object, if the physics relations in the depsgraph are setup correctly.
  • This fire inflow object is not in the physics relations in the depsgraph used for rendering, because the object is disabled in renders.
  • Therefore the fire is not rendered.

I'm not sure at which level that should be fixed. However, I think it should always render all the grids that have been baked, independent of whether the inflow object still exists. When the simulation has been baked, it should not depend on the existence of other objects anymore.

If one objects needs another one, it is to "pull" it into the dependency graph (doing build_object() in nodes and relations builder).

Not sure where is this violated. Is that something you can quickly check after all this investigation? :)

I looked into it a bit. Usually modifiers seem to pull other objects in, in the foreachIDLink link method. The issue is that the fluid modifier does not have a pointer to the objects it depends on. It depends, among others, on all objects that have a fluid collision modifier.
Even if I would iterate over all of these in foreachIDLink, I could not use the IDWalkFunc interface, because I do not have a ID **idpoin. Not sure if that makes sense.

One possible solution is to always include all objects in the depsgraph, that can be used as an "implicit" effector for other objects. A better solution would be to make these dependencies more explicit of course...

I still think, this specific bug could also be fixed without any depsgraph changes. The domain object should not depend on emitter objects during rendering. It should simply render what has been baked before. The optimization that e.g. fire is only drawn under specific circumstances uses a heuristic, that is not good enough.