Page MenuHome

Force field + hair dynamics not working in (linked) instanced collections
Confirmed, NormalPublicKNOWN ISSUE


System Information
Operating system: Windows 10 64 bit
Graphics card: GeForce GTX 1070

Blender Version
Broken: 2.80 3d8cbb534f82 (2019-01-25)
Worked: 2.79b release

A surface force field does not affect hair dynamics when it is part of a collection that is linked into another file.

Steps to reproduce:

  1. Create a hair particle system, with hairs along x axis.
  2. Enable hair dynamics on hair
  3. Create a surface force field underneath it.
  4. Press play button to verify hair is affected by force field.
  5. Save file
  6. Link the collection from the first file into another file. (I have 'Instance Collections' turned on)
  7. Press play. hair will fall and not be affected by the force field.

Example blend file attached.

Event Timeline

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 30.Jan 29 2019, 9:38 AM

Cannot reproduce actually [in a build from today].

I have linked the scene [that brings in everything] and hair is flying up...
Are you linking the scene? Or just the object?
Maybe you can show us a video of this failing?

Marking as incomplete until we have more information...

Or: are you linking the collection? (with Instance Collection option)
[see related comment in T60963]

Philipp Oeser (lichtwerk) raised the priority of this task from 30 to 50.Jan 29 2019, 12:31 PM

Can confirm now.

Sidenote [not sure this is related]: When linking the collection a debug build will actually assert here:

BLI_assert failed: /blender/blenlib/intern/BLI_ghash.c:466, ghash_insert_ex(), at '(gh->flag & GHASH_FLAG_ALLOW_DUPES) || (BLI_ghash_haskey(gh, key) == 0)'

1  raise                                                     0x7ffff466953f 
2  abort                                                     0x7ffff4653895 
3  ghash_insert_ex                   BLI_ghash.c       466   0x2ec239e      
4  ghash_insert                      BLI_ghash.c       516   0x2ec239e      
5  BLI_ghash_insert                  BLI_ghash.c       761   0x2ec239e      
6  read_file_bhead_idname_map_create readfile.c        616   0x28b9345      
7  library_link_begin                readfile.c        10653 0x28d7036      
8  BLO_library_link_begin            readfile.c        10670 0x28d7077      
9  wm_link_do                        wm_files_link.c   241   0x1cb5cef      
10 wm_link_append_exec               wm_files_link.c   452   0x1cb6778      
11 wm_handler_fileselect_do          wm_event_system.c 2179  0x1c7ef90      
12 wm_handler_fileselect_call        wm_event_system.c 2266  0x1c7f31a      
13 wm_handlers_do_intern             wm_event_system.c 2391  0x1c7f997      
14 wm_handlers_do                    wm_event_system.c 2618  0x1c80268      
15 wm_event_do_handlers              wm_event_system.c 3008  0x1c81541      
16 WM_main                           wm.c              425   0x1c768e6      
17 main                              creator.c         520   0x1c71565

regarding this assert: maybe @Bastien Montagne (mont29) can shed some light on this?

@Philipp Oeser (lichtwerk) that assert should for sure never be triggered, but in that case, it is caused by issue with brushes being saved in double or more (from userpref, iirc, @Campbell Barton (campbellbarton) knows the details and fixed the issue some days ago). So in that specific case, it is harmless, just means that the library reading code is only aware of one of the two brushes IDs sharing the same name… Re-saving the library with a recent build will fix that problem.

Philipp Oeser (lichtwerk) renamed this task from Force field + hair dynamics not working with linked library to Force field + hair dynamics not working in (linked) instanced collections.Jan 30 2019, 11:22 AM

@Andrew Williams (sobakasu) Is this the same problem as T60963?

I can confirm that this is still an issue in current master (9ae3f3ce929044e07ffaa46305c2d91a774d9214)

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Bug".Feb 10 2020, 1:39 PM

This is actually more a depsgraph/physics evaluation issue than a data/IO one.

Root of the problem is that objects that only exist as instances from [an empty-instanced collection, particle-instanced objects, …], i.e. which are not actually instanced by themselves in a collection of the current ViewLayer, are completely ignored by the code gathering a list of effectors during depsgraph building (see BKE_effector_relations_create).

Thing is, am not quiet sure how we could gather those instances properly here, and effector storage currently also expects proper objects afaict, not DupliObject.

Summoning @Sergey Sharybin (sergey) or @Brecht Van Lommel (brecht) here for more educated advices, but imho this should be considered a known limitation for now?

In the mean while, if you specify a given collection as source of effectors for your particle hair system, it should work fine in that specific case.

I would consider it a know limitation for now. It would be good to support instancing effectors like this, but the implementation is just not there.

Bastien Montagne (mont29) changed the subtype of this task from "Bug" to "Known Issue".Sep 22 2020, 4:34 PM