| Age | Commit message (Collapse) | Author |
|---|
|
Solves compilation warning with Clang, and moves manipulation with
DNA structures to the designed way for C++.
The tests and few other places are update to the new code by Jacques.
Ref T96847
Maniphest Tasks: T96847
Differential Revision: https://developer.blender.org/D14625
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Differentiate doc-strings from title/section text.
Also use explicit doxygen references to struct members
so it's not ambiguous which member is being referenced.
Note that these changes aren't complete (some files weren't touched).
|
|
Some DNA headers already did this, most did not. Even though many of them would
be included in C++ files and thus compiled as C++. This would be confusing and
developers may think they have to add `extern "C"` too a whole lot of
(indirect) includes to be able to use a C header in C++.
However, this is a misconception.
`extern "C"` does not cause code to be compiled with C rather than C++! It only
causes the linker to not use C++ function name mangling. See
https://stackoverflow.com/a/1041880.
Because extern DNA headers don't have function declarations, using `extern "C"`
actually should not have any effect. On the other hand, adding it causes no
harm and avoids confusion. So let's just have it consistently in C header
files.
Differential Revision: https://developer.blender.org/D9578
Reviewed by: Bastien Montagne, Sybren Stüvel
|
|
The design for how we approach the "Everything Nodes" project
has changed. We will focus on a different part of the project initially.
While future me will likely refer back to some of the code I remove here,
there is no point in keeping this code around in master currently.
It would just confuse other developers working on the project.
This does not remove the simulation modifier and data block. Those are
just cleaned up, so that the boilerplate code can be reused in the future.
|
|
|
|
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
|
|
|
|
I'll really have to refactor `ntreeUpdateTree` soon to avoid scanning
all node trees multiple times.
|
|
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 adds a basic internal emitter for every particle simulation.
The emitter cannot be controlled by the user yet. That will
come next.
|
|
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.
|
|
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
|
|
This adds an embedded node tree to the simulation data block dna.
The UI in the `Simulation Editor` has been updated to show a list
of simulation data blocks, instead of individual node trees.
The new `SpaceNodeEditor.simulation` property wraps the existing
`SpaceNodeEditor.id` property. It allows scripts to get and set
the simulation data block that is being edited.
Reviewers: brecht, mont29
Differential Revision: https://developer.blender.org/D7301
|
|
This data block will be the container for simulation node trees.
It will be used for the new particle node system (T73324).
The new data block has the type `ID_SIM`.
It is not visible to users and other developers by default yet.
To enable it, activate the cmake option `WITH_NEW_SIMULATION_TYPE`.
New simulation data blocks can be created by running `bpy.data.simulations.new("name")`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7225
|
