`mesh_get_eval_final` and friends could call `mesh_build_data`, which in
paint/sculpt mode would call `BKE_sculpt_update_mesh_elements` which
would call `mesh_get_eval_final`... ugly!
Would compare evaluated ob pointer to original one...
Found while investigating some errors in incomming cleanup, but this was
probably generating lost of other issues in some cases...
This is a temp fix for a better system.
Currently the studiolights can be referenced by a WM_job and being freed
via the API. This can happen when removing a studiolight via the
interface.
As the studiolight has no relation with the job, it is hard to detect if
it is still being used. I tried with a Mutex and a Thread Queue but they
were failing.
So the current temp fix is to keep the studiolights in memory until you
close blender. This Must be fixed ASAP! I added this fix so normal cases
can workish.
I moved some code from ED_rigidbody_object_remove() to
BKE_rigidbody_remove_object(), so that calling the latter doesn't leave
the object in rbw->group (causing a crash later on when rebuilding the
depsgraph).
The idea is to only use pointers to particles in original object when
creating an edit structure. The derived mesh we get from evaluated
object.
The rest of the commit is just keeping pointers in sync.
This makes it possible to perform re-evaluation of the scene without
having to re-run the simulation.
The CoW → Orig copy is only performed when the depsgraph is active, so
as to not influence the current scene while rendering in the background.
Alternatively, we could have the CoW copy share the cache with the
original to prevent too much copying of cache data. This will be faster,
but I'm not sure whether we can reliably check the DEG_is_active()
status at CoW copy creation time.
- the result of the SH2-coeffiecients are stored in a bin file (3*9
floats). As the file is a local file we do not care about the
architecture.
- solved issue that also for internal lights the irradiance file were
stored. We don't want that as it could be in a not accessible location
Not sure why remap call for static override reference ID pointer was put
there, probably a mistake during some merge back in the days...
But this ended up with self_id of libquery data struct still being set
to previous ID pointer, which could randomly generate crap like falsly
reporting indirect data and such, leading to lost reference datablock at
writefile time...
Since we free collection caches when we remap one of their objects, we
also need to tell depsgraph to flush this into the COWs of that
collection, otherwise things like draw code can access freed memory...
Currently focused on making parts which are a bottleneck for Spring,
to make things fast as possible. There are surely lots of places
where threading is not currently done, but we can keep doing this,
maybe even with help from the community :)
object.base_flag was not synced back from evaluated ID to original one.
Similar thing as copying back to original transform matrix, avoids
having to get data from evaluated one in lots of cases.
Previously, render slots were hardcoded to a fixed amount.
With this change, render slots now are stored in a list. Therefore, users can add and/or remove as many slots as they want.
Credit to brecht for the UI part.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D3474
Sometimes the evaluated pose channel pointers can change during depsgraph
evaluation, so we can't store them ahead of time. The object pointer
should be ok since evaluated ID memory is reused.
