Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
Those two functions had `BKE_` prefix, were defined in BKE headers, but
implemented in ED code, yuck.
Moved everything to ED area for now, since those do not look fondamental
enough to belong to BKE, and none of their usages requires it currently.
This is in order to disolve GPU_draw.h into more meaningful code blocks.
All the Image related function are in `image_gpu.c`.
All the MovieClip related function are in `movieclip.c`.
The IMB module now has a connection with GPU. This is not strickly
necessary and the code could be move to `image_gpu.c` if needed.
The Image garbage collection is also ported to `image_gpu.c`.
The report does not include any file, but probably that file is using the
settings for unified colors, which are currently not available in the UI,
so it always paints black. This enables unified colors and secondary
colors for sculpt vertex colors, so it should solve that issue.
Unified color does not make much sense now as the Paint tool is the only
one that has paint capabilities, but it will do in the future when
sculpt and paint at the same time is enabled and the paint capability is
added to more tools.
Reviewed By: sergey
Maniphest Tasks: T78323
Differential Revision: https://developer.blender.org/D8136
Mix up with imapaint.paintcursor & imapaint.paint.paint_cursor
Remove imapaint.paintcursor since it wasn't used.
Also rename paint_cursor_start_explicit() to paint_cursor_start(),
removing the existing paint_cursor_start() since it took the paint
struct from the context, a value that's known by all callers.
This caused an additional argument when exiting object modes
and many other low level functions which don't need to access context.
This simplifies fixing T77073.
A Colorband's CBData color **is not** considered `PROP_COLOR_GAMMA`.
A Brushes color **is** considered `PROP_COLOR_GAMMA`.
(PROP_COLOR_GAMMA is used for colors which would be color managed before
display, could be renamed to something better once...)
This leads to different rgb values in ColorBand.CBData of br->gradient
and brush->rgb for seemingly identical colors. (this is because color
pickers do differently in case block->is_color_gamma_picker/
ui_but_is_color_gamma)
Now it looks like `paint_brush_color_get` is expected to return a color
in sRGB (according to @jbakker this is for legacy reasons) so we need to
run the colorband colors through linear -> sRGB.
It might very well be the case that a much deeper cleanup in this area
is needed, this is just a fix to get gradient brush colors
consistent again...
Maniphest Tasks: T75985
Differential Revision: https://developer.blender.org/D7501
- The word 'Flip' is incorrect. 'Swap' or 'Switch' is correct.
- In Blender, we use 'primary' & 'secondary' color swatches, not 'foreground' and 'background'
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
Follow up of b2ee1770d4 and 10c2254d41, part of T74432.
Now the area and region naming conventions should be less confusing.
Mostly a careful batch rename but had to do few smaller fixes.
Also ran clang-format on affected files.
Caused by the introduction of UDIM (rBc30d6571bb47).
We need to make sure the tiles ImageUser is set up correctly [especially
the framenr], otherwise BKE_image_acquire_ibuf() and friends will fail
to find the correct ImBuf.
Also instead of initializing a minimal BKE_imageuser_default, now use
an appropriate ImageUser if avaliable and pass this around (instead of
just the tile_number). 2D painting can reuse the Image Editor ImageUser,
for 3D painting we still rely on a default ImageUser in most places, but
at least set the framenr correctly].
This also fixes crashes when doing image operations such as inverting or
resizing on images in a sequence in the Image Editor.
This also fixes color sampling (S) from the 3DView going wrong for image
sequences (would fallback to OpenGL sampling because an ImBuf could not
be found).
Maniphest Tasks: T74425
Differential Revision: https://developer.blender.org/D7022
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
The relation between the pressure/size and the pressure/alpha is a
fundamental property that defines the behavior of a brush, so it does
not make sense to have it unified across all brushes. This applies both
for sculpting and painting.
Some of the new 2.82 brushes need pressure/size or pressure/alpha to be
enabled to work propely, while others don't. Users should not be
switching on and off this property manually when changing brushes if they
want to use unified size. This is also causing that some users are using
the brushes with an incorrect configuration.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6291
This commit enables antialiasing in 2D painting.
It also includes some fixes related to line drawing in the stroke spacing code.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5833
There was a mix of old and new constants. Now have one list of WM_CURSOR_*
cursor types, using GHOST standard cursors when available and otherwise falling
back to our custom cursors.
Ref D5197
Particularly noticeable when vertex painting with a subsurf modifier.
In some cases every sculpt or paint stroke step would evaluate the dependency
graph. This should only happen for redraws. Now more selectively choose if the
dependency graph should be evaluated to initialize the view context. Doing it
in the view context evaluation is somewhat hidden, now it's more explicit.
Differential Revision: https://developer.blender.org/D5844
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
Cheap tip: anything that is not "Camel Case" and/or that is more than
a few words long should use `TIP_` translation, not `IFACE_` one.
Also added several missing strings (including the one reported in D5056
by Jean First (@robbott), thanks).
