Auto-depth is no longer reset during consecutive touch-pad motion.
Details:
- Add wmEvent::flag, WM_EVENT_IS_CONSECUTIVE to detect consecutive
track-pad & NDOF motion events. Expose via RNA as Event.is_consecutive.
- Consecutive events are broken by button/key presses and mouse motion.
- Add `WM_event_consecutive_data_*` functions, so operators can store
data between consecutive events.
- Add `ED_view3d_autodist_last_*` functions to access the last autodist
pivot point for view operators to use.
Various UI code would store the `AssetHandle` in a way that turns out to
be unsafe. The file-data is part of the file browser caching system that
releases file-data when a certain maximum of items is in the cache. So
even while just iterating over the assets, earlier iterated asset
handles may become invalid. Now asset handles are really treated as
volatile, short lived objects.
For the asset-view, the fix was more involved. There we need an RNA
collection of asset-handles, because the UI list code requires that. So
we create a dummy collection and get the asset handles as needed by
index. This again meant that I had to keep the index of the collection
and the asset-list in sync, so all filtering had to be moved to the UI
list.
I tried duplicating the file-data out of the cache instead, but that
caused problems with managing the memory/ownership of the preview
images.
`AssetHandle` should be removed and replaced by `AssetRepresentation`,
but this would be an even more disruptive change (breaking API
compatibility too).
Fixes#104305, #105535.
Pull Request: #105773
- Show/hide mask layers: the tooltip was confusing from a user's
perspective, because they should not be expected to know what a hide
flag is.
- Active Spline -> Active Point: likely a copy and paste error.
- Geo Nodes face is planar node: forgotten article.
- Axes, plural instead of axis for the viewport preferences. Here
there are several usages of axis or axes. Since they refer to
coordinate axes I believe they should be plural, even though the
property `mini_axis_type` is still wrong.
-----
Pull Request: https://projects.blender.org/blender/blender/pulls/105814
The two removed BKE functions were at a mid-level of abstraction
that doesn't make total sense in this API. Removing them is also
helpful in the general effort to have the attribute system rely less
on `CustomData` internally.
This simplifies the usage of the API and is preparation for #104478.
The `CustomData_add_layer` and `CustomData_add_layer_named` now have corresponding
`*_with_data` functions that should be used when creating the layer from existing data.
Pull Request: https://projects.blender.org/blender/blender/pulls/105708
- DriverVariable.name update function passed DriverVar to
BKE_driver_invalidate_expression as a ChannelDriver.
- DriverTarget.name update function passed DriverTarget to
BKE_driver_invalidate_expression as a ChannelDriver.
- DriverVariable.type update function DriverVar accessed ChannelDriver,
clearing a flag.
This was exposed by [0] however this issue existed beforehand.
[0]: c26566ad27
Refactoring mesh code, it has become clear that local cleanups and
simplifications are limited by the need to keep a C public API for
mesh functions. This change makes code more obvious and makes further
refactoring much easier.
- Add a new `BKE_mesh.hh` header for a C++ only mesh API
- Introduce a new `blender::bke::mesh` namespace, documented here:
https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces
- Move some functions to the new namespace, cleaning up their arguments
- Move code to `Array` and `float3` where necessary to use the new API
- Define existing inline mesh data access functions to the new header
- Keep some C API functions where necessary because of RNA
- Move all C++ files to use the new header, which includes the old one
In the future it may make sense to split up `BKE_mesh.hh` more, but for
now keeping the same name as the existing header keeps things simple.
Pull Request: https://projects.blender.org/blender/blender/pulls/105416
- The Math node lost the headers of its operation type menu in
ee985fa925 , because a translation context was assigned to the RNA
property, but the headers declaration was not updated to extract the
messages with matching contexts.
- The message "Group Input" had a trailing space, which can be added
after translation.
Fix issues with the display of frame node labels, that made them
harder to read for people with low vision or on high dpi displays:
* Unclamp the size of text that is drawn in the frame node
so all sizes can be displayed consistently at all zoom levels
and independet of the UI scale.
* Account for the label when calculating the frame node's
bounds, so child nodes don't obscure the label.
Pull Request: https://projects.blender.org/blender/blender/pulls/104555
Refactor the following functions and cover with tests
* `BKE_fcurve_calc_bounds` - used to get the `rctf` bounding box of an fcurve
* `BKE_fcurve_calc_range` - used to get only the x-range, potentially faster when not needing y extents
`get_fcurve_end_keyframes` has been replaced with `get_bounding_bezt_indices` - dealing with indices allows to iterate over that range later
### BKE_fcurve_calc_bounds
* pass in an `rctf` instead of float pointers
* extract logic to get bounds into separate functions
### BKE_fcurve_calc_range
* removed the parameter `do_min_length` it was always false, and this function shouldn't concern itself with clamping.
Calling code can do that if the return bool is false
* use function to get x bounds separated from `BKE_fcurve_calc_bounds`
Pull Request: https://projects.blender.org/blender/blender/pulls/105177
The C4100 warning is related to unused formal parameters in functions.
Enabling it better aligns with "-Wunused-parameter" option in other
compilers.
While suppressing it with `__pragma(warning(suppress:4100))` is not the
same as using `__attribute__((__unused__))` in GCC or Clang, it is
still preferable to use it over completely hiding the warning.
This ensures consistent warning behavior across compilers and improves
code quality by addressing unused function parameters.
(Note that some warnings in Windows-specific code have already been
silenced in 7fcb262dfd)
Pull Request: https://projects.blender.org/blender/blender/pulls/105534
Move two settings that were previously in the "View" menu of the Graph Editor into User Preferences.
It has been mentioned in the meeting by Luciano Muñoz Sessarego that it would be good to move that to the preferences so you can set it once and then forget about it.
The Settings moved are:
Only Selected Curve Keyframes
Use High Quality Display
Pull Request: https://projects.blender.org/blender/blender/pulls/104532
Add a filepath argument to load/save pre/post.
Also add save_post_failed and load_post_failed handlers so it's always
possible to for the pre handlers to run a matching post action.
This makes it possible to know the filepath of the blend file mean
loaded/saved as well as supporting running an action when load/save
operations fail.
When loading and saving the startup-file, the path argument is set to
an empty string.
Details:
New RNA types were added to support storing primitive values in
PointerRNA. Primitive{String/Int/Float/Boolean}RNA. These will likely
only be used in some limited cases, in the case of BKE_callback_exec it
allows strings to be included as part of the PointerRNA **pointers
argument.
Ref !104769.
Currently the shade smooth status for mesh faces is stored as part of
`MPoly::flag`. As described in #95967, this moves that information
to a separate boolean attribute. It also flips its status, so the
attribute is now called `sharp_face`, which mirrors the existing
`sharp_edge` attribute. The attribute doesn't need to be allocated
when all faces are smooth. Forward compatibility is kept until
4.0 like the other mesh refactors.
This will reduce memory bandwidth requirements for some operations,
since the array of booleans uses 12 times less memory than `MPoly`.
It also allows faces to be stored more efficiently in the future, since
the flag is now unused. It's also possible to use generic functions to
process the values. For example, finding whether there is a sharp face
is just `sharp_faces.contains(true)`.
The `shade_smooth` attribute is no longer accessible with geometry nodes.
Since there were dedicated accessor nodes for that data, that shouldn't
be a problem. That's difficult to version automatically since the named
attribute nodes could be used in arbitrary combinations.
**Implementation notes:**
- The attribute and array variables in the code use the `sharp_faces`
term, to be consistent with the user-facing "sharp faces" wording,
and to avoid requiring many renames when #101689 is implemented.
- Cycles now accesses smooth face status with the generic attribute,
to avoid overhead.
- Changing the zero-value from "smooth" to "flat" takes some care to
make sure defaults are the same.
- Versioning for the edge mode extrude node is particularly complex.
New nodes are added by versioning to propagate the attribute in its
old inverted state.
- A lot of access is still done through the `CustomData` API rather
than the attribute API because of a few functions. That can be
cleaned up easily in the future.
- In the future we would benefit from a way to store attributes as a
single value for when all faces are sharp.
Pull Request: https://projects.blender.org/blender/blender/pulls/104422
The first implementation based the max value on what seemed reasonable.
It was therefore limited it to 5.
I received a request from a user in the first already merged #104741
to allow a higher max value.
Thus I adjusted the max value to be the same as the max value used for
"Vertex Size", 32.
Pull Request: https://projects.blender.org/blender/blender/pulls/105544
Indicating light colors by coloring the light icons.
Task: #104280
Pull Request: #105236
- Added a checkbox under overlay extra to enable/disable light coloring. Disabled by default.
- The outer ring and the sun rays are colored.
- Only the base color is shown, colors in nodes are not considered.
- "Lines" in the sense of number of lines
- "Number" can mean "amount, count" or "index, offset"
- "Second" can be an ordinal number or a unit
- "Root": add the brush curve to the "square root falloff" sense
- "Strip" can be a sequence or a type of hair rendering
- "Constant" in the sense of a value, for the Geometry Nodes add
submenu (#105447).
Additionally, extract:
- "Press a key" from the Keymap preferences.
- "MaskLayer", upon new mask layer creation
Ref #43295, #105447
Drivers: Introduce the Context Properties
The goal: allow accessing context dependent data, such as active scene camera
without linking to a specific scene data-block. This is useful in cases when,
for example, geometry node setup needs to be aware of the camera position.
A possible work-around without changes like this is to have some scene
evaluation hook which will update driver variables for the currently evaluating
scene. But this raises an issue of linking: it is undesirable that the asset
scene is linked to the shot file.
Surely, it is possible to have post-evaluation handler to clear the variables,
but it all starts to be quite messy. Not to mention possible threading
conflicts.
Another possibility of introducing a way to achieve the goal is to make it so
the dependency graph somehow parses the python expression where artists can
(and already are trying to) type something like:
depsgraph.scene.camera.matrix_world.col[3][0]
But this is not only tricky to implement properly and reliably, it hits two
limitations:
- Currently dependency graph can only easily resolve dependencies to a RNA
property.
- Some properties access which are valid in Python are not considered valid
RNA properties by the existing property resolution functions:
`camera.matrix_world[3][0]` is a valid RNA property, but
`camera.matrix_world.col[3][0]` is not.
Using driver variables allows to have visual feedback when the path resolution
fails, and there is no way to visualize errors in the python expression itself.
This change introduces the new variable type: Context Property. Using this
variable type makes allows to choose between Active Scene and Active View
Layer. These scene and view layer are resolved during the driver evaluation
time, based on the current dependency graph.
This allows to create a driver variable in the following configuration:
- Type: Context Property
- Context Property: Active Scene
- Path: camera.matrix_world[3][0]
The naming is a bit confusing. Tried my best to keep it clear keeping two
aspects in mind: using UI naming when possible, and follow the existing
naming.
A lot of the changes are related on making it so the required data is available
from the variable evaluation functions. It wasn't really clear what the data
would be, and the scope of the changes, so it is done together with the
functional changes.
It seems that there is some variable evaluation logic duplicated in the
`bpy_rna_driver.c`. This change does not change it. It is not really clear why
this separate code path with much more limited scope of supported target types
is even needed.
There is also a possible change in the behavior of the dependency graph: it
is now using ID of the resolved path when building driver variables. It used
to use the variable ID. In common cases they match, but when going into nested
data-blocks it is actually correct to use relation to the resolved ID. Not sure
if there was some code to ensure that, which now can be resolved. Also not sure
whether it is still needed to ensure the ID specified in the driver target is
build as well. Intuitively it is not needed.
Pull Request #105132
Unify both functions in one, with a more telling name,
to be sure of the order of the arguments. Some functional
cleanup of the using code to make it more explicit.
Pull Request #105413
When movie framerate does not match scene, content length was clamped to strip
length in scen framerate. This also caused issues with retiming which behaved in
similar way. Retiming was modified to use frame index of strip content, so even
when scene framerate is changed, retiming data is preserved in correct
proportions. This means, that handles are mapped to time in seconds rather than
to frames.
During the discussion for #101413 there was consensus that we could make
OIIO a mandatory dependency. This patch does just that.
The `idiff` testing tool remains optional.
Pull Request #105111
Add overlay option for retopology, which hides the shaded mesh akin to Hidden Wire, and offsets the edit mesh overlay towards the view.
Related Task #70267
Pull Request #104599
This PR removes the BKE_nlatrack_add, and adds new:
* BKE_nlatrack_insert_before
* BKE_nlatrack_insert_after
* BKE_nlatrack_new_before_and_set_active
* BKE_nlatrack_new_after_and_set_active
* BKE_nlatrack_new_head_and_set_active
* BKE_nlatrack_new_tail_and_set_active
methods to easily add new NLA tracks in relation to the existing track list.
Pull Request #104929
With the goal of clearly differentiating between arrays and single
elements, improving consistency across Blender, and using wording
that's easier to read and say, change variable names for Mesh edges
and polygons/faces.
Common renames are the following, with some extra prefixes, etc.
- `mpoly` -> `polys`
- `mpoly`/`mp`/`p` -> `poly`
- `medge` -> `edges`
- `med`/`ed`/`e` -> `edge`
`MLoop` variables aren't affected because they will be replaced
when they're split up into to arrays in #104424.
