Smooth modifier ported to Grease Pencil 3.0
Exposed `smooth_curve_attribute()` from `grease_pencil_edit.cc`
to achieve the smoothing effect. It will not be the exact same result
as the old algorithm.
Pull Request: https://projects.blender.org/blender/blender/pulls/116975
Rename: anim -> ImBufAnim
Rename: anim_index -> ImBufAnimIndex
There were cases where removing redundant "struct" qualifier caused
a warning since the name of the struct member was also anim.
Use uppercase type name to conform with other types names.
Ref !117394
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
Splits the flag `..._FLAG_INSERTNEEDED` between autokey and
manual keying. The fact that this flag was shared between the two
systems has been the cause of issues in the past. It wouldn't
let you insert a keyframe even though you explicitly used an operator
to do so.
In order to be clearer what options are used where, the user preferences
have been reordered.
By default "Only Insert Needed" will be enabled for auto-keying, but not for manual keying.
The versioning code will enable both if it was enabled previously.
# Code side changes
The keying system has flags that define the behavior
when keys are inserted. Some of those flags were shared
between keying and auto-keying. Some were only used for
auto-keying.
To clarify that, prefix flags that used exclusively in one or the other
system with `AUTOKEY`/`MANUALKEY`
Also the flag name on the user preferences and the tool settings was renamed.
Previously it was called `autokey_flag`. To indicated that it is not only used
for autokeying, rename it `keying_flag`.
Fixes: #73773
Pull Request: https://projects.blender.org/blender/blender/pulls/115525
When using the MapUV node for certain NPR workflows (for example palette
based remapping of colors) it can be useful to not use the default
anisotropic filtering.
In preparation of potentially adding more filter modes at a later stage
and to keep things consistent with the 'transform' node we use the full
set of interpolation modes in the enum, but expose only the implemented
ones in RNA..
No functional changes expected.
Before this PR the keyframing code was aware of driver specifics
and changed the frame where a key is inserted to the current driver value.
This is now changed so that the calling code needs to know where on the
FCurve the key should be inserted. This removes the need for the
`INSERTKEY_DRIVER` flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/116823
It is very common for graphical editors with layers to support
locking individual layers to protect them from accidental edits due
to misclicks. Blender itself already supports locking vertex groups.
This adds lock toggles for shape keys, with lock/unlock all operators.
The flags are checked by sculpt brushes, edit mode transform tools,
and Smooth, Propagate and Blend From Shape operators. This selection
aims to cover operations that only deform the mesh, where the shape
key selection matters.
Topology changing operations always apply to all keys, and thus
incorrect shape key selection is less impactful. Excluding them
from the new feature greatly reduces the patch size.
Pull Request: https://projects.blender.org/blender/blender/pulls/104463
For high radii Kuwahara, we use a Summed Area Table (SAT) implementation
to accelerate the classic variant of the algorithm. The problem is that
due to limited floating point precision, the SAT can produce artifacts
in its output.
An attempt to fix this was implemented in #114191, and while that patch
improved precision by 10x, the artifacts still existed, albeit less
noticeable. But since the improved precision also meant a performance
penalty, it was decided that the improvement is not worth it.
Since the artifacts are only noticeable for scenes with very high
values, this patch adds a High Precision option that defaults to false
and can be enabled by the user upon noticing any artifacts. The option
simply uses direction convolution instead of SAT in this case. The
downside, of course, is that it can be orders of magnitude slower.
An alternative to using this option is for the user to clamp the input
or downsample the image. Both methods should be documented in the
documentation.
Fixes: #113578.
Pull Request: https://projects.blender.org/blender/blender/pulls/115763
Opacity modifier implementation based on GP2.
Functionality is largely unchanged.
_Color Mode_ is either `Stroke` or `Fill` for modifying color opacity or
`Hardness`.
_Uniform Opacity_ does two things at once (!):
- Sets the same opacity value for every point in a stroke.
- Sets opacity as an absolute value rather than a factor.
_Weight as Factor_ (button to the right of Opacity Factor): Use the
vertex group as opacity __factor__ rather than an overall __influence__.
This is confusing and hard to convey, but copies behavior from GP2.
The _Influence_ panel contains the same filter settings as the GP2
modifier, with some small changes:
- _Layer_ selects only strokes in the respective layer (with an _Invert_
option)
- _Material_ selects only points with the respective material (with an
_Invert_ option)
- _Layer Pass_ and _Material Pass_ select only strokes/points which are
rendered in the respective pass.
_Note 1: Layers don't have UI for setting a pass yet, this will be a
generic layer attribute. This can be set through the API for testing._
_Note 2: In GP2 a pass value of zero was used to disable pass filters.
Since zero is a valid pass ID an explicit flag has been added for the
purpose of turning pass filters on and off._
- _Vertex Group_: This can be used as an additional influence filter on
points. If _Weight as Factor_ is enable the vertex group instead
replaces the opacity factor. In _Fill_ mode the vertex group weight of
the stroke's first point is used as influence for the entire stroke.
- _Custom Curve_ is another possible influence factor per point. The
curve input value is the relative position of a point along its
stroke.
The Influence settings have been moved into a separate DNA struct, which
should help with reusability in various modifiers. Various utility
functions can be found int `MOD_grease_pencil_util.hh` for handling
influence settings and generating `IndexMasks` for modernized C++ code.
Pull Request: https://projects.blender.org/blender/blender/pulls/116946
Part of overall "improve filtering situation" (#116980) task:
* Add Bicubic filtering option to strip Transform "Filter" setting.
Previously this option only existed in Transform Effect "Interpolation"
setting.
- With this addition, it feels like the transform effect could
possibly be marked as legacy/deprecated, since the regular Transform
that is on all strips can do everything that Transform Effect did?
* Speed up bicubic filtering (used now in VSE, but also in CPU Compositor,
image paint, etc.) by slightly simplifying the code and using some SIMD.
Upscaling 96x54 image to 3840x2160 resolution, using Bicubic filtering:
- Windows (VS2022, Ryzen 5950X): 35.5ms -> 15.1ms
- Mac (clang 15, M1 Max): 29.6ms -> 24.4ms
* Add gtest coverage for bicubic functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/117100
Translation of the UI is currently split into 3 preferences:
interface, tooltips, and new data. The distinction between interface
and tooltips is currently unclear as tooltips also include a lot of
messages not displayed in the actual tooltips on mouse hover.
These include reports to the Info Editor, information in editor
headers and footers, and statuses in panels.
In order to limit the use of `TIP_()` to actual tooltips, this commit
introduces a new preference for this extra information: "Reports".
New translation macros are introduced: `RPT_()` and `CTX_RPT_()`, as
well as their equivalent for the Python API, `pgettext_rpt_()`, to be
imported as `rpt_()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
The struct `SpaceText_Runtime` already separates runtime data from
`SpaceText`, however it is still allocated inside `SpaceText`, read and
write file operations still copy this data, but is override on read.
This changes separate allocation of `SpaceText_Runtime` from
`SpaceText`.
Ref !115418
This adds a Python API for layout panels that have been introduced in #113584.
Two new methods on `UILayout` are added:
* `.panel(idname, text="...", default_closed=False) -> Optional[UILayout]`
* `.panel_prop(owner, prop_name, text="...") -> Optional[UILayout]`
Both create a panel and return `None` if the panel is collapsed. The difference lies
in how the open-close-state is stored. The first method internally manages the
open-close-state based on the provided identifier. The second one allows for
providing a boolean property that stores whether the panel is open. This is useful
when creating a dynamic of panels and when it is difficult to create a unique idname.
For the `.panel(...)` method, a new internal map on `Panel` is created which keeps
track of all the panel states based on the idname. Currently, there is no mechanism
for freeing any elements once they have been added to the map. This is unlikely to
cause a problem anytime soon, but we might need some kind of garbage collection
in the future.
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Before")
if panel := layout.panel("my_panel_id", text="Hello World", default_closed=False):
panel.label(text="Success")
if panel := layout.panel_prop(scene, "show_demo_panel", text="My Panel"):
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="After")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/116949
This cleanup changes the `layer` parameter in `get_drawing_at` and `get_editable_drawing_at` to a reference.
This makes it clear that the layer is required for this function.
Update the documentation of `CONSTRAINT_DISABLE` and `CONSTRAINT_OFF`
flags to clearly distinguish them from each other.
- `CONSTRAINT_OFF`: The eye icon in the interface. Managed by the user,
maybe indirectly via the animation system or drivers. Maps to both the
`mute` (positive) and `enabled` (negative) properties in RNA.
- `CONSTRAINT_DISABLE`: The red color in the interface that indicates
invalid settings. Set by Blender when a constraint is considered to be
invalid, for example a 'Copy Location' constraint without a target.
Maps to `is_valid` (negative) in RNA.
No functional changes.
Even though the brush rotation is computed as a 2D angle (based on the mouse
movement), it currently gets applied by rotating the projected X direction
around the the normal in 3D.
This patch ensures that rotation gets applied first, and only then does the
motion direction get projected into the tangent plane. A potential issue with
the current approach is that the random perturbations will also be applied in
2D, but this seems to be fine from discussions with @JulienKaspar and @Sergey.
Also, there was an error where the location should probably be converted *to*
world coordinates.
All these changes seem to fix the issue described in #116418.
I also noticed some minor "inconsistencies" with how the rotation is applied:
For curve strokes, the direction of the curve corresponded to the upward
direction of the brush. For view plane, area plane mapping and anchored strokes,
the mouse motion indicated the downward direction of the brush.
For compatibility, I tried my best to enforce the latter conventions throughout,
but I'm not so confident about oversights.
Pull Request: https://projects.blender.org/blender/blender/pulls/116539
As discussed in #105407, it can be useful to support returning
a fallback value specified by the user instead of failing the driver
if a driver variable cannot resolve its RNA path. This especially
applies to context variables referencing custom properties, since
when the object with the driver is linked into another scene, the
custom property can easily not exist there.
This patch adds an optional fallback value setting to properties
based on RNA path (including ordinary Single Property variables
due to shared code and similarity). When enabled, RNA path lookup
failures (including invalid array index) cause the fallback value
to be used instead of marking the driver invalid.
A flag is added to track when this happens for UI use. It is
also exposed to python for lint type scripts.
When the fallback value is used, the input field containing
the property RNA path that failed to resolve is highlighted in red
(identically to the case without a fallback), and the driver
can be included in the With Errors filter of the Drivers editor.
However, the channel name is not underlined in red, because
the driver as a whole evaluates successfully.
Pull Request: https://projects.blender.org/blender/blender/pulls/110135
The same is done for other geometry types. This allows us to use C++ types in
the run-time data more easily and avoids dumping runtime data into .blend files.
Pull Request: https://projects.blender.org/blender/blender/pulls/116840
- Improve the look of them, so they feel less like from year
1998 (more details and images in the PR).
- Some of the scopes got slightly faster in the process, others
stayed the same performance (details below).
- Remove VSE Scopes related data from SpaceSeq DNA, move it into
runtime instead.
The ability to adjust the "Backwire Opacity" was mistakenly removed in
version 2.93 (b365cc017a).
As this issue went unnoticed by most users, it appears reasonable to
completely remove this setting from the code.
By making this change, there is no longer a need to define a default
value for `View3DOverlay::backwire_opacity`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116799
- Move code to C++ namespace for blenkernel
- Remove unnecessary prefixes based on namespace change
- Remove use of `RawVector` for function-scoped static variable
- Use `StringRef` instead of char pointer
- Use safer `STRNCPY` instead of `strcpy` in tests
- Give span instead of vector to users of API
Pull Request: https://projects.blender.org/blender/blender/pulls/116808
Bone collection visibility now respects their hierarchy.
A bone collection is only visible when it is marked as visible and all
its ancestors (so parents, greatparents, etc.) are visible. Root bone
collections have no ancestors by definition, and only consider their own
visibility.
The effective ancestors' visibility is stored on each bone collection,
in its `BONE_COLLECTION_ANCESTORS_VISIBLE` flag. This makes it possible
to determine the effective visibility from just the flags of the bone
collection itself.
The `BONE_COLLECTION_ANCESTORS_VISIBLE` flag is now stored, with the
other flags, in `BoneCollection::flags`. This means that it's stored in
DNA, even though it's derived data and should actually be stored in a
runtime struct. However, `BoneCollection` doesn't have any runtime
struct yet, and I don't feel that the introduction of this flag is a
good enough reason to introduce that just yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/116784
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Make it possible to nest bone collections. The data structure on the
armature is still a flat array. It is organised as follows:
- Sibling collections (i.e. ones with the same parent) are stored
sequentially in the array.
- Each bone collection keep track of the number of children, and the
index of the first child.
- Root collections (i.e. ones without parent) are stored as the first
elements in the array.
- The number of root collections is stored on the Armature.
This commit also contains the following:
- Replaced the flat UIList of bone collections with a tree view.
- Updated the M/Shift+M operators (move/assign to collection) to work
with hierarchical bone collections.
- Updated RNA interface to expose only root collections at
`armature.collections`. All collections are available on
`armature.collections.all`, and children at `bonecollection.children`.
- Library override support. Only new roots + their subtrees can be added
via overrides.
See https://projects.blender.org/blender/blender/issues/115934
Co-authored with @nathanvegdahl and @nrupsis.
Pull Request: https://projects.blender.org/blender/blender/pulls/115945
There are some tragic design flaws with the Microsoft STL
implementation of `std::dequeue`. Unless we implement our
own similar data structure or use an implementation from
another library, the change isn't worth it.
This reverts commit b26cd6a4b9.
This reverts commit cc11ba33d9.
This reverts commit c929d75054.
This reverts commit bd3d5a750d.
Some common headers were including this. Separating the includes
will ideally lead to better conceptual separation between CustomData
and the attribute API too. Mostly the change is adding the file to
places where it was included indirectly before. But some code is
shuffled around to hopefully better places as well.
GSQueue dates back over 21 years, past the initial git commit. Nowadays
we generally prefer to use data structures from the C++ standard library
or our own C++ data structures. Previous commits replaced this container
with `std::queue` in a few areas. Now it is unused and can be removed.
This builds on top of f824476bd5 to show
panels in the geometry nodes modifier. It also changes the two existing panels
to use the new layout panels.
The open-close state of the panels is stored in the modifier itself. It contains a
mapping from panel id to the corresponding state flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/116472
Add a new normal mode called "Custom" which directly interpolates
a "custom_normal" attribute to the evaluated points for the final
normal. Extend the "Set Curve Normal" node with this mode and
give it the ability to set the custom normal value.
This is intentionally a very basic implementation of custom normals.
In particular, the storage is not rotation invariant. So the normals
are expected to be set procedurally at the end of the modifier stack.
On the other hand, it is very easy to understand and explain.
Pull Request: https://projects.blender.org/blender/blender/pulls/116066
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
This was added at the start of the project, as a way for the source
library to control what would be overridable by the user of the data
(production files).
The implementation never went beyond the experimental area, and only
exposed in the python API then. The idea has been superseeded by the
'cherry-pick' design, so there is no point in keeping this code any
longer.
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
Previously, attribute values were only visualized as color overlay in the 3d viewport.
Now it's possible to optionally show the attribute values as text. This can be enabled
in the `Viewer Node` overlay settings in the 3d view.
This is just the first initial version. More work towards making it look better
will be done next.
Pull Request: https://projects.blender.org/blender/blender/pulls/115664
This adds a new `Bake` node which allows saving and loading intermediate geometries.
Typical use cases we want address with this currently are:
* Bake some data for use with a render engine.
* Bake parts of the node tree explicitly for better performance.
For now, the format that is written to disk is not considered to be an import/export format.
It's not guaranteed that data written with one Blender version can be read by another
Blender version. For that it's better to use proper interchange formats. Better support for
those will be added eventually as well. We also plan an `Import Bake` node that allows
reading the blender-specific baked data independent of the Bake node and at different frames.
The baking works very similar to the baking in the simulation zone (UI and implementation
wise). Major differences are:
* The Bake node has a `Bake Still` and `Bake Animation` mode.
* The Bake node doesn't do automatic caching.
Implementation details:
* Refactored how we create the Python operators for moving socket items so that it also
makes sense for non-zones.
* The `ModifierCache` stores an independent map of `SimulationNodeCache` and
`BakeNodeCache`, but both share a common data structure for the actually baked data.
* For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make
sure that the node is baked even if it's currently not connected to the output.
* Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used
during baking. It's necessary because I want to evaluate the object again even though none
of its inputs changed. The reevaluation is necessary to create the baked data. Using
`DEG_id_tag_update` technically works as well, but has the problem that it also uses the
`DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches
which shouldn't happen here.
* Slightly refactored the timeline drawing so that it can also show the baked ranges of
Bake nodes. It does not show anything for baked nodes with a in Still mode though.
* The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the
code easier to follow compared to the previous nested
`ObjectBakeData > ModifierBakeData > NodeBakeData` data structure.
* The bake operators are disabled when the .blend file is not yet saved. This is technically
only necessary when the bake path depends on the .blend file path but seems ok to force
the user anyway (otherwise the bake path may be lost as well if it's set explicitly).
* The same operators are used to bake and delete single bakes in `Bake` nodes and
`Simulation Zones`. On top of that, there are separate operators of baking and deleting all
simulation bakes (those ignore bake nodes).
* The `Bake` node remembers which inputs have been fields and thus may be baked as attributes.
For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data
may still contain attribute data, even if the inputs to the bake node are disconnected.
* Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes
evaluation from the outside (from the modifier only currently). This is done by providing the
new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes.
Next Steps (mostly because they also involve simulations):
* Visualize nodes that have not been evaluated in the last evaluation.
* Fix issue with seemingly loosing baked data after undo.
* Improve error handling when baked data is not found.
* Show bake node in link drag search.
* Higher level tools for managing bakes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115466
Split the code, use preconditions, use rather plain language for
function names and add comments where it is not totally obvious, what
the code is supposed to do.
Before #108014, toggling "Auto Smooth" was an easy way to disable
evaluation of custom normals and face corner normals for faster
viewport playback performance. Now that corner normals are calculated
automatically as necessary, it's helpful to still have a way to disable
expensive normal computation for faster playback.
This commit adds a "Normals" scene simplify setting. To avoid a bunch
of complexity, it just influences which normals are requested from the
object by viewport rendering. In my tests, skipping calculating at
least doubled viewport FPS in a few test files with a large mesh with
custom normals. This works well because normals are cached and lazily
calculated.
Pull Request: https://projects.blender.org/blender/blender/pulls/113975
The main problem is, that retiming key frame index is defined in strip
content space (0 <> seq->len -1), but API functions must rescale this
index by applying `SEQ_time_media_playback_rate_factor_get()` and return
value in timeline space.
This wasn't done properly, in many places, some had challenges:
- `SEQ_retiming_key_timeline_frame_get()` returned floats, but UI
expects integers. Otherwise keys may be drawn inbetween frames.
- Function `right_fake_key_frame_get()` must return exact frame of
keys, otherwise lookup by frame would fail. But `retime_key_draw()`
can not compensate position of last fake key, so this has to be done
in `fake_keys_draw()` and `try_to_realize_virtual_key()`.
- For transformation to work as expected, double precision value has
to be used for frame index.
- For UI either API would had to be extended to provide helper functions
to deal with FPS mismatch, or it needs to know the FPS difference.
I have opted to put `SEQ_time_media_playback_rate_factor_get()` in
"public" headers. Neither solution is great.
Add support for enum values in ID properties.
This is needed for the "Menu Switch" node implementation (#113445) which
relies on ID properties for the top-level modifier UI.
Enums items can optionally be added to the UI data of integer
properties. Each property stores a full set of the enum items to keep
things simple.
Enum items can be added to properties using the `id_properties_ui`
function in the python API. A detailed example can be found in the
`bl_pyapi_idprop.py` test.
There is currently no support yet for editing enum items through the UI.
This is because the "Edit Property" feature is implemented entirely
through a single operator (`WM_OT_properties_edit`) and its properties.
Buttons to add/remove/move items would be operators changing another
operator's properties. A refactor of the custom properties UI is likely
required to make this work.
Pull Request: https://projects.blender.org/blender/blender/pulls/114362
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.
Recently this was inlined [0] however the purpose of this define is to
allow for the method of setting the value to be changed.
It also means the hack doesn't have to be explained whenever it's used.
Move the BEZKEYTYPE to DNA, update it's doc-string and restore the
original comment.
[0]: fd3629b80a
The Realtime compositor currently relies on the GPU cache in image IDs.
That cache only supports single layer images, so multi-layer images will
be acquired without a cache, introducing significant IO bottlenecks for
the GPU compositor.
This patch ignores the image GPU cache and stores the images in the
static cache manager of the compositor. Draw data was introduced to the
image ID for proper cache invalidation, like other IDs such as masks.
The downside is that the cache will no longer be shared between EEVEE
and the compositor. But realistically, images are not typically shared
between materials and compositors.
This is just a temporary solution until we have proper GPU storage
support for image buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/115511
Update code examples to current C++ style. Change formatting
slightly to use more columns. Rewrite secions to be more explicit
and precise. Avoid cryptic / uncommon code in examples. Finding
real edges in particular is never inlined, we just use the function
for it.
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
For context, see 6d09fa3577. Overall, these values were still
written in some cases, but never used. Nowadays the viewer node and
attribute overlays give even better answers to these needs.
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
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
- CTX_wm_region(C) must be NULL checked as it's not checked in the
poll function.
- Add back the removed flag, note it's dirty.
- Replace ternary operators with min/max.
The new grid socket (#115270) will make these nodes obsolete and
provide more elegant ways of implementing the features. Removing
these nodes now to clean up and make future changes simpler.
Pull Request: https://projects.blender.org/blender/blender/pulls/115567
The `paint_init_pivot` calculates the `location` based
on the midpoint of the bounds of the object. For grease pencil
the bounds depend on the current frame (for original data).
This fixes the issue by making the `bounds_min_max` function
dependent on the `frame` and by introducing a `bounds_min_max_eval`
for evaluated 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
While it may have been working from a practical PoV (not certain though,
since some bug would prevent clearing runtime data when writing embedded
Scene collection in current code), this is semantically wrong.
The owner of an embedded ID is a critical piece of information in
Blender data structure and ID management code. Having it written in
.blend files is also a potential good source of data for investigating
issues.
Further more, this handling of `owner` ID data is somewhat generic now
in ID management, so if this data should be considered runtime, then the
change should also be made in NodeTree and Key IDs.
This commit partially reverts 44dd3308a5, in the future I'd like to
be involved in the review of changes affecting ID management.
NOTE: fix for embedded collection runtime data not being cleared on
write will be committed separately.
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
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
This uses the principles outlined in
Screen Space Indirect Lighting with Visibility Bitmask
to compute local and distant diffuse lighting.
This implements it inside the ray-tracing module as a fallback when the
surface is too rough. The threshold for blending between technique is
available to the user.
The implementation first setup a radiance buffer and a view normal
buffer. These buffer are tracing resolution as the lighting quality is
less important for rough surfaces. These buffers are necessary to avoid
re-projection on a per sample basis, and finding and rotating the
surface normal.
The processing phase scans the whole screen in 2 directions and outputs
local incomming lighting from neighbor pixels and the remaining
occlusion for everything that is outside the view.
The final steps filters the result of the previous phase while applying
the occlusion on the probe radiance to have an energy conserving mix.
Related #112979
Pull Request: https://projects.blender.org/blender/blender/pulls/114259
When animators want to key something in the viewport,
the code needs to know *which properties* should be keyed of that selected thing.
So far that was done with keying sets, and a pop-up that let's
you choose the keying set to use. You can get rid of the popup by
choosing a keying set ahead of time. But that is also not always desirable.
That pop-up is quite confusing and gives way too many options.
To simplify this process this PR adds a User Preference option to choose one or more of:
* Location
* Rotation
* Scale
* Rotation Mode
* Custom Properties
Now whenever the `I` key is pressed in the viewport,
and no keying set is enabled, it reads the preferences for which channels to insert.
# User Facing changes
* The popup will not be shown when pressing the hotkey,
but you can still explicitly use keying sets by going to the menu
* Which channels are keyed is defined by a User Preference setting under animation
* when a keying set is used explicitly, the User Preference settings are ignored
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/113504
Store paint masks as generic float attributes, with the name
`".sculpt_mask"`. This is similar to 060a534141, which made
the same change for face sets. The benefits are general
consistency, nicer code, and more support in newer areas
that deal with attributes like geometry nodes.
The RNA API is replaced with one created in Python. The new
API only presents a single layer as an attribute class, so it
should be simpler to use in general:
- Before: `object.data.vertex_paint_masks[0].data[0].value`
- After: `object.data.vertex_paint_mask.data[0].value`
Pull Request: https://projects.blender.org/blender/blender/pulls/115119
Avoid the need to call the separate `BKE_mesh_wrapper_minmax` function
that dealt with the edit mesh wrapper. This makes the API inconsistent,
since other mesh functions don't implicitly deal with the wrapper.
But the bounds are a bit of a special case anyway in regard
to the GPU subdivision wrapper already, and this is much more
convenient in the rest of the refactors for #96968.
This path merges the Musgrave and Noise Texture nodes into a single
combined Noise Texture node. The reasoning is that both nodes
intrinsically do the same thing, which is the layering of Perlin noise
derivatives to produce fractal noise. So the patch de-duplicates code
and unifies the use of fractal noise for the end use.
Since the Noise node had a Distortion input and a Color output, while
the Musgrave node did not, those are now available to the Musgrave types
as new functionalities.
The Dimension input of the Musgrave node is analogous to the Roughness
input of the Noise node, so both inputs were unified to follow the same
behavior of the Roughness input, which is arguable more intuitive to
control. Similarly, the Detail input was slightly different across both
nodes, since the Noise node evaluated one extra layer of noise. This was
also unified to follow the behavior of the Noise node.
The patch, coincidentally fixes an unreported bug causing repeated
output for certain noise types and another floating precision bug
#112180.
The versioning code implemented with this patch ensures backward
compatibility for both the Musgrave and Noise Texture nodes. When
opening older Blender files in Blender 4.1 the output of both nodes are
guaranteed to always be exactly identical to that of Blender files
created before the nodes were merged in all cases.
Forward compatibility with Blender 4.0 is implemented by #114236.
Forward compatibility with Blender 3.6 LTS is implemented by #115015.
Pull Request: #111187
Move object runtime data to a separate header and allocate it separately
as `blender::bke::ObjectRuntime`. This is how node, mesh, curves, and
point cloud runtime data is stored.
Benefits:
- Allow using C++ types in object runtime data
- Reduce space required for Object struct in files
- Increase conceptual separation between DNA and runtime data
- Remove the need to add manual padding in runtime data
- Include runtime struct definition only in files that require it
Pull Request: https://projects.blender.org/blender/blender/pulls/113957
Extend node tools to display tool assets in object mode as well
as edit and sculpt modes. For consistency with existing Blender
design, selection cannot be set and is just "true" in object mode
because it can't be visualized. The visibility of tools can be
customized per object type in object mode as well.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/114819
For improving performance in the triangulate node (#112264), it's
helpful to know whether the mesh has edges or faces that overlap
each other. If that is known to be false, the node can skip edge de-
duplication.This might apply to the future "Replace Faces" node too.
This information is stored as a flag on the mesh and set in various
places that create "clean" new meshes. It isn't calculated lazily unlike
other other areas, because the point is to improve performance, and
the calculation probably isn't faster than the duplication check it's
meant to replace.
Pull Request: https://projects.blender.org/blender/blender/pulls/113205
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
Remove `Material > Shadow Mode` and use `Object > Shadow Ray Visibility`
and `Material > Transparent Shadows` instead.
The versioning system auto-updates objects/materials in EEVEE
scenes so their behavior is as close as possible to the previous one.
Update Cycles to use the native `use_transparent_shadow` property.
Note:
Material changes don't set any `recalc` flag on the objects that use
them, so the EEVEE Next shadow maps don't update when changing
settings/nodes.
Fixing this issue is required for 4.1, but it's out of the scope of this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/113980
Also remove const for non-pointer arguments which is meaningless in
the declaration, move a scene enum to the "enums.hh" header, and add
missing forward declaration of structs.
This adds a new way of computing occlusion using visibility bitmask. To
make it more algorithm agnostic, we name it horizon scan.
This cleans-up / simplify the code compared to the Horizon based solution.
There is no more trickery for fading influence of distant samples which
makes the result match cycles closer.
This introduces a new thickness option. Maintaining it relatively low
makes it possible to avoid over occlusion because of in front geometry.
Making it too low will cause under occlusion.
Related #112979
Pull Request: https://projects.blender.org/blender/blender/pulls/114150
Adds a new scene tool setting `use_grease_pencil_multi_frame_editing`.
The `foreach_*_drawing` functions are moved to the `ed::greasepencil` namespace in the editor, since they are now context sensitive and depend on the toolsetting. They are now named `retrieve_editable_drawings` and `retrieve_visible_drawings` and return
an array of drawings instead of calling a callback function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114283
* Add viewport display support for Sphere and Plane probes.
* Make all probe display options per object instead of per scene.
(Uses the already existing `LIGHTPROBE_FLAG_SHOW_DATA`
and adds a new `data_display_size ` property to the `LightProbe` DNA)
* Python `show_data` property has been deprecated and renamed to
`use_data_display` (`data_display_size ` has been exposed as well).
Pull Request: https://projects.blender.org/blender/blender/pulls/114176
Changes to edit mode mesh overlays, use hue shift instead of color
fading/darkening for selection mode visual differentiation, and some
theme changes to improve the display of mesh edges and faces with good
selection visibility.
- Removed "edge" toggle from edit mode overlays panel.
- No longer halves the edge and face alpha depending on selection mode.
Half the face alpha in wire-frame mode. For better visibility on most
themes.
Ref !111431
If "Region Overlap" was disabled, the region coordinate calculations
would end up placing the header on the bottom, taking space away from
the main asset shelf region. This is because the header was abusing the
`RGN_SPLIT_PREV` flag a bit, because it gave the desired behavior of
hiding the regions together. This worked well because the regions
wouldn't actually do the splitting when one used region overlap and the
other not. But disabling region overlap would bring the splitting
usually enabled with the `RGN_SPLIT_PREV` flag.
This PR removes the `RGN_SPLIT_PREV` flag from the asset shelf header.
Instead a new flag is introduced to only enable the behavior of
`RGN_SPLIT_PREV` of hiding a region together with the previous one. So
the header stays at the top of the region, and labels stay visible.
The new flag is added to the `ARegion.alignment` flags, even though it's
more related to behavior than alignment. However this is more
convenient, and keeps it together with related flags.
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
Known limitations to be addressed separately:
* We are not warning/keeping track of the named layers.
* There is no lookup for layers (groups) yet.
Ref !113908.
This field supports either a Layer, or a Layer Group name as input,
and outputs a selection.
The nodes that use this should add the name to the list of Named
Dependencies of the node-tree.
Ref !113908.
After eda58d6419, multiply operation does not affect alpha channel, but
Some users do expect this feature present.
This adds option `multiply_alpha`, so that multiplication (in strip
color panel) will affect alpha channel as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/113791
Instead of calculating the expected insertion index for a customdata entry being moved, this implementation just records the initial layer indices so that it can compare them with the final indices to determine how the customdata entries need to be re-arranged.
Also simplifies the `add_layer` function and adds an implementation that just takes a `name` and adds a new layer with that name to the root group.
Pull Request: https://projects.blender.org/blender/blender/pulls/113962
It shouldn't be possible to retrieve a mutable interface item from
a const node tree. Unfortunately that means we have to duplicate
the accessor methods. Fortunately they are very small.
Instead of having two APIs (`find_layer_by_name` +
`find_layer_group_by_name`) replace them with a single API
`find_node_by_name`.
This returns a `TreeNode` but the caller can easily check if it's a
layer or a group.
- Adds the missing new RNA definitions
- Split settings panel into surface and volume
- Expose displacement and volume nodetree panels
- Rename `Cull Backfaces` to `Backface Culling`
for consistency
- Rename `use_backface_culling_probe` to
`lightprobe_volume_single_sided` for accuracy
and avoiding confusion as it is not a real
backface culling.
- Rename `Screen Space Refraction` to
`Raytrace Refraction` for accuracy.
Motivation is to make it closer to cycles now
that EEVEE is compatible with more features.
Pull Request: https://projects.blender.org/blender/blender/pulls/113971
Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
- Add mandatory forward opaque prepass for any opaque region
- Rename the "Show Backface" pass as `MAT_PIPE_PREPASS_OVERLAP`
- Replace Blend mode by Surface Render Method
- Add do versioning for `surface_render_method`
- Rename the Prepass pipe enum for consistency as they share
the same depth shader
- Makes sure all object types subscribe to all passes
This does not change the UI yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/113968
This adds correct object bounds estimation.
This works by creating an occupancy texture where one
bit represents one froxel. A geometry pre-pass fill this
occupancy texture and doesn't do any shading. Each bit
set to 0 will not be considered occupied by the object
volume and will discard the material compute shader for
this froxel.
There is 2 method of computing the occupancy map:
- Atomic XOR: For each fragment we compute the amount of
froxels **center** in-front of it. We then convert that
into occupancy bitmask that we apply to the occupancy
texture using `imageAtomicXor`. This is straight forward
and works well for any manifold geometry.
- Hit List: For each fragment we write the fragment depth
in a list (contained in one array texture). This list
is then processed by a fullscreen pass (see
`eevee_occupancy_convert_frag.glsl`) that sorts and
converts all the hits to the occupancy bits. This
emulate Cycles behavior by considering only back-face
hits as exit events and front-face hits as entry events.
The result stores it to the occupancy texture using
bit-wise `OR` operation to compose it with other non-hit
list objects. This also decouple the hit-list evaluation
complexity from the material evaluation shader.
## Limitations
### Fast
- Non-manifolds geometry objects are rendered incorrectly.
- Non-manifolds geometry objects will affect other objects
in front of them.
### Accurate
- Limited to 16 hits per layer for now.
- Non-manifolds geometry objects will affect other objects
in front of them.
Pull Request: https://projects.blender.org/blender/blender/pulls/113731
See #105317
In 46cf093270, face maps were just converted to an integer
attribute. While the internal data remains the same that way, we lose
the names and some convenient methods of interaction. This commit
additionally converts each face map to a separate boolean attribute
using the old name. This does require that no attributes were using that
name already.
Each boolean attribute can be thought of as a selection, accessible in
geometry nodes and properly interpolated by mesh processing
algorithms. The selections no longer have to be unique, meaning
one face can be part of multiple selections.
Pull Request: https://projects.blender.org/blender/blender/pulls/113769
This commit makes using (most of) `BKE_report` API safe in
multi-threaded situation.
This is achieved by adding a `std::mutex` lock to the `ReportList`
struct (in a slightly convoluted way unfortunately, due to this being a
DNA struct). This lock is then used to make most operations on
`Reportlist` data thread-safe.
Note that while working on this, a few other minor issues aroze in
existing usages of Reportlist by the WM code, mainly the fact that
`wm_init_reports` and `wm_free_reports` were both useless:
- init was called in a context where there is not yet any WM, so it
was doing nothing.
- free was called on a WM that would be later freed (as part of Main
freeing), which would also call cleanup code for its `reports` data.
Both have been removed.
Further more, `wm_add_default` (which is the only place where a WM ID is
created) did not initialize properly it reports data, this has been
fixed.
This change is related to the wmJob thread-safety tasks and PRs (#112537,
!113548).
Pull Request: https://projects.blender.org/blender/blender/pulls/113561
In !112591, nodes got the ability to group sockets into panels. The
labels for these sockets are automatically shortened if they begin
with the same text as their parent labels. For instance, "Transmission
Weight" will be shortened to just "Weight" because it is under the
"Transmission" panel.
While this is a good heuristic for English, it breaks down in
languages which do not have the same word order.
This commit adds a `.short_label()` callback to socket declarations so
that a shortened label can be explicitly declared.
It also adds two regexps to the translation script so that these new
fields can be extracted to the .po translation files. One extracts the
label with a translation context, the other without. Only the one
without context is currently in use.
The current automatic shortening logic is kept and will be used only
if a shortened label is not manually provided.
Fixes#112970: Node socket labels under panels are not shortened when
translated.
Pull Request: https://projects.blender.org/blender/blender/pulls/113070
This patch adds the ability for users to expand the grease pencil component in the spreadsheet and see the values for each `CurvesGeometry` in each layer.
It also makes it so that all the geometry components can be expanded for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/113507
This adds `GreasePencilEditHints` and correctly implements
`crazyspace::get_evaluated_grease_pencil_drawing_deformation`
to support querying the deformation of points after evaluation.
This is needed for users to properly select points in edit mode while
seeing the effects of the modifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/113586
In order to recreate the behavior of some builtin nodes
which have implicit inputs for ID/Index or positions, provide
a hard-coded list of default/unconnected fields for sockets.
The point is to let assets recreate the behavior of builtin
nodes in a simple way that's easy to change in the future if
this becomes a more generalized feature. A hardcoded list
makes this predictable and simple in the meantime.
When the option is set to something besides "Default Value"
it overrides the "Hide Value" option. Otherwise the default
input would conflict with the visible default value button.
This makes it possible to add #109846 as an asset in the
essentials bundle. The design is meant to be easily
extendable for shader nodes, though that isn't included
in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113175
We had a short discussion on this change. "Grease Pencil Layer" is
just a bit too long, especially in the UI. Even though "Layer" might be
ambiguous, it shouldn't be in the context of geometry nodes. There are
currently no other "Layers" and if there were, using the same domain
name could be fine (just like we reuse the point domain for e.g. vertices
in meshes and control points in curves).
This also renames the internal enum to `ATTR_DOMAIN_LAYER`
Pull Request: https://projects.blender.org/blender/blender/pulls/113589
Update to the new naming convention for `Light Probes`:
`Reflection Cubemap` -> `Sphere`
`Reflection Plane` -> `Plane`
`Irradiance Grid` -> `Volume`
Note that this breaks the Python API (`bpy.types.LightProbe.type`).
Pull Request: https://projects.blender.org/blender/blender/pulls/113452
This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
This PR reuses the scene specific reflection probe resolution for all
reflection light probes in the scene. The target is to have a automatic
detection for the resolution. But as long as we don't have a mechanism
for detection it is better to not introduce a new UI element that will
be removed within the foreseen future.
This setting is currently used by EEVEE and EEVEE-Next. EEVEE supports
resolutions upto 4096px. This will be clamped to 2048 when using
EEVEE-Next.
The motivation for this is that EEVEE-Next will soon replace
EEVEE and 4096 can then be removed from the choices that the user can
made. Adding as separate option could need synchronization, and that
option would also be temporary as it will be removed by the resolution
detection mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113491
Currently nodes are reordered so that the "on top" nodes are last in
the list. Node order changing for simple operations like selection
means we either have to reevaluate the node tree data-block on
selections or accept that the evaluated order can be different from the
original. Currently we do the latter (see d76a0e98ba), but
makes it complex to access nodes by index, and is hard to reason about.
Instead of reordering nodes, store the ui order in the node itself
and sort the nodes before drawing them or doing any processing
that depends on the "depth."
The "selected_nodes" list in the context is no longer ordered by the
recent selection.
Pull Request: https://projects.blender.org/blender/blender/pulls/113419
This PR is contains the initial capture pipeline for planar probes.
It requires work to generate the correct view to capture and to include
the result during ray tracing. These will be developed in a separate PR.
This PR detects if a planar probe is active in the scene. If this is
the case the planar probe pipeline will be activated. During rendering
this is done by querying the depsgraph, during viewport drawing this
is done during sync. If an planar probe is detected and the pipeline
wasn't activated. The pipeline will be activated and the sampling
will be reset to ensure the pipeline is filled with all objects.
Per object the user can set the visibility of the object in planar
reflections.
For a reflection plane the resolution and clipping offset can be set.
EDIT: Resolution option was removed because too complex to
implement with the little time we have at the moment.
Related to #112966
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/113203
IME editing would cast GHOST_TEventImeData to wmIMEData then read/write
an additional member that doesn't exist in GHOST_TEventImeData.
In practice it's likely struct padding prevented this from showing up
as a bug. Nevertheless it's bad practice to rely on this.
- Make GHOST_TEventImeData read-only, move the is_ime_composing boolean
into the window.
- Add static assert to ensure both structs are the same size.
- Correct code comments.
This PR implements an initial drawing tool that can already be used for testing.
While this is not fully feature complete (compared to the current grease pencil draw tool) the following is already implemented:
* Pressure support for radius and opacity.
* Material color and vertex color support.
* New active smoothing algorithm based on curve fitting.
* Simplify algorithm as a post-process step.
Some deliberate limitations include:
* The drawing plane is always the front plane. Drawing on surfaces is also not supported.
*
The current approach has not been optimized for performance yet. The goal was to have a straightforward implementation
first and then focus on performance later.
There are numerous parameters in the code that are hard-coded for now. These should be exposed at some point, potentially as user settings.
Pull Request: https://projects.blender.org/blender/blender/pulls/110093
Enable tests for EEVEE Next.
As a workaround for allowing the use of EEVEE Next (still an
experimental feature) with `--factory-startup`, `arg_handle_engine_set`
enables the feature when `-E BLENDER_EEVEE_NEXT` is used.
In addition, EEVEE Next is always registered, so it's available when
calling `WM_init`.
If it's actually disabled, it will be immediately unregistered after that.
Notes:
- `get_gpu_device_type` always fails with error:
> GPU API is not available in background mode
- Setup and tests are the same as EEVEE. There are many tests that
only make sense for Cycles, and many EEVEE Next features that are
not actually tested.
Pull Request: https://projects.blender.org/blender/blender/pulls/112161
The goal of this refactor is to reduce the amount of boilerplate code that is
necessary to have a dynamic number of sockets on nodes. This is achieved
by making the code more reusable. Currently, only the simulation and repeat
zone nodes make use of this. However, even with just those two, the amount
of code is reduced already. The benefit of this refactor will become even more
significant as more nodes support a dynamic number of sockets. For example,
the bake node and for-each zone will also benefit from this.
We could probably make some of the utility functions non-templates using type
erasure. This could reduce the compilation overhead when the number of nodes
with item arrays increases. The main reason for why everything is templated
now is that it made this refactor easier. Without this patch, all the code was
essentially "manually templated". So the implementations look still similar to
before now, just that concrete types are replaced with template parameters.
No user-visible changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/113114
This patch implements the Keying Screen node for the Realtime
Compositor. Draw data was introduced to the Movie Clip ID to allow
caching of the keying screen.
Pull Request: https://projects.blender.org/blender/blender/pulls/113055
This patch changes the interpolation algorithm utilized by the Keying
Screen node to a Gaussian Radial Basis Function Interpolation. This is
proposed because the current Voronoi triangulation based interpolation
has the following properties:
- Not temporally stable since the triangulation can abruptly change as
tracking markers change position.
- Not smooth in the mathematical sense, which is also readily visible in
the artists sense.
- Computationally expensive due to the triangulation and naive
rasterization algorithm.
On the other hand, the RBF interpolation method is temporally stable and
continuous, smooth and infinitely differentiable, and relatively simple
to compute assuming low number of markers, which is typically the case
for keying screen objects.
This breaks backward compatibility, but the keying screen is only used
as a secondary input for keying in typical compositor setups, so one
should expect minimal difference in outputs.
Pull Request: https://projects.blender.org/blender/blender/pulls/112480
Separate user configuration of subpixel antialiasing from the hinting
options. For example, this allows turning this on while hinting is
"None", or off when hinting is "Full".
Pull Request: https://projects.blender.org/blender/blender/pulls/113027
For text objects, the CharInfo mat_nr material index used to start at 1
(not at zero like for meshes or nurbs).
Code was mostly considering this (but not in all places, so material
index handling (removing/moving) could still go wrong.
As an alternative to !109746 (where it was made sure all places would
make the right assumption about mat_nr starting at 1), this PR now
changes the mat_nr to be zero-based.
This is more in line with other places handling material indices.
Versioning code is in place to properly convert old files.
Fixes#109491
Pull Request: https://projects.blender.org/blender/blender/pulls/112954
For Blender 4.0 we decided to support individual icons for different
snap elements.
This was originally contributed by Erik Abrahamsson as !107054 with
some contributions by myself (Germano).
This set of icons being simple geometric symbols, that should be
familiar to CAD artists.
Note that Face and Volume share the same icon (circle). This is
deliberate since they communicate a similar functionality - are not
aimed at precision snapping the same way the vertex or perpendicular
are.
Also note that later we should also try to change the icons shown in
the snap menu to match the symbols that the artists see in the preview
window.
———
On the decision process:
The version currently in main (and rolled back here) was an initial
attempt of aggregating more information to the icons (e.g., by aligning
the icons to the target edges) while making them more suitable to
Blender. After presenting both options to (parts of the) community,
there was nothing fundamentally broken found with either option, though
options diverged over personal preference.
With that in mind, in the latest UI module meeting it was agreed to use
the original proposal then.
This final call was proposed by Dalai Felinto on his role of
commissioner (stakeholder) for the snap polishing tasks (#73993) and
designer for the related Snap Base design #66484.
———
This commit reverts commit 9c2e768f5b.
The reverted icons (referred originally as minimalistic icons) may be
proposed later as a separate theme option.
Adds a menu to choose the asset library to use to the asset shelf
catalogs selector popover. This is consistent with the asset browser.
After talking to animators and some artists, this is likely something
they would want to have, since they don't always want all their assets
and catalogs to populate the asset shelf. It's also necessary for the
pose library UI to provide the same features roughly than the old one
(in the sidebar, before the asset shelf was introduced).
Previously, it was only possible to inspect the data from the first iteration. That
applied to both, the viewer node as well as socket inspection. Now, there is a
new `Inspection Index` setting in the zone properties. It specifies which iteration
should be used by the inspection features.
In theory we could support features like counting the index from the end, but
that can be done separately as well, as it likely requires more UI.
Pull Request: https://projects.blender.org/blender/blender/pulls/112818
This PR adds vertex groups to `CurvesGeometry` as well as an attribute read/write accessor.
This is also in preparation for GPv3. Since the goal is to have full compatibility with the current grease pencil features, vertex groups need to be supported.
Grease Pencil allows filtering by vertex group for modifiers.To support this, it also makes sense to have read/write access for vertex groups in the attributes API.
In the future, vertex groups should be just another custom attribute on meshes/curves/grease pencil. There are some more issues to be solved before that can happen. This step gets us a bit closer since the vertex weight data is stored in `CustomData`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106944
Currently retiming is quite awkward, when you need to retime multiple
strips strips in sync. It is possible to use meta strips, but this is
still not great. This is resolved by implementing selection.
General changes:
Gizmos are removed, since they are designed to operate only on active
strip and don't support selection.
Transform operator code is implemented for retiming data, which allows
more sophisticated manipulation.
Instead of drawing marker-like symbols, keyframes are drawn to
represent retiming data. Retiming handles are now called keys. To have
consistent names, DNA structures have been renamed.
Retiming data is drawn on strip as overlay.
UI changes:
Retiming tool is removed. To edit retiming data, press Ctrl + R, select
a key and move it. When retiming is edited, retiming menu and
context menu shows more relevant features, like making transitions.
Strip and retiming key selection can not be combined. It is possible to
use box select operator to select keys, if any key is selected.
Otherwise strips are selected.
Adding retiming keys is possible with I shortcut or from menu.
Retiming keys are always drawn at strip left and right boundary. These
keys do not really exist until they are selected. This is to simplify
retiming of strips that are resized. These keys are called "fake keys"
in code.
API changes:
Functions, properties and types related to retiming handles are renamed
to retiming keys:
retiming_handle_add() -> retiming_key_add()
retiming_handle_move() -> retiming_key_move()
retiming_handle_remove() -> retiming_key_remove()
retiming_handles -> retiming_keys
RetimingHandle -> RetimingKey
Retiming editing "mode" is activated by setting `Sequence.show_retiming_keys`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109044
Shadow Map Ray Tracing is a technique that ray cast against the shadow
depth buffer. The technique is described in "Soft Shadows by
Ray Tracing Multilayer Transparent Shadow Maps".
Note that we only implement the single layer approach since storing
multiple depth is prohibitively expensive.
Pull Request: https://projects.blender.org/blender/blender/pulls/111809
Previously, it was only possible to bake all simulations at once. This is great
for simple use-cases that, but in more complex setups one can have independent
simulations that should also be baked independently. This patch allows baking
individual simulation zones.
Furthermore, each simulation zone can now also have its own bake path and
simulation frame range. By default the simulation frame range is the scene frame
range, but it can also be customized on the scene or simulation zone level. The
bake path is generated based on the modifier bake path by default, but can be
set to another absolute or relative (to the .blend file) path.
The timeline drawing has been modified as well to be able to show more information
in the case when some simulations are baked and others are not. Instead of showing
a line for every simulation, it shows a condensed view of the important information
using at most two lines:
Is something baked? Is something valid or invalid? Also see #112232.
Pull Request: https://projects.blender.org/blender/blender/pulls/112723
Draw the background of the asset shelf header fully transparent, with an opaque
background with rounded corners behind sections containing buttons. This
reduces the visual space consumed by the asset shelf, and makes the header
follow a tabbed folder metaphor better. Also, this works much better with our
click-through feature, where transparent parts of regions without buttons are
passed through the region under it (we might want to consider unifying code
here a bit).
The edge to drag for region resizing respects the transparent sections.
When there is little space between sections, the sections get merged so that
there are no small gaps in the bar.
Part of #107881.
----
Note that the core of this is implemented in a generic way, so this can be
reused for other regions.
Pull Request: https://projects.blender.org/blender/blender/pulls/112241
It was already called that way in the UI, since it's referring to a
behavior, not a type. Update the code to match that. Note that this is
a BPY compatibility breaking change for 4.0.
Currently vertices are mapped to B-Bone segments without taking the
rest pose curve into account. This is very simple and fast, but causes
poor deformations in some cases where the rest curvature is significant,
e.g. mouth corners in the new Rigify face rig.
This patch implements a new mapping mode that addresses this problem.
The general idea is to do an orthogonal projection on the curve. However,
since there is no analytical solution for bezier curves, it uses the
segment approximation:
* First, boundaries between segments are used for a binary space
partitioning search to narrow down the mapping to one segment.
* Then, a position on the segment is chosen via linear
interpolation between the BSP planes.
* Finally, to remove the sharp discontinuity at the evolute surface
a smoothing pass is applied to the chosen position by blending to
reduce the slope around the planes previously used in the BSP search.
In order to make per-vertex processing faster, a new array with the
necessary vectors converted to the pose space, as well as some
precomputed coefficients, is built.
The new mode is implemented as a per-bone option in order to ensure
backward compatibility, and also because the new mode may not be
optimal for all cases due to the difference in performance, and
complications like the smoothed but still present mapping
discontinuities around the evolute surface.
Wiki: https://wiki.blender.org/wiki/Source/Animation/B-Bone_Vertex_Mapping
Pull Request: https://projects.blender.org/blender/blender/pulls/110758
Pull Request: https://projects.blender.org/blender/blender/pulls/110758
Enable visual keying of bones that are influenced by an IK constraint.
This wasn't possible before, as the visual keying system only checked
constraints on the bone itself, and not whether the bone was part of an
IK chain.
This commit introduces a new `bPoseChannel::constflag` value
`PCHAN_INFLUENCED_BY_IK` that is set whenever the pose bone is part of
an IK chain.
The `pchan->constflag` field is computed during depsgraph evaluation. If
the depsgraph is active, it is now also written back to the original
pchan, so that it can be used in the "should visual keying be used"
function.
Fixes: #76791 "Different results when keyframing visual transforms and
applying transforms manually on IK constraint". Note that visually
keying does *not* copy the visual pose to the current pose. Furthermore,
when visually keying only part of the IK chain, the result of
re-evaluating the IK constraint (for example by moving the scene forward
and then backward by one frame) may still produce a different result, as
the IK chain now has a different start orientation.
Note that commit explicitly does not cover Spline IK constraints. They
can introduce heavy shear, especially with the default settings, which
cannot be represented by keys on loc/rot/scale.
For historical reference: 876cfc837e
introduces the 'use visual keying' preference option, where Blender
automatically chooses whether or not to use visual keying. This is why
there is a function at all that determines whether to use visual keying
or not.
Rename the `bPoseChannel::flag` `PCHAN_HAS_TARGET` to `PCHAN_HAS_NO_TARGET`
as that is actually the meaning of the flag (in the majority of the code).
Since the flag was so confusingly named, there were some mixups in the
armature overlay drawing code as well, which have been fixed now too.
Add a checkbox to node group inputs to force inputs to be single values
and not accept varying fields. While this could also be done more
automatically, and it could be argued that requiring the flexibility is
helpful for users who want to use attributes, there are cases where the
field inferencing doesn't work, or the "use attribute" option is just
unhelpful. People use workarounds with primitive nodes to get the same
behavior anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/112745
In preparation of https://projects.blender.org/blender/blender/pulls/112535, we need to make sure all layer tree manipulations are in functions on the `GreasePencil` struct so we can keep the `CustomData` for layers in sync with the layer tree.
This PR makes sure that all the functions that change the layer tree in any way are `protected` on the `LayerGroup` class. The `GreasePencil` struct is declared `friend` with `LayerGroup`.
We also cleanup and remove a lot of code duplication between layers and layer groups and try to write functions in a generic way for `TreeNode` (both layers and layer groups are tree nodes).
Pull Request: https://projects.blender.org/blender/blender/pulls/112837
The goal is to make the search faster to use by dynamically adapting to the user.
This can be achieved using the simple but common approach of showing recently
selected items at the top. Note, that the "matching score" between the query and
each search item still has precedence when determining the order. So the last used
item is only at the top, if there is no other search item that matches the query better.
Besides making the search generally faster to use, my hope is that this can also
reduce the need for manually weighting search items in some places. This is
because while the ordering might not be perfect the first time, it will always be
once the user selected the element that should be at the top once.
This patch includes:
* Support for taking recent searches into account in string searching.
* Keep track of a global list of recent searches.
* Store recent searches on disk similar to recently opened files.
* A new setting in the user preferences that allows disabling the functionality.
This can be used if deterministic key strokes are required, e.g. for automated tests.
In the future this could be improved in different ways:
* Add some kind of separator in the search list to indicate which elements are at
the top because they have been used recently.
* Store the recent search items per search, instead of in a global list. This way
it could adapt to the user even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/110828
Avoid confusion when checking for DNA members by using the names
in DNA headers ("Light" instead of "Lamp" for e.g.)
Internally SDNA stores names without aliases for compatibility.
The intention with aliasing DNA names is for `dna_rename_defs.h`
to be the only place where the non-aliased names needed to be referenced
however versioning checks also needed to reference the old names.
This wasn't obvious, causing mistakes in versioning checks (now fixed):
- SpaceOutliner::filter
- BrushGpencilSettings::hardness
- bGPDstroke::hardness
Details:
- Alias lookup tables are now ensured for BlendFileData::filesdna.
- DNA_struct_exists & DNA_struct_member_exists now use aliased names
in versioning code.
Use with_alias / without_alias suffix for functions
so it's clear which is intended (no functional changes).
Add macros for versioning checks to avoid noisy changes,
currently they use the non-aliased versions of these functions
but should eventually be moved to use the aliased versions because
it's confusing to use the original names when these should only need
to be referenced from `dna_rename_defs.h`.
YimingWu
Campbell Barton
Jacques Lucke
Hans Goudey
Aras Pranckevicius
Lukas Tönne
Christoph Lendenfeld
Martijn Versteegh
Alexander Gavrilov
Omar Emara
Falk David
Damien Picard
Guillermo Venegas
Sybren A. Stüvel
Marcelo Mutzbauer
Germano Cavalcante
Hans Goudey
Brecht Van Lommel
Bastien Montagne
Philipp Oeser
Julian Plak
Richard Antalik
Nathan Vegdahl
Clément Foucault
Habib Gahbiche
Hans Goudey
Hoshinova
Miguel Pozo
Gilberto Rodrigues
Julian Eisel
Dalai Felinto
Douglas Paul
Harley Acheson
Jeroen Bakker