Adds a new `Set Grease Pencil Color` node.
It was already possible to write to the color and opacity attributes using the
`Store Named Attribute` node, but this required the user to know the names
of the "built in" attributes.
Similar to how we can set other built-in attributes (e.g. the curve radius) this
adds a node to write to the following Grease Pencil attributes:
* `vertex_color` (point domain): The color of a point (the alpha value is used
as a mix factor with the base material color).
* `opacity` (point domain): The opacity of a point.
* `fill_color` (curve domain): The fill color of a stroke (the alpha value is used
as a mix factor with the base material color).
* `fill_opacity` (curve domain): The fill opacity of a stroke.
For consistency with other nodes, there is a mode to switch between writing
to the points (`Stroke` mode) and the fills (`Fill` mode).
Pull Request: https://projects.blender.org/blender/blender/pulls/136260
Add a "Pixel Density" sub-panel to render output settings which
can be used to set the density (as pixels per inch for example).
This is then written to images that support pixel density.
Details:
- The scene has two values a PPM factor and a and base unit.
- The base unit defaults to pixels per inch as this is the most
common unit used.
- Unit presets for pixels per inch/centimeter/meter are included.
- The pixel density is stored in the render result & EXR cache.
- For non 1:1 aspect renders, the density increases on the axis
which looks "stretched", so the PPM will print the correct
aspect with non-square pixels.
Ref !127831
**Problem**
When using Texture Paint mode, the Image Editor will show a UV Wireframe
to display the active object's UVs. In every other mode, this wireframe
is absent. This is currently a big problem for Sculpt Mode since the
Experimental Texture Paint system is a part of that mode, meaning that
the user can't see their UVs while they paint in Sculpt Mode. This is
also troublesome for users that would like to quickly view an object's
UVs without using Texture Paint Mode.
**Solution**
Since it's useful to be able to view an object's UVs at all times, the
Image Editor should display UV Wireframes in all Object Modes regardless
of the Image Editor's mode. This is the best solution since it means
that future Blender features, that would benefit from having a preview
of an object's UV Wireframes, will automatically have that option since
UV Wireframes are supported in all modes. Also, if a user doesn't want
to see UV Wireframes for any reason, it can be disabled with an Overlay
option.
Additionally, when multiple objects are selected, each object should
have its UV Wireframe drawn in the Image Editor. The selected objects
that aren't active should have less opaque wireframes to indicate which
wireframe belongs to the active object. This is the best approach for
having multiple objects selected since it allows the user to quickly
view the UV layout for all selected objects to troubleshoot UV problems,
like texture mapping. This is especially helpful when using a material
for multiple different objects.
An alternative solution would be to only show the UV Wireframe for the
active object, but this would be undesirable because it would make
troubleshooting UV positions tedious when working with multiple objects
since the user would need to select objects individually.
Co-authored-by: T0MIS0N <50230774+T0MIS0N@users.noreply.github.com>
Co-authored-by: Sean Kim <SeanCTKim@protonmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/135102
Add a "dumb vector" storage option for custom normals, with the
"custom_normal" attribute. Adjust the mesh normals caching to
provide this attribute if it's available, and add a geometry node to
store custom normals.
## Free Normals
They're called "free" in the sense that they're just direction vectors
in the object's local space, rather than the existing "smooth corner
fan space" storage. They're also "free" in that they make further
normals calculation very inexpensive, since we just use the custom
normals instead. That's a big improvement from the existing custom
normals storage, which usually significantly decreases
viewport performance. For example, in a simple test file just storing
the vertex normals on a UV sphere, using free normals gives 25 times
better playback performance and 10% lower memory usage.
Free normals are adjusted when applying a transformation to the entire
mesh or when realizing instances, but in general they're not updated for
vertex deformations.
## Set Mesh Normal Node
The new geometry node allows storing free custom normals as well as
the existing corner fan space normals. When free normals are chosen,
free normals can be stored on vertices, faces, or face corners. Using
the face corner domain is necessary to bake existing mixed sharp and
smooth edges into the custom normal vectors.
The node also has a mode for storing edge and mesh sharpness, meant
as a "soft" replacement to the "Set Shade Smooth" node that's a bit
more convenient.
## Normal Input Node
The normal node outputs free custom normals mixed to whatever domain is
requested. A "true normal" output that ignores custom normals and
sharpness is added as well.
Across Blender, custom normals are generally accessed via face and
vertex normals, when "true normals" are not requested explicitly.
In many cases that means they are mixed from the face corner domain.
## Future Work
1. There are many places where propagation of free normals could be
improved. They should probably be normalized after mixing, and it
may be useful to not just use 0 vectors for new elements. To keep
the scope of this change smaller, that sort of thing generally isn't
handled here. Searching `CD_NORMAL` gives a hint of where better
propagation could be useful.
2. Free normals are displayed properly in edit mode, but the existing
custom normal editing operators don't work with free normals yet.
This will hopefully be fairly straightforward since custom normals
are usually converted to `float3` for editing anyway. Edit mode
changes aren't included here because they're unnecessary for the
procedural custom normals use cases.
3. Most importers can probably switch to using free normals instead,
or at least provide an option for it. That will give a significant
import performance improvement, and an improvement of Blender's
FPS for imported scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132583
This patch supports GPU OIDN denoising in the compositor. A new
compositor performance option was added to allow choosing between CPU,
GPU, and Auto device selection. Auto will use whatever the compositor is
using for execution.
The code is two folds, first, denoising code was adapted to use buffers
as opposed to passing in pointers to filters directly, this is needed to
support GPU devices. Second, device creation is now a bit more involved,
it tries to choose the device is being used by the compositor for
execution.
Matching GPU devices is done by choosing the OIDN device that matches
the UUID or LUID of the active GPU platform. We need both UUID and LUID
because not all platforms support both. UUID is supported on all
platforms except MacOS Metal, while LUID is only supported on Window and
MacOS metal.
If there is no active GPU device or matching is unsuccessful, we let
OIDN choose the best device, which is typically the fastest.
To support this case, UUID and LUID identifiers were added to the
GPUPlatformGlobal and are initialized by the GPU backend if supported.
OpenGL now requires GL_EXT_memory_object and GL_EXT_memory_object_win32
to support this use case, but it should function without it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136660
This adds a new more accurate antialiasing to the Grease Pencil
render engine. This is only available for render.
This Accumulation AA doesn't replace the SMAA. SMAA is still
used by the viewport and for removing aliasing from the
depth buffer. However, using both at the same time can lead
to overblurred result.
Here are some measurements for how much the render time
increases compared to the baseline with different (SSAA) sample
counts (using an example production file, rendered at 1080p,
results might vary depending on the scene complexity):
* 8 samples: +0.14 s
* 16 samples +0.36 s
* 32 samples: +0.58 s
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/136551
This implements bundles and closures which are described in more detail in this
blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/
tl;dr:
* Bundles are containers that allow storing multiple socket values in a single
value. Each value in the bundle is identified by a name. Bundles can be
nested.
* Closures are functions that are created with the Closure Zone and can be
evaluated with the Evaluate Closure node.
To use the patch, the `Bundle and Closure Nodes` experimental feature has to be
enabled. This is necessary, because these features are not fully done yet and
still need iterations to improve the workflow before they can be officially
released. These iterations are easier to do in `main` than in a separate branch
though. That's because this patch is quite large and somewhat prone to merge
conflicts. Also other work we want to do, depends on this.
This adds the following new nodes:
* Combine Bundle: can pack multiple values into one.
* Separate Bundle: extracts values from a bundle.
* Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node.
* Evaluate Closure: evaluates the passed in closure.
Things that will be added soon after this lands:
* Fields in bundles and closures. The way this is done changes with #134811, so
I rather implement this once both are in `main`.
* UI features for keeping sockets in sync (right now there are warnings only).
One bigger issue is the limited support for lazyness. For example, all inputs of
a Combine Bundle node will be evaluated, even if they are not all needed. The
same is true for all captured values of a closure. This is a deeper limitation
that needs to be resolved at some point. This will likely be done after an
initial version of this patch is done.
Pull Request: https://projects.blender.org/blender/blender/pulls/128340
Previously when an action was baked, the slot name was not retained.
This causes problems when switching between actions because the slot
will not automatically be assigned.
This is now fixed by ensuring that the name of the last assigned slot
is used to create the new slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/136814
This adds a new Camera Info node to Geometry Nodes. It provides information
about the passed in camera like its projection matrix and focus distance.
This can be used for camera culling which was must more complex before.
It also allows building other view-dependent effects.
Pull Request: https://projects.blender.org/blender/blender/pulls/135311
In Geometry Nodes a geometry is represented by a `GeometrySet`. This is a
container that can contain one geometry of each of the supported types (mesh,
curves, volume, grease pencil, pointcloud, instances). It's possible for a
`GeometrySet` to contain e.g. a mesh and a point cloud.
This patch creates a Python wrapper for the built-in `GeometrySet`. For now,
it's main purpose is to consume the complete evaluated geometry of an object
without having to go through complex hoops via `depsgraph.object_instances`. It
also also allows retrieving instances that have been created with legacy
instancing systems such as dupli-verts or particles.
In the future, the `GeometrySet` API could also be used for more kinds of
geometry processing from Python, similar to how we use `GeometrySet` internally
as generic geometry storage.
Since we can't really have constness guarantees in Python currently, it's
enforced that the `GeometrySet` wrapper always has its own copy of each geometry
type (so e.g. it does not share a `Mesh` data-block pointer with any other place
in Blender). Without the copy, changes to the mesh in the geometry set would
also affect the evaluated geometry that Blender sees. The copy has a small cost,
but typically the overhead should be low, because attributes and other run-time
data can still be shared. This should be entirely thread-safe, assuming that no
code modifies implicitly shared data, which is forbidden. For historic reasons
there are still cases like #132423 where this assumption does not hold in all
cases. Those cases should be fixed. To my knowledge, this patch does not
introduce any new such issues or makes existing issues worse.
Pull Request: https://projects.blender.org/blender/blender/pulls/135318
When viewing extension details, no need to call userpref_show if a
Preferences editor is in the main window, as that will just open a new
Preferences window.
Pull Request: https://projects.blender.org/blender/blender/pulls/136139
Texture nodes are already supported through the GPUMaterial and
multi-function compositor abstractions. So we just need to expose them
through the add menu.
Add support for a 5th modifier key called "hyper",
this is a modifier supported on Wayland & X11 although
other platforms could support an additional modifier too.
Both GNOME and KDE can map CapsLock to Hyper.
Other compositors can use the XKB_DEFAULT_OPTIONS environment variable.
This allows users to have an additional modifier for their own use
that doesn't conflict with other keys.
Ref !136340
Rename to be more consistent with other Blender keymaps, as well as the
naming convention used in "View Type."
- "SequencerCommon" -> "Video Sequence Editor"
- "SequencerPreview" -> "Preview"
- "Sequencer Timeline Tool" -> "Sequencer Tool"
- "Sequencer Preview Tool" -> "Preview Tool"
There is versioning in place to make sure custom keyconfigs keep working.
Once #131102 goes through, if we would like to rename the "Sequencer"
view type to "Timeline" or "Sequencer Timeline," then we can make the
necessary changes here too.
Pull Request: https://projects.blender.org/blender/blender/pulls/136217
Strip locking was meant to be used with strip transformation only. So
the check, whether strip is locked is removed from hide/unhide operator.
Further it was requested to lock sound strip subframe offset. Since this
is time related property, it was moved to time panel. This also
addresses request to make it more obvious, why the value can't be
changed.
The name of the property was clarified from "Offset" to
"Sound offset", because there are another 2 offsets in the panel.
Finally, when channel is locked, properties in side panel now reflects
this state. This is done by adding RNA get function for `Strip.lock`
property. Function `seq::transform_is_locked` is used instead of
checking `SEQ_LOCK` flag, because it also checks channel state. With
this setup, the lock property can't be disabled while channel is locked.
However strip lock flag will be unset, which can be prevented. (I am not sure which is better. Both are fine in my eyes.)
Pull Request: https://projects.blender.org/blender/blender/pulls/135831
Previously when an addon is expanded on the UI, the "Maintainer" string
would be cut short until a `<` character, to prevent showing e-mail on the
UI, however there could be more than one person/email entries in there
so to prevent cutting short the string, now we use regex to take out the
email part only, so full maintainer string is displayed.
Pull Request: https://projects.blender.org/blender/blender/pulls/136031
When using vertex parenting, an option for using the parent object
final evaluated indices is exposed in the Object Properties: Relations
panel. This allows the calculation of the parent vertex position to
ignore the the CD_ORIGINDEX layer and instead use the final indices
that may have been altered by the node tree evaluation.
The indices that will be used for the vertex parenting are also exposed
to the UI in the same panel, allowing them to be altered after the
vertex parent has been created.
Following discussion to document the `icon_value` property of
`GIZMO_GT_button_2d` in PR #136080, and generally improve the
documentation of this Gizmo Type, this patch adds a new "Gizmo
Simple 2D" Python template, and renames the existing "Gizmo
Simple" template to "Gizmo Simple 3D".
Pull Request: https://projects.blender.org/blender/blender/pulls/136304
When updates are available, clicking on the button in the status bar
was only showing "Add-on" updates.
Restore the ability to show "All" extension types which is
set when showing updates.
This adds icons for ICON_RGB_RED, ICON_RGB_GREEN, and ICON_RGB_BLUE
that display with those colors. This does not remove the existing
monochrome ICON_COLOR_* icons. This also allows the translation of
the "R", "G", "B" characters shown, for languages that prefer color
words that do not start with these.
Pull Request: https://projects.blender.org/blender/blender/pulls/136154
Part of #134755 / #134766.
Adds options to the new Import Settings popover (added in 7a6beb65f4)
to toggle collection instancing for dragging in collections. It can be
toggled separately for linking and appending, since it's typical to use
instancing for linking, but not appending (current default, also with
this change).
Previously, toggling collection instancing was only possible via the
Adjust Last Operation panel but this wasn't obvious, many people were
not aware. Adding this option based on feedback by the Blender Studio.
Pull Request: https://projects.blender.org/blender/blender/pulls/135996
When the scene settings indicate the active keying set should be used,
this is taken into account for all auto-keying done by the add-on. This
covers:
- Pasting global transform
- Pasting relative transform
- Fix to Camera
Support is limited to *relative* keying sets. Absolute keying sets,
which thus determine what gets keyed regardless of the selection, are
not supported, as the interaction between the "copy this object/bone's
transform" is currently not known.
Fix to Camera has its own settings for what to key; these will be
combined with the keying set. Only those properties that are enabled in
the Fix to Camera settings AND included in the keying set will be keyed.
To give a concrete example: when the "Location & Rotation" keying set is
active, and "Location" and "Scale" are checked in the Fix to Camera
panel, only the location will be keyed.
A message is shown in the Fix to Camera panel to notify users that the
keying set will affect the keys as well.
The keying set will only be considered when the auto-keying option "Only
Active Keying Set" is enabled.
Fixes: #136076
Pull Request: https://projects.blender.org/blender/blender/pulls/136187
This patch adds a new Image Info node which returns information about
compositor images. The node has three sources:
The node returns the following information:
- Pixel Coordinates: The coordinates of the centers of the pixels in the
image. Those are essentially the integer coordinates with half pixels
offsets added.
- Texture Coordinates: Zero centered pixel coordinates normalized along
the greater dimension. Somewhat analogous to Object coordinates in
shader nodes.
- Resolution: The resolution of the image.
- Location: The location of the image in the virtual compositing space.
- Rotation: The rotation of the image in the virtual compositing space.
- Scale: The scale of the image in the virtual compositing space.
This node is very useful to allow greater flexibility and procedural
creations. For instance, coordinates can be used to create procedural
effects like vignette using very simple math nodes. And size can be used
to compute size-relative parameters for pixel-parameter nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/135104
This patch adds common nodes that are used in Geometry Nodes and Shader
Nodes to the compositor. The following new nodes were added:
- Vector Math.
- Vector Rotate.
- Vector Mix.
- Value Mix.
- Clamp.
- Float Curve.
- Blackbody.
The follow nodes were replaced by common counterparts:
- Value.
- Color Ramp.
- Mix Color.
- Map Range.
- Math.
- Combine XYZ.
- Separate XYZ.
- Vector Curves.
Some new features were gained in the process:
- Mix Color can now clamp both factor and result.
- Map Range can map different types and interpolations.
- Vector Curves gained a new Factor input.
Some behaviors were changed:
- Map Range previously forcibly clamped values whose magnitude is larger
than the arbitrary value of 10000. This is no longer the case.
Some nodes were removed:
- Map Value. This was Map Range without the maximum 10000 limitation
followed by a Clamp node. Both are now available as nodes.
Some common nodes remain separate:
- Separate/Combine Color. Shader counterpart does not yet support all
color modes, and does not support alpha.
- RGB Curves. Shader variant does not support Film-Like curves or
Black/White balancing.
Texture nodes will also be added soon in a separate patch. Nodes that
were replaced are now deprecated but still exist and will later be
removed in v5.0. Backward compatibility code was introduced to convert
from the deprecated nodes to the new nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/135300
Part of #134755 / #134766.
Replaces the current import method menu in the middle of the Asset
Browser header with a "Import Settings" popover. The import method is
located there now, because it doesn't need to be as prominent as it used
to be, especially with #104686.
Plan is to add further settings to this popover, e.g. see #135996 or
#134943.
Before this patch, Video Output using FFmpeg video
display lot of parameters.
But some of theses have a meaning only for some codec
(mainly lossy gop codecs : H264, H265, AV1...)
Hide not useful parameters for codec :
'DNXHD', 'FFV1', 'HUFFYUV', 'PNG', 'QTRLE'
- DNXHD : intra frame codec, encoding setting depends of a profile
- FFV1/QTRLE : Intra or P frames only. Lossless codec
- HUFFYUV/PNG : Intra lossless codec
Co-authored-by: mvji <33432858+mvji@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/135827
The import nodes are considered complete enough to expose without
the experimental option. This commit removes the option so they will
be exposed in 4.5. There are still some possible future improvements,
including automatic caching, possibly exposing more input sockets,
and possibly including imported paths in the "Internal Dependencies"
panel. Those are considered non blocking though.
Pull Request: https://projects.blender.org/blender/blender/pulls/135957
Face Orientation Front Color has been changed to transparent for the
default theme (8bcb714b9e). This PR makes the Blender Light theme for
the face orientation front match the default theme alpha.
Pull Request: https://projects.blender.org/blender/blender/pulls/136034
