The translate node moves every point in the geometry, and the scale
node multiplies the "scale" attribute of the input geometry by its input.
While these operations are already possible with the "Attribute" nodes,
these new nodes fit nicely with the nodes specifically for changing the
"rotation" attribute that already exist, and they provide a simpler way
to do the same thing.
Differential Revision: https://developer.blender.org/D10100
This adds a new Align Rotation to Vector node based on the mockup
in T83669.
Reviewers: HooglyBoogly, simonthommes
Differential Revision: https://developer.blender.org/D10081
This patch implements the same operations and interface as the regular
vector math node, but it runs for every element of the attribute. This
should expand what's possible with geometry nodes quite a bit.
Differential Revision: https://developer.blender.org/D9914
No ID (even remotely) related to Main database should ever be created
directly through MEM_mallocN. Using `BKE_libblock_alloc` is the bare
minimum.
Note that there is no behavior change expected here.
This node updates the "rotation" attribute on points.
Multiple ways to specify the rotation are supported.
Differential Revision: https://developer.blender.org/D9883
Ref T83668.
This new node increases the radiance of an image by a scalar value.
Previously, the only way to adjust the the exposure of an image was with
math node or using the scene's color management.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D9677
Ref: T82651
Normally people use "Combine XYZ" to input a vector, but it is more
interesting to have an explicit vector input.
So this is basically "Combine XYZ" without any input sockets, the values
are stored in the node itself.
Differential Revision: https://developer.blender.org/D9885
This patch adds two related nodes, a node for separating points
and mesh vertices based on a boolean attribute input, and a node
for creating boolean attributes with comparisons.
See the differential for an example file and video.
Point Separate (T83059)
The output in both geometries is just point data, contained in the mesh
and point cloud components, depending which components had data in the
input geometry. Any points with the mask attribute set to true will be
moved from the first geometry output to the second. This means that
for meshes, all edge and face data will be removed. Any point domain
attributes are moved to the correct output geometry as well.
Attribute Compare (T83057)
The attribute compare does the "Equal" and "Not Equal" operations by
comparing vectors and colors based on their distance from each other.
For other operations, the comparison is between the lengths of the
vector inputs. In general, the highest complexity data type is used
for the operation, and a new function to determine that is added.
Differential Revision: https://developer.blender.org/D9876
The matte_id is stored in a different structure in 2.92. This patch will
write the old matte_id field so the files can be opened correctly in
older versions.
Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
The implementation is pretty much the same as for Object sockets.
The socket color is the one that is used for collections in the outliner.
Part of D9739.
This node can be used to mix two attributes in various ways.
The blend modes are the same as in the MixRGB shader node.
Differential Revision: https://developer.blender.org/D9737
Ref T82374.
The parameter type was incorrectly changed in rB6be56c13e96048cbc494ba5473a8deaf2cf5a6f8 by me.
This can be any id and does not have to be a node tree.
This commit adds a node that fills every element of an attribute
with the same value. Currently it supports float, vector, and color
attributes. An immediate use case is for "billboard" scattering.
Currently people are using the same input to a Random Attribute node's
min and max input to fill every element of a vector with the same value,
which is an unintuitive way to accomplish the same thing.
Differential Revision: https://developer.blender.org/D9790
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
Don't refresh the list of sockets, so that when the .blend file is restored the
links remain valid. Also display such nodes in red to indicate an error, same
as when the node type info is missing.
This is essentially adding that new callback, and using it only for already
existing Scene's 3DCursor.
Note that the place where this is called has been moved again, after all
have been lib-linked, such that those callbacks may also work on ID pointers.
Maniphest Tasks: T71759
Differential Revision: https://developer.blender.org/D9237
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.
Note that possibility to pass the new ID pointer as parameter was kept,
as this is needed for some rather specific cases (like in depsgraph/COW,
when copying into already allocated memory).
Part of T71219.
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
Add a `NOLINT` marker to explicitly silence a warning from Clang-Tidy's
`readability-function-size` rule for the `node_type_base()` function.
This function is indeed huge, but that is because a lot of macros are
expanded. Before expansion things are still not small, but still
understandable & expandable.
No functional changes.
The hardcoded age limit is now gone. The behavior can be implemented
with an Age Reached Event and Kill Particle node. Other utility nodes
to handle age limits of particles can be added later. Adding an
Age Limit attribute to particles on birth will be useful for some effects,
e.g. when you want to control the color or size of a particle over its
life time.
The Random Float node takes a seed currently. Different nodes will
produce different values even with the same seed. However, the same
node will generate the same random number for the same seed every
time. The "Hash" of a particle can be used as seed. Later, we'd want
to have more modes in the node to make it more user friendly.
Modes could be: Per Particle, Per Time, Per Particle Per Time,
Per Node Instance, ...
Also a Random Vector node will be useful, as it currently has to be
build using three Random Float nodes.
The following nodes work now (although things can still be improved of course):
Particle Birth Event, Praticle Time Step Event, Set Particle Attribute and Execute Condition.
Multiple Set Particle Attribute nodes can be chained using the "Execute" sockets.
They will be executed from left to right.
A simulation data block has an embedded node tree, which requires
special handling in a couple of places. Some of those places were
missing beforehand.
This also adds a relation to make sure that the simulation is evaluated
after animations on the embedded node tree are evaluated.
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.
Since the function only iterates over the input members,
and matches their identifiers, `bNode *`can be `const`.
All other usages of the `nodeFindSocket` use it with
other functions that modify the node. (e.g.: ``nodeAddLink` )
But an exporter needs the node to be a `const`, so this
creates unnecessary and slightly unsafe design changes.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D8142
- no sockets on Frame nodes
- no Input sockets on Group Input nodes
- no Output sockets on Group Output nodes
Maniphest Tasks: T76538
Differential Revision: https://developer.blender.org/D7671
