MTLFrameBuffer has been implemented to support creation of RenderCommandEncoders, along with supporting functionality in the Metal Context.
Optimisation stubs for GPU_framebuffer_bind_ext has been added, which enables specific assignment of attachment load-store ops at the bind level, rather than on a framebuffer object as a whole.
Begin and end frame markers are used to encapsulate frame boundaries for explicit workload submission. This is required for explicit APIs where implicit flushing of work does not occur.
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D15027
Add WITH_GHOST_WAYLAND_DBUS option, so Blender can be built without
DBUS support. Currently it's only used to access the cursor theme.
Without this the "default" cursors are used instead.
Disabling this since it adds an additional dependency for a minor gain
in functionality, with the benefit of removing a library requirement.
There is also a problem where Blender hangs on startup for ~5 seconds
when DBUS isn't running. Eventually it would be good to be able to avoid
this problem without a build option.
For Wayland the mouse & tablet are separate devices with their
own location, button-pressed state and focused window.
Split internal state storage so they're separate.
Also track mouse button press/release state without needing focused
windows.
This potentially overallocates buffers so that they are usable
for more data types, which allows buffers to be reused more
easily. That leads to fewer separate allocations and improved
cache usage (in one of my test files the number of separate
allocations went down from 1826 to 1555).
This commits reduces the number of function calls through function
pointers in `blender::Any` when the stored type is trivial.
Furthermore, this implements marks some classes as trivial, which
we know are trivial but the compiler does not (the standard currently
says that any class with a virtual destructor is non-trivial). Under some
circumstances we know that final child classes are trivial though.
This allows for some optimizations.
Also see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1077r0.html.
The issue was that the "radius" lookup below fails, because there is no
curve data. Arguably, it should be possible to add attributes even when
there is no data. However, the rules for that are a bit loose currently.
A simple fix is to just not run the conversion code when there is nothing
to convert.
As described in T98943, this commit adds a node that can
evaluate a field on a separate domain in a larger field context.
This is potentially useful in many cases, to avoid relying on
a separate capture attribute node, which can make it easier
to build reusable fields that don't need geometry inputs.
Internally, the node just evaluates the input field in the larger
field context and then uses the generic domain interpolation,
so the code is simple. One future optimization might be using
the input selection to only evaluate part of the input field, but
then the selection has to be interpolated as well, and that might
not always be worth it.
Differential Revision: https://developer.blender.org/D15289
Currently when converting from the legacy curve type to the new type,
which happens during evaluation of every legacy curve object, the
`CurveEval` type is used as an intermediate step. This involves
copying all data twice, and allocating a bunch of temporary arrays.
It's also another use of `CurveEval` that has to be removed before
we remove the type.
The main user difference besides the subtlety described below
will be improved performance.
**Invalid Handles and Types**
One important note is that there are two cases (that I know of)
where handles and handle types can be invalid in the old curve
type. The first is animation, where animated handle positions don't
necessary respect the types. The second is control points with a
single aligned handle that didn't necessarily align with the other.
In master (partially on purpose) the code corrects the first situation
(which caused T98965). But it doesn't correct the second situation.
It's trivial to correct for the second case with this patch (because of the
eager calculation decided on in D14464), but this patch makes the choice
not to correct for //either//.
Though not correcting the handle types puts curves in an invalid state,
it also adds flexibility by allowing that option. Users must understand
that any deformation may correct invalid handles.
Fixes T98965
Differential Revision: https://developer.blender.org/D15290
This reduces the amount of code, and improves performance a bit by
doing more with less virtual method calls.
Differential Revision: https://developer.blender.org/D15293
This node takes a point count,a vector field, and float field and creates
a pointcloud with n points at the positions indicated in the vector
field with the radii specified in the float field.The node is placed in
the "Point" menu.
Differential Revision: https://developer.blender.org/D13920
Maniphest Task: https://developer.blender.org/T93044
Mistake in 54182e4925de4ee. The dirty flag was always cleared,
but we only want to clear it after translating a mesh if it normals
were already non-dirty.
It was looking up the last modifier in the stack, ignoring visibility, instead
of mesh->runtime.subsurf_runtime_data set by the modifier evaluation and used by
the drawing code.
If there is an error we should stop rendering, instead of finishing with a
wrong render result or reporting a wrong benchmark time.
Ref T96519
Differential Revision: https://developer.blender.org/D15287
This implements client-side window decorations for moving and resizing
windows and HiDPI support.
This functionality depends on the external project 'libdecor' that is
currently a build option: WITH_GHOST_WAYLAND_LIBDECOR.
Reviewed by: brecht, campbellbarton
Ref D7989
In the cases where length is zero, we simply equally distribute the
value based on the control point/curve index.
Differential Revision: https://developer.blender.org/D15285
Manta flow used the `__main__` namespace which it was executed in,
this caused a bug when calculating fluid from Python, which clears
it's `__main__` name-space after execution.
This caused Manta-flows name space to be cleared too.
Resolve this by creating a separate name-space for manta-flow.
Reviewed by: SonnyCampbell_Unity
Ref D15269
Before [0] mouse-motion events left the 'event.value' un-changed,
so a mouse-move would be set to PRESS/RELEASE based on previous events.
Support accessing the previous event value directly
to address feedback from T99102.
Note that the previous cursor location is already exposed.
[0]: 52af3b20d45ea525a0ce66b2613ac132c9032a3f
This reverts commit c503c5f756aab850e8afe2513b2dc7b645cf84af,
alternate fix for T82244.
Scripts that run in background mode expected rotation to be usable,
defaulting to the 3D viewport when there is no active windowing data.
Also resolves T88610.
When running the render test cases on MacOS/Intel the hair render
test fail. Most likely due to the dense geometry and the low
resolution of the test image.
This patch increases the fail threshold so these tests will pass.
Note that I haven't been able to test whether this is also the case
for Linux/Windows. If that is the case we should remove the platform
specific test.
Makes the current test cases pass on NVIDIA 1080Ti/515.
The tests still fail on other platforms (AMD, Intel). Some are actual failures.
Other require platform specific reference images.
Original patch provided by Brecht van Lommel.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D15264
When using the old particle hair with the hair info length it wasn't
working with AMD GPUs. The reason was that the drw_curves uniform buffer
wasn't initialized what made the shader select the incorrect length.
Commit 277fa2f441f4 added channels region to unintended editors if sequencer was
used in area. This caused issues with some editors having 2 tool regions and
non functioning side panel.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D15253
As grab already uses it's own virtual coordinates, cursor warping can
be used when grab is enabled.
Currently nothing depends on this however it could be useful in future.
Walk mode implemented it's own grab which relied on WM_cursor_warp
to work (which isn't implemented for wayland).
Resolve this by using WM_cursor_grab_{enable/disable}.
Besides fixing Wayland this removes the need for workarounds:
- Ensure the event received were after the event generated from warping.
- Alternate logic that reset the "center" when using tablets.
- Checking the cursor location was scaled by native-pixels on macOS.
There is a minor change in behavior: on completion the cursor is left
at the location walk-mode began instead of the center of the region.
