Sequencer was not initialized yet, and RNA update function tried to clean up cache.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8323
This means that we delete all override properties except for those over
ID pointers *if* the assigned pointer matches the linked data hierarchy.
Then we reload affected datablocks.
Regression from d6cefef98f
This also fixes an unreported issue where finding an exact match
wasn't being detected for items that contained an ID prefix.
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.
This adds extra deform modes to the slide mode of the Topology
Slide/Relax brush (both slide and smear are almost identical).
This is useful to move topology to a specific area to add more localized
details
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D8349
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.
It looks like the code left this as a todo, but the basic solution is to
add an extra parameter to BKE_bose_rest to check whether bones
are selected before reseting them.
I also corrected the operator description which said it acted on only
selected bones even when there is an option to turn that off. The
"act on selected" is generally implied for Blender's operators anyway.
Differential Revision: https://developer.blender.org/D8319
Previous ones were extremely confusing and innacurate (probably
inherited from older versions of scene collections?).
Also, use named fields in struct initialization, much much safer and
cleaner than anonymous, positionned-based thing.
Added support for transforming only origins with greasepencil objects.
The new functions is based on BKE_gpencil_transform. That is why there is FIXME statements in there.
Reviewed By: Campbell, Antonio
Differential Revision: http://developer.blender.org/D8303
Trying to get shape key pointer after having unlinked its owner from
Main data-base is rather useless... So those shapekeys ended up never
being deleted.
This refactor is in response to reports in which the adaptive domain with noise caused a crash (e.g. T79009). It should also fix issues where the smoke appeared to be cut off when using the adaptive domain together with noise. It is also possible that some of these changes improve the lines issue from T74559.
That project cannot be opened correctly ayway, it has recursive
collections intanciating themselves...
But at least now we have a check at startup to detect and 'fix' those
nasty cycles in collections.
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
c08d847488 incremented the patch version instead of the file subversion
for versioning code when adding new options. This commit resets the patch
version and instead bumps the file subversion.
Status Bar can show scene statistics, memory usage, version, etc set by context menu. Part two of T75672.
Differential Revision: https://developer.blender.org/D7557
Reviewed by Julian Eisel
When the playhead drawing moved to an overlay, a check was added to keep
it from drawing with a locked interface. This is necessary for some overlays,
but not this one, so this removes the check, making it the responsibility of
the editor.
A context function is added to make that check easier in the future.
Differential Revision: https://developer.blender.org/D8313
Instead of depending on static initialization order of globals use
static variables within functions. Those are initialized on first use.
This is every so slighly less efficient, but avoids a full class of problems.
I removed bf_blenkernel from `nodes/CMakeLists.txt` again (added it yesterday),
because now this was causing me unresolved symbol errors... Without it, cmake
seems to link the libraries bf_simulation, bf_blenkernel and bf_nodes in the right
order. Not sure if that is just luck or if it is guaranteed.
It was possible to fix the issue by using cmakes `LINK_INTERFACE_MULTIPLICITY`,
but that is probably bad style.
This also introduces the `blender::nodes` namespace. Eventually,
we want to move most/all of the node implementation files into
this namespace.
The reason for this file-move is that the code fits much better
into the `nodes` directory than in the `blenkernel` directory.
Not sure if these conversions are a good idea. However, we have them
in Cycles, so they be available in the simulation node tree for consistency
reasons.
For still images, always return 0 for the current frame number. This ensures
Cycles can detects that the image did not change.
Based on patch by Vincent Blankfield.
Differential Revision: https://developer.blender.org/D8242
Function names will be updated in a separate commit.
This will be the place for the new particle system and other
code related to the Simulation data block. We don't want
to have all that code in blenkernel.
Approved by brecht.
This commit introduces a new way to build unit tests. It is now possible
for each module to generate its own test library. The tests in these
libraries are then bundled into a single executable.
The test executable can be run with `ctest`. Even though the tests
reside in a single executable, they are still exposed as individual
tests to `ctest`, and thus can be selected via its `-R` argument.
Not yet ported tests still build & run as before.
The following rules apply:
- Test code should reside in the same directory as the code under test.
- Tests that target functionality in `somefile.{c,cc}` should reside in
`somefile_test.cc`.
- The namespace for tests is the `tests` sub-namespace of the code under
test. For example, tests for `blender::bke` should be in
`blender::bke:tests`.
- The test files should be listed in the module's `CMakeLists.txt` in a
`blender_add_test_lib()` call. See the `blenkernel` module for an
example.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7649
