This integrates the functionality for `parallel_for_weighted` from 9a3ceb79de
into `parallel_for`. This reduces the number of entry points to the threading
API and also makes it easier to build higher level threading primitives. For
example, `IndexMask.foreach_*` may use `parallel_for` if a `GrainSize` is
provided, but can't use `parallel_for_weighted` easily without duplicating a
fair amount of code.
The default behavior of `parallel_for` does not change. However, now one can
optionally pass in `TaskSizeHints` as the last parameter. This can be used to
specify the size of individual tasks relative to each other and relative to the
grain size. This helps scheduling more equally sized tasks which generally
improves performance because threads are used more effectively.
One generally does not construct `TaskSizeHints` manually, but calls either
`threading::individual_task_sizes` or `threading::accumulated_task_sizes`. Both
allow specifying individual task sizes, but the latter should be used when the
combined size of consecutive tasks can be computed in O(1) time. This allows
splitting up the work more efficiently. It can often be used in conjunction with
`OffsetIndices`.
Pull Request: https://projects.blender.org/blender/blender/pulls/121127
On this level it makes sense to have a single `add_item` function
because the operator does not take any parameters. It's also
mostly the same for different kinds of socket items except
for one line.
This requires adding a destructor and deleting move and copy assignment
for SculptSession, because (for now at least) we want to keep the PBVH
as an opaque type (though with one exception for including pbvh_intern.hh
in paint.cc for the SculptSession destructor).
Pull Request: https://projects.blender.org/blender/blender/pulls/121227
Make the recently added option descriptions a bit more consistent with
each other.
Small layout change to not have so much spacing between the 2 related
export options and move them under the existing options.
Pull Request: https://projects.blender.org/blender/blender/pulls/121198
This has some benefits:
* Nodes with dynamic socket amounts can remain more self-contained
(2 fewer files to edit with this patch).
* It's easier to reuse existing C++ code, reducing redundancy.
One new thing I'm doing here is to define operators in node files. It seems
reasonable to register operators that belong to a node together with that
node. Without this, code spreads out further than necessary without any real benefit.
This patch affects the simulation zone, repeat zone, bake node and index switch node.
The UI is slightly affected too. Since we had the UI defined in Python before,
it wasn't possible to integrate it into the node properties panel. That is possible
now and looks better anyway. The previous UI was an artifact of technical limitations.
Pull Request: https://projects.blender.org/blender/blender/pulls/121178
PR #118581 changed strip text color to be the same as active strip
theme outline, which been widely regarded as a bad move. Revert
text color to white just like it was before.
This allows the user to copy the driver(s) of a property to other selected items (e.g. objects, nodes, etc.) via the right-click menu. The implementation is based on the "Copy to Selected" operator, and generally behaves the same except for copying drivers instead of values.
Resolves#120518
This avoid self intersection during tracing which expect
unbiased depth. We compensate by adding a 1.5 shadow pixel
offset in the normal direction which is enough to fix
most remaining self shadowing. But another bias parameter
will likely need to be added anyway.
Fixes#121194
Mistake in b3aca5b28f. Some sculpt PBVH code has null checks
so I must have assumed a null PBVH was an expected situation. It turns
out those null checks are very inconsistent. We would probably be better
off removing them and ensuring the PBVH always exists.
Add the "plus" icon to the "New Bone Collection" operator,
and the separator line before the list of bone collections.
It now matches the object's "Move to Collection" operator, and
Grease Pencil's "Move to Layer" operator.
The root issue is that `shadow_punctual_footprint_ratio` was not
fed with Z distance but by radial distances to camera and
light.
This commit cleans up this computation by only precomputing the
film pixel radius on CPU. This allow the LOD computation to be
more local and easier to read.
Fix#119725
Pull Request: https://projects.blender.org/blender/blender/pulls/121167
This PR adds a polyline hide operator for sculpt mode as well as the
necessary generic callback code to allow using this gesture in other
selection tools.
Added features include:
* *Polyline Hide* operator
* `WM_gesture_polyline_*` callback functions for other operators
* Status bar text while using the polyline modal
* Common *Gesture Polyline* keymap for usage with the modal
Unlike the *Box Hide* and *Lasso Hide* operators, the *Polyline Hide*
operator does not provide a simple shortcut to click and show all
hidden elements in a mesh. This is because the existing operators
operate on a click-drag action while the new operator is invoked by
just a click.
Design Task: #119353
Pull Request: https://projects.blender.org/blender/blender/pulls/119483
Use existing function `screen_animation_region_supports_time_follow` in
`areas_do_frame_follow` to check region-space types in case of: follow current
frame is enabled and playback is moved with arrow keys
Noticed this while checking #110620
Pull Request: https://projects.blender.org/blender/blender/pulls/120056
Transport rays that enter to another location in the scene, with
specified ray position and normal. This may be used to render portals
for visual effects, and other production rendering tricks.
This acts much like a Transparent BSDF. Render passes are passed
through, and this is affected by light path max transparent bounces.
Pull Request: https://projects.blender.org/blender/blender/pulls/114386
Crash could could happen if `Clip Display` > `Render Undistorted` was
enabled on a clip, but the clip then unlinked (code was accessing the
clips `MovieTracking` for garbage memory then).
To resolve, just check the clip prior.
NOTE: there are similar other checks (e.g. in `spline_under_mouse_get`)
that actually check the clip prior.
Pull Request: https://projects.blender.org/blender/blender/pulls/121203
The initial mouse sample has a pressure of zero, which excludes all
points from the selection when the grab tool starts. Use a pressure of
1 to ensure all points are included.
Pull Request: https://projects.blender.org/blender/blender/pulls/121183
Currently support for data-block inputs is disabled because pointer
properties in operator properties aren't properly handled in Blender
(for more info, see 871c717c6e). This commit brings basic
support for them by storing strings (data-block names) in the operator
properties instead. The main downside of using strings compared other
theoretical solutions is that data-blocks from different library files
can have the same name. This solution won't work well for those cases.
However, it still brings a lot of utility to node tools for a relatively
simple code change.
I investigated two other solutions for this that didn't work out. Using
the recently added enum custom property support didn't work because
the data-block names would still have to be unique. Plus generating an
enum would require a bunch of boilerplate code. Extending the existing
button search code to handle integer session UID backed data-blocks was
much trickier than I expected. The code there is already quite spagetti-
like, and things got out of hand quickly. That's still valid future work
though. The implementation can be changed without breaking
compatibility of files.
Pull Request: https://projects.blender.org/blender/blender/pulls/121148
This commit fixes several critical issues with previous code:
* It only covered a (very small) subset of potential ID references in a
node (namely, just the `bNode::id` pointer).
* It completely ignored linked data case.
* It would modify ID pointers in the clipboard itself.
The new code stores ID reference info in a separate mapping. It uses the
new 'sub-data' foreach_id feature from `BKE_lib_query` to reliably and
generically process all ID pointers of a node.
The paste handling of ID pointers is split in two steps:
* All knowns ID references are searched for in current Main data-base,
and the result (current valid ID pointer or null if not found) is
stored temporarily in the ID references mapping.
* Once a node has been duplicated from the clipboard into the paste
destination nodetree, its ID pointers are updated accordingly.
This allows to keep the 'reference ID' data in the clipboard always
valid, regardless of which IDs are currently existing in Main (i.e. to
keep all available data, even when opening new blendfiles, or doing
undo/redo that would affect the existing IDs).
Pull Request: https://projects.blender.org/blender/blender/pulls/121122
The idea is to allow iterating over e.g. all ID usages of a node from a
whole nodetree, using the same generic handling as existing 'whole ID'
`foreach_id` code.
This is necessary in some cases wher a sub-data needs to processed
independently from any 'owner ID', e.g. in some copy/paste handling.
This is a pre-requirement for proper fix of nodes copy/paste (see
e.g. #120103).
Pull Request: https://projects.blender.org/blender/blender/pulls/121018
revert Fix: weight and vertex paint radial symmetry wrong with mirror
Was causing #121155, will check again on Monday
Both vertexpaint and weightpaint would only apply all of radial symmetry
for the "initial stroke".
When going over the combinations of symmetry axis, some of radial
symmetry would be skipped, e.g. when mirroring from right to left with
`Mirror X` turned ON, a dab on the right would have radial symmetry from
that point, and an additional dab on the left from mirroring (but the
mirrored dab would not have radial symmetry on its own).
This does not lead to symmetric results at all, sculptmode also does not
behave that way (there, radial symmetry is performed on the mirror axis
as well).
Now do the same thing as in sculptmode to get symmetric results when
using mirror and radial symmetry together.
Also use the utility function to skip invalid symmetry iterations.
Stumbled over this when looking into #120843
Pull Request: https://projects.blender.org/blender/blender/pulls/120931
This happened, because of lazy initialization of clicked retiming keys.
When the key is moved, the speed changed in respect to strip start, not
(uninitialized, but drawn) key at left handle.
Initialize both keys when any virtual key is selected.
Remove the one-definition-rule violation due to two `Triangle` types
being used inside the same `blender::io::stl` namespace. Make a small
set of non-functional changes in the surrounding code along the way to
use `const` in more places.
STL had 4(!!) triangle types:
- A `class Triangle` : Used for import, contains indices
- A `struct Triangle` : Used for export, contains verts/normals, the ODR
violation
- A `struct ExportBinaryTriangle` : Used for export but is really the
same as the above type
- A `struct STLBinaryTriangle` : Used for import but was a duplicate
of the above type
Now STL has just 2. The `class Triangle` containing indices during
import and a `struct PackedTriangle` containing the verts/normals for
everything else. The duplicated `BINARY_HEADER_SIZE` constant is now
common as well.
Performance remains the same for both import/export and ascii/binary.
Pull Request: https://projects.blender.org/blender/blender/pulls/121179
The goal of this PR is to remove any user facing parameter
bias that fixes issues that are caused by inherent nature of
the shadow map (aliasing or discretization).
Compute shadow bias in the normal direction to avoid
both shadow leaking at certain angles or shadow
acnee.
This bias is computed automatically based on the minimum
bias amount required to remove all errors. The render
setting is removed as of no use for now.
#### Normal bias
We do the bias in world space instead of shadow space
for speed and simplicity. This requires us to bias using
the upper bound of biases for the same location in space
(using biggest texel world radius instead of UVZ bias).
This isn't much of an issue since the bias is still less
than 2 texel. The bias is still modulated by facing
ratio to the light so surfaces facing the light have no
biase.
This fixes both self shadowing and flat occluders aliasing
artifacts at the cost of moving the shadow a bit on the
side. This is the blue arrow in the diagram.
We always bias toward the normal direction instead of the
light direction. This is alike Cycles geometric offset for
the shadow terminator fix. This is better since it does'nt
modify the shading at all.
#### Slope bias
To avoid aliasing issue on zero slope receiver, we still
have to use the slope bias with a size of 1 pixel.
#### PCF filtering
We now parametrize the filter around the normal instead of
using the shadow map local space. This requires to use
a disk filter instead of box, which is also more pleasant
for most light shapes (all except rectangle lights).
Setting the filter around normal avoid overshadowing from
zero slope occluders. This cannot be fixed by more slope bias
in light space PCF. We could fix it in light space by projecting
onto the normal plane but that gives an unbounded bias when `N.L`
is near 0 which causes either missing shadows or self shadow if
using an arbitrary max offset value.
To avoid overshadowing from any surface behind the shading
point, we reflect the offset to always face the light.
Doing so instead of using the perpendicular direction
is better for very sharp geometric angles, has less
numerical precision issue, is symetrical and is cheaper.
To avoid any self shadowing artifact on zero slope receivers
with angled neighbors (like a wall and the floor), we have
to increase the slope bias according to the filter size.
This might be overkill in most situation but I don't feel
this should become a setting and should be kept in sync
with the filter. If it has to become an option, it should
simply a factor between unbiased filter and best bias.
#### Shadow terminator
The remaining artifacts are all related to shadow terminator
one way or another. It is always caused by the shading
normal we use for biasing and visibility computation not
being aligned with the geometric normal.
This is still something we need a setting for somewhere.
Pull Request: https://projects.blender.org/blender/blender/pulls/121088
The difference was that the depth slope bias was not
written to the depth buffer which could lead to situation
where the value written to the color target was greater
than it should.
Use the depth write feature to output the slope biased
depth. Output 1 depth to not discard and loose the benefit
of early depth test.
