This patch implements the Texture node for the realtime compositor. The
evaluation of the texture is not GPU accelerated, but is cached as a
form of temporary implementation since the Texture node is deprecated
and will be removed in the future. Furthermore, texture node evaluation
is not supported for now.
This patch also introduces the concept of an ID static cache, which
uses the DrawDataList mechanism to invalidate the cache as needed,
consequently, a DrawDataList was added to the Tex ID structure.
An improvement that should be implemented outside of this patch is to
implement support for proxy textures in results to avoid redundant
copies in the execute method of the texture node. This should be
straightforward bit will be implemented in a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/107291
Fixes a warning on GCC 13 about `uint` being used in the declaration and
the proper enum type `eDupli_ID_Flags` being used in the definition for
`BKE_id_copy_for_duplicate`.
Similar to the cache of loose edges added in 1ea169d90e,
cache the number of loose vertices and which are loose in a bit map.
This can save significant time when drawing large meshes in the
viewport, because recalculations can be avoided when the data doesn't
change, and because many geometry nodes set the loose geometry
caches eagerly when the meshes contain no loose elements.
There are two types of loose vertices:
1. Vertices not used by any edges or faces
`Mesh.loose_verts()`
2. Vertices not used by any faces (may be used by loose edges)
`Mesh.verts_no_face()`
Because both are used by Blender in various places, because the cost
is only a bit per vertex (or constant at best) and for design consistency,
we cache both types of loose elements. The bit maps will only be
allocated when they're actually used, but they are already accessed
in a few important places:
- Attribute domain interpolation
- Subdivision surface modifier
- Viewport drawing
Just skipping viewport drawing calculation after certain geometry
nodes setups can have a large impact. Here is the time taken by
viewport loose geometry extraction before and after the change:
- 4 million vertex grid node: 28 ms to 0 ms
- Large molecular nodes setup (curve to mesh node): 104 ms to 0 ms
- Realize instances with 1 million cubes: 131 ms to 0 ms
Pull Request: https://projects.blender.org/blender/blender/pulls/105567
Animation: Adds a new "Parent Space" Orientation option for the Transformation Gizmo.
---
For child targets (objects, bones, etc) being able to transform in parent space is a desired feature (especially when it comes to rigging / animation).
For objects:
* with a parent, the gizmo orients to it's parents orientation
* without a parent, the gizmo orients to Global space
For Armatures:
* Child bone shows parent's space regardless if "Local Location" is set for parent bone
* For root bone **without** "Local Location" set, use the armature objects space.
* For root bone **with** "Local Location" set, use local bone space.
---
No new transformation orientation code needs to be written, we can achieve the desired results be using the existing `transform_orientations_create_from_axis`, `ED_getTransformOrientationMatrix`, and `unit_m3` methods. To do this, we check to see if the bone has a parent, if so, we use the bones pose matrix (`pose_mat`). This is done similarly for objects using the parent's object matrix (`object_to_world`).
Pull Request: https://projects.blender.org/blender/blender/pulls/104724
This patch adds several tools and options to the weight paint mode of Grease Pencil.
* Blur tool: smooths out vertex weights, by calculating a gaussian blur of adjacent vertices.
* Average tool: painting the average weight from all weights under the brush.
* Smear tool: smudges weights by grabbing the weights under the brush and 'dragging' them.
* With the + and - icons in the toolbar, the user can easily switch between adding and subtracting weight while drawing weights.
* With shortcut `D` you can toggle between these two.
* The auto-normalize options ensures that all bone-deforming vertex groups add up to 1.0 while weight painting.
* With `Ctrl-F` a radial control for weight is invoked (in addition to the radial controls for brush size and strength).
* With `Ctrl-RMB` the user can sample the weight. This sets the brush Weight from the weight under the cursor.
* When painting weights in vertex groups for bones, the user can quickly switch to another vertex group by clicking on a bone with `Ctrl-LMB`.
For this to work, follow these steps:
* Select the armature and switch to Pose Mode.
* Select your Grease Pencil object and switch immediately to Weight Paint Mode.
* Select a bone in the armature with `Ctrl-LMB`. The corresponding vertex group is automatically activated.
Pull Request: https://projects.blender.org/blender/blender/pulls/106663
Update the RNA and DNA documentation for two bone matrices:
- `PoseBone.matrix_channel` (`bPoseChannel::chan_mat` in DNA) contains
the evaluated loc/rot/scale channels, including constraints and drivers.
- `PoseBone.matrix` (`bPoseChannel::pose_mat` in DNA) contains the same
transform, but then expressed in the armature object space.
No functional changes, just clarifications in comments / tooltips.
This is the first step for refactoring the lightcache system.
Each probe instance (as in `Object`) will now store its own baked data.
The data is currently stored in uncompressed readable format.
This introduces two new operators for baking to avoid confusion with
the previous light baking pipeline. These do nothing other than
creating empty caches that will be populated by EEVEE later on.
The DNA storage is made to be able to include multiple caches
in case of baked simulation over time but it isn't yet supported.
I prefer to keep the implementation simple for now as the long term
goals for this feature are uncertain.
There is still a type flag (`LightProbeObjectCache.cache_type`) that
will be used for versioning.
The naming convention of structs is a bit weird but that's all I
found in order to avoid interfering with the old scene light cache
that is still used by (old) EEVEE.
Related task #106449.
Pull Request: https://projects.blender.org/blender/blender/pulls/106808
These IDs kept their address, but their content has been replaced
(re-read from the memfile undo step). Add an ID tag to identify them.
As a further cleanup, systematically tag these IDs for despgraph COW,
since their data is effectively modified (though in practice all of
these IDs are expected to already have other update tags anyway).
No change in behavior is expected from this commit.
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
Having a type defined allows the compiler to help with type safety. For
example we can use it in switches to trigger a warning when a new object
type is added but not covered by the switch yet (but probably should).
Re-organize ID tags in a more logical way, and keep their values
strictly increasing, splitting the free available ones in-between the
main groups (to avoid having to edit all tags values when adding a new
one).
Note that shuffling around these ID tags values should not be an issue
anymore, all of these are strictly run-time, and fully cleared in write
code when writing into a .blend file.
This also lead to the second cleanup, which is removing some asserts on
ID tag values in readcode, these are useless since the tag is cleared on
write.
Similar to 7eee378ecc, this change decreases memory usage and
improves performance when copying curves and meshes without changing
their topology. The same change used for custom data layers is applied
to face and curve offset indices, which aren't stored as a custom data
layer.
The implicit sharing info for the offsets is stored in the mesh and
curve runtime structs, since it doesn't need to be written to files
directly. When changing the offsets pointer directly, the sharing info
must be updated accordingly. To make that easier, a few utility
functions take care of common operations like making an array mutable,
resizing an array, and creating sharing info for allocated data.
This commit also clarifies the intention to not allocate the offsets
at all when there are no curves/faces. That slightly complicates some
of the logic, but there's no reason for the single `0` integer to be
allocated.
Pull Request: https://projects.blender.org/blender/blender/pulls/106907
This type will be used to store mesh edges in #106638, but it could
be used for anything else too. This commit adds support for:
- The new type in the Python API
- Editing the type in the edit mode "Attribute Set" operator
- Rendering the type in EEVEE and Cycles for all geometry types
- Geometry nodes attribute interpolation and mixing
- Viewing the type in the spreadsheet and using row filters
The attribute uses the `blender::int2` type in most code, and
the `vec2i` DNA type in C code when necessary. The enum names
are based on `INT32_2D` for consistency with `INT8` and `INT32`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106677
The position attribute has special meaning for point clouds, and
meshes and curves have access methods for the attribute as well.
This saves boilerplate and gives more consistency between types.
This integrates the new implicit-sharing system (from fbcddfcd68)
with `CustomData`. Now the potentially long arrays referenced by custom
data layers can be shared between different systems but most importantly
between different geometries. This makes e.g. copying a mesh much cheaper
because none of the attributes has to be copied. Only when an attribute
is modified does it have to be copied.
Also see the original design task: #95845.
This reduces memory and improves performance by avoiding unnecessary
data copies. For example, the used memory after loading a highly
subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25%
less which is the expected amount because in `main` there are 4 copies
of the data:
1. The original data which is allocated when the file is loaded.
2. The copy for the depsgraph allocated during depsgraph evaluation.
3. The copy for the undo system allocated when the first undo step is
created right after loading the file.
4. GPU buffers allocated for drawing.
This patch only gets rid of copy number 2 for the depsgraph. In theory
the other copies can be removed as part of follow up PRs as well though.
-----
The patch has three main components:
* Slightly modified `CustomData` API to make it work better with implicit
sharing:
* `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are
meaningless when implicit-sharing is used.
* `CD_ASSIGN` has been removed as well because it's not an allocation
type anyway. The functionality of using existing arrays as custom
data layers has not been removed though.
* This can still be done with `CustomData_add_layer_with_data` which
also has a new argument that allows passing in information about
whether the array is shared.
* `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It
only existed because of `CD_REFERENCE`.
* `CustomData_copy` and `CustomData_merge` have been split up into a
functions that do copy the actual attribute values and those that do
not. The latter functions now have the `_layout` suffix
(e.g. `CustomData_copy_layout`).
* Changes in `customdata.cc` to make it actually use implicit-sharing.
* Changes in various other files to adapt to the changes in `BKE_customdata.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106228
Makes it possible to select multiple custom script directories in Preferences >
File Paths, replacing the single Scripts path option. Each of these directories
supports the regular script directory layout with a startup file (or files?),
add-ons, modules and presets.
When installing an add-on, the script directory can be chosen.
NOTE: Deprecates the `bpy.types.PreferencesFilePaths.script_directory`
property, and replaces `bpy.utils.script_path_pref` with
`bpy.utils.script_paths_pref`.
Pull Request: https://projects.blender.org/blender/blender/pulls/104876
Introduces *ARegionType.poll()* as a way to dynamically add/remove a region. The region is still there internally, but is not accessible to the user.
Previously editors would to this manually, by either removing/adding regions altogether, or hiding them, unsetting their alignment (so no AZones are added I assume) and removing their event handlers. Polling makes this much simpler.
We plan to use this in #102879.
This patch refactors multiple editors to use region polling:
- File Browser
- Sequencer
- Clip Editor
- Preferences
Notes:
- Previously, editors would lazy-create some of the regions. Versioning is added here to ensure they are always there. Could be a separate patch.
- Some editors reuse a region in different display modes, and so additional work needs to be done to reinit regions they become available or the mode changes. Typically `V2D_IS_INIT` is unset for that, which isn't great. Could be improved, but not a new issue.
Behavior change:
- When the Preferences are opened as a regular editor, the "execution" region in the preferences that displays the *Save Preferences* button would still be there, but empty with a scrollbar.
This patch makes it disappear entirely.
## Implementation
- Introduces `ARegionType.poll()`
- Before a window is drawn, all contained regions have their poll checked, and the result is stored in a flag (`RGN_FLAG_POLL_FAILED` - runtime-only flag).
- If the result of the poll changes, the area is re-initialized and event handlers are added/removed.
- UI code checks the flag as needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/105088
Implements #95967.
Currently the `MPoly` struct is 12 bytes, and stores the index of a
face's first corner and the number of corners/verts/edges. Polygons
and corners are always created in order by Blender, meaning each
face's corners will be after the previous face's corners. We can take
advantage of this fact and eliminate the redundancy in mesh face
storage by only storing a single integer corner offset for each face.
The size of the face is then encoded by the offset of the next face.
The size of a single integer is 4 bytes, so this reduces memory
usage by 3 times.
The same method is used for `CurvesGeometry`, so Blender already has
an abstraction to simplify using these offsets called `OffsetIndices`.
This class is used to easily retrieve a range of corner indices for
each face. This also gives the opportunity for sharing some logic with
curves.
Another benefit of the change is that the offsets and sizes stored in
`MPoly` can no longer disagree with each other. Storing faces in the
order of their corners can simplify some code too.
Face/polygon variables now use the `IndexRange` type, which comes with
quite a few utilities that can simplify code.
Some:
- The offset integer array has to be one longer than the face count to
avoid a branch for every face, which means the data is no longer part
of the mesh's `CustomData`.
- We lose the ability to "reference" an original mesh's offset array
until more reusable CoW from #104478 is committed. That will be added
in a separate commit.
- Since they aren't part of `CustomData`, poly offsets often have to be
copied manually.
- To simplify using `OffsetIndices` in many places, some functions and
structs in headers were moved to only compile in C++.
- All meshes created by Blender use the same order for faces and face
corners, but just in case, meshes with mismatched order are fixed by
versioning code.
- `MeshPolygon.totloop` is no longer editable in RNA. This API break is
necessary here unfortunately. It should be worth it in 3.6, since
that's the best way to allow loading meshes from 4.0, which is
important for an LTS version.
Pull Request: https://projects.blender.org/blender/blender/pulls/105938
Previously the only way to control the subtype was to remove the group
input or output and create it again. This commit adds a dropdown to
change an existing socket, for supported socket types.
Based on a patch by Angus Stanton: https://developer.blender.org/D15715
It was necessary to fix the UI code slightly; the layout's context
wasn't being used in calls to an operator's enum items callback.
Pull Request: https://projects.blender.org/blender/blender/pulls/105614
Allows NLA strips to horizontally translated over each other. If a strip is dropped when translating, it'll cause the strip to shuffle into place.
---
Abstracted large conditional branch in `recalcData_nla` into it's own `nlastrip_fix_overlapping` method for increased readability. No logical changes were made.
---
[Archived Phabricator Patch](https://archive.blender.org/developer/D10102)
Pull Request: https://projects.blender.org/blender/blender/pulls/105532
Remove comments from `eBConstraint_Types` that
- were used long ago during a big refactor effort, but are no longer
necessary, or
- just repeated the name of the enum constant.
No functional changes.
Face Nearest only works with individual projection, so always set the
`SCE_SNAP_PROJECT` flag in this case.
Also gray out the `Project Individual Elements` option in the UI if
`Face Nearest` is enabled.
And change the description to indicate that `Project Individual Elements`
is always enabled with the `Face Nearest` option.
(I feel a better design for this option needs to be considered).
No user visible changes expected.
For brush assets, we need a way to store a reference to a brush in .blend files, so that the last active brush can be restored from the file. See #101908. It seems like a generally useful thing to have.
Adds a new DNA struct to store a "weak" asset reference, that is, a reference that can break under a number of circumstances, but should work reliably enough under normal usage. There's no way to reliably reference an asset currently, so this works on a "best effort" basis. It can break when assets are moved inside the asset library, asset libraries are unregistered from the Preferences, or a file is opened on a different machine with different Preferences, for example. It can also break currently if an asset library is renamed.
It contains:
- Information to identify the asset library the asset can be found in.
- A relative "identifier" (currently a relative path) for the asset within the asset library.
There's further code to resolve a weak reference to file paths and Blender library paths.
Part of #101908.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/105603
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
This patch adds an option to the Status Bar: `Scene Duration`
This shows the duration of the current scene in frames and timecode
`Duration: <timecode> (Frame <current frame>/<total frames>)`
The timecode follows the formatting defined in the user preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/104882
These `ME_POLY_LOOP_PREV` are redundant, since they're similar to
the `poly_corner_prev` inline functions. They were also confusing,
since they took an index into the poly and returned an index into
the entire corner range. Instead structure code to use the function
version, and simplify some loops in the process.
Add control over how bone relation lines are drawn. Instead of always
drawing from the head of the child to the tail of the parent, give users
a choice for the parent side of the line. This can now be toggled
between the head and the tail of the bone, where the tail is Blender's
original behaviour and is retained as default value.
Pull request: https://projects.blender.org/blender/blender/pulls/105427
Translating an image in fullframe compositor now also translates
the backdrop image for the viewer node.
Attached gif shows the behavior. Notice how gizmo moves with correct
values with the image but the frame stays to indicate what will get
rendered.
Note: This patch is a continuation of [D12750]
(https://archive.blender.org/developer/D12750). In a previous patch,
display offset on screen was not computed correctly. This has now
been fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/105677
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
This flag is moved to a different variable but the default value is still placed on the wrong variable.
This fixes the default value assignment but due to the old flag bits are in conflict with used bits in the new flag variables, versioning changes are not included.
Pull Request: https://projects.blender.org/blender/blender/pulls/105852
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.
