| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
This reverts commit 39b525e0f07fa25dcda54226ade789959b642dec and
3121015dceb1d269d79690c8f15c8e1406c9b09f as tests are failing.
|
|
Use binary search for querying deform weights.
Spring 02_020_A.anim.blend on Ryzen 1700X goes from 12.4 to 12.7fps.
During profiling it was detected that adding new items to the head was faster than adding to the tail.
Reviewed By: Campbell Barton
Differential Revision: https://developer.blender.org/D8127
|
|
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.
|
|
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.
|
|
IDs like embedded ones (master collections, root node trees) cannot be
linked, and thus cannot be real override themselves.
Since they are managed by their owner ID, that one will also have the
overrides for their locally edited properties.
We still need a way to mark them as overridden though, for various UI
and override-internal purposes, this is done using a new ID flag.
Note that since Shae Keys are not linkable, and their pointers are not
editable in RNA, they are also considered as embedded from override
point of view.
|
|
This is cleaner, but also crucial to avoid weird issues when behaviors
of those checks are modified...
|
|
|
|
|
|
|
|
|
|
Using 'name' for the full path of a file reads badly,
especially when id.name is used in related code.
|
|
Make it clear that this is the absolute path,
allow the 'name' to be renamed to 'filepath'.
Rename is safe since this is only for run-time.
|
|
This removes G_FILE_HISTORY, G_FILE_SAVE_COPY & G_FILE_USERPREFS.
Using file-flags made logic harder to follow since it's not so clear
which flags are expected to be in G.fileflags & which are meant to be
set and passed as arguments, these are shared between read & write
functions too.
Add BlendFileWriteParams so options which don't need to be stored
aren't mixed up with flags that are stored for reuse.
|
|
When "Relative Remap" option was added, the intention was only to remap
paths that were already relative. However it remapped all paths.
This was reported as T62612 and fixed recently,
however some Python script authors depended on the old behavior.
For users, it's reasonable to use the existing operators to make paths
absolute/relative. For scripts however it's useful to be able to write
out individual data-blocks with the ability to make all paths relative.
Now `bpy.data.libraries.write()` takes a path_remap argument which can
be `NONE/RELATIVE/RELATIVE_ALL/ABSOLUTE` allowing the script author to
choose how paths are handled when writing out data-blocks.
Addresses T77768.
|
|
|
|
|
|
This is necessary so that it can be accessed from `blendWrite`
and `blendRead` callbacks from modifiers.
|
|
|
|
This is part of T76372.
|
|
When a fluid is put under influence of gravity or acceleration, it
forms an internal pressure gradient, which causes observable effects
like buoyancy. Since now cloth has support for simulating pressure
changes caused by fluid compression or expansion, it makes sense to
also support the effects of gravity.
This is intended for better simulation of objects filled or
surrounded by fluids, especially when constrained by collisions
or pinned vertices, and should result in more realistic shapes.
Obviously, this doesn't actually simulate fluid dynamics; instead
it is assumed that the fluid immediately adapts to changes in the
shape or acceleration of the object without friction or turbulence,
and instantly reaches a new static equilibrium.
Differential Revision: https://developer.blender.org/D6442
|
|
Related to T77524.
This brings back the old way of handling corrupted data.
|
|
This cannot work, because the storagename is the empty string.
|
|
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7965
|
|
The current particle state is stored in a `CustomData` instance and
the cache is stored in `PointCache`.
The current state exists on the copy-on-write copies of the simulation,
while the cache only exists in the original data block.
This patch implements a temporary trivial particle simulation that does not
use the node system yet. It is used for testing and will be replaced soon.
`PointCache` still has some limitations that need to be overcome using
separate refactorings. For example, we need to be able to store the number
of particles in the point cache. Also we need to change which attributes
are stored for a particle system more dynamically than is currently possible afaik.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
material and texture
|
|
|
|
|
