`NOD_zone_socket_items.hh` contained code for different nodes. It's better to
split this into headers per node, because that scales better. Also it helps to
keep the code for each individual node more closely together.
Pull Request: https://projects.blender.org/blender/blender/pulls/120945
This patch adds the ability to snap strips to markers. Previously, there
only existed options to snap to hold offsets and the current frame.
This snap type works identically to other snapping options by checking
for the relevant bit (here `SEQ_SNAP_TO_MARKERS`) and adding the marker
frame numbers to `snap_data->target_snap_points` within
`seq_snap_target_points_build()`.
To enable `seq_get_snap_target_points_count()` to have access to marker
information, the current Scene object is now passed to the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/120450
For example, the `Bake` node generally does not propagate any anonymous
attributes. That's true regardless of whether it is baked or not. However, if it
is muted, the attributes should be propagated.
Pull Request: https://projects.blender.org/blender/blender/pulls/120887
The class `AnimDataConvertor` was implementing `operator bool`
to indicate "if this AnimDataConvertor is valid, i.e. can be used to process animation data from source ID".
The cleanup replaces this with a `is_vaild` function, making the
code easier to read and allowing to jump to the function definition
of `is_valid`.
Legacy GPv2 code seems to clamp the final computed radius to `0` (at
least in some cases, see e.g. line 3992 in
`gpencil_stroke_perimeter_ex`).
Add a clamping node to the generated geometry node used to mimmic the
legacy thickness adjustment in GPv3 converted data.
NOTE: There are still some artifacts in testfile used to investigate
this issue (`(Anim) 10 Picknick by Susanne Weise.blend`), that looks
like invalid radius handling on some curves ends... Clamping _may_ be
needed in other places maybe?
Pull Request: https://projects.blender.org/blender/blender/pulls/120840
Fix linking & library-overriding with NLA Tweak Mode enabled. This is a
two-pronged approach:
- When linking an animated ID from a library file, and it happens to be
in NLA Tweak Mode, it is forced out of tweak mode. This ensures that
the correct Action is loaded, and that all the NLA flags are set
correctly to display the NLA animation (instead of only the tweaked
strip).
- For library overrides there is now a post-process step that runs after
all 'apply' functions have been run. This is necessary to ensure that
all the flags and pointers that NLA Tweak Mode depends on are actually
set correctly and consistently.
This also adds one utility function `BKE_nla_debug_print_flags()` that
is by now unused. It was very useful in debugging this, though, and I
think it'll be useful in the future as well.
Design task: #120573
Pull Request: https://projects.blender.org/blender/blender/pulls/120830
Caused by addition of new code in 4e10aa6e71, which was not guarding
against negative frame values. The only other place that called
BKE_sound_set_scene_sound_pitch_constant_range guarded against negative
frames (added in 1fb692e896 + 49a0502f35), but generally it looks like
negative frames are a "no no" in audaspace, so just move the value
sanitization into BKE_sound_set_scene_sound_pitch_constant_range itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/120891
Compute shaders are required since 4.0. There was one occasion where
an older AMD driver failed and support was turned off. This driver
is now marked unsupported.
This PR includes:
- removing the check in viewport compositing
- remove properties from system info
- always construct draw manager.
- remove unused pass logic in draw hair/curves
- add deprecation warning when accessed from python
Pull Request: https://projects.blender.org/blender/blender/pulls/120909
All tools in Draw Mode, Sculpt Mode and Weight Paint Mode didn't work
correctly when the position of strokes was changed by modifiers.
In technical terms this was caused by
`get_evaluated_grease_pencil_drawing_deformation()`: when not in Edit
Mode, it effectively always returned the original position of stroke points
instead of the modified ones. In this PR there is a little fix for that.
Pull Request: https://projects.blender.org/blender/blender/pulls/120672
Since image vectorscope RGB mode addition (567455124d), changing
the opacity was causing the scope to get recalculated from scratch,
because opacity value was put into vecscope_rgb data directly.
Instead of that, make vecscope_rgb data only contain RGB, and fill in
the GPU vertex buffer alpha values when creating the GPU batch.
Now tweaking the scope opacity slider feels at about the same
performance as in 4.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/120854
Replace the C-class pattern function pointers with actual class methods.
Other than the obvious benefit of not requiring the "this" pointer to be
explicitly passed into every function call, this will make it much simpler
to remove the entire C-API class and replace it with its "impl" next.
For that next step we need to expose code to the implementation
of the topology refiner, so instead of defining stubs locally in the
opensubdiv intern class, we spread some WITH_OPENSUBDIV checks
in the blenkernel. As far as I know this is the only way to remove the
intermediate C-API and call opensubdiv functions directly from there.
Move most code to `blender::bke::subdiv`. That helps organization
and makes using C++ in subdiv code easier, which will be useful for
removing the unnecessary opensubdiv C-API wrapper.
This is just adding a switch for enabling custom range.
Custom range is now optional as we compute a tight bound
to integrate around volume objects by default.
The custom range is only needed for scene with really
thick world volumes.
Pull Request: https://projects.blender.org/blender/blender/pulls/120823
Now that lights are supported for refraction BSDFs,
there is no reason to not add support for it.
Versionning sets it to zero for compatibility with
legacy EEVEE.
This is also needed in order to support per object
ray visibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/120796
While keeping the general process the same, this commit heavily
refactors the animation handling as part of the GPv2 to GPv3 conversion
process.
The whole animation handling is now embeded in new class, which covers
all current use cases (conversion of all fcurves matching a given root
RNA path, or a specific set of given full RNA paths, and transfer to
another ID's animation data if required).
The new system is also now able to perform custom additional conversion
on FCurves if necessary, through a new function callback.
This is used in this commit to fix two issues with the animation of the
'Stroke Thickness' GPv2 layers adjustment factor (the need to divide the
values by 2000, and to switch from an 'integer' FCurve to a regular
one).
Finally, this commit also adds suport for animation of the old GPv2
'Thickness Scale' parameter.
--------
NOTE: While this already improves a lot the animation handling code of
GPv3 conversion, this could still use more clean-up. Don't think it's
worth it within current usage scope though.
But if more use cases need to be covered, and/or we need such conversion
behavior in other places, it could be good to do another improvement
pass and move this as generic 'animation conversion' helper in a
dedicated BKE module.
Fix snapping issues caused by commit 1c77779160, where a mesh
representing the edited mesh was introduced.
Mesh snap to vertex now works in the following order:
- Snap to vertices of visible triangles
- Snap to vertices of loose edges
- Snap to loose vertices
The problem arises because in editing mode, faces whose vertices are
being transformed are ignored, marked as hidden in the snap, resulting
in the loss of some vertices in triangles.
The solution involves considering the edges and vertices of hidden
faces as loose elements since, despite being connected to faces, they
are still visible to snap. Two new types of BVHTree were created for
this purpose:
- BVHTREE_FROM_LOOSEVERTS_NO_HIDDEN
- BVHTREE_FROM_LOOSEEDGES_NO_HIDDEN
This modification addresses two related issues:
- snapping in edit mode to vertices and edges of a face being
transformed
- snapping to mesh with hidden loose elements
Optionally, the first issue could be tackled separately by generating
BVHTrees within the snap system itself and storing them in a
`SnapCache_EditMesh *em_cache`, then passing this cache as a parameter
to the `snap_object_mesh` function.
Pull Request: https://projects.blender.org/blender/blender/pulls/120270
The main motivation for this is that it's part of a fix for #113377,
where I want to propagate the edit mesh pointers through copied
meshes in modifiers and geometry nodes, instead of just setting the
edit mesh pointer at the end of the modifier stack. That would have
two main benefits:
1. We avoid the need to write to the evaluated mesh, after evaluation
which means it can be shared directly among evaluated objects.
2. When an object's mesh is completely replaced by the mesh from another
object during evaluation (with the object info node), the final edit
mesh pointer will not be "wrong", allowing us to skip index-mapped
GPU data extraction.
Beyond that, using a shared pointer just makes things more automatic.
Handling of edit mesh data is already complicated enough, this way some
of the worry and complexity can be handled by RAII.
One thing to keep in mind is that the edit mesh's BMesh is still freed
manually with `EDBM_mesh_free_data` when leaving edit mode. I figured
that was a more conservative approach for now. Maybe eventually that
could be handled automatically with RAII too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120276
Callers to RNA_struct_name_get_alloc weren't accounting for allocation
which is unlikely as the fixed sized buffers used in these cases were
large.
- CTX_data_dir_get_ex & context_path_add_generic
would use uninitialized stack memory.
- OverrideRNAPathTreeBuilder::build_path & ensure_entire_collection
would leak memory.
Previous code would re-create a node-tree everytime conversion code was
called (on main file read, but also on all link/append operations).
Worse, it would assing a local generated nodetree to converted linked
GPv3 objects.
This commit solves both issues in a similar way as what was done for the
legacy mesh 'auto smooth' generated node tree.
It also slightly refactors the conversion code by adding a single struct
containing all 'runtime' conversion data (two mappings currently). This
struct is then passed to internal conversion functions as reference.
The creation of a special nodegroup for the legacy 'auto smooth'
conversion used to handle 'setting the library' part itself.
Use instead the recently introduce `in_lib` variants of ID creation API.
On top of simplifying the code, this commit also fixes 'linked'
generated nodetrees always getting a `.001` suffix added to their names.
Fall back to CPU subdivision when there are split edges and the mesh
normals domain is face corners. This is required because splitting the
normals on faces adjacent to sharp edges doesn't work well with the
performance requirements of GPU subdivision.
This is related to 1111903416
Pull Request: https://projects.blender.org/blender/blender/pulls/120674
Previously, this conversion would often result in invalid quaternions or
hit an assert in `normalized_to_quat_fast`. It's not super nice to convert
to euler as an intermediate step performance wise, but it seems to be
the easiest solution for now. Extracting rotations from matrices should
not be done all that often anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/120568
Extract
- Statuses for the external text editor
- Newly created enum node item
- Newly created plane track data
- Newly created custom orientation data
- Operator names in drag and drop menu (need to use operator's
translation context)
- GN attribute statistic node inputs
Disambiguate
- Single-letter colors: A and B can mean Alpha and Blue, or simply A
and B as in two operands in an operation
- Dissolve: issue reported by Tamar Mebonia in #43295
- Translate in the User Preferences. This introduces a new
BLT_I18NCONTEXT_EDITOR_PREFERENCES ("Preferences") translation
context
- Planar (reported by deathblood)
This one is incomplete, because there is currently no way to
disambiguate presets or GN fields. I don't see how either could be
achieved cleanly.
The former would need to define the context inside the preset and
evaluate the file prior to showing it in the presets menu, which
sound bad.
The latter would need to introduce an additional string inside
`FieldInput`s, which would be controversial given how little it
would be used.
Remove
- Unused translation `iface_("%s")` in toolbar
- Remove obsolete N_() tags in a few node descriptions.
Pull Request: https://projects.blender.org/blender/blender/pulls/119065
Add a new keyframe type named 'generated', which is meant to indicate
that the key was set by some automated tool (like an add-on), rather
than manually by an animator.
This is meant for tooling that needs to create keys in a repeatable way.
With this new key type, the tool can know which keys it generated
before, and thus those can be removed and re-generated.
Pull Request: https://projects.blender.org/blender/blender/pulls/120564
When creating a filename for use with a File Handler, we should guard
against problematic characters like "/" and "\\", among others, which are
not safe to use in paths. Sanitize the incoming name with
`BLI_path_make_safe_filename` to ensure the name can be used.
For empty incoming names, or names containing all spaces, we default to
"untitled" before adding the extension.
Pull Request: https://projects.blender.org/blender/blender/pulls/120652
This commit ensures that no legacy GP data is shared between GP objects
and annotations, before doing the conversion, by duplicating annotation
data when required.
Conversion code can then completely ignore annotation GPv2 IDs.
Pull Request: https://projects.blender.org/blender/blender/pulls/120581
For socket value logging this needs to be used in a couple other places.
Also remove the operator name argument. For the forseable future this
will only be used with the existing node tools operator anyway.
This PR adds an option to specify custom colors for a
motion path. One for frames before the current frame
and one frame for after. With this it is easier to see
the relation of the motion path to the current frame.
That was already the case with the default colors, but
not with custom colors.
On a technical side note, the colors pre and post the current
frame were already different.
The shader multiplied the custom color by 0.25
for anything pre current frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/119375