4da32e9334
Caused by e968b4197b / 67e23b4b29 Since culprit commits, we are not running `MANTA::initGuiding` / `fluid_alloc_guiding` if guiding is meant to be pulled from other domains (it does work with effectors though). This is because atm. only the `FLUID_DOMAIN_ACTIVE_GUIDE` flag sets `mUsingGuiding` to true (activated in `update_obstacleflags`, so only for effectors). So to fix this, we have to ensure that `MANTA::initGuiding` runs (also if guiding is pulled from domains), but also make sure we dont run into the crashes from T102257. It seems that the real reason we were getting crashes in T102257 is that 67e23b4b29 made it so that resetting the cache (including a call to `fluid_modifier_reset_ex`) in `fluid_modifier_processDomain` happens **after** `FluidDomainSettings.active_fields` have been updated (this happens in `update_flowsflags` & `update_obstacleflags`). But `fluid_modifier_reset_ex` also resets `FluidDomainSettings.active_fields`. If we then update pointers later in `fluid_modifier_processDomain`, we never get anything in the guiding related pointers for the new `mCurrentID` (specifically `mPhiGuideIn` will be a nullptr). This is the real reason `initGuiding()` runs a second time (it does once for `fluid_modifier_init` then again as a consequence of the call to `manta_guiding`). This patch proposes to move the resetting process from 67e23b4b29 **above** the refreshing of the `FluidDomainSettings.active_fields`, this way these field stay intact, we do get the first run of `initGuiding()` from `fluid_modifier_init`, manta pointers get updated with intact fields afterwards (so we then get a valid `mPhiGuideIn`), which then prevents the second run from `manta_guiding` to actually call the python script again. The fix from e968b4197b is then not needed and reverted in this patch. This should be good for LTS I think. Pull Request: https://projects.blender.org/blender/blender/pulls/117067 |
||
---|---|---|
.. | ||
extern | ||
intern | ||
CMakeLists.txt |