- `BMLayerItem.copy_from(other)` had a typo in its docstring that prevented `other` being typed.
- `BMesh.from_object()` and `BMesh.from_mesh()` had untyped arguments.
- `BMVert.copy_from_vert_interp()`'s `fac` argument was untyped.
- `remove(item)` method of `BMVertSeq`, `BMEdgeSeq` and `BMFaceSeq` had no type for `item`.
- `get()` method of `BMEdgeSeq` and `BMFaceSeq` had "sequence" in the description of `verts` but not in the type.
Pull Request: https://projects.blender.org/blender/blender/pulls/122374
Move the loop over all affected nodes to each brush implementation,
making use of lambdas to avoid a bunch of boilerplate code. This makes
it clearer what logic actually depends on the vertices in each node, and
decreases future overhead if we decide to make PBVH nodes smaller.
Access the vertex to face map directly from the mesh as necessary.
This helps to prevent unnecessary calculation (it isn't necessary in
weight paint mode besides the blur brush anymore), though it is
used for vertex normals calculation for smooth-shaded meshes.
`ss.vert_positions` and `pbvh.vert_positions` are expected to point to the
same evaluated deformed position array here. It's preferrable to use the
span we already have locally. Though eventually we hope to remove the
vertex position array from PBVH.
Reading the selection is much cheaper than calculating the brush radius
since it just requires reading from a boolean array. Better to do it earlier
so the radius calculation can be skipped for deselected points.
Multires isn't supported here anyway, and if it was it would look very different
because the weights and colors would probably be stored on the subdivided
grids somehow. For now this code is just confusing and gets in the way. It
also mixes up the purpose of the PBVH iteration macro abstraction.
This was caused by #122255 which used the normal
to tag the translucent with thickness case. But
this normal is then overwritten during the first
call to `light_eval_single`.
This patch moves the tag to a special type of
`LightingType` which then gets flushed to
`LIGHT_DIFFUSE` when used.
Pull Request: https://projects.blender.org/blender/blender/pulls/122400
Fix for #121890
The image shows testing results with "green" texture. It is expected that
all vectors are displaced along Y axis.
Cases are "no displacement", "tangent", "object" and "world" spaces.
Results are consistent with Cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/122376
A subtle error in 66da875488 mean that the existing selection
was overwritten instead of adding to the final flag on the result BMesh
element. Selection is often interpolated separately which is probably
why this mistake wasn't more observable earlier.
A subtle mistake in 66da875488 meant that existing selection
was overwritten instead of maintained in the BMesh utility functions for
copying element custom data and flags.
There is a fundamental issue when adding nodes from versioning code right now.
Generally speaking, versioning code should not change after it has been written.
If old versioning code suddenly changes its behavior, it can invalidate the versioning
code that comes after it.
The issue is that while the versioning code itself doesn't change, it is indirectly calling
code that is changing and evolving all the time. This makes the versioning unreliable
and makes it hard to do certain changes (e.g. changing which sockets a node has).
It's easy to overlook issues this creates because many of these cases don't have
regression tests.
The solution is to keep the versioning code more independent from the part of
Blender that is constantly evolving. More specifically, this means that when adding
a node, this should not take the current node initialization and declaration code into
account. Instead, the versioning code should just manually create the node with
the sockets that it expects based on the version that the versioning code has been
written for.
This patch adds new `version_node_add_empty`, `version_node_add_socket` and
`version_node_add_link` methods which allow creating nodes without calling ever
evolving code.
Pull Request: https://projects.blender.org/blender/blender/pulls/121664
This PR adds the *Polyline Mask*, *Polyline Face Set*, and
*Polyline Trim* tools.
## Limitations
* *Polyline Face Set* is not added to either of the *Sculpt*
or *Face Sets* menu as none of the other face set gestures are in
either.
Pull Request: https://projects.blender.org/blender/blender/pulls/122248
Part of #116901.
Avoid the "extractor" abstraction for creation of edit mode overlay data
vertex buffers. Use threading::parallel_for loops instead. Also prefer
code duplication over linking things that are unrelated. This is the
last "extractor" loop that runs by default in edit mode so there is a
small performance improvement there. Besides that, the changes is the
same as the other similar refactors.
Pull Request: https://projects.blender.org/blender/blender/pulls/122386
Finding the boundary uses a Moore neighborhood. The algorithm iterates
over filled pixels, following pixels with empty neighbors, in clockwise
direction. For a given pixel and input direction (where the boundary is
coming from), the next neighbor is found by checking neighbors clockwise
from the previous pixel.
The last direction in this inner loop would be opposite the input
direction, i.e. if the pixel has only one neighbor it can loop back
and iterate over pixels that are already in the boundary, from the
opposite direction. However, this last direction was excluded from the
search (an earlier implementation did not support it). Using this search
direction as well allows the boundary to go back and forth over the same
line of pixels until the boundary is closed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122383
This PR adds the `Line Face Set` tool and adds it to the following
location:
* Sculpt Mode toolbar
## Limitations
None of the existing Face Set gesture operators exist in either the
Sculpt dropdown or the Face Set dropdown, this PR does not add the Line
Face set tool in either location as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122245
This PR adds a new operator: `PAINT_OT_visibility_edit` to support
iteratively expanding or shrinking the visibility of a mesh, similar to
the *Grow / Shrink Mask* actions and the *Grow / Shrink Face Set*
options. This operator is exposed via two new entries in the *Sculpt*
toolbar entry as *Show More* and *Show Less* and have also been
assigned to Page Up and Page Down in the default Blender keybinds for
Sculpt Mode.
### Technical Details
Each of the PBVH types is solved slightly differently, though the
general principle for each is as follows:
1. Make a copy of the current mesh visibility state
2. Iterate over elements (faces & corners if available, otherwise
vertices) to look at adjacency information
3. Apply appropriate visibility change to vertices
4. Sync face visibility
### Limitations
* Currently, like all other operators in the `paint_hide.cc` file. This
new operator is limited to Sculpt mode only.
Based off of [this](https://blender.community/c/rightclickselect/pz4y/)
RCS request.
Pull Request: https://projects.blender.org/blender/blender/pulls/120282
The "render_stats" handler now includes the message line that was
written to stdout as the first arg (using `BKE_callback_exec_string`
instead of just `BKE_callback_exec_null`).
This can be useful to track render progress (and people were relying on
parsing stdout in the past).
Was a request in chat.
This also corrects possible output from the callback being written in
between message parts in `do_write_image_or_movie` (which was probably a
mistake in 93d5e106aa).
Pull Request: https://projects.blender.org/blender/blender/pulls/119789
The `overlay_wireframe` shaders uses a `nor` input but it wasn't added
to the GPU batch since the normals were split to a separate vertex buffer.
Adding that input gets closer to the appearance in 4.0. But it still looks a
bit different-- the outline is not as bright overall.
Fixes#120781.
Pull Request: https://projects.blender.org/blender/blender/pulls/120827
As Node Wrangler add-on is moving to extensions platform and maybe isn't shipped
with Blender from 4.2 onwards, some of it's more important functionalities which are
crucial for Blender UX can be ported inside core. Also see #121749.
This PR ports "Preview Node" operator from add-on inside `scripts/startup/bl_operators`.
When Shift-Ctrl (or Shift-Alt) clicked on the node operator connects output socket of the
node to active Output node in the tree (group, material, light, or world output). For Geometry
Nodes this is just handy operator, but in Shader Nodes, because Viewer Node isn't
implemented, this has always been the only way to quickly preview nodes by connecting
it to Material Output.
Changes made from Node Wrangler version:
- Renamed operator from "Preview Node" to "**Connect to Output**", because node previews
already mean a different thing in context of compositor and shader editor, and viewer node
is used for previewing in geometry nodes. Connect to Output is correct name because in every
context it's called that's what it does.
- Assigned shortcut Shift-Alt-Click in shader editor as well. Even though Shift-Ctrl click already
works, it's good to have consistency with geometry nodes, so that users can use same shortcut
in both contexts.
Operator doesn't work in compositor. It's not clear if that's wanted (to connect to Composite node),
and if it is it'll be added in separate PR.
Original authors of the add-on: Bartek Skorupa, Greg Zaal, Sebastian Koenig, Christian Brinkmann, Florian Meyer
Pull Request: https://projects.blender.org/blender/blender/pulls/122016
This node allows replacing the transformation of every instance by providing a matrix.
Before, this was only possible by using the Store Named Attribute node. It's more common
in Blender to have specialized built-in nodes for built-in attributes (e.g. Set Position, and Set ID).
Pull Request: https://projects.blender.org/blender/blender/pulls/121473
While easier to understand, the conventionnal global
scene thickness parameter have some downside:
- It doesn't scale with larger scenes since the
distant samples have small thickness
- It doesn't handle fine geometric variation in
foreground.
The proposed angular thicknes makes all sample
have the same angular span. This makes it
distance independant and capture different occluder
thickness with less artifacts. The downside is
that the occluders have the same angular span
at any distance which makes the same occluder inflate
with distance.
A downside is that the geometry near the shading point is
under-represented. Leaving light leaking or lack of AO
at contact points. To fix this, we introduce back a
geometric thickness parameter.
Pull Request: https://projects.blender.org/blender/blender/pulls/122334
This allows using strokes with a "Dot" material as boundaries for the
fill tool.
Note: "Square" materials are not currently supported, they get rendered
as dots too. This is the same in GPv2, there just isn't a simple shader
for rotated squares.
Pull Request: https://projects.blender.org/blender/blender/pulls/122324
The "Maximum Gap" setting for the "Natural Drawing Speed"
mode was not working.
This was because the code used `math::max` to try and clamp the value
to a maximum when it should have used `math::min`.
This fixes this issue.
Volumes and grids were not yet handled by the Geometry Nodes value
logging system. This patch adds basic information (number of grids)
to the value logger and node tooltips.
Pull Request: https://projects.blender.org/blender/blender/pulls/121622
This is slight optimization. Number of nodes with additional outputs like `Valid`
flag of other math-related things will be more in future, its better to strict api
and do not evaluate even singles. This also can reduce number of logged values.
Pull Request: https://projects.blender.org/blender/blender/pulls/121799
