When dissolving an edge merges faces, use an angle threshold before
dissolving vertices from the face which have become chains as reult
of the merge (connected to 2 edges).
Also fix edge-flag handling when dissolving multiple edges
from a chain into a single edge, previously flags from the
resulting edge was effectively random.
Now flags from all edges are merged.
Resolves#100184.
Ref !134017
- Place doc-strings before arguments (avoid over long lines).
- Enable clang-format for BMesh operator definitions.
- Remove invalid comments (likely left in from copy-paste).
- Use double back-ticks for RST.
- Use full sentences.
No functional changes.
We attempt to enforce a minimum area height so that they cannot be made
smaller than header height. This works correctly as we drag resize
areas but not when loading blend files. We skip doing so if resizing
from smaller to a bigger vertical size. This PR just makes it so we
enforce minimum size always.
Pull Request: https://projects.blender.org/blender/blender/pulls/139804
In 5.0, we plan to change the brush size from representing radius to
diameter. This means that for 5.0 files loaded in 4.5, we need to
scale the stored value when reading the relevant brush fields.
Related to #134204
Pull Request: https://projects.blender.org/blender/blender/pulls/139561
The value isn't created unless jitter is enabled, but it was always
retrieved for a function argument. The uninitialized memory wasn't read,
but it caused a crash in debug builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/139854
Current strategy to deal with operators not supporting custom NURBS
knots is to fall back to calculated knots for curves of the custom mode
but with no `CurvesGeometry::custom_knots` allocated. Such curves are
the result of operators that copy only `Point` and `Curve` domains. This
way the problem is only postponed. It is not possible to add new custom
knot curves to such `CurvesGeometry` as custom knot offsets are
calculated all together and there is no way to distinguish between old
curves with lost knots and new ones. This is more a future problem.
The actual problem in `main` can be shown with an attached blend file
(see PR) by applying `Subdivide` to some points and then adding new
`Bezier` curve to the same object. This particular problem could be
addressed somewhere in `realize_instances.cc` but the actual problem
would persist.
This PR handles custom knots in all places where `BKE_defgroup_copy_list`
is iused, and where `bke::curves::copy_only_curve_domain` is called.
Here the assumption is made that only these places can copy custom knots
modes without copying custom knots. Depending on operator logic knots are
handled most often in one of two ways:
- `bke::curves::nurbs::copy_custom_knots`:
copies custom knots for all curves excluding `selection`. Knot modes
for excluded curves are altered from the custom mode to calculated.
This way only curves modified by the operator will loose custom knots.
- `bke::curves::nurbs::update_custom_knot_modes;`
alters all curves to calculated mode.
In some places (e.g. `reorder.cc`) it is possible to deal with knots
without side effects.
PR also adds `BLI_assert` in `load_curve_knots` function to check if
`CurvesGeometry::custom_knots` exists for custom mode curves. Thus
versioning code is needed addressing the issue in files in case such
already exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/139554
This requires a minimum driver version of 535, however most devices
were already requiring 570 due to the CUDA toolkit version.
The update is required to be able to use an API function for correct
stack size calculation.
Code for older API versions has been removed.
Fix#138185: OSL custom camera errors with OptiX
Pull Request: https://projects.blender.org/blender/blender/pulls/139801
When binary files managed by git-lfs are not hosted by the main source
repo (e.g. when using the github mirror), the fall-back repo set up by
`lfs_fallback_setup` does fetch the files, but the follow-up call to
`git pull` in `work_tree_update` does not check them out.
This commit simply adds an extra `git lfs checkout` command there.
Pull Request: https://projects.blender.org/blender/blender/pulls/139825
This commit improves DNA parsing resilience to data corruption in two ways:
* Detect and abort on failure to allocate requested amount of memory.
* Detect multiple usages of the same `type_index` by different struct
definitions.
The second part fixes the `dna_genfile.cc:1918:40.blend` case reported
in #137870.
Pull Request: https://projects.blender.org/blender/blender/pulls/139803
The Movie distortion node crops its data if the movie size differs from
the input size. That's because boundary extensions do not take
calibration size into account. To fix this, we use the same coordinates
range as the distortion grid computation, which computes the distortion
in the space of the calibration size.
Pull Request: https://projects.blender.org/blender/blender/pulls/139822
Adds a new operator in Grease Pencil edit mode to convert between curve
types. This acts as a replacment for the `Set Curve Type` operator as
the new operator better aligns with previous workflows and artist
expectations. Specifically using a threshold to adjust how well the
resulting curves fit to the original.
It can be found in the `Stroke` > `Convert Type` menu.
This operator aims at keeping visual fidelity between the curves. When
converting to a non-poly curve type, there's a `threshold` parameter
that dictates how closley the shapes will match (a value of zero meaning
an almost perfect match, and higher values will result in less accuracy
but lower control point count).
The conversion to `Catmull-Rom` does not do an actual curve fitting.
For now, this will resample the curves and then do an adaptive
simplification of the line (using the threshold parameter)
to simulate a curve fitting.
The `Set Curve Type` operator is no longer exposed in the
`Stroke` menu.
This also adds a new `geometry::fit_curves` function.
The function will fit a selection of curves to bézier curves. The
selected curves are treated as if they were poly curves.
The `thresholds` virtual array is the error threshold distance
for each curve that the fit should be within. The size of the virtual
array is assumed to have the same size as the total number of
input curves.
The `corners` virtual array allows specific input points to be treated
as sharp corners. The resulting bezier curve will have this point and
the handles will be set to "free".
There are two fitting methods:
* **Split**: Uses a least squares solver to find the control
points (faster, but less accurate).
* **Refit**: Iteratively removes knots with the least error starting
with a dense curve (slower, more accurate fit).
Co-authored-by: Casey Bianco-Davis <caseycasey739@gmail.com>
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/137808
Set `UI_BLOCK_LIST_ITEM` flag for the block this will assign
`UI_BUT_LIST_ITEM` flag for tree view label buttons, see: `uiItemL_()`
That way `wcol_list_item` is being used for tree view.
(see: `widget_state()` / `widget_state_label()`
Pull Request: https://projects.blender.org/blender/blender/pulls/126026
This avoid having to compile specializations JIT and
use the same API as subprocess compilation.
This bridges the gap between subprocess and threaded
compilation.
Pull Request: https://projects.blender.org/blender/blender/pulls/139702
It would run into using the same frame twice, looking like "freeze
frames"
Apparently we had a similar issue before, see 3f8ec963e3
Just a PoC to show that this looks like a precision/rounding issue when
getting a "working" `UsdTimeCode`.
In the modifier code, we are doing a roundtrip going from frame >> time
(in seconds -- via `BKE_cachefile_time_offset`) and then back to frame
before we store that in `USDMeshReadParams`.
To avoid the precision loss, this PR introduces
`BKE_cachefile_frame_offset` to stay in the "frame" domain and
circumvent going through FPS alltogether.
There might be better ways to let USD handle the "sightly off"
`UsdTimeCode` better though.
Pull Request: https://projects.blender.org/blender/blender/pulls/139793
Duplicating collection doesn't work when multiple collections are
selected, instead first selected collection is just duplicated. Now fixed
by iterating over list of selected collections returned by
`outliner_collect_selected_parent_collections` after traversing. In that
function, child collections are skipped if parent collection is already
selected, this avoids extra copies from being generated (i.e creates one
copy of nested collections).
Resolves#139651
Pull Request: https://projects.blender.org/blender/blender/pulls/139719
This commit adds a feature to the bug fixes per release tool to ensure
the version numbers of the backported Blender versions are in ascending
order.
Before: 4.2.9, 4.4.1, 4.2.9
After: 3.6.22, 4.2.9, 4.4.1
Pull Request: https://projects.blender.org/blender/blender/pulls/139011
In a previous commit (1) a feature was added to the bug fixes per
release script that prompted users if they want to sort revert commits.
This commit removes this feature, instead preferring that revert
commits are sorted in the overrides task (blender/blender#137983)
This was done because:
- The overrides task allows for greater control over how revert commits
are classified, and it's synced between all users.
- The prompt to sort the commits appearing each time the script is run
is annoying for triagers who may run the script multiple times in one
day as they sort through various commits.
(1) blender/blender@9679d9a3eb
Pull Request: https://projects.blender.org/blender/blender/pulls/138505
Comparing the object with "edit_object" isn't correct as
multiple objects may be in edit-mode across multiple scenes.
Check the object for edit-mode data instead.
Annotation `Callable[[Any, ...], str | None]` is not supported by Python
typing system and ... will be misinterpreted as unknown type instead of
option to provide variable number of arguments.
Ref !138804
Regression in [0] which would re-highlight gizmos when they had been
tagged for highlighting.
This caused highlighting to be recalculated unexpectedly while
blocking modal operators run that used a timer.
The timer events would be passed though to the gizmo handler which
then re-evaluated the highlighted gizmo based on the cursor position.
Resolve by skipping pass-through for gizmos.
[0]: f839847d3b4849425c3b06a52aae4361d384fea4
Object::actcol assignments from edit-mode data wasn't clamping
the index to the valid range. This caused an out of bounds read when
accessing Object::matbits.
While material indexes should typically be within the material bounds,
this isn't guaranteed. Selecting a face for example with a material
outside the range was crashing.
Add a utility function that sets the active material index to replace
existing inline checks.
Follow up to the fix for #139369.
This changes how tooltips for dragging multiple files are shown. this
shows an `Documents` icon and a counter of how many files are dragged.
When multiple files are dragged from Blender internal file browser,
this avoids showing the thumbnail of the file selected to start
dragging, if selection is unique this thumbnail will be visible.
Pull Request: https://projects.blender.org/blender/blender/pulls/136276
This is required to make ray differentials work correctly for OSL custom
cameras.
But it also lets us simplify the implementation, and makes the OSL
functionality more complete, such as implementing all noise types.
Pull Request: https://projects.blender.org/blender/blender/pulls/138161
Keep around the dummy BVH for lights, even if it serves no purpose for now.
Previously I assumed it was not needed, but there is some device specific
code that assumes it exists, and not much point trying to refactor that now
when in the future we actually want to create a BVH for lights.
Pull Request: https://projects.blender.org/blender/blender/pulls/139798
With these changes, we can now mark devices which are expected to work as
performant as possible, and devices which were not optimized for some reason.
For example, because the device was released after the Blender release,
making it impossible for developers to optimize for devices in already
released unchangeable code. This is primarily relevant for the LTS versions,
which are supported for two years and require proper communication about
optimization status for the new devices released during this time.
This is implemented for oneAPI devices. Other device types currently are
marked as optimized for compatibility with old behavior, but may implement
the same in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/139751
A small number of USD files in the wild contain invalid face index data
for some of their meshes. This leads to asserts in debug builds and
crashes for users in retail builds(sometimes). There is already an
import option to Validate Meshes but it turns out that we, and most
other importers, perform validation too late. We crash before getting to
that validate option (see notes).
This PR implements a cheap detection mechanism and will auto-fix if we
detect broken data. The detection may not find all types of bad data but
it will detect what is known to fail today for duplicate vertex indices.
We immediately validate/fix before loading in the rest of the data. The
downside is that this will mean no additional data will be loaded.
Normals, edge creases, velocities, UVs, and all other attributes will be
lost because the incoming data arrays will no longer align.
It should be noted also that Alembic has also chosen this approach. It's
check is significantly weaker though and can be improved separately if
needed.
If auto-fix is triggered, it will typically appear as one trace on the
terminal.
```
WARN (io.usd): <path...>\io\usd\intern\usd_reader_mesh.cc:684
read_mesh_sample: Invalid face data detected for mesh
'/degenerate/m_degenerate'. Automatic correction will be used.
```
A more general downside of these fixes is that this applies to each
frame of animated mesh data. The mesh will be fixed, and re-fixed, on
every frame update when the frame in question contains bad data.
For well-behaved USD scenes, the penalty for this check is between 2-4%.
For broken USD scenes, it depends on how many meshes need the fixup. In
the case of the Intel 4004 Moore Lane scene, the penalty is a 2.7x
slowdown in import time (4.5 s to 12.5 s).
Pull Request: https://projects.blender.org/blender/blender/pulls/138633
The checks and related warnings detecting usage of blendfiles generated
by newer versions of Blender were not fully behaving as expected for
libraries. In particular, opening an older main blendfile linking
against newer library ones would not always detect and report the
`has_forward_compatibility_issues` status properly.
Found out while working on 'longer ID names' compatibility PR for 4.5
(!139336).
