This is part of T76372.
It adds the `blend_write`, `blend_read_data`, `blend_read_lib`
and `blend_read_expand` which correspond to the various
steps when reading and writing .blend files.
Having these callbacks allows us to decentralize the blenloader
code a lot more. This has the affect that code related to any
specific ID type is less scattered.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D8670
`IDTypeForeachCacheFunctionCallback` lists the `flags` parameter
as `uint`, having these functions use `eIDTypeInfoCacheCallbackFlags`
results in the following warning when building with MSVC:
warning C4028: formal parameter 4 different from declaration
This change resolves this warning by changing the parameter to
the appropriate type.
Some implementation have different maximum texture size.
This patch avoid crash when texture allocation fails when:
- trying to bake a lightcache too big for the OpenGL imeplementaion.
- loading a cache from file that is too big for the OpenGL imeplementation.
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
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).
