Related to {D15885} that requires scene parameter
to be added in many places. To speed up the review process
the adding of the scene parameter was added in a separate
patch.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15930
This refactors the geometry nodes evaluation system. No changes for the
user are expected. At a high level the goals are:
* Support using geometry nodes outside of the geometry nodes modifier.
* Support using the evaluator infrastructure for other purposes like field evaluation.
* Support more nodes, especially when many of them are disabled behind switch nodes.
* Support doing preprocessing on node groups.
For more details see T98492.
There are fairly detailed comments in the code, but here is a high level overview
for how it works now:
* There is a new "lazy-function" system. It is similar in spirit to the multi-function
system but with different goals. Instead of optimizing throughput for highly
parallelizable work, this system is designed to compute only the data that is actually
necessary. What data is necessary can be determined dynamically during evaluation.
Many lazy-functions can be composed in a graph to form a new lazy-function, which can
again be used in a graph etc.
* Each geometry node group is converted into a lazy-function graph prior to evaluation.
To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are
no longer inlined into their parents.
Next steps for the evaluation system is to reduce the use of threads in some situations
to avoid overhead. Many small node groups don't benefit from multi-threading at all.
This is much easier to do now because not everything has to be inlined in one huge
node tree anymore.
Differential Revision: https://developer.blender.org/D15914
Minor adjustments to event icons required after recent font changes.
See D15582 for more details and examples.
Differential Revision: https://developer.blender.org/D15582
Reviewed by Brecht Van Lommel
Note that lib_override functions have kept the unused argument,
but this may be removed too. It impacts many lib_override functions
so this can be handled separately.
The only difference between `GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR`
and `GPU_SHADER_3D_LINE_DASHED_UNIFORM_COLOR` is that in the vertex
shader the 2D version uses `vec4(pos, 0.0, 1.0)` and the 3D version
uses `vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
The only real difference between `GPU_SHADER_2D_SMOOTH_COLOR` and
`GPU_SHADER_3D_SMOOTH_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_SMOOTH_COLOR' and '3D_SMOOTH_COLOR'
is 'SMOOTH_COLOR', but the old names still work for backward
compatibility.
The only real difference between `GPU_SHADER_2D_FLAT_COLOR` and
`GPU_SHADER_3D_FLAT_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_FLAT_COLOR'' and '3D_FLAT_COLOR'
is 'FLAT_COLOR', but the old names still work for backward
compatibility.
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
- Use the proper context (Operator, since that is what the cursor
keymap status uses)
- Add a few missing message extraction tags
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15867
Caused by {rB3f3d82cfe9ce}
Since above commit, a `uiRNACollectionSearch` may contain a NULL
`search_prop`, crashing the menu entry for "Jump To Target"
(`ui_jump_to_target_button_poll`).
Now safeguard against this with a NULL check (getting search callbacks
to work for "Jump To Target" can be investigated in master).
Maniphest Tasks: T100731
Differential Revision: https://developer.blender.org/D15832
Changes to the text caret (cursor) when editing Text objects in the
3D Viewport.
See D15797 for more details and examples.
Differential Revision: https://developer.blender.org/D15797
Reviewed by Brecht Van Lommel
While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
Those strings were at least partly disambiguated:
- Area
- Zone
- Measurement
- Ease
- BBone Ease In / Out
- Back
- Camera BG image depth
- GP interpolate sequence
- Edge Crease
- Theme
- Jitter
- Brush
- GPencil
- Lens distorsion compositing node
- Cineon color management
- Black
- Gamma
- White
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15791
Inconsistencies in update/tagging code between different code doing the
same 'Clear. liboverride operation lead to crashes in some cases.
Unify deg tagging and WM notifiers accross the three editor-level
codepaths performing the common Make/Reset/Clear operations.
Preserve if possible the active object accross Clear operation.
Several cleanup/rename/re-arangement of code to make it more consistent.
`UI_context_active_but_prop_get_templateID` became much more widely used
with recent rBfec254364884, which revealed that it did not do any check
on actual type of data it accesses, resulting easily in undefined
behavior.
Now also check the callback function pointer, this should be safe
enough.
Patch by @Severin (Julian Eisel), many thanks!
We only need to 'manually' remap RNA ID pointer property to the newly
created override if the owner itself was not already a local override.
Also some more minor tweaks to notifiers sent when creating the
override.
Assigning to RNA ID pointer properties will not _always_ trigger a
rebuild of the outliner tree, so try to enforce this when actually
creating overrides.
This introduces a new `UI_MT_button_context_menu` class which is
registered at startup. Addons can append/prepend draw functions to this
class, in order to add their custom context menu entries.
The new class replaces the old `WM_MT_button_context` class, thus
requiring a small change in addons using this feature. This is done
because addons were previously required to register the class
themselves, which caused addons to override each other's context menu
entries.
Now the class registration is handled by Blender, and addons need only
append their draw functions. The new class name ensures that addons
using the old method don't override menu entries made using the new
class.
Menu entries added with the legacy `WM_MT_button_context` class are
still drawn for backwards compatibility, but this class must not be used
going forward, as any addon using it still runs the risk of having its
menu entries overridden, and support for the legacy class is subject to
removal in a future version.
Reviewed By: campbellbarton
Maniphest Tasks: T100423
Differential Revision: https://developer.blender.org/D15702
Case where object was directly linked and not owned by a linked
collection was not properly handled, added some level of support for it
now.
Note that the behavior may not always be ideal in cases where the linked
object would be linked in many different local collecitons, hard to get
best solution always from this Editor given limited hierarchy data
available here.
The offending line was attempting to artificially add width to the
length of the string in order to "avoid ellipsing text that nearly
fits". The line doesn't actually appear to do anything beneficial, and
it causes the nasty text bug.
Old:
{F13029695}
New:
{F13327308}
Reviewed By: campbellbarton
Ref D15585
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
