Currently, the scene strip preview uses the existing dependency
graph built for that scene. This was not a big issue before
the sequencer scene was introduced, because the user would have
to create two main Blender windows to run into problems.
Now with the sequencer scene, it's possible to look at the scene
of a scene strip within the same window.
When the user is editing the scene (e.g. moving an animated object)
any open sequencer preview will cause the edits to be flushed.
This can e.g. result in visual jumping of animated objects, and more.
This PR attempts to fix the issue in a straightforward way: Use
a separate dependency graph for rendering the sequencer preview.
While this fixes the immediate issues, there are some consequences:
* The memory usage of the scene dependency graph _can_ roughly
double (since there are now likely two instances of the same
dependency graph). Because of implicit sharing, unmodified data
will not be copied. But for example modifiers on meshes would
currently create two copies of the evaluated data in the two
dependency graphs.
* Creating the dependency graph can be costly, which will cause the
first frame that the scene has to render to be slower.
Note: The current code changes some properties of the original scene
like the frame, subframe etc. before rendering and then restores
the original state. In theory, this part of the code can be removed,
but may be a bit too risky for just a fix. This should be improved
at a later stage.
Also resolves#146769, #139501.
Pull Request: https://projects.blender.org/blender/blender/pulls/147457
Partial revert of c03fdf5d9d, going back to previous versions of the
icons for hide_on (closed eye), restrict_select_on (unfilled mouse
cursor), and the combined versions (vis_sel_xx). These changes are a
bit too contentious to be added so late in the release. Note this
leaves in the changes to the lock icons.
Pull Request: https://projects.blender.org/blender/blender/pulls/147836
This speeds up drawing of the UI of the Geometry Nodes modifier, especially for
very large node trees like in the files from #146949.
A couple previous commits and #147883 speed up the inferencing significantly
already. However, there is a certain limit to how fast this can be on large
complex node trees. While there is some more optimization potential, this patch
implements a cache on the Geometry Nodes modifier level. This means that as long
as the inputs and the node tree stays the same, the inferencing only has to
happen once, instead of on every redraw.
The main difficulty with this cache is that we don't have a good way to
invalidate it eagerly when any of the modifier inputs changes. That can
hopefully become simpler with #138117. For now, we have to check all input
values on redraw to check if anything has changed compared to the last redraw
and recompute the cache if there is any change.
Pull Request: https://projects.blender.org/blender/blender/pulls/147930
The problem was that the Pen Tool would not set the `Resolution` attribute
and so when the `Resolution` attribute didn't exist, the newly added curve
would default to a value of 0, which would then lead to an Assert.
This problem would also effect `Curves` Objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/147673
Split the "Interpolation Line" theme property into three for each
interpolation mode, and use them accordingly. In the current theme
refactor, almost all theme properties of the dope sheet are getting
either removed (unused), or moved (shared). This decluttering opens up
the possibility to allow more theming, and let artists read the Dope
Sheet better.
## Avoiding Confusion
There's two "Bézier" interpolation types:
- Called "Bézier" in the interpolation type menu, and
- Called "Bézier" in the code, for the types that are labeled as
**"Easing" and "Dynamic"** in the interpolation type menu.
Since this commit is about the interpolation lines, which are **not**
drawn for the former, **this PR only covers Constant, Linear, and the
latter form of Bézier interpolation types.**
Pull Request: https://projects.blender.org/blender/blender/pulls/144255
This patch adds proper internal support for 2D vectors in GPU materials,
while previously it used a 3D vector with the Z component ignored as a
workaround. This has no user-facing consequences.
The type conversion file was split into an additional code generation
file for easier refactoring.
Pull Request: https://projects.blender.org/blender/blender/pulls/147983
This breaks tests (and the VR addon itself of course).
Needs to be done differently, will create new PR for proper fix.
This reverts commit 0c22ef5ae7.
This breaks tests (and the VR addon itself of course).
Needs to be done differently, will create new PR for proper fix.
This reverts commit 0c22ef5ae7.
When a Cycles render is uneven (E.g. a small portion of the image takes
significantly longer to render than the rest of the image), then GPUs
typically suffer from poor performance due to low occupancy unless a
large number of samples is scheduled to compensate for that small
complex region.
Due to how Cycles render scheduler is setup, Cycles tries to
increase GPU occupancy by increasing the number of scheduled samples,
but also balance render preview update time by scaling back
the number of scheduled samples based on the previous workloads time
per sample to try and fit within the target update time.
However using the previous workloads time per sample to scale back the
scheduled number of samples gives suboptimal results because the
previous workloads time per sample is usually not representative of the
new time per sample that occurs as GPU occupancy increases, because
increasing GPU occupancy typically results in reduced time per samples.
This commit improves on this issue by assuming that increasing GPU
occupancy linearly improves performance, and adjusts the function
that scales back the sample count to fit within a specific update
window to use this assumption. This leads to Cycles increasing the
amount of work scheduled onto the GPU quicker at the beginning of
uneven/low occupancy scenes, generally leading to improved performance,
especially when rendering at low sample counts or with strict
time limits.
Ref #147954
Pull Request: https://projects.blender.org/blender/blender/pulls/147950
Found when running with ASAN on through Xcode. Crashed on exit.
Multiple threads can release their own context at the same time
and thus release the `metal_layer_` multiple times, resulting
in use after free.
Pull Request: https://projects.blender.org/blender/blender/pulls/147972
Move the versioning code that switches the Timeline editor to Dope
Sheet from the 'first' to the 'after linking' versioning stage.
There was already versioning code that effectively turns the Dope
Sheet back into a Timeline, for pre-2.80 files, and this runs in the
'after linking' stage. The 5.0 versioning code now correctly runs
after this.
Fixes: #147742
Pull Request: https://projects.blender.org/blender/blender/pulls/147734
In the Viewport VR Preview, an unusual and complicated import
manipulates sys.path to import a class from a file that is already
importable anyway.
There is no documented reason for this, and the common way to subclass an RNA type in python is by using its `bpy.types....` registered class, _not_ by directly subclassing the python type used to declare/register the parent type.
Pull Request: https://projects.blender.org/blender/blender/pulls/147656
Only draw the Summary backdrop color when the Summary channel has been
expanded. This prevents the default used-to-be-timeline Dope Sheet
from showing a big red bar at the bottom of the window.
The channel box backdrop (when the channel bar is expanded) also
follows this, so when expanded it is red as before, and when collapsed
it is dark grey.
Pull Request: https://projects.blender.org/blender/blender/pulls/147708
Blender cannot handle bones with (near) zero length. Prior to this
commit such bones were deleted when exiting Armature Edit mode. Now
they are kept and elongated so that they are numerically stable (or at
least they should be, given the threshold to the length that was
already in place).
To avoid the elongation from impacting the position of child bones,
they are disconnected from the tiny bone.
Apart from that it's quite nice for users that Blender no longer
silently deletes bones, this is also useful for the USD importer, as
it can import bones and expect them to exist afterwards (see
#147048).
Note: this only impacts armatures with bones of length ≤ 0.000001
units.
Pull Request: https://projects.blender.org/blender/blender/pulls/147814
Add a command line option to load Blender without a window frame.
Currently this is only used on Wayland, enabled for WITH_UI_TESTS since
attempting to load LIBDECOR caused the tests to crash on start on Fedora.
For tests there is no need to use LIBDECOR, so disable the window frame.
This can also be used by users who don't want to use the X11 fallback if
LIBDECOR can't be found.
Ref !147716
Only draw the Summary backdrop color when the Summary channel has been
expanded. This prevents the default used-to-be-timeline Dope Sheet
from showing a big red bar at the bottom of the window.
The channel box backdrop (when the channel bar is expanded) also
follows this, so when expanded it is red as before, and when collapsed
it is dark grey.
Pull Request: https://projects.blender.org/blender/blender/pulls/147708
Rename modules in `./scripts/modules/` to use an underscore prefix to
make it clear they aren't intended to be part of public API's. This
also means there is no implication that these modules should be stable,
allowing us to change them based on Blender's internal usage.
The following modules have been marked as private:
- `animsys_refactor`
- `bl_console_utils`
- `bl_i18n_utils`
- `bl_previews_utils`
- `bl_rna_utils`
- `bl_text_utils`
- `bl_ui_utils`
- `bpy_restrict_state`
- `console_python`
- `console_shell`
- `graphviz_export`
- `keyingsets_utils`
- `rna_info`
- `rna_manual_reference`
- `rna_xml`
Note that we could further re-arrange these modules
(under `_bpy_internal` in some cases), this change is mainly to mark
them as private, further changes can be handed on a case-by-case basis.
Ref !147773
Since VSE HDR preview was implemented (18110744a2), the preview image
is put into RGBA 16F format "color texture", and the overlay
(checkerboard, grids etc.) is put into RGBA 8U format "overlay texture".
This was rendering the color image as NON premultiplied alpha in
the viewport color texture, which is not what happens in other places
(e.g. image space).
Later commit (c279d894db) fixed transparency of the overlay texture,
in order to make pure emissive (color non zero, alpha zero) colors
from EXR files show up in VSE preview. However that exposed the issue
that underlying color texture is not premultiplied.
Fix this by premultiplying the output color in gpu_shader_display_transform
that is used by VSE preview. This is done at the end of the shader
isntead of using fixed function blending, since premultiplication needs
to happen in a way that preserves pure-emissive colors.
Comparison images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/147892
