This was introduced in rBe5c0d4613a8943c712b57fb336997ecd78e6508e.
The issue is that the new fluid system does not use the pointcache
system for caching anymore, but still relies on pointcache for
other things. For example, it uses DEG_add_collision_relations
which internally creates relations with pointcache. Not sure if
there are other issues.
Ideally, this dependence should be resolved in one way or another
at some point, but that is out of scope for this fix.
Differential Revision: https://developer.blender.org/D9984
Reviewers: brecht
This is the initial merge from the geometry-nodes branch.
Nodes:
* Attribute Math
* Boolean
* Edge Split
* Float Compare
* Object Info
* Point Distribute
* Point Instance
* Random Attribute
* Random Float
* Subdivision Surface
* Transform
* Triangulate
It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier.
Notes on the Generic attribute access API
The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).
Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.
It includes commits from:
* Dalai Felinto
* Hans Goudey
* Jacques Lucke
* Léo Depoix
The issue was that the same point cache was read by multiple
threads at the same time (the same object was evaluated for
render and for the viewport).
Both threads incremented PTCacheMem->cur which lead to the crash.
The fix is to remove the PTCacheMem->cur and store it on the
stack instead. This way every thread has its own cur.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D9606
Root of the issue is that point caches are added to the object's list
on-demand, which often ends up with them being added only during
depsgraph evaluation, i.e. on COW objects.
This could result in having 'orig' data caches with invalid/unset stack
index at some points (e.g. when reading a file and applying
liboverrides), leading to discarding valid existing disk cache files.
Fact that one of those index is signed, and the other not, does not
help...
While this is very weak, fixing broken PointCache code is out of the
scope of a bug fix, so this patch merely:
* Simplifies and factorizes the code generating the 'extension' part of
caches filenames;
* Ensures `BKE_object_insert_ptcache` is called when needed so that we
always have a valid stack index to generate that filename extension.
This is only a bandaid, but it is simple and should be safe enough for
now.
Related to T82503.
This code is not used by the new fluid simulation system.
Therefore, it does not make sense to keep it around.
We do want to integrate the fluid system with the generic cache
system eventually, but refactoring the system is easier when there
is less dead code that has to be refactored.
Note, I could not remove BKE_ptcache_id_from_smoke entirely yet,
because the depsgraph seems to expect that object that
uses DEG_add_collision_relations also has a pointcache.
That is because it wants to reset the point cache when any of the
other objects changed (this does not work with fluids currently).
Reviewers: sebbas
Differential Revision: https://developer.blender.org/D8987
The issue was that the pointcache was not storing dead particles,
even though they are displayed. This lead to the rendering issue,
because only alive particles can be read from the point cache in
the frame that is rendered.
This also fixes an issue unrelated to rendering: when dead particles
are displayed, their position is incorrect when some frames are
skipped during playback.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8907
The point cache code needs a non NULL rbw pointer.
This could have been avoided if there was a sanity check in the convert
function, so added a check there as well.
This patch adds a new compound shape entry to the shape selection
dropdown. It also corrects wrong inertia calculation for convex hulls,
that resulted in strange behavior for small objects.
The compound shape take the collision shapes from its object children
and combines them. This makes it possible to create concave shapes from
primitive shapes. Using this instead of the mesh collision shape is
often many times faster.
Reviewed By: Sergey, Sebastian Parborg
Differential Revision: http://developer.blender.org/D5797
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.
`CD_LOCATION` was only used temporarily due to the lack
of a better alternative. This also removes the name from
`CD_LOCATION` again, because at most one layer of this
type should exist.
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.
The new simulation type can also reference a point cache, but it is not an object.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8097
This commit makes uses of the new OpenVDB IO in Mantaflow (introduced in 781f783a66ac).
From now on, fluid cache files in OpenVDB format will contain a list of grids per frame (before: one .vdb file per grid per frame). Besides regular grids, particle systems are also stored using OpenVDBs PointGrid data structures.
All older cache formats will remain fully functional:
- Uni caches (.uni) files are still available from the UI and can be used as before
- Raw caches (.raw) are no longer available from the UI, but loading them is still possible
- Old OpenVDB caches (one .vdb per grid) can no longer be baked either, but loading them is still possible.
It is also no longer possible to choose file formats for 'Noise' and 'Particles'. Instead there are now options to set the file format for 'Volumetric' and for 'Mesh' data.
Known issues (planned to be resolved soon):
- OpenVDB files are currently not taking into consideration the clipping value (FluidDomainSettings). Empty cells are therefore being written too. Depending on the scene, this can make file sizes unnecessarily large.
- Domains are not being exported at their world position. Instead they are always clipped to the origin.
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
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
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
The files are now split up into the following sections:
- `BKE_anim_path.h` and `anim_path.c` for path/curve functions.
- `BKE_anim_visualization.h` and `anim_visualizationanim_path.c` for
animation visualization (mostly motion paths).
- `BKE_duplilist.h` for DupliList function declarations. These were
already implemented in `object_dupli.c`, so they were rather out of
place being declared in `BKE_anim.h` in the first place.
No functional changes.
Unlike Linux where fseek/tell will be either 32 or 64 bit
depending on the target platform, it will always be 32 bit
on windows.
We had some macro magic in BLI_winstuff.h that substituted
them for 64 bit versions, but that is upsetting the system
headers if they get included after BLI_winstuff.h which
is problematic for D6811.
This diff adds proper functions in blenlib and updates
all calls that were using the BLI_winstuff.h header to
gain 64 bit file IO.
note: Anything that was using the 32 bit versions (ie not
including BLI_winstuff.h) will still be using the 32 bit
versions, which is perhaps a good code quality Friday project.
Differential Revision: https://developer.blender.org/D7160
Reviewers: brecht dfelinto
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
Show all memory-related byte size strings calculated with a base of 1024.
Differential Revision: https://developer.blender.org/D5714
Reviewed by Brecht Van Lommel
Issue was exposed by recent own rB03bf84db86b commit, but was actually
present in RNA API for PointCaches since (probably) ages: whole accessor
code here was assuming that owner ID was an Object, when it is actually
a scene for RigidBody simulations...
Had also to make `BKE_ptcache_id_find()` and friends a bit more
flexible, now they also accept a NULL object pointer parameter...
i18n code does not work from threads on some plaforms, so it is disabled
in Blender when called from non-main thread.
Means that we have to go to a slightly different approach, with dirty
tag and generating string on request for UI.
Note: Also had to update the `info` string size, to fit with expensive
asiatic scripts in utf-8... Using mem for that kind of runtime data is
not really nice, but for now it will have to do.
