"Solidify" modifier in "Complex" mode was creating redundant layer
"bevel_weight_edge.001", if mesh has bevel weights for vertex set.
All modifier's custom edge bevel weight calculations went there and got lost.
Pull Request: https://projects.blender.org/blender/blender/pulls/115178
This struct is currently defined in the `functions` module but not actually used there. It's only used by the geometry nodes module, with an indirect dependency from blenkernel via simulation zone baking. This scope is problematic when adding grids as socket data, which should not be part of the functions module.
The `ValueOrField` struct is now moved to blenkernel, so it can be more easily extended to other kinds of data that might be passed around by geometry nodes sockets in future. No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115087
Use float3, float3x3, and Array for data used for mesh crazyspace
calculation. Propagate the change wherever necessary to not add
more casting to the old C types.
Because `ObjectRuntime` (and therefore `DEGObjectIterData`) became
non-trivial structs, the code that swaps iterators for RNA depsgraph
object iteration had to be changed a bit to be more friendly to C++
memory semantics.
Pull Request: https://projects.blender.org/blender/blender/pulls/114998
Move object runtime data to a separate header and allocate it separately
as `blender::bke::ObjectRuntime`. This is how node, mesh, curves, and
point cloud runtime data is stored.
Benefits:
- Allow using C++ types in object runtime data
- Reduce space required for Object struct in files
- Increase conceptual separation between DNA and runtime data
- Remove the need to add manual padding in runtime data
- Include runtime struct definition only in files that require it
Pull Request: https://projects.blender.org/blender/blender/pulls/113957
Cleanup talked about in the previous semi-related PR, #114501
- saacos, saasin, sasqrt have been 100% identical to saacosf,
saasinf, sasqrtf since 2012.
- For all the above, there exist more intuitively named safe_acosf,
safe_asinf, safe_sqrtf that do the same thing, so switch all code to those.
Pull Request: https://projects.blender.org/blender/blender/pulls/114593
Function Module Inclusive Time Exclusive Time
--------------------------------------------------------------------------
mesh_render_data_update_normals blender 297.51 0.00
315 -> 297
acos() usage in all places related to normal calculations shows up in the
profiler. Given that "angle between faces" is only additional heuristic
weight in there (the effect of it at all is very subtle), approximate but
faster version of acos() might be just fine. Especially since some other
parts of Blender (e.g. mikktspace) use approximate acos in a conceptually
the same part.
- Adds safe_acos_approx() to BLI_math_base.hh. Implementation the same
as already exists in Cycles; max error 0.00258 degrees. Between 2x and 4x
faster in my tests.
- Changes all normals related calculations to use the function above instead
of saacos.
Computing normals on a Stanford Lucy (14m verts) mesh:
- Mac (arm64, M1 Max): 247ms -> 229ms
- Win (x64, Ryzen 5950X): 276ms -> 250ms
All places that are about "normal calculation" were changed, including e.g.
Corrective Smooth modifier. Applying that one to the same 14m vertices mesh,
Mac M1 Max: 9.96s -> 9.76s
Tiny changes in several test output expectations w.r.t. normals are
observed, these were reviewed and updated expectations checked in svn.
Pull Request: https://projects.blender.org/blender/blender/pulls/114501
Each node group asset exposes various properties through sockets.
Although they can generally be considered user-created data, for
built-in assets they are also part of the UI and should be
translated--especially since more modifiers should be migrated to
Geometry Nodes in the future.
This commit enables the translation of those properties in the
Modifier Properties editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/114256
The issue crash was caused by non-safe cast from a bare C array
float[4][4] to float4x4*. Such cast is not safe because it might
break alignment.
Modified the code so that the transform matrices are passed by
value.
Technically it could mean higher memory usage, but odds that the
actual geometry which is a part of boolean operation consumes much
more memory. Additionally, avoiding indirection could potentially
lead to better performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/114421
Currently the node tool node group and data-blocks referenced by it
may not be part of the active dependency graph. This means we
cannot retrieve their evaluated geometry when executing the operator.
Since operators almost always use the evaluated geometry of other
objects, and since geometry nodes is mostly set up to deal with
evaluated data-blocks currently, this must be fixed.
Instead, set up a temporary dependency graph and add the selected
objects and the data-blocks used by the node group. That graph is
evaluated to give simple access to evaluated data-blocks.
Unfortunately this will cause more work than necessary in a few ways:
1. Selected objects are reevaluated an extra time before execution.
2. All data-blocks referenced by the group are completely evaluated again.
3. The node group itself is reevaluated, which recreates the function graph.
These may or may not become bottlenecks in the future, but it's best to
keep it simple late in the release process. And between a completely
broken feature and a potentially slow feature, the choice is clear!
Pull Request: https://projects.blender.org/blender/blender/pulls/114293
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
`EdgeHash` was replaced by `VectorSet`, but the changes in the data
structure hid some other changes, causing incorrect indices to be used.
Instead use `Map` and explicitly build the indices similar to how they
were counted in a separate loop before.
Caused by: 425b871607
Known limitations to be addressed separately:
* We are not warning/keeping track of the named layers.
* There is no lookup for layers (groups) yet.
Ref !113908.
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
In 3.6 the names of node group sockets were using char arrays, but now
use allocated strings. The RNA system assigns nullptr to such strings
when assigning an empty string through python (UI assignment appears to
always generate a valid string). This creates issues with many STL
functions, in particular assigning nullptr to `std::string` will crash.
We have to check for valid pointers before using them in places that
don't handle nullptrs.
Pull Request: https://projects.blender.org/blender/blender/pulls/113924
This commit makes using (most of) `BKE_report` API safe in
multi-threaded situation.
This is achieved by adding a `std::mutex` lock to the `ReportList`
struct (in a slightly convoluted way unfortunately, due to this being a
DNA struct). This lock is then used to make most operations on
`Reportlist` data thread-safe.
Note that while working on this, a few other minor issues aroze in
existing usages of Reportlist by the WM code, mainly the fact that
`wm_init_reports` and `wm_free_reports` were both useless:
- init was called in a context where there is not yet any WM, so it
was doing nothing.
- free was called on a WM that would be later freed (as part of Main
freeing), which would also call cleanup code for its `reports` data.
Both have been removed.
Further more, `wm_add_default` (which is the only place where a WM ID is
created) did not initialize properly it reports data, this has been
fixed.
This change is related to the wmJob thread-safety tasks and PRs (#112537,
!113548).
Pull Request: https://projects.blender.org/blender/blender/pulls/113561
This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
Simplifies the fix to #111120, because it is clearer that the threadsafe
Mesh access is used rather than the potentially problematic object-level
bounds access.
`iota` is name that has no meaning, it's not an acronym or initialism.
It's usually very cryptic when I come across it. Replacing it with a
specialized function makes the code more readible.
Disambiguate:
- Rename "Near" to "Proximity" as a particle event type, because using
an adjective in this context is inconsistent and sounds
strange (even in English IMO).
Extract:
- "Skip" (Geometry nodes Simulation node output socket)
- "Bake" (Directory path to geometry nodes bake files in the modifier
UI)
- " (Recovered)" (File information in title bar)
Pull Request: https://projects.blender.org/blender/blender/pulls/112974
Previously, the geometry nodes modifier was converting the
viewer path to a compute context at the same time as it was
setting up side effect nodes for the geometry nodes evaluation.
Now, this is changed to be a two step process. First, the viewer
path is converted to the corresponding compute context.
Afterwards, a separate function sets side effect nodes up so
that the given node in the given compute context will be evaluated.
This has three main benefits:
* More obvious separation of concerns.
* Can reuse the code that maps a viewer path element to a compute
context already.
* With gizmo nodes (#112677), it may become necessary to add side
effect nodes based on a compute context, but without having a
corresponding viewer path.
Sometimes .blend files have compatibility issues between Blender versions,
because .blend files depended on the specific order of geometry elements
generated by some nodes/modifiers (#112746, #113018). While we make
guarantees about the order in some places, that is relatively rare, because it
makes future improvements much harder. The functionality in this patch
makes it easier for users to notice when they depend on things that are not
expected to be stable between Blender builds.
This is achieved by adding a new global flag which indicates whether some
algorithms should randomize their output. The functionality can be toggled
on or off by searching for `Set Geometry Randomization`. If there are no
differences (or acceptable minor ones) when the flag is on or off, one can
be reasonably sure that one does not on unspecified behavior (can't be 100%
sure though, because randomization might be missing in some places). If
there are big differences, one should consider fixing the file before it comes
to an actual breakage in the next Blender version.
Currently, the setting is only available when `Developer Extras` is turned on,
because the setting is in no menu.
With this patch, if we get bug reports with compatibility issues caused by
depending on indices, one of the following three cases should always apply:
* We actually accidentally broke something, which requires a fix commit.
* Turning on geometry randomization shows that the .blend file depends on
things it shouldn't depend on. In this case the user has to fix the file.
* We are missing geometry randomization somewhere, which requires a fix
commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113030
The array modifier used to output the start cap even if the
mesh is empty. This behavior was unintentionally changed in
8b2556e8d8. This patch brings back the old behavior.
The use case for this was to load an evaluated mesh of one
object into another object. So it was always kind of a hack, but
there is still no good reason to change the behavior.
Nowadays, one should just use the Object Info node in Geometry
Nodes to achieve the same result.
Initializing all vertices from the original could allocater vertex
groups into the custom-data which were later overwritten witout freeing.
The leak happened in the test file:
.../lib/tests/modifier_stack/explode_modifier.blend
Previously, it was only possible to bake all simulations at once. This is great
for simple use-cases that, but in more complex setups one can have independent
simulations that should also be baked independently. This patch allows baking
individual simulation zones.
Furthermore, each simulation zone can now also have its own bake path and
simulation frame range. By default the simulation frame range is the scene frame
range, but it can also be customized on the scene or simulation zone level. The
bake path is generated based on the modifier bake path by default, but can be
set to another absolute or relative (to the .blend file) path.
The timeline drawing has been modified as well to be able to show more information
in the case when some simulations are baked and others are not. Instead of showing
a line for every simulation, it shows a condensed view of the important information
using at most two lines:
Is something baked? Is something valid or invalid? Also see #112232.
Pull Request: https://projects.blender.org/blender/blender/pulls/112723
