Blender 4.0 added new socket types that get written into legacy node
group interfaces by forward compatibility code. Such unsupported socket
types have to be handled by the socket declaration system and ignored
during execution.
Ported blender-v3.6-release fix#114056
Pull Request: https://projects.blender.org/blender/blender/pulls/114401
This patch changes how wrapped translations are handled by the Realtime
Compositor. Previously, translations were always stored on the result
and delayed until automatically realized later. The wrapping status was
also stored to control this later automatic realization.
This patch changes that such that translations are immediately realized
for the axes that has enabled wrapping. Consequently, the image will not
get translated, but its content will, in a clip on one side, wrap on the
opposite side manner.
Another change is that wrapping information is no longer propagated to
future automatic realizations, so tilling or repeating an image is no
longer possible. An alternative method of repetition will be introduced
in a later patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/113669
Unsupported data can be removed, which reallocated the custom data layer
array. Since the temporary ID vectors referenced memory in that array
directly, this could lead to a use-after-free. Instead remove unsupported
data before collecting the referenced attribute IDs.
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.
The Huang model has issues with fireflies in various scenes, and the
defualt choice is somewhat arbitrary anyway as they have both pros and
cons. For now be conservative and keep the default the same as before.
This node supports either a Layer or a Layer Group name as input,
and outputs a selection field for it.
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.
Pull Request: https://projects.blender.org/blender/blender/pulls/113908
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.
Instead of calculating the expected insertion index for a customdata entry being moved, this implementation just records the initial layer indices so that it can compare them with the final indices to determine how the customdata entries need to be re-arranged.
Also simplifies the `add_layer` function and adds an implementation that just takes a `name` and adds a new layer with that name to the root group.
Pull Request: https://projects.blender.org/blender/blender/pulls/113962
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
The longer term plan is to allow using the same node groups in different
node tree types anyway. Also, the implicit field inputs is something that
shader nodes could benefit from soonish already.
This also fixes a bug where the geometry nodes specific declare function
was not used anymore since 38813a7441.
Face Corner is not supported.
In case prefer domain is used, face corner shouldn't be proposed.
This will make the viewer node preview the values on the point
domain instead in the viewport.
Pull Request: https://projects.blender.org/blender/blender/pulls/113905
Of the two overloaded functions clang chose the non-span version with
only a single item in the initializer list. Resolve that by not using an
intializer list in that case.
It was set to none, which draws as a dot instead of the already familiar
UV Map icon used in the UV Maps list and other places.
Affects:
* UV Map
* Tangent
* Normal Map
Following !113793 efforts to unify icons.
