This is the first step for having sequences covered with session UUID
with the goal to remove code which uses original sequence pointer to
match sequences.
Currently this UUID is maintained on file load, allocation and leaf
duplication function.There are more cases to cover and ensure UUID
is re-generated or re-used when needed. It will be done as follow-up
development.
High quality emitters need to maintain state themselves. For example,
this it needs to remember when it spawned the last particle.
This is especially important when the birth rate is changing over time.
Otherwise, there will be very visible artifacts.
It is quite likely that other components of the simulation need their own
state as well. Therefore, I refactored the `SimulationState` type a bit,
to make it more extensible. Instead of using hardcoded type numbers, a
string is used to identify the state type. Also, instead of having switch
statements in many places, there is a new `SimulationStateType` that
encapsulates information about how a specific state is created/freed/copied/...
I removed the integration with the point cache for now, because it was
not used anyway in it's current state.
Object sockets work now, but only the new Object Transforms and the
Particle Mesh Emitter node use it. The emitter does not actually
use the mesh surface yet. Instead, new particles are just emitted around
the origin of the object.
Internally, handles to object data blocks are passed around in the network,
instead of raw object pointers. Using handles has a couple of benefits:
* The caller of the function has control over which handles can be resolved
and therefore limit access to specific data. The set of data blocks that
is accessed by a node tree should be known statically. This is necessary
for a proper integration with the dependency graph.
* When the pointer to an object changes (e.g. after restarting Blender),
all handles are still valid.
* When an object is deleted, the handle is invalidated without causing crashes.
* The handle is just an integer that can be stored per particle and can be cached easily.
The mapping between handles and their corresponding data blocks is
stored in the Simulation data block.
Every Particle Simulation node has a name (or a path when it is in a node group).
This name has to be used in the Simulation modifier on a point cloud to see
the particles.
Caching has been disabled for now, because it was holding back development
a bit. To reset the simulation, go back to frame 1.
Currently, there is no way to influence the simulation. There are just some
randomly moving points. Changing that is the next step.
Caused by recent own refactor of cache presevation handling in readfile,
EEVEE's lightcache are weird birds that can also be saved in .blend
files, need a special handling for those 'persistent' caches...
Treat those as pure runtime code, reset to NULL by reading code, for
now.
Think those could be handled like Image gputextures (i.e. considered
runtime cache and preserved across undo steps), but probably not
critical for now.
Some notes:
* `Image.cache` acts as some kind of 'main' cache, when it is NULL
(could not be restored), other caches should also be cleared. Oddly
enough, previous code was not clearing **all** caches, could not find
any reason for that behavior, so new code does a full clear.
* `imamap` is still used for Node previews from scenes' compositor,
however this is actually fully disabled in `direct_link_node()`.
* For render slots we cannot use offsetof as third part of the cache
key, so we are using a hash of the slot's name instead.
As far as I can tell, this fixes T76989: Visual glitches when undo after
reload multiple images by script (in Material Preview).
Main goal here is to have better specificity using cache keys, to avoid
same memroy address being re-used messing up with cache pointers
restoration after undo had to re-read a data-block.
Once all caches handling are ported to this new system, it should fix
random issues like the one reported in T76989.
Part of D8183, refactoring how we preserve caches across undo steps in
readfile code.
Changed variable names from mmd, mds, mfs, and mes to fmd, fds, ffs, and fes. The author of this commits lights a candle for all the merge conflicts this will cause.
The shortcuts act on the modifier with its panel under the mouse.
The following shortcuts are enabled by default:
- Remove modifier: X, Delete
- Apply modifier: Ctrl A
- Duplicate modifier: Shift D
More shortcuts can be added in the keymap.
Each panel can now store a custom data RNA pointer, and a new
function is added to get the custom data for the panel under the
cursor. This custom data could be used to refactor the "List Panel
System" to generalize it and integrate it further with RNA.
The same functionality will be added in further commits where it
applies to constraints, grease pencil modifiers, and effects.
Differential Revision: https://developer.blender.org/D8031
Prelimenary step to fix T77460.
Not sure how or when that thing was done, but since that call walks
around collections relationships, it's an utterly critical violation of
liblinking principles (code here should never, ever 'get outside' of its
own ID scope).
This was wroking so far only because code called through this function
(`BKE_collection_parent_relations_rebuild`) was only following parents
pointers (in `BKE_collection_find_cycle()`), which would be either valid
or non-existent.
But next commit is going to change that to also check collection's
objects instancing of other collections.
