The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
The ConsoleLine's `cursor` stores the index of the char where the
cursor is currently at. This works for ASCII characters, which
are all one-byte long, but will be offset when the string contains
multi-byte UTF8 sequences.
This caused an issue during auto-complete where the matching results
would be offset to the right.
This commit reuses the same logic as the text editor's
`current_character` RNA property, so that on getting and setting, the
cursor index is converted from and to UTF-8.
Ref: !114121
This gives better asserts in debug builds through use of Span, more
safety when name convention attributes happen to have different types
or domains, and simpler code in some cases. But the main reasoning is to
avoid relying on the specifics of CustomData more to allow us to replace
it in the future.
There were two issues at play here.
The first is that only enum properties with raw array access were
supported.
The second is that if the item property pointer was found immediately,
`rna_raw_access` could fall back to the slower loop without checking if
the property was an enum property, which the slower loop did not
support. This would cause the code to go through the entire slower loop
without doing anything. In the case of `foreach_get` without a
compatible buffer, this meant that the temporary, uninitialized array
(which was supposed to be set by `rna_raw_access`) would be converted to
Python integers, causing garbage values to be retrieved by
`foreach_get`, since they were created from uninitialized memory.
This patch adds support for enum properties that are not arrays and adds
asserts if an enum array property is encountered because they do not
exist.
Additional unreachable asserts have been added to the default case of
each switch block within the slower loop because there are prior checks
that the property type is supported, so the switch blocks should never
get an unsupported property type.
Pull Request: https://projects.blender.org/blender/blender/pulls/115508
- "Frame Step" -> "Number of frames to skip forward while baking each
frame": expand description which was just copying the prop name.
- "b-bone" -> "B-Bone": title case.
- "Volumes Lighting" -> "Volume Lighting": typo.
- "Volumes Shadows" -> "Volume Shadows": typo.
- "Insert Blank Keyframe (All Layer)" -> "(All Layers)": typo.
- "the an" -> "an", typo.
- "Inverse" -> "Invert": use verb instead of noun for an action.
- "Desination" -> "Destination": typo.
- "Hides all other F-Curves other than the ones being framed": remove
extra "other".
- "Remove Bone from Bone collections" -> "Collection", singular because
the operator is only applied to the active collection. Also title
case on "Collection".
- "Change Stroke material with selected material" -> "Assign the
active material slot to the selected strokes": rephrase by reusing
the message from the non-Grease Pencil materials.
- "VisAction", "VisArea" -> "Visibility Action", "Visibility Area":
expand abbreviation. This is not exposed in the UI right now but
will show up in the API docs.
- "Stop Mode Right / Global Down" -> "Stop Move" (typo).
- "... for node input %s": remove extra space.
- "Move along their normal" -> "Move shadows along their normal":
rephrase unclear sentence.
- "Stat Vis" -> "Mesh Analysis": stands for "Statistical
visualization"? Unclear and not shown anywhere. Reuse the label
specified in the UI code instead.
- " Output data...": remove leading space.
- "Attribute domain for the selection and group id inputs": title case
on "Selection" and "Group ID" as that is how they appear in the UI.
- "Ior" -> "IOR": uppercase acronym, for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/115964
This de-duplicate some passes in the raytracing
pipeline and make it more ready for adoption
of arbitrary closure evaluation. This last part
means the removal of some per closure type
options.
The put in common the tile classification step
that is now done only once for all 3 closure
type. Also add some speedup to the tile
compaction phase that is now only twice
faster.
The horizon-scan setup was also de-duplicated
and run only if needed, which can save up to
0.5ms is complex scenes.
However, this moves the max-roughness and and
resolution scaling to a common parameter.
This is to be able to support arbitrary closure
evaluation where multiple closure with conflicting
parameters could be evaluated in one tracing pass.
Pull Request: https://projects.blender.org/blender/blender/pulls/116009
Adds initial support for File Handler registration with the python API
for design task #68935. File Handlers will allow developers to associate
additional UI behavior and capability to operators traditionally used
only within the file browser.
The initial commit should have no user visible changes, but will serve
as the foundation for providing file drag & drop capabilities to
operators that can manage files (#111242).
See the PR for an example of python usage.
See design task #68935 for remaining work to be explored in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/112466
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
No functional changes.
Before this PR the interpolation mode of a new keyframe
was read from the User Preference at the deepest level
where the keyframe is created.
In case where this shouldn't be done, the flag
`INSERTKEY_NO_USERPREF` was passed in.
In this case it would fall back to some default values.
In order to make these low level functions
more flexible, the keyframe settings are now passed in.
I've made a new struct `KeyframeSettings` that holds the
* interpolation
* key type
* handle type
and a function `get_keyframe_settings` that allows
you to quickly get this settings struct.
This is a first step that will allow to pass in the
interpolation mode from python in the future.
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/115898
No functional changes.
To reduce the argument count of `insert_vert_fcurve`,
the x and y argumentsto define the position
of a keyframe can be merged into a single `float2`
Pull Request: https://projects.blender.org/blender/blender/pulls/115886
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
This was reported for UV editing but also e.g. some modeling operations
were affected.
In 295bc1249a, a listener for `NC_GEOM` > `ND_DATA` was added to the
Outliner in order to update when renaming bones (c4622c405e).
Since we are only interested in the naming part (no need to update the
Outliner otherwise), the notifier/listener combo was made more specific
by including the `NA_RENAME` action here.
Since this was a very general thing to listen to, other operations might
have relied on this to properly update, but having checked many things,
I could spot only one case where an Outliner update was missing after
the initial change and that was adding images.
This case was added separately now.
Pull Request: https://projects.blender.org/blender/blender/pulls/115799
Move the contents of `ANIM_bone_collections.h` into its C++
`ANIM_bone_collections.hh` sibling. Blender is C++ by now that we can do
without the C header.
No functional changes.
This PR adds the drawing placement modes from GPv2.
The drawing placement defines the depth (origin, view, surface, etc.) and a plane (view, cursor, xz, etc.).
This introduces a new helper class `DrawingPlacement` that does all of the internals to find the correct projection and just exposes a simple function to project from screen space to the drawing plane/surface.
Note: Drawing on other strokes currently doesn't work, because GPv3 can't be rendered to image yet. We use the depth buffer of the grease pencil render result to find the right depth.
Pull Request: https://projects.blender.org/blender/blender/pulls/115602
This is in preparation for eventual hierarchical bone collections.
The motivation here is that this will allow us to efficiently specify
children as an index range, which would be inefficient with a listbase
due to the list traversal overhead incurred for index-based look ups.
We're still saving to blend files as a list base for forwards compatibility
with Blender 4.0, but storing as an array at runtime for efficient indexing.
This should not result in any user-visible changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115354
- Support passing in unterminated C-strings when clamped by the size
argument.
- Pair string and it's size arguments together in IDP_NewStringMaxSize.
- Remove redundant size check which made it seem as if the string
might not be null terminated.
- Replace clamping the result of strlen(..) with BLI_strnlen,
to avoid calculating the length past the size checked.
- Add doc-string for unclamped string creation.
Changes:
- Renamed Split Viewer Node to Split Node
- Split Node is now under `Utilities` (similar to Switch node)
- Versioning: split viewer from 4.0 and before is replaced with the new split node connected to a new viewer node.
Pull Request: https://projects.blender.org/blender/blender/pulls/114245
The compositor doesn't run when changing node tree options. That was due
to a nullptr notifier reference for RNA node tree edits.
This patch uses the node tree ID for the notifier reference.
Additionally, the listener code was extended to always tag the node tree
when the reference is null, which converts missing updates issues like
this one to superfluous updates, since it is safer.
Pull Request: https://projects.blender.org/blender/blender/pulls/115532
Currently, in weight paint mode, there is an icon for
face and vertex selection mode, but there isn't one
for the default mode where the user can select a bone
in any tool by alt clicking.
This lack of indication might lead to confusion for the users
when they are not able to select a bone by
alt clicking during weight painting.
By adding a bone selection icon when there is a pose
mode armature, we can communicate to the user that:
1. they can select a bone while the bone selection icon is active.
(when they are not in face or vertex selection mode)
2. they have forgot to select an armature when entering
weight paint mode by not showing the bone selection
icon at all when there is no pose mode armature.
When the bone selection icon is inactive,
the user can't select a bone.
(alt clicking selects face and vertex mode's respective element)
When no armature is selected when entering weight paint mode,
the bone selection icon doesn't show up indicating that the user
has forgot to select an armature.
(The user is also unable to select a bone by alt clicking.)
## Selection tool for bone selection mode
Currently, while selection tools exist for face and vertex
selection mode, one doesn't exist for the default mode
(bone selection mode). As the default mode will be getting
a clear indicator that it will function as a bone selection mode,
I added a selection tool entry for the bone selection mode.
Face and vertex selection modes has the shortcut 1 and 2,
so it seemed natural to give bone selection mode the shortcut of 3.
Pull Request: https://projects.blender.org/blender/blender/pulls/115409
Sequencer timeline UI repainting is 3x-4x faster now, for complex
timelines. On Sprite Fright Edit data set, with whole timeline visible
(2702 strips), repainting the timeline UI with all overlay options
(waveforms, offsets, thumbnails etc.):
- Windows (Ryzen 5950X, RTX 3080Ti, OpenGL): 62ms -> 18.6ms (16FPS -> 54FPS)
- Mac (M1 Max, Metal): 39.8ms -> 11.5ms (25FPS -> 86FPS)
This is achieved by:
- Avoiding tiny GPU draw calls (i.e. drawing one quad a time), instead
batch all the quads / lines needed by the timeline display into
series of about-1000 quads per draw.
- For retiming keys display, batch their keyframe point drawing too.
- For audio waveform overlay display, change it to draw batched quads
instead of alternating between line strips and triangle strips. This
actually changes how the waveform looks like (implements #115274)
and fixes some visual issues with waveforms too.
- For fcurve overlays, also draw them as batched quads.
While at it, this also fixes an issue where while dragging strips over
other strips, their text labels would look as if they are behind the
background strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/115311
Description added in 9c2330d821.
It is unclear what "external" in this case means, why these asset
libraries are considered "normal" (are the others not "normal"?) and the
term "asset repository" is wrong (should be "asset library").
I think this isn't actually shown in the UI currently in fact.
Implement the next phases of bounds improvement design #96968.
Mainly the following changes:
Don't use `Object.runtime.bb` for performance caching volume bounds.
This is redundant with the cache in most geometry data-block types.
Instead, this becomes `Object.runtime.bounds_eval`, and is only used
where it's actually needed: syncing the bounds from the evaluated
geometry in the active depsgraph to the original object.
Remove all redundant functions to access geometry bounds with an
Object argument. These make the whole design confusing, since they
access geometry bounds at an object level.
Use `std::optional<Bounds<float3>>` to pass and store bounds instead
of an allocated `BoundBox` struct. This uses less space, avoids
small heap allocations, and generally simplifies code, since we
usually only want the min and max anyway.
After this, to avoid performance regressions, we should also cache
bounds in volumes, and maybe the legacy curve and GP data types
(though it might not be worth the effort for those legacy types).
Pull Request: https://projects.blender.org/blender/blender/pulls/114933
This adds a new function, `compare_meshes`,
as a replacement for `BKE_mesh_cmp`.
The main benefits of the new version are the following:
- The code is written in c++, and makes use of the new attributes API.
- It adds an additional check, to see if the meshes only differ by
their indices. This is useful to verify correctness of new algorithmic
changes in mesh code, which might produce mesh elements in a different
order than the original algorithm. The tests will still fail, but the
error will show that the indices changed.
Some downsides:
- The code is more complex, due to having to be index-independent.
- The code is probably slower due to having to do comparisons "index-
independently". I have not tested this, as correctness was my priority
for this patch. A future update could look to improve the speed,
if that is desired.
- This is technically a breaking API change, since it changes the
returned values of `rna_Mesh_unit_test_compare`. I don't think that
there are many people (if any) using this, besides our own unit tests.
All tests that pass with `BKE_mesh_cmp` still pass with the new version.
**NOTE:**
Currently, mesh edge indices are allowed to be different in the
comparison, because `BKE_mesh_cmp` also allowed this. There are some
tests which would fail otherwise. These tests should be updated, and
then the corresponding code as well.
I wrote up a more detailed explanation of the algorithm here:
https://hackmd.io/@bo-JY945TOmvepQ1tAWy6w/SyuaFtay6
Pull Request: https://projects.blender.org/blender/blender/pulls/112794
Note: Everything here is read-only, this is expected to be used as
testing/validating/debug info access for the time being, not as an
actual way to edit data.
When pressing `I` in the viewport, the colors of the FCurve channels were no longer set correctly.
Caused by #113504
Fix by removing the flag that determined that in the first place,
and read straight from the user preferences. Then move the code
that sets the mode on the FCurve into the function that actually creates it.
For 99% of cases the code went to the user preference flag `AUTOKEY_FLAG_XYZ2RGB`
and if that was set, the `INSERTKEY_XYZ2RGB` would be set. The only case where this
was not from the user preferences was from custom keying sets.
There was an override flag for FCurve colors on custom keying sets.
I removed that with this patch since the use case is not apparent
and custom keying sets are hardly used.
Pull Request: https://projects.blender.org/blender/blender/pulls/115297
The problem here was that `RNA_parameter_set_lookup` was used incorrectly.
Instead of passing in the `PointerRNA`, one can pass in the value directly. If one
wanted to pass the `PointerRNA`, one would have to use `PARM_RNAPTR`, but
that's not necessary here.
Pull Request: https://projects.blender.org/blender/blender/pulls/115347
No functional changes.
Rename the `eAutokey_Flag` to `eKeyInsert_Flag`
to indicate that it is not only used for auto keying.
Also rename the enum items to better reflect what they are used for.
Pull Request: https://projects.blender.org/blender/blender/pulls/115295
Add an "Index Switch" node which is meant as a simpler version of
the "Menu Switch" from #113445 that doesn't allow naming items
or displaying them in a dropdown, but still allows choosing between
an arbitrary number of items, unlike the regular "Switch" node.
Even when the Menu Switch is included (which should be in the
same release as this), it may still be helpful to have explicit mapping
of indices, and a fair amount of the internals can be shared anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/115250
Currently we have options to transfer the paint mask, face sets, and
color attributes to the new mesh created by voxel remesh. This doesn't
make use of the generic attribute design, where it would be clearer to
transfer all attributes with the same methods. That's reflected in the
code as well-- we do duplicate work for the mask and vertex colors, for
example.
This commit replaces the transfer options with a single checkbox for
all attributes. All attribute types on all domains are transferred with
basically the same method as the "Sample Nearest" node from geometry
nodes-- they take the value from the nearest source element of the same
domain. Face corners are handled differently than before. Instead of
retrieving the mixed value of all the corners from the nearest source
vertex, the value from the nearest corner of the nearest face.
---
Some timing information, showing that when interpolating the same
data, the attribute propagation is significantly faster than before.
Edge and corner attributes would add some cost (edges more than
corners), but might not always be present.
Before
```
voxel_remesh_exec: 3834.63 ms
BKE_shrinkwrap_remesh_target_project: 1141.17 ms
BKE_mesh_remesh_reproject_paint_mask: 689.35 ms
BKE_remesh_reproject_sculpt_face_sets: 257.14 ms
BKE_remesh_reproject_vertex_paint: 54.64 ms
BKE_mesh_smooth_flag_set: 0.15 ms
```
After
```
voxel_remesh_exec: 3339.32 ms
BKE_shrinkwrap_remesh_target_project: 1158.76 ms
mesh_remesh_reproject_attributes: 517.52 ms
```
Pull Request: https://projects.blender.org/blender/blender/pulls/115116
* Rename "Type" to "Shape" in user interface. RDNA already used
the term Shape (Still need to push this from office)
* Show LightProbe overlay settings
* Rename "Cubemap" to "Sphere"
* Rename "Planar" to "Plane"
Pull Request: https://projects.blender.org/blender/blender/pulls/114406
This add the displacement option to EEVEE materials.
This unifies the option for Cycles and EEVEE.
The displacement only option is not matching cycles
and not particularly useful. So we decided to not
support it and revert to displacement + bump.
Pull Request: https://projects.blender.org/blender/blender/pulls/113979
Expose the ID type identifier as defined by the `rna_enum_id_type_items`
enum items as `ID.id_type` in RNA.
Add some test to `id_management` ensuring that all ID types exposed in
`bpy.data` have a valid `id_type` value, i.e. that they have a matching
entry in `rna_enum_id_type_items`.
This will hopefully prevent future cases like #115151 .
