Page MenuHome

Hair Dynamics: cannot generate a valid particle cache
Confirmed, NormalPublicKNOWN ISSUE


System Information
Operating system: 4.20.12-gentoo Linux
Graphics card: Radeon(TM) Pro WX9100 (VEGA10, DRM 3.27.0, 4.20.12-gentoo, LLVM 6.0.1)

Blender Version
Broken: 2.80 (sub 48) commit hash: bf9904ec8018 Build: 2019-03-13 01:14:16 Linux Release branch: blender2.7

Worked: (optional) 2.79b commit hash and date unknown; compiled from Gentoo repository

Short description of error
Fails to make a valid particle cache when rendering a dynamic hair system via Cntl + F12. Hair particle motion appears compromised after the first frame. see video clip dyn_on.mkv.

A .blend file with a mesh object that has a hair particle system defined on it. Hair dynamics is turned on in the particle system properties panel. The file should have been previously saved without a cache. Blend file dyn_on.blend provided for this requirement.

Exact steps for others to reproduce the error

  1. Open dyn_on.blend
  2. Cntl + F12 to render animation (implicitly build in-memory cache)
  3. Observe: a. Cache indicator on timeline shows only 1 or 2 valid initial frames; remaining 248 - 249 frames are invalid. b. Hair particles exhibit only limited rotational dynamics. They do not follow the surface of the sphere (i.e., they appear "unanchored"), nor do they seem affected by gravity. See dyn_on.mkv video clip. c. After the last frame has been rendered, click on the rewind control in the timeline. The cache section in the Particles properties reports the state of the cache: "1 frames in memory (216 KB), not exact since frame 0"


  1. Bake particle dynamics first or
  2. Run the animation through in the 3D viewport to create an in-memory or on disk cache before rendering.

Rendering with an in-memory, on-disk, or with baked dynamics appears to generate an unaffected animation. See dyn_on_cache.mkv video clip.


  1. Examples rendered in Cycles, but EEVEE and Workbench rendering does not change behavior.
  2. Hair particles rendered with a collection of simple mesh geometry in the examples, but rendering with single mesh objects or rendering hair paths does not change behavior.
  3. Running in single thread mode (-t 1 on command line) does not change behavior.
  4. Rendering via CPU or GPU does not change behavior.
  5. Problem seems specific to hair particle systems. Emitter particle systems without pre-computed caches can be rendered with Cntl + F12; the cache seems fully valid in the time line, dynamics of falling emitter particles do not seem unusual and the cache section in the Particles properties reports that there are 250 valid frames in memory at the conclusion of the animation.

T62439 describes a failure in particle updates which seems very similar in appearance exhibited by particles in video clip dyn_on.mkv.

- dyn_on_cache.mkv
- dyn_on.mkv
- dyn_on.blend

Event Timeline

Sebastian Parborg (zeddb) lowered the priority of this task from 90 to 50.

I could have sworn there was already a ticket for this (particles not simulating when rendering without a cache), but I can't find it if that is the case.

@Dalai Felinto (dfelinto) reassign if this is not for you.

In blenkernel/intern/particle.c:psys_cache_paths, a N X (S + 1) array of "hair segment vertices" is built for the N hairs in the particle system, each with S segments. So for four segment hairs, there is a root, tip, and three interior hair vertices, for a total of 5. These "hair vertices" are distinct from model geometry vertices.

This pathcache "bucket" is created fresh at the start of rendering each frame and populates the particle system's pathcache field. psys_cache_paths() appears to develop a "snapshot" of positions, velocities and rotations of each hair vertex at the present frame.

It is not clear to me why this is so, but it seems in the case of Cntl + F12, without prior baking or creating an in-memory/disk cache, that the position, rotation or velocity of the underlying mesh appears not to be incorporated in the calculation of hair vertex positions, rotations or velocities. Watching the content of the pathcache in GDB during a rendering reveals unchanging positions frame after frame. This is not the case in baked/prior pointcache circumstances;
the pathcache appears to reflect the dynamics of the underlying object mesh.

One is tempted to think of an omitted transform somewhere, but I suspect that the problem is more diffuse than a dropped matrix. Fortunately, the severity of this bug is somewhere between a paper cut and a mild annoyance, since the workaround is simply to generate a point cache or bake the dynamics, and do such workarounds until the Glorious Rewrite of Particle Systems takes place. On the other hand, one would like to think that a shiny, production-ready 2.80 is going to be feature complete in every respect. One hates to let go of ideals.

@Sebastian Parborg (zeddb) let's find someone else that actually is familiar with this area ;) @Sergey Sharybin (sergey) worked on hair, @Sybren A. Stüvel (sybren) worked on cache, ...

Notes based on blender 2.80 commit: 7454fa927b80 Sat Mar 23 14:25:29 2019 +1100 T62563 still persists in this blender version.

Close to the heart of the matter is a - perhaps incomplete - meshing of designs of how dependency graph (depsgraph) updates proceed in the
rendering context and view layer context.

Frame-to-frame dependency graphs updates occur in two contexts: rendering, the consequence of CNTL F12, and view layer updates, the
consequence of running the timeline pointer forward.

These two contexts do not manage dependency graph updates in exactly the same way. In the rendering context, a per-frame call to
BKE_object_free(Object *ob), object.c:553, takes place, which frees the particle systems in ListBase ob->particlesystem. It is an array of
PointCaches deeper in these structures which encapsulate the state of frame T for hair simulators, which compute from them frame T + 1.
These PointCaches are freed as well and are not reconstructed in the course of the dependency graph update for frame T + 1. This
circumstance gives rise to the main feature of this bug: a hair simulation that essentially restarts from an initial T = 1 state
on every frame.

In contrast, the view layer context does not employ the draconian data management policy of BKE_object_free() at all. Only by toggling on the
Hair Dynamics checkbox property in the Particle panel does one see BKE_object_free(Object *ob) called on mesh objects with particle
systems. It is not called per-frame when one scrubs the timeline forward. Consequently, PointCache state persists from frame-to-frame and
hair simulation proceeds in an expected fashion.

Details in partsystem_notes.txt, attached.

Commit: 549468365157 (November 9, 2018) appears to have set the stage for this bug, which is a side effect. Very close to the heart of the matter is the hair dynamics simulation depending on the persistence of the same ParticleSystem object across the initial three frames of animation. With the commit, the prerequisite continuity of ParticleSystems can no longer be guaranteed, as they are reinitialized with the frame-by-frame deletion and recreation of the rendering dependency graph. Currently I'm wandering through the rabbit hutch that is particle_system_update() and friends, looking for either Big Buck Bunny, a contemporary of the code, it seems, or a way for ParticleSystems to be stateless - or at least less stateful. Simpler flavors of simulations, such as hair without dynamics or particle emitters, do not have equivalent dependencies on persisting ParticleSystem objects, and were unaffected by the November commit.

Details in partsystem_notes_2.txt, attached.

Philipp Oeser (lichtwerk) renamed this task from Cannot generate a valid particle cache for dynamic hair particles to Hair Dynamics: cannot generate a valid particle cache.Sep 4 2019, 8:22 PM
Philipp Oeser (lichtwerk) removed Dalai Felinto (dfelinto) as the assignee of this task.
Garry R. Osgood (grosgood) changed the subtype of this task from "Report" to "Known Issue".Dec 25 2019, 3:17 PM

Per Tracker Curfew, Tracker curfew and changes and T71418
Known issue: user documentation could use a Note box to the effect that caches cannot be generated for dynamic hair by means of a final render ( Cntl + F12 ), but generating a cache for dynamic hair by previewing the animation in the view port or baking hair dynamics works. In these two cases the particle system interacts with a persistent depsgraph in Viewport mode. Render depsgraphs do not persist but are recreated frame-by-frame. The hair particle system has not been designed to interact with transient depsgraphs.