Node socket tooltips suffered from several issues.
- Some could not be translated because they were not properly
extracted, so extraction macros were added.
- Some were extracted but included newlines at the end which did not
get translated, such as `ss << TIP_("Geometry:\n")`, changed to
`ss << TIP_("Geometry:") << "\n"`.
- Some translations were not functional, such as:
`TIP_(attributes_num == 1 ? " Named Attribute" : " Named Attributes");`
because `TIP_()` needs to be around a single string.
- Some extraction macros had no effect and were removed, such as:
`.description(N_(leading_out_description));`
This is a no-op macro which can be used only around a string literal.
Pull Request: https://projects.blender.org/blender/blender/pulls/107257
It arguably reads easier if simple operations like reading from indices
of an array don't each get their own line. Also the same corner
attribute sampling was repeated in a few places. And add a new
function to sample normals from the corner domain, and use
lower level arguments to the lower level functions (i.e. not just
a mesh pointer, but the necessary data arrays).
Usually anonymous attributes are removed earlier, but otherwise
the extrude node can end up doing extra work.We need to retrieve the
propagation set and remove not-propagated attributes. And also fix
a case where in vertex mode, the offsets array could be freed when
the mesh is resized.
Use a grain size for the final tree creation/balancing/lookup that
depends on the average size of each tree. When the trees are larger,
fewer trees are processed on each thread and vice versa. I didn't notice
a difference when there are hundreds of thousands of groups, but
when there are few (i.e. around the number of cores), I noticed a 6x
performance improvement, from over 1 second to around 0.2 s.
Note that generally the performance is better with many small groups,
because the creation and balancing of trees is single threaded.
If the Group ID input isn't a single value, it's likely to be a span,
so making sure that's true should generally be free, at least in
most cases. This brought a test with 1 million points from 37
to 34 ms, roughtly an 8% improvement.
Currently `Mesh to Volume` creates a volume using
`openvdb::tools::meshToVolume` which is then filled with the specified
density and the class set to Fog Volume. This is wrong because
`meshToVolume` creates a signed distance field by default that needs
to be converted to a Fog Volume with `openvdb::tools::sdfToFogVolume`
to get a proper Fog volume.
Here is the description of what that function does (from OpenVDB):
"The active and negative-valued interior half of the narrow band
becomes a linear ramp from 0 to 1; the inactive interior becomes
active with a constant value of 1; and the exterior, including the
background and the active exterior half of the narrow band, becomes
inactive with a constant value of 0. The interior, though active,
remains sparse."
This means with this commit old files will not look the same.
There is no way to version this as the options for external band width
and not filling the volume is removed (they don't make any sense for a
proper fog volume).
Pull Request: https://projects.blender.org/blender/blender/pulls/107279
The String to Curves node allows selecting various metrics for the
characters. Size is the absolute height between two lines, and is
correctly marked as a distance. Character, Word and Line Spacing, on
the other hand, do not represent any distance, but are proportional to
the base size and should not have distance units.
This commit simply removes the properties' `PROP_DISTANCE` subtype.
Pull Request: https://projects.blender.org/blender/blender/pulls/106660
Many nodes output anonymous attributes (e.g. the top selection in the
Cylinder node). The actual data is only contained in the geometry output
though. The field output just contains a reference to this data (essentially
just the generated name of an attribute). This data can be output even
without computing the geometry itself.
As of right now, this only simplifies the code a bit, but does not have a
bigger impact, because to use the anonymous attribute, you always need
the geometry anyway. However, with the upcoming simulation nodes,
it's possible to create the anonymous attribute in one frame and to access
it in another frame. In the other frame we only need the anonymous
attribute reference and don't have to create the actual geometry again.
Skipping creating the actual attribute on the geometry can have a
significant performance benefit.
- Implement mesh creation in GeometrySet agnostic way, with less context
- Remove useless comments
- Use a field to clamp crease values instead of clamping when copying
- Small variable name tweaks
- Use `BKE_subdiv_new_from_mesh` instead of "update"
- Remove crease layers before writing, avoiding potential copy
Similar to the cache of loose edges added in 1ea169d90e,
cache the number of loose vertices and which are loose in a bit map.
This can save significant time when drawing large meshes in the
viewport, because recalculations can be avoided when the data doesn't
change, and because many geometry nodes set the loose geometry
caches eagerly when the meshes contain no loose elements.
There are two types of loose vertices:
1. Vertices not used by any edges or faces
`Mesh.loose_verts()`
2. Vertices not used by any faces (may be used by loose edges)
`Mesh.verts_no_face()`
Because both are used by Blender in various places, because the cost
is only a bit per vertex (or constant at best) and for design consistency,
we cache both types of loose elements. The bit maps will only be
allocated when they're actually used, but they are already accessed
in a few important places:
- Attribute domain interpolation
- Subdivision surface modifier
- Viewport drawing
Just skipping viewport drawing calculation after certain geometry
nodes setups can have a large impact. Here is the time taken by
viewport loose geometry extraction before and after the change:
- 4 million vertex grid node: 28 ms to 0 ms
- Large molecular nodes setup (curve to mesh node): 104 ms to 0 ms
- Realize instances with 1 million cubes: 131 ms to 0 ms
Pull Request: https://projects.blender.org/blender/blender/pulls/105567
The node outputs the index of the closest element to itself. See #102387
for the original design.
This is different from the Sample Nearest node in two important ways:
* It does not have a geometry input, instead the geometry is taken from the
field evaluation context.
* The node can exclude the "current" element from the search.
* The group id input can be used to build subsets of elements that only
consider each other as neighbors and ignore elements with other ids.
Pull Request: https://projects.blender.org/blender/blender/pulls/104619
Whether the outputs are fields only depends on whether at least one of the
last three inputs is a field. It does not matter whether the `Value` input is
a field.
Pull Request: https://projects.blender.org/blender/blender/pulls/106007
The typical order is vertex, edge, face(polygon), corner(loop), but in
these three functions polys and loops were reversed. Also use more
typical "num" variable names rather than "len"
Add the ability to retrieve implicit sharing info directly from the
C++ attribute API, which simplifies memory usage and performance
optimizations making use of it. This commit uses the additions to
the API to avoid copies in a few places:
- The "rest_position" attribute in the mesh modifier stack
- Instance on Points node
- Instances to points node
- Mesh to points node
- Points to vertices node
Many files are affected because in order to include the new information
in the API's returned data, I had to switch a bunch of types from
`VArray` to `AttributeReader`. This generally makes sense anyway, since
it allows retrieving the domain, which wasn't possible before in some
cases. I overloaded the `*` deference operator for some syntactic sugar
to avoid the (very ugly) `.varray` that would be necessary otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/107059
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
Previously, there was a "main" and "tmp" buffer and the final
result was expected to be in the "main" buffer. Now the two buffers
are called a and b and the final result can be in either of those.
This can improve performance especially if the number of iterations is low.
Pull Request: https://projects.blender.org/blender/blender/pulls/106860
Fixes a bug introduced in b0b9e746fa.
The volume transformation matrix is multiplied in the wrong order
which means the grid scale is applied on the translation.
Similar to 7eee378ecc, this change decreases memory usage and
improves performance when copying curves and meshes without changing
their topology. The same change used for custom data layers is applied
to face and curve offset indices, which aren't stored as a custom data
layer.
The implicit sharing info for the offsets is stored in the mesh and
curve runtime structs, since it doesn't need to be written to files
directly. When changing the offsets pointer directly, the sharing info
must be updated accordingly. To make that easier, a few utility
functions take care of common operations like making an array mutable,
resizing an array, and creating sharing info for allocated data.
This commit also clarifies the intention to not allocate the offsets
at all when there are no curves/faces. That slightly complicates some
of the logic, but there's no reason for the single `0` integer to be
allocated.
Pull Request: https://projects.blender.org/blender/blender/pulls/106907
The extrude node resizes an existing mesh, but doesn't initialize new
data for most non-generic data types like shape keys or freestyle tags,
or custom normals. The split edges node doesn't process some
similar vertex data too.
In the future this data can become generic attributes, or it can be
supported in the nodes anyway. But now the new data is un-initialized
after being allocated.
Fixes#106926
The position attribute has special meaning for point clouds, and
meshes and curves have access methods for the attribute as well.
This saves boilerplate and gives more consistency between types.
- "Lens" can be a transparent object used in cameras, or specifically
its property of focal length
- "Empty" can be an adjective meaning void, or an object type. The
latter is already disambiguated using `ID_ID`
- "New" and "Old" are adjectives that can have agreements in some
languages
- "Modified" is an adjective that can have agreement in some languages
- "Clipping" can be a property of a camera, or a behavior of the
mirror modifier
- "Value" in HSV nodes, see #105113
- "Area" in the Face Area geometry node, can mean a measurement or a
window type
- "New" is an adjective that can have agreement
- "Tab" can be a UI element or a whitespace character
- "Volume" can mean a measurement or an object type. The latter is
already disambiguated using `ID_ID`
These changes introduce the new `BLT_I18NCONTEXT_TIME` translation
context.
They also remove `BLT_I18NCONTEXT_VIRTUAL_REALITY`, which I added at
one point but then couldn't find which messages I wanted to fix with
it.
Ref #43295
Pull Request: #106718
Implements #95967.
Currently the `MPoly` struct is 12 bytes, and stores the index of a
face's first corner and the number of corners/verts/edges. Polygons
and corners are always created in order by Blender, meaning each
face's corners will be after the previous face's corners. We can take
advantage of this fact and eliminate the redundancy in mesh face
storage by only storing a single integer corner offset for each face.
The size of the face is then encoded by the offset of the next face.
The size of a single integer is 4 bytes, so this reduces memory
usage by 3 times.
The same method is used for `CurvesGeometry`, so Blender already has
an abstraction to simplify using these offsets called `OffsetIndices`.
This class is used to easily retrieve a range of corner indices for
each face. This also gives the opportunity for sharing some logic with
curves.
Another benefit of the change is that the offsets and sizes stored in
`MPoly` can no longer disagree with each other. Storing faces in the
order of their corners can simplify some code too.
Face/polygon variables now use the `IndexRange` type, which comes with
quite a few utilities that can simplify code.
Some:
- The offset integer array has to be one longer than the face count to
avoid a branch for every face, which means the data is no longer part
of the mesh's `CustomData`.
- We lose the ability to "reference" an original mesh's offset array
until more reusable CoW from #104478 is committed. That will be added
in a separate commit.
- Since they aren't part of `CustomData`, poly offsets often have to be
copied manually.
- To simplify using `OffsetIndices` in many places, some functions and
structs in headers were moved to only compile in C++.
- All meshes created by Blender use the same order for faces and face
corners, but just in case, meshes with mismatched order are fixed by
versioning code.
- `MeshPolygon.totloop` is no longer editable in RNA. This API break is
necessary here unfortunately. It should be worth it in 3.6, since
that's the best way to allow loading meshes from 4.0, which is
important for an LTS version.
Pull Request: https://projects.blender.org/blender/blender/pulls/105938
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
Now that mesh primitive nodes calculate their bounds in constant time,
it's worth updating the bounds eagerly when translating a geometry
since doing so should be very cheap and might save a more significant
amount of time if they're needed later.
Also slightly unify the translation functions for the different types.
Pull Request: https://projects.blender.org/blender/blender/pulls/106159
Standardize naming, use spans and references for input parameters,
and improve documentation. Now the functions expect the lookups to
succeed as well, they will fail and assert otherwise.
The functions are also simple enough that it likely makes sense to keep
them all inlined
Strict compiler was generating possible-uninitialized warning.
Added an explicit initialization and asserts to solve the noisy
output and catch possible errors early on.
Pull Request: https://projects.blender.org/blender/blender/pulls/105990
