Hardocde the position of the essentials assets in the menu,
for consistent alphabetical order and a clearer indication of
the different between the nodes and builtin "Array" modifiers
(the old one is now called "Array (Legacy)").
Pull Request: https://projects.blender.org/blender/blender/pulls/146887
OpenGL has the concept of streaming buffers these buffers are marked to be
rewritten and used a small number of times. Vulkan (being low-level API)
doesn't have this concept. When performing font rendering Blender uses
streaming buffers and can slow down Vulkan as GPU barriers are added
between uploading and using the buffer.
Using a different approach could reduce the GPU barriers. The overall
idea is:
Altering render graph nodes
During font rendering the streaming buffer is rewritten from start with
the data to render the next part. This could only cover a part of the fully
allocated buffer. And would introduce a barrier before and after rewritting
the next part.
The allocated buffer on the GPU can fit more data but that data needs to be
passed along the first update to reduce the barriers. Allowing access to an
existing node in the render graph would allow to change the initial upload to
upload more data, without additional barriers.
VKStreamingBuffer
A new buffer type is introduced that will keep track of the streaming buffer
on the current render graph. A streaming buffer can be shared between multiple
threads and requires state manager to be done per context.
Pull Request: https://projects.blender.org/blender/blender/pulls/146956
7becc38a3c introduced new text rendering.
In the refactoring the vertex buffer was replaced by a more shallow
storage buffer. However the refactoring removed one optimization that
the vulkan backend uses, namely the actual amount of bytes that is being
used by the draw call. This resulted in overly large data transfers.
For example in the text editor the texts are rendered one glyph at a
time. But the storage buffer would always upload the data for 1024
glyphs.
This PR allows the usage size of a storage buffer to be set to ensure
that the data transfers are limited.
The implementation wasn't added to OpenGL as it draws incorrectly.
Issue detected during the research of !146956 That PR will implement
better data streaming inside the Vulkan backend and also requires
to know the actual usage size of the buffer to detect what data can
be grouped together.
Pull Request: https://projects.blender.org/blender/blender/pulls/146958
The current filter was still using the legacy Grease Pencil
type (now Annotations).
Now this uses the correct `FILTER_ID_GP` and uses the
other filter for Annotations.
Pull Request: https://projects.blender.org/blender/blender/pulls/146978
Deletion of NTree IDs through custom code path using
`blender::bke::node_tree_free_tree` is fully by-passing standard ID
management code, and was missed when ID::runtime was made an allocated
pointer.
We should really spend some time at some point to get these custom temp
node IDs handling code under control, there should be little to no need
for all this custom allocation and deletion code anymore nowadays.
Caused by 866fcd0a09
To search for strips, we do so on an `Editing` object or a `MetaStrip`
object.
Code from 866fcd0a09 got the `MetaStack` but then tried to use this
directly as a `MetaStrip`.
We should be getting its `parent_strip` though it seems.
For reference, this is what was done prior to 866fcd0a09
`sequences_object = ed.meta_stack[-1]`
Pull Request: https://projects.blender.org/blender/blender/pulls/146967
This adds a new operator which can join multiple nodes together. Currently, it
only supports joining Group Input nodes. However, in the future it could be
extended to join e.g. Bake and Capture Attribute nodes.
This uses the recently freed up ctrl+J shortcut for this functionality, which
feels natural to me.
The implementation is fairly straight forward. The main tricky aspect is
sometimes the nodes can't be joined when that would result in two sockets being
linked to each other twice. In this case, the a separate Group Input node is
kept.
The selected nodes are merged into the active node (in case the active node is
part of the selection, otherwise there is a fallback).
Pull Request: https://projects.blender.org/blender/blender/pulls/146894
When writing .blend files, Blender traditionally wrote raw runtime-pointers into
the file. Since these pointers are different whenever Blender is restarted or
the file is loaded again, the written .blend file will be very different every
time. The file always changing is a problem with tools that use change-detection
on .blend files such as:
* Change detection during undo in Blender. When a serialized data-block is the
same in two consecutive undo steps, it's known that the data didn't change and
the data-block does not have to be reloaded and can potentially skip depsgraph
evaluation. Also see #141262.
* BAT: https://projects.blender.org/studio/flamenco/issues/104437
* Generally using .blend files in version control. The diffs can be smaller when
pointers aren't changing all the time and have a lower memory footprint.
This PR makes pointers in .blend files across multiples saves much more
consistent, improving the situation for the cases above. Although there is still
other data that changes on almost every save currently; that needs to be
addressed separately.
The basic design for pointer stability in blend files stable pointers, described
in #127706, is fairly straight forward. This patch implements a slightly
modified variant of that design. When reading .blend files, Blender already does
not care if the stored pointer values are actual pointer values, or just some
arbitrary identifiers. Therefore, we mainly just have to change the write-file
code. This also implies that this change is fully forward and backward
compatible.
The main non-obvious aspect of this patch is how to actually do the remapping of
runtime pointers to stable identifiers. In theory, having a single integer that
increments for every newly detected pointer works. But in practice that leads to
many changes in the .blend file because one pointer is added or removed
somewhere, all subsequent pointers will be different too. So some kind of
scoping is required to make sure that one small change does not affect
everything else.
This PR starts a new scope pointer identifier scope whenever a new ID data-block
starts. At first I thought it would be good to have separate maps for id-local
and global pointers. However, that's tricky currently, because at write-time, we
don't always have enough information to know if a specific pointer is local or
global. I worked on #146136 to improve the situation but the problem is bigger
than that since we also have various void pointers in DNA structs. Fortunately,
the solution implemented now also works fine with a single global map.
Implicit sharing in undo steps also had to be changed slightly to work with the
stable address identifiers instead of raw pointers.
There's also new code to find all pointers in DNA structs in the first place.
This is done once when writing starts. Then whenever a struct is written, a copy
is made, all pointers are replaced and the modified struct is written to the
.blend file. There is an optimization for the case when a struct does not
contain any pointers because then the copy can be skipped.
For checking the diff between two saved .blend files, I recommend enabling
`GENERATE_DEBUG_BLEND_FILE` and then diffing the text version of the .blend
files.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/127729
Each name has to be unique within a group, so when renaming an idproperty, one
has to make sure that the parent group does not contain duplicates afterwards.
This patch raises a `NameError` when setting the name to one that exists
already. Alternatively, one could delete the already-existing property, but that
seems unexpected and the user should rather do that explicitly.
This also adds a new unit test for this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/146892
The grid layout for UI lists wasn't used in practice from all we can
tell. It was badly maintained for a long time (bugs went unnoticed). I
think it was added for an earlier version of the asset UI design.
This was planned for removal in 5.0, see blender/blender#110461.
Usages in bundled scripts were already removed in efa8d942b8.
Pull Request: https://projects.blender.org/blender/blender/pulls/146656
When drag is initiated, store selected keyblocks inside pointer array
(see: `create_drag_data`). Later iterate over these pointers inside
`on_drop()` function to place them one by one at `drop_index`
Resolves#143929
See PR description for video
Pull Request: https://projects.blender.org/blender/blender/pulls/144431
Unlike other Outliner views, this will not open up elements to find
objects "underneath" (since Data API view lazy loads elements iirc), but
given that you already have that object visible somewhere in the DataAPI
view (so e.g. Objects expanded) we could actually do the centering/
scrolling by getting an ID from the `TreeElement` (in case of an
`TSE_RNA_STRUCT`).
This came up in #145904
Pull Request: https://projects.blender.org/blender/blender/pulls/145920
In 3D Viewport theme settings there is "Active Spline" property, which behaves weirdly.
Color of that property is multiplied to color of curve handles. Even though it says active,
it's multiplied in selected and unselected states, for all curves all the time.
That doesn't make much sense, has no real value, and ends up only causing confusion.
Having this property on anything but pure black means that whatever colors you choose
for curve handles in Preferences isn't actually what you're getting them. If color is set to
high-saturation color it completely washes away all colors and makes it difficult to differentiate
between handle types.
I think there is no reason for this property to exist, so this PR just removes that property.
Pull Request: https://projects.blender.org/blender/blender/pulls/145360
Allow translating node menu socket items using the declared socket
translation context.
In order to do this, the context needs to be copied to the socket's
default_value property when the tree is evaluated. To do that, the
context is redefined inside the prop's itemf callback, getting it from
the socket declaration.
In addition, add contexts to two sockets related to color.
This panel defines labels manually, through a helper function
`add_labeled_field`. This commit simply adds `IFACE_` translation
macros around the labels.
This new translation context is for some special cases when
translation cannot be avoided, for example in an interface where some
props are built-in (translatable) and others are
user-defined (non-translatable), but we don't know which ones in
advance.
It allows specifying explicitly that translation should not occur
for user data when building the UI.
It is a followup to !145963, in which the context was introduced as a
string literal instead of a defined context.
Use the "Action" context for this, if in any language it's different
from a sequencer meta strip, which already uses "Sequence".
Reported by Ye Gui in #43295.
Applies thin film iridescence to metals in Metallic BSDF and Principled BSDF.
To get the complex IOR values for each spectral band from F82 Tint colors,
the code uses the parametrization from "Artist Friendly Metallic Fresnel",
where the g parameter is set to F82. This IOR is used to find the phase shift,
but reflectance is still calculated with the F82 Tint formula after adjusting
F0 for the film's IOR.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Co-authored-by: RobertMoerland <rmoerlandrj@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/141131
This expands Cycles' support for handling OSL property metadata for
Custom camera parameters and translating it to Blender's UI.
Specifically, it adds support for:
- Translation inputs (`string vecsemantics = "POINT"`)
- Normal inputs (`string vecsemantics = "NORMAL"`)
- File inputs (`string widget = "filename"`)
- Angle inputs (`string unit = "radians"`)
- Distance inputs (`string unit = "m"`)
- Time inputs (`string unit = "s"` or `string unit = "sec"`)
- Enum inputs (`string widget = "mapper", string options = "left:0|right:1"`)
It also sets the default value correctly, and corrects a warning string to
also mention cameras in addition to nodes as possible users of OSL shaders.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/146736
The multi-function node evaluation code correctly didn't create a grid
with an unsupported type, but then the code crashed in the logging
code when setting default for the outputs. Instead just use a common
utility for that goal. And also add support for executing a function node
if only outputs with supported types are required (for example when
creating a grid for the "Fac" output of the noise node, but not the
color output).
Pull Request: https://projects.blender.org/blender/blender/pulls/146937
This property is not user editable and is calculated internally. When presented as a property in the UI, it shows the animatable button which is useless. This just removes the flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/146907
When trying to find and open an older file, it is annoying when it is not in the
recent files list anymore. This patch increases the length of the recent files
list, without making the menu huge by making better use of menu-search.
Specifically the following is changed: * Number of remembered recent files is
increased from 20 to 200 by default. * The recent files menu is limited to 20
entries. * When activating menu search (by pressing space when in the menu), all
available recent files can be searched. * There is a new "More..." menu entry at
the bottom, which also activates the menu search.
Pull Request: https://projects.blender.org/blender/blender/pulls/146884
Previously, the input socket drawing code did not cover all cases with required
and optional labels for all socket types. E.g. menu sockets were never drawn
with label (unless there was some error) regardless of whether `optional_label`
was set or not.
This patch unifies the handling of this flag, i.e. all socket types support
drawing with and without label. This is also required before we can expose this
functionality to users.
Since all menu inputs had optional labels by default before, this patch makes
labels optional explicitly by changing the declaration of all the nodes. This
way, there is no expected user-visible change with this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/146935
Each socket is generally drawn into a separate row like in `draw_node_input`.
However, this row was not created when a socket had a custom drawing function.
This caused all properties of the Index Switch node to be grayed out in the
sidebar.
The new name better represents the actual meaning of the value.
"hide_value" was wrong because it didn't even hide the label in
many cases.
This property just indicates that the input is still understandable
even if the label is not drawn. It's up to the drawing code to make
the final decision whether the label should be drawn or not. This
option just gives it the opportunity to skip the label if that results
in a cleaner UI.
This removes the `SOCK_NO_INTERNAL_LINK`, `SOCK_COMPACT` and `SOCK_HIDE_LABEL`
flags from `eNodeSocketFlag`. Those are not necessary, because they just store
a copy of the data that is stored in the socket declaration and are thus
effectively runtime data.
None of these flags were exposed to Python, so there is no breakage expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/146925
This was an oversight in the initial implementation. If there is no closure,
the node should behave like if it's muted, so it passes through inputs to
outputs when the names are equal. This is the same behavior as in
Geometry Nodes.
The issue was that the Separate XYZ node was linked to something
expecting a field and something expecting a single value. This
incorrectly resulted in the input getting a field data requirement,
instead of single-value.
There were two issues:
* Missing null checks when the compute context of a socket can't be detected
statically.
* Incorrect parent compute context detection for closures. The tricky aspect is
that closures can be evaluated in a different compute context from where they
are created.
Pull Request: https://projects.blender.org/blender/blender/pulls/146922
#140856 added support for output visibility inferencing. Internally, it relied
on checking whether the output value of a group is a constant fallback value,
while on the user level this is mainly controlled with the new `Enable Output`
node. While it works, there are some unexpected behaviors when the user happens
to output the fallback value without expecting the socket to be hidden.
Additionally, this approach required the output value to be inferenced, which
may trigger more evaluation than we'd want.
This patch better aligns the internal behavior with the user-expected behavior.
This is achieved by not relying on any specific fallback values. Instead, for
each output socket it does an explicit check for whether it is connected to an
Enable Output node. Then the Enable input of that node is computed and the
output visibility is derived from that directly. This is still fully composable
with nested node groups etc. It also allows extending this check in the future
to e.g. automatically disable certain anonymous attribute outputs when the
corresponding output geometry is unused.
Note, since only changes in menu sockets are allowed to change visibility by
convention, this also applies here. Same as before.
The main design on the user-level with the Enable Output node is still exactly
the same as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/146918
