Correct trim for cyclical curves mentioned in T101379, splitting the
curves if the start/endpoint is at the 'loop point'.
Correct implementation based on comments in D14481, request was made to
use 'foreach_curve_by_type' to computing the point lookups.
Included corrections from D16066 as it may not be a adopted solution.
Exposed selection input by adding it as input to the node.
Note: This is disabled for 3.4 to avoid making UI changes in Bcon3.
Differential Revision: https://developer.blender.org/D16161
The preferred domain is used to decide which domain the viewer node
should use when set to "Auto" domain. This commit adds it to some curve
input nodes and the curve and mesh topology nodes. This makes debugging
node setups with these nodes a bit faster and less frustrating.
The "all curve" sampling is implemented as two functions internally.
The first finds which curve each "global" sample should be on. Then
the second is the regular evaluation and sampling in that curve.
The first operations creates lengths, but they were processed as
factors when passed to the second function.
The node has always be a bit confusing for the NURBS case, since it
uses the distance between control points since the evaluated/control
point mapping isn't obvious, but it also went above 1, which wasn't
correct.
Instead, retrieve the total length from the point lengths calculated
in the previous step. The results should be the same for other curve
types.
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
The goal is to improve clarity and readability, without
introducing big design changes.
Follows the recent obmat to object_to_world refactor: the
similar naming is used, and it is a run-time only rename,
meaning, there is no affect on .blend files.
This patch does not touch the redundant inversions. Those
can be removed in almost (if not all) cases, but it would
be the best to do it as a separate change.
Differential Revision: https://developer.blender.org/D16367
As described in T92474 and T91650, this patch adds two features to the
sample curve node. First is an index input, to allow choosing the curve
to sample for each point. Second is a custom field input, which is
evaluated on the control points of the curve and then sampled like the
other outputs. There is an "All Curves" option for the old behavior
which takes the length of all curves into account.
For invalid curve indices, the node outputs zeros (default values).
Invalid lengths and factors are clamped.
There have been various discussions about splitting the node up more,
but this is an intuitive combination of options and will work well
enough for current use cases. The node could still be generalized more
in the future.
Keep in mind that the source field is evaluated on curve control points,
not the evaluated points used for sampling. This is necessary so that
fields like "Index" work as expected.
Differential Revision: https://developer.blender.org/D16147
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
Retrieve the surface UV coordinates with the attribute API instead of
the helper function. This allows more flexibility of data types (and
domains), which is helpful especially because geometry nodes
can't write 2D vectors yet.
This patch implements the normalize node for the realtime compositor.
Differential Revision: https://developer.blender.org/D16279
Reviewed By: Clement Foucault
This patch implements the tone map node for the realtime compositor
based on the two papers:
Reinhard, Erik, et al. "Photographic tone reproduction for digital
images." Proceedings of the 29th annual conference on Computer graphics
and interactive techniques. 2002.
Reinhard, Erik, and Kate Devlin. "Dynamic range reduction inspired by
photoreceptor physiology." IEEE transactions on visualization and
computer graphics 11.1 (2005): 13-24.
The original implementation should be revisited later due to apparent
incompatibilities with the reference papers, which makes the operation
less useful.
Differential Revision: https://developer.blender.org/D16306
Reviewed By: Clement Foucault
Attribute copying often uses identical logic for copying selected
elements or copying with an index map. Instead of reimplementing
this in each file, use the common implementation in the array_utils
namespace. This makes the commonality more obvious, gives improved
performance (this implementation is multithreaded), reduces binary
size (I observed a 173KB reduction), and probably reduces compile time.
String attributes are intentionally not fully supported in geometry nodes
yet because more design work is necessary to decide how they should behave.
For now just disable handling string attributes to avoid crashes.
There might be more or fewer curves in the input to the deform curves on
surface node than the original, so the curve's surface UV coordinates
need to be retrieved from the original curves.
A vertex might be connected to no edges or no faces. Most of these nodes
worked fine in that case, but we might as well make that explicit
and skip the sorting anyway.
This makes instance handling more consistent with all the other geometry
component types. For example, `MeshComponent` contains a `Mesh *` and
now `InstancesComponent` has a `Instances *`.
Differential Revision: https://developer.blender.org/D16137
Resolve by setting no_muted_links() on Factor sockets.
Same issue as T101613
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D16153
Currently, the scale node always changes the interpolation of its result
to bilinear. This was done because the scale node does not have an
interpolation option, unlike the Transform node, so a default of
bilinear was assumed. This turned out to be problematic, because in the
pixelation use cases, a nearest interpolation is typically preferred by
the user.
This patch changes the default interpolation of input nodes to bilinear,
makes the scale node keep the interpolation of the input it receives,
and makes the pixelate node changes the interpolation to nearest. In
effect, for non-pixelation use cases, the default bilinear interpolation
will be used, and for pixelation use cases, the nearest interpolation
will be used unless explicitly specified using a node that sets the
interpolation.
Currently there is no way to tell that these node types are deprecated
in the UI. This commit adds "(Legacy)" to the end of the names.
It also makes it simple to skip these in the various node searches
more automatically than before.
Fixes T101700
Differential Revision: https://developer.blender.org/D16223
Besides texture nodes, which aren't supported anyway, we don't have any
builtin nodes that still use the socket template system, so this can be
removed.
This lowers the search weight for color-specific
mix functions on non-color sockets.
Reported in blender.chat by simonthommes
Differential Revision: https://developer.blender.org/D16228
This patch implements the variable size blur option in the Bokeh Blur
node. The implementation is different from the CPU one in that it also
takes the Bounding Box input into account, which is ignored for some
reason for the CPU. Additionally, this implementation does not do the
optimization where the search radius is limited relative to the maximum
value in the size texture. That's because the cost of computing the
maximum is not worth it for most use cases.
The reference implementation does three unexpected things that are
replicated here nonetheless. First, the center bokeh weight is always
ignored and assumed to be 1. Second the size of the center pixel is
taken into account. Third, a unidimensional distance is used instead of
a 2D euclidean one. Those need to be considered independently.
Differential Revision: https://developer.blender.org/D16185
Reviewed By: Clement Foucault
This patch implements generic parallel reduction for the realtime
compositor and implements the Levels operation as an example. This patch
also introduces the notion of a "Compositor Algorithm", which is a
reusable operation that can be used to construct other operations.
Differential Revision: https://developer.blender.org/D16184
Reviewed By: Clement Foucault
Allows searching for Mix blend modes
e.g. Overlay when using link drag search
Requested by @simonthommes in GN chat
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D16209
The attribute node already allows accessing attributes associated
with objects and meshes, which allows changing the behavior of the
same material between different objects or instances. The same idea
can be extended to an even more global level of layers and scenes.
Currently view layers provide an option to replace all materials
with a different one. However, since the same material will be applied
to all objects in the layer, varying the behavior between layers while
preserving distinct materials requires duplicating objects.
Providing access to properties of layers and scenes via the attribute
node enables making materials with built-in switches or settings that
can be controlled globally at the view layer level. This is probably
most useful for complex NPR shading and compositing. Like with objects,
the node can also access built-in scene properties, like render resolution
or FOV of the active camera. Lookup is also attempted in World, similar
to how the Object mode checks the Mesh datablock.
In Cycles this mode is implemented by replacing the attribute node with
the attribute value during sync, allowing constant folding to take the
values into account. This means however that materials that use this
feature have to be re-synced upon any changes to scene, world or camera.
The Eevee version uses a new uniform buffer containing a sorted array
mapping name hashes to values, with binary search lookup. The array
is limited to 512 entries, which is effectively limitless even
considering it is shared by all materials in the scene; it is also
just 16KB of memory so no point trying to optimize further.
The buffer has to be rebuilt when new attributes are detected in a
material, so the draw engine keeps a table of recently seen attribute
names to minimize the chance of extra rebuilds mid-draw.
Differential Revision: https://developer.blender.org/D15941
The name of the node group in the geometry nodes logger is created
in `GeoModifierLog::get_local_tree_logger`, where it references the
compute context. However, the compute context is a local variable
that doesn't live as long as the log. Therefore the log needs to own
the node group name.
Removing the ownership from `NodeGroupComputeContext` may be
possible as well, but seems less obviously correct. This can be a
temporary solution until we can completely avoid storing strings
in the logger (see D15775).
Fixes T101599
Unfortunately this commit changed behavior in a fundamental way that
can't be addressed without larger changes. Previously the position
outputs were evaluated on the edge domain and then interpolated to the
context domain, which could be useful for some rudimentary mesh smoothing.
After the commit they were just evaluated at the specified index, which
looks practically random when evaluated on a different domain. We may need
a new node that doesn't have the implicit behavior in the future.
This reverts commit 4ddc5a936e.
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
Previously the edge index was always determined by the field context,
and the node didn't work when the context was in any other domain.
Adding an index input makes it work much more nicely with the other
topology nodes. It's now in the topology submenu too.
I also reimplemented the edge positions input to use the field at index
node internally. That will probably make it slower for now, but we need
to optimize that to do nothing in some special cases anyway.
Differential Revision: https://developer.blender.org/D16105
