This PR replaces the existing CPU wall-clock based profiling mechanism with more precise GPU counter based timestamps. As before, it is enabled by setting the env var `CYCLES_METAL_PROFILING=1`. Original implementation by Morteza Mostajabodaveh.
Pull Request: https://projects.blender.org/blender/blender/pulls/121208
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
Display layer properties in n-panel of dopesheet (grease pencil mode).
Draw code is moved inside separate classes then inherit them in actual panel drawing
class to avoid copy pasting the code in two places (in layer properties
panel and dopesheet side panel).
Part of #110056
Pull Request: https://projects.blender.org/blender/blender/pulls/120606
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
Use XDG_CURRENT_DESKTOP to check if GNOME is running.
Previously the existence of a `gtk_shell*` interface was used however
the WAYFIRE compositor provides this interface which made GHOST require
LIBDECOR.
Initializing LIBDECOR was hanging as the initial configuration was
never seen. From a quick check it doesn't seem like a bug in Blender's
LIBDECOR use, the issue may be in either LIBDECOR or WAYFIRE.
Whatever the case, LIBDECOR isn't needed so workaround the bug by
changing how GNOME is detected.
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
Since moving to "tools/" the suggested command would modify
headers *outside* Blender's source directory (now prevented).
Since "#pragma once" was used - the duplicate header check
needed to be moved from the end to the start of the header.
Other changes:
- Add type hints.
- Exclude headers intended to be included multiple times.
- Use `argparse` for argument parsing.
- Use str.format.
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
When passing strings to str.format(..) use `{:s}` format specifier
which only takes strings and wont run `.__str__()` on non-strings.
While `{!s}` is an equivalent to `%s`, for the most part `%s` was
used for strings, so using `{:s}` is clearer and more specific.
Part of modernizing scripts in Blender, where the previous convention
was to use percentage formatting which has become the "old" way to
format strings in Python.
See proposal for details #120453.
Ref !120552
Updates to refactor from [0].
- Rename "_context" as it's no longer unused.
- Remove call to `iface_` as the string no longer contains text.
- Remove redundant `enumerate(..)`.
- Use ternary operator instead of a tuple lookup.
- Assign a ratio variable for reuse.
[0]: 7e2075b809
Use __repr__ for formatting file instead of __str__ because non-standard
characters will be escaped and the string will be properly quoted.
Also, a modules __file__ is not *guaranteed* to be a string
(although it almost always is), nevertheless, __repr__ generally
results more more humanly readable results.
Note that __repr__ was already used to format __file__ in most places.
