Page MenuHome

Bake All Dynamics not baking hair particles
Closed, DuplicatePublic

Description

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.60
CPU : Intel i9-9900K

Blender Version
Broken: version: 2.81 (sub 14), branch: master, commit date: 2019-10-07 20:16, hash: rBa856c5eccffb
Worked: (optional)

Short description of error
When working with multiple particle emitters on a same object, The Bake All Dynamics button doesn't bake anything (when the particles are hair). I had the problem with 2.80 and checked with 2.81 if this was addressed but apparently not.
It is not very efficient to have to go through every particle system in the scene and bake them individually.
Especially since baking individually will only use one CPU core.
Perhaps a solution could be to start launching individual blender instances for every particle system ? This way it would make use of multiple cores. It is sad to see my cpu maxing out at 12% when baking a hair sim, while the other 7 cores are sitting idle…
If for some technical reason All Hair Dynamics cannot be baked with a single click, maybe gray out the Bake All Dynamics Button while in "hair" mode ? It would save a lot of people some time searching why this doesn't work...

Exact steps for others to reproduce the error
Just add a particle system, switch to hair instead of emitter, and Bake All Dynamics will do nothing.

Event Timeline

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 80.Oct 9 2019, 1:19 PM

Some first notes (without diving deeper)

Afaics, if you are going for multiple hair systems on a single object, Bake [instead Bake All Dynamics] will bake multiple hair systems (on that single object) at once (no need to do them separately)

  • 2.79 is the same here
  • there seems to be a bug though [specific to this file?] (in that if you leave both cache names empty, one hair system will just vanish after frame one)
  • that bug can be worked around by writing a separate cache file for each hair system (just name the caches differently...), those still contain both systems [if written to disk they are the same size]
  • one can also see that by doing a disk cache in this file [you dont get indices anymore -- _00 vs _01]
  • I think I managed to reproduce from a fresh file: if you are caching to disk first (all fine, two hair systems get _00 and _01), then cache to memory (disable Disk Cache), then cache to disk again (enable Disk Cache) --> (bug, two hair systems dont _00 and _01)... needs further investigation...

Now if you are using Bake All Dynamics:

T62563, T62893 might be related

When working with multiple particle emitters on a same object, The Bake All Dynamics button doesn't bake anything (when the particles are hair)...

Shades of T53083 perhaps?

Thanks for your reply. I've made some further investigating. I did notice what you suggested about two systems on a single object being baked simultaneously.
It is true when Disk Cache is enabled for both systems, and no name is given to the cache. When I bake only one, I see in the cache folder that two sets of .bphys are created for each frame. Named #_00.bphys and #_01.bphys

In the viewport the playback is good. However, as soon as I click on the second system, all the ###_01.bphys vanish, and the cache for this system disappears, stating "0 frames on disk, cache is outdated. And then the viewport is laggy as it caches the simulation of the second system again.

If I rename both caches to "Sys1" and "Sys2", the same thing happens. I do get both systems cached in the folder with the right names : "Sys1_#_00.bphys" and "Sys2_###_01.bphys", but as soon as I click on the other system, its cache is deleted from the folder. The order doesn't matter. First or second system baked first, the other's cache is later discarded.

Clicking "Current Cache to Bake" after baking "one" of the system does not solve this.

Thankfully, if I manually bake both systems individually the cache stays permenantly. But it is a tedious

Sorry to say that PointCaches are pretty new to me (just wrapping my head around this now)

I can also confirm that switching to the other particle system will delete the .bphys from disk, that needs to be investigated further.
For me though, giving them different names solves this, I can then select the other particle without loosing the .bphys

What I did find in a specific situation [regarding the case when blender only writes to _00 (instead of _00 and _01)] was:

  • ParticleSettings has a pid->cache->index of 0
  • ParticleSettings.001 has a pid->cache->index of -1 [ in that case ptcache_filename calls BKE_object_insert_ptcache but the list of ob->pc_ids is empty?, we are not incrementing and eventually we end up with the _00 extension twice :( ]

Aand, we still have the case where where hair (and keyed particles) are ommitted (on purpose?) for Bake All Dynamics (relating to T53083).
Stay tuned.

FYI, the skipping of hair particles with Bake All Dynamics was introduced in rB66918b3add4d.
On first sight, I dont see a particular reason to skip [tested non-skipping which seems to work], but this is ancient, so I guess this has never been considered a bug...

I propose to split this report up:

  • the issue about Bake All Dynamics skipping hair particles is really a duplicate of T53083 and should be merged into that report [afraid this is not really abug in the end...]
  • the issue about the vanishing ###_01.bphys when selecting the other particle system is really a different issue and should be handled in a new, separate report [@Benoit Alexis (alexisb38): could you open a new report for this? Please also reference this report in the new report since there is already some information gathered here -- or just paste stuff from here into the new report... -- thx in advance!]

Thank you very much for your time ! here is the new report for the "vanishing cache" : T70696

Maybe the Bake All Dynamics issue is not really a bug since it was coded that way, but its behavior is really confusing for the user, and quite honestly it represents a lot of wasted time, I can't imagine how so few people have reported this so far. So should it be a feature request then ?

Thank you very much for your time ! here is the new report for the "vanishing cache" : T70696

Maybe the Bake All Dynamics issue is not really a bug since it was coded that way, but its behavior is really confusing for the user, and quite honestly it represents a lot of wasted time, I can't imagine how so few people have reported this so far. So should it be a feature request then ?

Thx for the new report!
I will merge this report with T53083 then... [lets keep discussion about its status (bug? feature request?) in there... and yep, if find this unclear as well]