No user visible change expected.
There's no good way to identify items from their base class which is
annoying for development/debugging. I ended up adding a helper like this
a few times, so makes sense to just add this to the API.
This is implemented as an overloaded function,
`assert_baklava_phase_1_invariants()`, with variants for `Action`, `Layer`, and
`Strip`.
The invariants asserted are those that are specific to phase 1 and which will
later be lifted as more features (such as animation layers, additional strip
types, etc.) are added. The intention is for this to serve as a kind of todo
marker for later phases *and* to help ensure that the phase-1 invariants
currently hold at runtime.
In addition to adding the overloaded function itself, this commit also uses it
in a couple of places in the keyframing code. Upcoming work on the keyframing
code will be using it more.
This is based on a discussion with @dr.sybren.
Pull Request: https://projects.blender.org/blender/blender/pulls/123830
The BLT_I18N_MSGID_MULTI_CTXT() macro allows extracting a single
message into up to 16 different contexts. The regex to do that was
slightly wrong because it did not account for the macro potentially
ending with a ",".
The contexts for "New" were also sorted.
Pull Request: https://projects.blender.org/blender/blender/pulls/123793
This is a follow up to #123022 to clean up the resultant verbose parameter
passing. We add a new struct `FCurveDescriptor` that contains the parameters
needed for either looking up or creating an fcurve, and that in turn is passed
down the keyframing call chains where fcurve lookup/creation needs to be done.
Pull Request: https://projects.blender.org/blender/blender/pulls/123486
On started Blender was scanning icons for PNG's to display in the theme menu
which hasn't been available since early 2.x days.
Also remove some other unused icon functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/123870
In the File Browser we sometimes show tiny icons at the bottom-left of
items. This PR draws these using the shader's outline mode rather than
overprinting them twice.
Pull Request: https://projects.blender.org/blender/blender/pulls/123865
This implements a von-Kries-style chromatic adaption using the Bradford matrix.
The adaption is performed in scene linear space in the OCIO GLSL shader, with
the matrix being computed on the host.
The parameters specify the white point of the input, which is to be mapped to
the white point of the scene linear space. The main parameter is temperature,
specified in Kelvin, which defines the blackbody spectrum that is used as the
input white point. Additionally, a tint parameter can be used to shift the
white point away from pure blackbody spectra (e.g. to match a D illuminant).
The defaults are set to match D65 so there is no immediate color shift when
enabling the option. Tint = 10 is needed since the D-series illuminants aren't
perfect blackbody emitters.
As an alternative to manually specifying the values, there's also a color
picker. When a color is selected, temperature and tint are set such that this
color ends up being balanced to white.
This only works if the color is close enough to a blackbody emitter -
specifically, for tint values within +-150. Beyond this, there can be ambiguity
in the representation.
Currently, in this case, the input is just ignored and temperature/tint aren't
changed. Ideally, we'd eventually give UI feedback for this.
Presets are supported, and all the CIE standard illuminants are included.
One part that I'm not quite happy with is that the tint parameter starts to
give weird results at moderate values when the temperature is low.
The reason for this can be seen here:
https://commons.wikimedia.org/wiki/File:Planckian-locus.png
Tint is moving along the isotherm lines (with the plot corresponding to +-150),
but below 4000K some of that range is outside of the gamut. Not much can
be done there, other than possibly clipping those values...
Adding support for this to the compositor should be quite easy and is planned
as a next step.
Pull Request: https://projects.blender.org/blender/blender/pulls/123278
Icons can have contrasting outlines, but currently this can only happen
for some icons and when the theme setting "Icon Border" is greater than
zero. This change shows them in the same situations but also allows
them to be shown when needed. For special situations like having an
icon overlay on an icon, or for the icons in the corners of File
Browser preview items, etc. In a nutshell this allows UI_icon_draw_ex
to honor its outline argument, rather than ignoring it unless the theme
setting was also set.
Pull Request: https://projects.blender.org/blender/blender/pulls/123863
The `create_liquid_geometry` still used the older attributes
API to write the velocities.
This replaces the use of `BKE_attribute_new` with
the newer attribute API.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123854
It is possible that the file does not have Grease Pencil paint
yet, leading to a crash in the BKE_paint_init().
The simple fix is to swap the order of acquiring the paint
pointer and the code which ensures that this paint exists.
The issue was introduced with f06fd85d97 where the building of the keylist used was
restricted to the visible range of the dope sheet.
The optimization uses `BKE_fcurve_bezt_binarysearch_index` which can only work when
the FCurve is sorted. During transformations in the dope sheet this is not the case as the
sorting only happens when the transformation is applied.
The fix is to do a range check in the for loop instead of a binary search.
Testing the range comes with a performance impact though.
| Before optimization | broken with f06fd85d97 | this PR |
| - | - | - |
| 90ms | 6ms | 20ms |
An alternative solution would be to sort FCurves during transformations of the Dope Sheet.
This is done in the Graph Editor and with the recent speedups introduced there this could be
a viable option. However this is out of scope for this fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/123824
When a buffer resource was read, and after that read from another
shader stage it would not generate the appropriate pipeline barrier.
This is fixed by keeping the last write action around and check
if the shader stage was already included in the previous barriers.
Pull Request: https://projects.blender.org/blender/blender/pulls/123845
The `Stick` drawing mode for armatures was overriding the colors,
meaning it ignored bone colors specified by the user and also didn't use
the correct color for selected vs active.
Pull Request: https://projects.blender.org/blender/blender/pulls/123544
The "verts per grid" calculation was wrong for the non-flat/indexed
vertex buffer layout used for smooth shading. For example, for a
multires subdivision level of 8, each PBVH node's vertex buffers
were 3 times larger than they needed to be.
Pull Request: https://projects.blender.org/blender/blender/pulls/123808
Combined with previous logic, this roughly doubles the performance of
sculpt-mode multires draw vertex buffer extraction in my simple test.
That measurement is for when we initially enter sculpt mode when the
VBO creation is single threaded. Otherwise in my testing the copying
was bound by memory bandwidth and the improvement was smaller.
Draw Manager visibility compute shader triggered a read-after-write
hazard. This root cause was that the incorrect access was read from
the shader interface. It was set to none, skipping the needed pipeline
barrier.
Pull Request: https://projects.blender.org/blender/blender/pulls/123839
This was due to wrong indexing into `num_triangles_per_stroke` and
`num_vertices_per_stroke`. We were using the the index of the stroke
in the drawing instead of the index into the `visible_strokes` mask.
Clarify the tooltip for the half float color depth property for EXR
images to indicate that it doesn't affected data passes and that they
will still be saved as full float.
