Though "Point Cloud" written as two words is technically correct and should be used in the UI, as one word it's typically easier to write and parse when reading. We had a mix of both before this patch, so better to unify this as well.
This commit also renames the editor/intern/ files to remove pointcloud_ prefix.
point_cloud was only preserved on the user facing strings:
* is_type_point_cloud
* use_new_point_cloud_type
Pull Request: https://projects.blender.org/blender/blender/pulls/134803
Previously, the code would assert in `BLI_fopen` when the path is relative.
There are two main options to make the path absolute:
1. Always use the path of the current .blend file as base.
2. Is the path of the .blend file "owns" the current node as base. So when
the Import node is part of a linked node tree, the path of the linked .blend
file is used as base.
Both options are useful depending on the specific use-case, but the latter
seems more consistent with other places in Blender. For more advanced
functionality, we might need nodes that give the current .blend file path
and one node to join paths.
Pull Request: https://projects.blender.org/blender/blender/pulls/134794
Restriction of the nodes api to clearly define never-null function arguments.
Side effects: some assertions and null-check (with early return) were removed.
On the caller side is ensured to never derefer null to pass argument (mainly in RNA).
In addition, one pointer argument now actually a return type.
By-reference return types instead of pointers going to be separate kind of
change since also imply of cleaning up variables created from reference.
Also good future improvement would be to mark a copy-constructor as
explicit for DNA node types.
Pull Request: https://projects.blender.org/blender/blender/pulls/134627
Previously we generally expected CustomData layers to have implicit
sharing info, but we didn't require it. This PR clarifies that we do
require layers with non-null data to have implicit sharing info. This
generally makes code simpler because we don't have to have a separate
code path for non-shared layers. For example, it makes the "totelem"
arguments for layer freeing functions unnecessary, since shared data
knows how to free itself. Those arguments are removed in this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134578
When calling the `lookup_or_add` functions on `MutableAttributeAccessor`
we need to make sure that the writer is actually created and the call
did not fail.
This fixes many of the instances where we would use an unchecked
attribute writer and potentially crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/134413
Collapsing curves to a single point when just resampling is unexpected. This
patch changes it so that non-zero-length curves keep at least one segment.
The fix is fairly straight forward, but a bunch of additional code is added to
support the legacy option to avoid breaking backward compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/133659
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Currently UI code always has to use char pointers when interacting with
the translation system. This makes benefiting from the use C++ strings
and StringRef more difficult. That means we're leaving some type safety
and performance on the table. This PR adds StringRef overloads to the
translation API functions and removes the few calls to `.c_str()` that
are now unnecessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/133887
It already doesn't work in a very fairly simple case when the Grease Pencil
geometry is transformed. This simple case used to work before we changed
the Transform Geometry node to transform layers instead of points.
Pull Request: https://projects.blender.org/blender/blender/pulls/134131
Previously, when evaluated on the face corner domain, the normal input
node just returned the face normals, as if the mesh was completely flat
shaded. This ignores face and edge smoothness, and custom face corner
normals. In the past couple years the expected behavior of accessing
normals has become much clearer and this behavior is clearly a mistake
in retrospect.
This commit exposes the same face corner normals used everywhere else
in Blender when the node is evaluated on the corner domain. The old
behavior is accessible with a node property in the sidebar. There is
versioning so old files have the property set and get the same results.
This is split from !132583.
Pull Request: https://projects.blender.org/blender/blender/pulls/133340
Numerical instability mainly comes from adding values together which have very
different magnitude. There are algorithms to keep the error small like "Kahan
Summation", however those are also slower because of additional code in the hot
loop. This patch implements a simpler approach that is slightly less accurate,
but still seems to solve the cases that people commonly run into while being
simpler and faster. The approach is to simply compute a couple partial sums
first, and to add those up in the end. The individual partial sums can also be
computed in parallel. Care has to be taken to maintain determinism with floating
point values.
If accuracy is still not enough for some use cases, we can revisit this later
and e.g. use doubles or a better summation algorithm.
Pull Request: https://projects.blender.org/blender/blender/pulls/132759
This makes specifying a legacy type for new node types optional (e.g.
`GEO_NODE_MESH_TO_CURVE`). Instead, only the `idname` is used as a stable
identifier for node types. So there is less redundancy for now.
This change helps with the decentralized definition of nodes and reduces the
number minimum number of files that need to be changed for a new node from 5 to
4. It especially helps when multiple nodes are worked on at the same time,
because the legacy type definition was very prone to have merge conflicts.
For compatibility reasons and because it's still used by existing code, the
`legacy_type` is not removed. All existing nodes keep their current
`legacy_type`. New nodes will receive an auto-incremented legacy type. It's
still necessary to give nodes unique legacy types, because some code checks if
two nodes have the same type by comparing their `legacy_type`. These types only
have to be unique at run-time though. Some randomness is used to avoid depending
on stable generated legacy types accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/133044
The Warning geometry node uses its warning type as label. These enum
items were extracted using the default context, but translated using
"Nodetree". The items Warning, Info and Error, should be quite
unambiguous and translated using the default context instead.
In addition, a string "Unknown" was translated twice. Replace one of
those translations with a simple `N_()` extraction macro.
"Smooth" can be many things, but mostly a verb or adjective depending
on context.
Already handled in the past, but some things were missed or introduced
since then.
- "Cross" can refer to a cross shape "+" in the context of a gizmo or
a particle display mode.
- In the context of a sequence, refers to a blending mode (cross
fade).
Issue reported by Hoang Duy Tran.
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
This removes the second to last usage of `NOD_static_types.hh` which we intend
to remove. A nice benefit is that the idname is now finally more explicit when a
node is registered. Previously it was difficult to search for the definition of
a node in the code when one had only the idname, which is the main identifier
for nodes.
The main change is in `node_type_base`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132815
As part of an effort to remove this header, reducing the need for macro/
include magic and making node definitions more independent, move
the node UI name and description definitions to each node's file.
The UI name, description, and idname are also moved to std::string
instead of char arrays.
Similar to b43e2168e3.
Pull Request: https://projects.blender.org/blender/blender/pulls/132708
Make the type structs non-trivial, use new and delete for allocation and
freeing, and use std::string for most strings they contain. Also use
StringRef instead of char pointers in a few places. Mainly this improves
ergonomics when working with the strings.
Pull Request: https://projects.blender.org/blender/blender/pulls/132750
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
The issue was that the propagation of referenced anonymous attributes treated
geometry outputs of the foreach zone as "normal". That means that every
anonymous attributes referenced by the input socket would also be referenced by
the output socket.
However, just like in the repeat zone, this so called "propagate relation" needs
some special behavior, because anonymous attributes references created inside a
zone have to remain inside that zone. Instead, the output node creates a new
anonymous attribute reference that is used outside of the zone.
Note, this is the same as #132560 but also implements the right-to-left pass,
whereas before only the left-to-right pass was implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/132607
The issue was that the propagation of referenced anonymous attributes treated
geometry outputs of the foreach zone as "normal". That means that every
anonymous attributes referenced by the input socket would also be referenced by
the output socket.
However, just like in the repeat zone, this so called "propagate relation" needs
some special behavior, because anonymous attributes references created inside a
zone have to remain inside that zone. Instead, the output node creates a new
anonymous attribute reference that is used outside of the zone.
Pull Request: https://projects.blender.org/blender/blender/pulls/132560
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
