The mask is expected to be always be displayed smooth, and the
option mainly existed for some legacy drivers. IF smooth drawing
causes issues it should be fixed in the drawing code, not as an
option in the interface.
Differential Revision: https://developer.blender.org/D15266
The camera frame (used for selection) was drawn outside the near
clipping plane in those cases.
This has been an issue before as seen in the following commits:
- rB6e7e6832e87
- rB33d322873e6
- rB4f9451c0442
Remaining issue was that the code which ensure the frame isn't behind
the near clipping plane was not taking into account the camera could be
scaled (in Z).
A caller of `BKE_camera_view_frame_ex` (namely
`OVERLAY_camera_cache_populate`) applies scale (also on the depth) which
does not play well with the way `BKE_camera_view_frame_ex` did it.
Now take Z scale into account.
Ref D15178
Selection of Python Console renders in front of the text.
Since the default theme uses a low opacity selection color,
it isn't obvious, but increasing alpha to 100% shows it clearly.
Ref D13111
In perspective mode the snap point direction needs to be taken into
account to define which side of the face is being looked at.
If there is no face under the mouse cursor, there is no direction
adjustment and the element normal will be used.
Since 7afcfe111a `startdisp` and `enddisp` fields are used as runtime
position storage for effect strips exclusively.
Use getter functon to return handle position and make properties read
only.
The `DEG_OB_COMP_TRANSFORM` and `DEG_OB_COMP_GEOMETRY` relations between
the **Domain** object and the **Flow**, **Effector** and **Force Field** objects
are added in the `updateDepsgraph` callback of the Fluid modifier, more
specifically in `DEG_add_collision_relations`.
The node linked to these components is the `POINT_CACHE` whose assigned
function is `BKE_ptcache_object_reset`.
So include the `eModifierType_Fluid` modifier in outdated cache checks.
Reviewed By: sergey, zeddb
Maniphest Tasks: T84369
Differential Revision: https://developer.blender.org/D15210
Use function `sequence_editor.display_stack(meta_strip)` to set
displayed timeline content.
To view top-level timeline, that does not belong to any meta strip, pass
`None` as argument.
Differential Revision: https://developer.blender.org/D12048
Variable frame rate (VFR) files have been difficult to work with.
This is because during sequential decoding, spacing between frames is
not always equal, but it was assumed to be equal. This can result in
movie getting out of sync with sound and difference between preview and
rendered image. A way to resolve these issues was to build and use
timecodes which is quite lengthy and resource intensive process. Such
issues are also difficult to communicate through UI because it is not
possible to predict if timecode usage would be needed.
With this patch, double buffer is used to keep previously decoded frame.
If current frame has PTS greater than what we are looking for, it is not
time to display it yet, and previous frame is displayed instead.
Each `AVFrame` has information about it's duration, so in theory double
buffering would not be needed, but in practice this information is
unreliable.
To ensure double buffer is always used, function
`ffmpeg_decode_video_frame_scan` is used for sequential decoding, even
if no scanning is expected.
This approach is similar to D6392, but this implementation does not
require seeking so it is much faster. Currently `AVFrame` is only
referenced, so no data is copied and therefore no overhead is added.
Note: There is one known issue where seeking fails even with double
buffering: Some files may seek too far in stream and miss requested
PTS. These require preseeking or greater negative subframe offset
Fixes: T86361, T72347
Reviewed By: zeddb, sergey
Differential Revision: https://developer.blender.org/D13583
It didn't make much sense to use the "Widget Label" font style here,
since this is just regular text, not labels for widgets. Checked with
@pablovazquez and we agreed on using the "Widget" font style instead.
Also fixes a mismatch where we used the "Widget Label" font style for
drawing, but the "Widget" font style for string width calculations.
Fixes T99207.
The fix is to ensure the filter for id type is run when displaying
assets from an Asset Library.
In the current implementation the id_type filter does not run if a blend
file is opened that also happens to be in an Asset Library directory. If
we have opened a blend file that is in an Asset Library directory, we
now use the same filtering check as for the "Current File" asset
library.
Differential Revision: https://developer.blender.org/D15284
Reviewed by: Julian Eisel
Changes to scrollbars so that they are always visible, but thin and
dim, and widen and become more visible as your mouse approaches.
See D6505 for details and examples.
Differential Revision: https://developer.blender.org/D6505
Reviewed by Campbell Barton
Clear delta transform value after applying transform.
Include delta location while applying transform.
Use `copy_v3_fl` for resetting object scale
Reviewed By: mano-wii
Maniphest Tasks: T99070
Differential Revision: https://developer.blender.org/D15270
Add support for Variable/Multiple Master font features. These are fonts
that contain a range of design variations along multiple axes. This
contains no client-facing options.
See D12977 for details and examples
Differential Revision: https://developer.blender.org/D12977
Reviewed by Brecht Van Lommel
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
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
