This will hopefully make it faster to start using the node editor.
The workspace also includes the spreadsheet. Note that while
existing startup files won't have this workspace added, it will be
in the list of options when clicking on the "add workspace" button.
Ref T86499
Some operations may use no preferredResolution ({0, 0}) when calling determineResolution on inputs to check if they have resolution on their own. See MixOperation or MathOperation determineResolution implementation. In such cases {0, 0} resolution ends up being set when an input doesn't have own resolution, breaking propagation of the original preferredResolution. They don't mean to set it as resolution, it's just a check.
This patch only allows to set valid resolutions (>0). When it's 0 it may be understood as "No preferred or determined resolution" so it should not be set to give output operations another chance of finding a proper resolution by calling determineResolution again with a different preferredResolution.
Test file:
{F9932526}
Reviewed By: #compositing, jbakker
Differential Revision: https://developer.blender.org/D10972
Currently viewers and previews only display node trees that have at least one node with fixed resolution size. When all inputs are generated, nothing is displayed in most cases (RGB Node is displayed as a single pixel on previews). By generated I mean inputs not having resolution on their own, they create content dynamically given an output resolution.
This patch adds support for those cases by using an appropriate preferred resolution on Viewers/Previews which propagates to generated inputs as output resolution. Now:
- Viewers will display generated inputs with scene render resolution.
- Previews will display them with scene aspect ratio.
This is consistent with final render result and respects relative space.
The benefit for the user is being able to compose images without any input source. For example for creating mask images or simple backgrounds.
Reviewed By: Jeroen Bakker
Differential Revision: https://developer.blender.org/D10611
This change shows the object or material name with the cursor when picking for a cryptomatte node.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D10705
Build proxies automatically when added to sequencer timeline and when
switching preview size.
This behavior can be disabled in user preferences.
Reviewed By: sergey, fsiddi
Differential Revision: https://developer.blender.org/D10363
The Blender/Cycles XYZ color space has a D65 white point instead of E, and
this was not correctly accounted for both in the OpenColor config reading code
and the bundled config.
This meant that since the OpenColorIO v2 upgrade, the Linear ACES color space
was not working correctly, and other OpenColorIO configs defining
aces_interchange were not interpreted correctly.
Auto frees cryptomatte session when it the pointer is collected from the
stack.
Reviewed By: Jacques Lucke
Differential Revision: https://developer.blender.org/D10667
This adds the initial boilerplate code that is required to introduce
the new spreadsheet editor. The editor is still hidden from the ui.
It can be made visible by undoing the change in `rna_screen.c`.
This patch does not contain any business logic for the spreadsheet editor.
Differential Revision: https://developer.blender.org/D10645
Ref T86279.
When opening the SVG you wouldn't even see the icons, since they are all white
now. You'd always have to set up a document background color and make sure to
undo that again before saving the file, so it's not written into it.
Just make everyone's life easier by saving the file with a proper background
(gray with checkerboard).
Inkscape often does a number of unrelated changes when saving an SVG, not sure
if these are just formatting changes in the source SVG text or if there's more
to it. Either way this makes adding new icons hard since you want to avoid
these unrelated changes. Saving the file in a new Inkscape version every once
in a while should mitigate the problem a bit.
Regenerating the icons (e.g. through `make icons`) shows no difference in the
output.
Note that I also ran "Clean Up Document" in Inkscape, but that doesn't seem to
have changed anything/much.
Using `make icons` for 420f538fad changed some icons that it shouldn't have
touched on my system. Not sure what caused this, maybe a bug in the slightly
outdated Inkscape version there (1.0.1). Here on macOS the version is only
reported as 1.0 so I'm not sure what the situation is. Either way, this fixes
the icons.
Sync the list of icons in CMakeLists.txt with UI_icons.h.
Restore, in the source file, the FUND icon that was accidentally
deleted.
Delete four old/unused icons.
See also D9715.
Ref T84819
Build System
============
This is an API breaking new version, and the updated code only builds with
OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated.
* Tinyxml was replaced with Expat, adding a new dependency.
* Yaml-cpp is now built as a dependency on Unix, as was already done on Windows.
* Removed currently unused LCMS code.
* Pystring remains built as part of OCIO itself, since it has no good build system.
* Linux and macOS check for the OpenColorIO verison, and disable it if too old.
Ref D10270
Processors and Transforms
=========================
CPU processors now need to be created to do CPU processing. These are cached
internally, but the cache lookup is not fast enough to execute per pixel or
texture sample, so for performance these are now also exposed in the C API.
The C API for transforms will no longer be needed afer all changes, so remove
it to simplify the API and fallback implementation.
Ref D10271
Display Transforms
==================
Needs a bit more manual work constructing the transform. LegacyViewingPipeline
could also have been used, but isn't really any simpler and since it's legacy
we better not rely on it.
We moved more logic into the opencolorio module, to simplify the API. There is
no need to wrap a dozen functions just to be able to do this in C rather than C++.
It's also tightly coupled to the GPU shader logic, and so should be in the same
module.
Ref D10271
GPU Display Shader
==================
To avoid baking exposure and gamma into the GLSL shader and requiring slow
recompiles when tweaking, we manually apply them in the shader. This leads
to some logic duplicaton between the CPU and GPU display processor, but it
seems unavoidable.
Caching was also changed. Previously this was done both on the imbuf and
opencolorio module levels. Now it's all done in the opencolorio module by
simply matching color space names. We no longer use cacheIDs from OpenColorIO
since computing them is expensive, and they are unlikely to match now that
more is baked into the shader code.
Shaders can now use multiple 2D textures, 3D textures and uniforms, rather
than a single 3D texture. So allocating and binding those adds some code.
Color space conversions for blending with overlays is now hardcoded in the
shader. This was using harcoded numbers anyway, if this every becomes a
general OpenColorIO transform it can be changed, but for now there is no
point to add code complexity.
Ref D10273
CIE XYZ
=======
We need standard CIE XYZ values for rendering effects like blackbody emission.
The relation to the scene linear role is based on OpenColorIO configuration.
In OpenColorIO 2.0 configs roles can no longer have the same name as color
spaces, which means our XYZ role and colorspace in the configuration give an
error.
Instead use the new standard aces_interchange role, which relates scene linear
to a known scene referred color space. Compatibility with the old XYZ role is
preserved, if the configuration file has no conflicting names.
Also includes a non-functional change to the configuraton file to use an
XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier
since the matrix is the same one we have in the code now and that is also
found easily in the ACES specs.
Ref D10274
Adds an exception so that the key-binding `control + Tab` does not get
duplicated as `command + Tab` on macOS because this is a global system
shortcut for the app switcher.
The key-binding `command + Tab` was shown for the operators “Toggle
Graph Editor“ and “Toggle Dope Sheet” in Dope Sheet and Graph Editor,
but only `control + Tab` actually worked.
Differential Revision: https://developer.blender.org/D10304
Before committing D10224, bundled preset names that are lowercase need
updating to title case for display in the UI. This changes several of
the preset file names to title case, and fixes a couple of other naming
issues in the preset names. A few strings in the code are also changed
to reflect the new filename of the Blender keymap.
The outline for the active modifier was abusing the property search
match theme color, as noted in a comment. This commit adds a new
theme color in RNA specifically for the active modifier outline.
Simplification and changes to the Navigation gizmo. Better indication of negative axes, consistent use of color and size to indicate orientation, ability to be resized.
Differential Revision: https://developer.blender.org/D9744
Reviewed by Campbell Barton
The green is still distinct from the more turquoise use for geometry, and
they are never used in the same node graph. The use of red makes sense, but
would need changes to other sockets and categories to set it apart well.
Ref T82689
Fixed an issue that was causing the app icon to render with a
'plated' background color in the taskbar and other areas of Windows.
Updated all app icons in Microsoft Store package to match Microsoft's
design recommendations.
Added multiple scales for app icons for high resolution displays.
Added high contrast app icons.
Reviewed By: pablovazquez, jmonteath
Maniphest Tasks: T79356
Differential Revision: https://developer.blender.org/D9681
None of these changes should be visible, but the files were somehow
out of sync with the blend file, so they need to be updated to reflect
those changes.
The command line syntax for Inkscape changed quite a bit for the 1.0 release,
see https://wiki.inkscape.org/wiki/index.php/Release_notes/1.0#Command_Line.
Think it's reasonable to expect Inkscape 1.0 or later be installed if you want
to generate the icons with the script. It's easy to get via the website, if the
distribution doesn't provide new enough packages. Only few people would use the
script anyway.
I also had to change the path for command line access on macOS which apparently
changed (https://stackoverflow.com/a/60068607). Although I didn't find a
mention of this change in the Inkscape release notes.
The issue can be simply resolved by moving the primitives and plus
icons slightly. They still bump up against the top and bottom of the
header but it looks much better now.
Parts of the tool icons for box, circle, lasso, and tweak select that were
meant to be flat or at a 45 degree angle were slightly misaligned, making
the edge look blurry.
Fix T83415: 3D View is red when using stereo
The red view was caused by SRGB not being enabled for an SRGB texture attached to the framebuffer.
Currently, when configuring a framebuffer, the first texture attachment needs to be an SRGB format in order for the framebuffer to be binded with SRGB enabled.
Thus, simply changing the SRGB texture attachment as the first texture attachment removes the red color in the view.
Reviewed By: #eevee_viewport, jbakker
Maniphest Tasks: T83415
Differential Revision: https://developer.blender.org/D9845
Remove 'U.wheellinescroll' preference, currently hidden and unused.
Differential Revision: https://developer.blender.org/D9616
Reviewed by Brecht Van Lommel
This is a workaround for T80804.
There's a startup crash that happens on 2.91.0 on Windows, an `EXCEPTION_ACCESS_VIOLATION`
on `atio6axx.dll`. It is triggered by `glClear` on the `detect_mip_render_workaround`
function. The workaround moves the function after the device/driver workaround section and
sets the flag to the affected one to avoid running the check.
It is deprecated hardware that has not meet the minimum requirements since 2.79, but is
still usable and this extends its usability a bit before the cards are finally blacklisted.
Reviewed By: Jeroen Bakker
Differential Revision: https://developer.blender.org/D9667
New layout for the 'About' dialog featuring the full version of the Blender logo.
Differential Revision: https://developer.blender.org/D9507
Reviewed by Hans Goudey
This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the
render pass tab and used in shader materials. Both Object and World based
shaders are supported. The AOV can be previewed in the viewport using the
renderpass selector in the shading popover.
AOV names that conflict with other AOVs are automatically corrected. AOV
conflicts with render passes get a warning icon. The reason behind this is that
changing render engines/passes can change the conflict, but you might not notice
it. Changing this automatically would also make the materials incorrect, so best
to leave this to the user.
**Implementation**
The patch adds a copies the AOV structures of Cycles into Blender. The goal is
that the Cycles will use Blenders AOV defintions. In the Blender kernel
(`layer.c`) the logic of these structures are implemented.
The GLSL shader of any GPUMaterial can hold multiple outputs (the main output
and the AOV outputs) based on the renderPassUBO the right output is selected.
This selection uses an hash that encodes the AOV structure. The full AOV needed
to be encoded when actually drawing the material pass as the AOV type changes
the behavior of the AOV. This isn't known yet when the GLSL is compiled.
**Future Developments**
* The AOV definitions in the render layer panel isn't shared with Cycles.
Cycles should be migrated to use the same viewlayer aovs. During a previous
attempt this failed as the AOV validation in cycles and in Blender have
implementation differences what made it crash when an aov name was invalid.
This could be fixed by extending the external render engine API.
* Add support to Cycles to render AOVs in the 3d viewport.
* Use a drop down list for selecting AOVs in the AOV Output node.
* Give user feedback when multiple AOV output nodes with the same AOV name
exists in the same shader.
* Fix viewing single channel images in the image editor [T83314]
* Reduce viewport render time by only render needed draw passes. [T83316]
Reviewed By: Brecht van Lommel, Clément Foucault
Differential Revision: https://developer.blender.org/D7010
During the development of the new nodes in the `geometry-nodes` branch
the color of the new nodes wasn't considered, so all of the nodes ended
up red, the color for "input" nodes. This patch introduces two new
colors, one for "Geometry" and one for "Attributes". There are only two
attribute nodes currently, but the next sprint will add two more,
attribute mix, and sample from texture. The attribute nodes are
conceptually different enough from the nodes that modify the geometry
that they deserve their own color.
Differential Revision: https://developer.blender.org/D9682
During revision of {D8952} one of the comments was to make a function that converts the render percentage to a factor. This to avoid code duplication. However the duplicated code was already all over the compositor code. So in order to avoid this code duplication for {D8952} I propose to first cleanup the duplicated code and build patch {D8952} based on this clean up.
The method that converts the render percentage to a factor is put in the CompositorContext. Why? The CompositorContext keeps DNA information like the renderdata. DNA, and thus the CompositorContext, keeps the size of the render resolution in percentage (user oriented). The compositor needs the size of the render resolution as a factor. So the CompositorContext seems like the obvious place to have this conversion method.
Why not in de NodeBase? The method could've been added to the nodebase, but I wanted to keep the nodebase as clean as possible and not put simple "conversion" methods into this base class. Also I didn't really like the call flow: you'd always have to get the renderdata size from the context and then convert.
Putting it in the CompositorContext avoids this extra invoke of a call.
Why not in the Converter? See nodebase. And the Converter seems more like a class for "structural" and complex node tree conversions. Not the simple conversions.
Reviewed By: Sergey Sharybin
Differential Revision: https://developer.blender.org/D9566
Previously, the alternate row color in the Video Sequence Editor was
just a shaded version of the editor's background color. This makes it
theme-able just like in the file browser and outliner, although the
default color is very slightly different.
Differential Revision: https://developer.blender.org/D9634
