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
This commit fixes a issue where the node wrangler addon would connect
bump mapping textures to the filter width input of the bump node,
instead of the height input.
Pull Request: https://projects.blender.org/blender/blender/pulls/146684
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.
Node sockets could already be declared using:
```cpp
add_input<decl::<SOCKET TYPE>>("NAME")
```
They can now additionally be declared with:
```cpp
add_input(socket_type, "NAME")
```
This commit adds the later form to the message extraction regex. Since
they are mutually exclusive, they are now in a non-capturing group
with an | operator.
Reported by Ye Gui in #43295.
This extracts the names and descriptions for displays, views, and
colorspaces. They are all used in the different parts of the UI.
The views' descriptions are used for the displays'.
The extraction uses the built-in PyOpenColorIO module. This ensures
only data that is actually used is extracted (not ignored in the
config).
use_nodes is now deprecated in Blender 5.0
- Remove check checks
- Remove all nodes before creating the node tree is no more needed : these nodes are no more created at material creation
Implements #146360
Update VFX template with minimum changes:
- Replace Timeline with DopeSheet footer.
- Save (with compression). 525kb → 92kb
All changes were done on a release build at 1920x1080, without a
preferences folder.
See PR for details and screenshtos.
Pull Request: https://projects.blender.org/blender/blender/pulls/146851
We used to set shader->osl_surface_ref during shader compilation and then
pushed it into the shared vectors.
This worked as long as everything was serial - but after the multithreading
change, we a) compile everything and then b) build the shared vectors since
just pushing into them from multiple threads would not work.
However, if there are multiple devices, then each shader will be compiled
multiple times - so in the end, shader->osl_surface_ref etc. will be set
to the last device's value. Then, we end up pushing that value into every
device's vectors, which breaks for the earler devices.
The fix is simple - just preallocate the vectors and pass the correct index
into the compilation function. This way, each thread can safely store its
result and we can get rid of shader->osl_surface_ref entirely.
Note that while multiple shaders are compiled in parallel, the loop over
devices for a given shader is serial, so there's no concern of conflicts
over other shader internals.
Pull Request: https://projects.blender.org/blender/blender/pulls/146617
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
