It was unclear when the bone eyedropper could be used
since it stayed active even though it would be impossible to pick something.
The limitation is that an armature has to be in pose or edit mode to pick from.
Since that is the case we can check in the poll function if the active
object is an armature and if that armature is either in pose or edit mode.
Follow up to: #138182
Pull Request: https://projects.blender.org/blender/blender/pulls/138498
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
When mouse is moved from one area to other of same spacetype, previous
region is not redrawn. This results in tooltip being stuck at the edge of
previous area. In such case, send a redraw call to that region.
Pull Request: https://projects.blender.org/blender/blender/pulls/136168
Callbacks: exec invoke & modal now use a typed enum wmOperatorStatus.
This helps avoid mistakes returning incompatible booleans or other
values which don't make sense for operators to return.
It also makes it more obvious functions in the WM API are intended
to be used to calculate return values for operator callbacks.
Operator enums have been moved into DNA_windowmanager_enums.h
so this can be used in other headers without loading other includes
indirectly.
No functional changes expected.
Ref !136227
The UI code assumed buttons had no more than 4 elements
however Python scripts may define larger array sizes.
Resolve the bug by adding functions for array access that take an
array size limit to prevent buffer overflows (read & write).
Note that this only adds the "float" versions of these functions,
for completeness int & boolean can be supported as a separate commit.
When displaying keymaps on the Status Bar we prefer to show Confirm and
then Cancel. We have a few places where these are reversed
accidentally. This just makes these consistent with the rest.
Pull Request: https://projects.blender.org/blender/blender/pulls/133947
On Mac we can now pick colors from outside Blender windows, but this
requires pressing the "Enter" key. This PR just changes the status bar
so that on Mac OS it shows this information to the user.
Pull Request: https://projects.blender.org/blender/blender/pulls/133120
Have `eyedropper_color_sample_fl` return success, in case platform
sampling starts but is canceled (Async return on MacOS). Removes any
chance of returning black color on failures.
Pull Request: https://projects.blender.org/blender/blender/pulls/133124
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
Restore overlay depth drawing which was removed in [0].
For viewport navigation this is useful. Disable overlays
for other operations such as painting & object placement.
Also disable color drawing in the overlay_next engine drawing
when drawing depth, since it caused the viewport to show a
checkered backdrop.
Details:
A boolean argument has been added to ED_view3d_depth_override instead
of new enums in eV3DDepthOverrideMode since mixing object-filtering
and draw-type in the one enum gets verbose & awkward, where most
existing enums would have needed to include NO_OVERLAY in their name.
V3D_DEPTH_NO_OVERLAYS has been renamed to V3D_DEPTH_ALL,
the caller must pass in use_overlay as false.
[0]: 5fea1eda36
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
Blender crashes when picking Cryptomatte while rendering. This is
because pass data are not yet allocated. To fix this, we just fail the
picking until data becomes available.
Part of the brush assets project followups, see #116337.
Based on feedback, it seems important to indicate to the user when a brush has
unsaved changes.
There's no reliable updating mechanism we can use or hook into here, except for
RNA "update" callbacks. Brush data gets changed in many places in code, the only
way to do this seems manual tagging every time a brush property gets changed.
This PR introduces `BKE_brush_tag_unsaved_changes()` for this. I spent some time
going through all brush properties to ensure changes call the tagging function.
A known limitation with this will be that changes to dependencies won't be
indicated in the brush. E.g. Changing the texture attached to a brush won't make
the brush be indicated as changed.
The UI to indicate the changed brushes is being discussed still, see #128846.
Pull Request: https://projects.blender.org/blender/blender/pulls/128845
Removes unused GPv2 functions in blenkernel.
Notes:
- Functions for layer masks are still in use, but annotations never
have layer masks in the first place. Would be good to remove the data
structures so we can remove the functions too.
- Some multi-frame edit functions are also still nominally used, but
multi-frame editing is not an active feature for annotations. This
should also be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/128709
This adds an eyedropper button to properties where you can choose a bone.
Clicking it activates the modal operation and you can pick:
* Bones from the Outliner
* Bones from the 3D Viewport if the Armature is in Pose Mode or Edit Mode
## Limitation
Picking from the 3D viewport while in Object Mode doesn't work due to technical reasons.
The selection buffer is only filled with pose bones if the armature is in pose mode.
Using the picker while in object mode gives you the Armature object, not its bones.
So you cannot use the bone picker to constrain an object to a bone.
UNLESS you pin the panel with the object, go to pose mode and then pick.
There is a warning printed for those cases to tell the user why this hasn't worked.
Pull Request: https://projects.blender.org/blender/blender/pulls/121523
Only paint code and brush management code should access this member
directly. Normal code should just use the getter.
Case in point, !125449 might make the querying of the active brush more
involved, so the getter should definitely be used to avoid accessing the
wrong brush.
This adds the Eyedropper tool to GPv3.
A few changes have been made:
- Added `Brush` mode.
- Set active color in palette.
- Show the palette in the UI.
- Add UI for setting material mode.
- Drag for color accumulation.
Pull Request: https://projects.blender.org/blender/blender/pulls/126211
The issue here is that copying the GPU viewport back to the CPU is an expensive
operation, so doing it for every frame when dragging the eyedropper is not ideal.
Instead, copy it once at the start and keep reading from it until the user
releases the eyedropper.
Pull Request: https://projects.blender.org/blender/blender/pulls/126072
Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
Clang (at least on OSX) has optimization issues with the pointer
version, which seem to be 'fixed' by using references.
Note that using references here is not a bad thing anyway (none of these
pointers would ever be expected to be NULL).
Pull Request: https://projects.blender.org/blender/blender/pulls/124883
Cryptomatte layer initialization required the active scene to update the
image user frame, but the image user is already updated through other
mechanisms and is thus redundant to do at draw time, so we remove the
frame update call as well as the scene argument from the call chain. The
frame number of the image user is ignored at compositing time in any
case since it is set to the compositing scene frame.
This is needed for #124738.
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
Previous code would declare properties as `extern PropertyRNA`, but
implement them as type-refined data (e.g. `FloatPropertyRNA`).
This is fully illegal thing, it happened to work 'fine' so far for two
main reasons:
* C-linking does not do type-checks on extern data.
* Code using these publicly exposed data would always use them as
`PorpertyRNA *` pointers, and pass them to RNA API.
However, this (finally !) breaks when trying to move generated
`RNA_property.h` header to C++, since at least MSVC2022 does mangle the
type in the extern'ed symbol name, which makes linking fails epically.
This commit fixes the issue by only declaring `PointerRNA *` pointers in
the headers. These pointers are then defined in each implementation file
(the `rna_xxx_gen.cc` ones), and assinged to the address of a matching
local static variable. These static variables are type-refined, and
actually contain the property definition data.
Pull Request: https://projects.blender.org/blender/blender/pulls/124603
This patch supports the Cryptomatte picker in the 3D viewport. Instead
of picking a color from the viewport GPU texture, we instead sample the
scene directly to get the object or material under the cursor, then hash
their names to get the Cryptomatte hash value. We do this because the
viewport texture have limited precision, so it can't store the
Cryptomatte hash values.
Additionally, we adjust the Cryptomatte session code to extract the
Cryptomatte manifest from the scene directly, as opposed to the
RenderResult. This is done to make it work even when no RenderResult
exist, as is the case for the viewport compositor, which is needed
especially after #123378.
Pull Request: https://projects.blender.org/blender/blender/pulls/123815
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
Currently, when color-picking from the viewport, the code will read the final
displayed pixel color and then somewhat attempt to undo the display transform.
However, this has several limitations - for example, precision is limited to 8
bit, and it does not account for e.g. View Transform or exposure/gamma.
Since we have the pre-display-transform color in a GPU texture anyways, this
code therefore adds a View3D-specific eyedropper handler (similar to e.g.
the image space) that reads from the viewport texture.
Pull Request: https://projects.blender.org/blender/blender/pulls/123408
