This fix makes it so the circular brush is fitted into the square
texture. This seems to be the most straightforward way to resolve
confusion of the inter-dependencies between different brush and
texture options.
Pull Request: https://projects.blender.org/blender/blender/pulls/110896
The hard eraser tool was not working properly when trying to erase closely to existing points, leading either to the insertion of various close points in the stroke, or to deleting a whole stroke segment.
This was due to the differenciation between the computation of the intersections between the eraser and the stroke, and the computation of whether a point lie inside the eraser, which lead to inconsistencies in the interpretation of the result.
This patch solves this issue by :
* computing if the point is inside the eraser based on the result of the intersection, to avoid unconsistencies,
* computing with integers and not float (we are in screen space anyways),
* adding the ability for source points to be cuts, and not only the inner intersections.
Pull Request: https://projects.blender.org/blender/blender/pulls/110801
Face set code modifies visibility of faces, then flushes those changes
to vertex and edge visibility. However, then it did an extra flush back
from vertices to faces and edges, which shouldn't be necessary.
Historically, the OCIO based color management implementation in Blender
had exceptions to treat specific configurations differently. It was a
compatibility with the legacy "No color management" option.
With time and more development in the area there are better ways of
achieving this goal, if needed.
This commit removes the named-based exception, which also solves confusion
about why certain similar configurations (from OCIO stand point) give
different results. As well as allows to create a cleaner plate for an
upcoming additions in the OCIO configuration such as AgX.
Quite simple and technical change which constant-folds the check for
whether the scene color management enabled or not with "true" value.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110580
Dynamic topology drawing can now use the smooth status saved in each
edge. Because of that, the "Smooth Shading" draw option is unnecessary
and just adds confusion because of inconsistency between dynamic
topology drawing and other modes.
Fixes#109191
Pull Request: https://projects.blender.org/blender/blender/pulls/110548
This change is needed for PAINT_OT_weight_sample_group to be accessed
from a menu.
Otherwise using the OPTYPE_DEPENDS_ON_CURSOR flag causes both the
initial activation and the selected vertex group to prompt the user
to select a region.
Exit the operator code if `DG_LOCK_WEIGHT` flag is set
for active vertex group to avoid painting over locked vertex
group. New function `BKE_object_defgroup_active_is_locked`
created to handle this.
Binding a key to weight-paint with mode set (invert/smooth for e.g.)
caused regular weight painting to reuse this setting.
Don't reuse paint "mode" between strokes.
This also allows the default to be removed from the key-map.
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
Utility functions make accessing the next and previous corner of a face
more obvious, and range based for loops make iterating over corners
or vertices in a face simpler too.
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
Implementation of the stroke mode of the eraser tool for grease pencil.
In this mode, the eraser removes each stroke that it touches, meaning each stroke that either intersects the eraser or that has all points inside of it.
Pull Request: https://projects.blender.org/blender/blender/pulls/110304
Implementation of the hard eraser for grease pencil.
The tool "cuts" the strokes, meaning it removes points that are inside the eraser's radius, while adding points at intersections between the eraser and the strokes.
Note that this does not implement the "Stroke" and "Dissolve" mode of the eraser yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/110063
It is possible to organize shape keys into a tree through the
reference key setting. Mesh editing and sculpting a reference
key is supposed to update all its children, but this was only
done for one level of dependencies.
This changes the code to retrieve the complete set of dependent
keys and update them all.
The paint code doesn't invoke `stroke->redraw`
on `INBETWEEN_MOUSEMOVE` events. This causes
drawing lag on devices that tends to generate
more of them, like pen tablets.
The code no longer does this. It does still exclude
inbetween events for updating the paint cursor.
I checked, and only the two paint modes (3d texture paint and image paint) actually
use `stroke->redraw`. Both are implemented to only draw when necessary:
* `paint_2d_redraw` checks for `.need_redraw` flag on tiles.
* `paint_proj_redraw` checks `ProjStrokeHandle.need_redraw`.
I believe this may be the cause of #93796
Pull Request: https://projects.blender.org/blender/blender/pulls/110119
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
Caused by 7a943428de
Looking at history, e.g. 575ade22d4 or prior, it seems the
"fallthrough" [related compiler warning was removed in 7a943428de] was
actually intended in the case of `VPAINT_TOOL_AVERAGE`.
So first, the average color is calculated and after that regular drawing
should happen with that color.
Now make this more clear by calling both `calculate_average_color` as
well as `vpaint_do_draw` before breaking.
Pull Request: https://projects.blender.org/blender/blender/pulls/109971
Many high-level functions with unrelated code were templated based on
the color attribute domain and type. In the end, those were just a few
branches though, similar to other branches. So to reduce binary bloat
and clarify code, move tempates to the point where separate types are
actually needed. Also move constant code out of loops, and use generic
arrays and spans to store some caches. The binary ended up 53 KB
smaller for me, which isn't much but it's in the right direction.
Performance wise nothing really changes. The vast majority of time in
vertex paint is spent on unrelated things like calculating normals or
uploading GPU buffers anyway.
The one ugly part I didn't account for when I started is the casting
between the "ColorGeometry" and "ColorPaint" types. I'm not sure that
this is correct, but it's just a more explicit version of what was
there already.
Pull Request: https://projects.blender.org/blender/blender/pulls/109941
We need setters and getters for these two very commonly accessed attributes of grease pencil.
The code is based on the implementation of `CurvesGeometry::positions()` and `CurvesGeometry::positions_for_write()`.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/109733
Word ordering for wmTimer API wasn't consistent.
- Use "WM_event_timer_" / "WM_event_timers_" prefix.
- Rename "wm_window_timer" to "wm_window_timers_process"
because it wasn't clear what the function did from its name.
- Rename "wm_window_process_events" to "wm_window_events_process"
for consistency with "wm_window_timers_process".
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Clay strips was using it's own brush local matrix,
which wasn't quite compatible with texture matrices.
This could lead to brush textures not lining up with
the stroke dabs.
There was also a bug where the stroke was starting
20 pixels into the stroke, which is much higher than
necassary to derive the initial rake angle.
Notes:
* The clay strips brush now uses SCULPT_cube_tip_init
to calculate the local brush matrix.
* SCULPT_cube_tip_init now accepts custom brush location
and radius arguments.
* The mouse sample preroll used to calculate initial brush
rotation angle is now smaller than the update interval.
* Clay strips now supports tip_scale_x, which has also
been added to DNA defaults.
The file is easier to read and change when less context is needed at
each step. Also extract some complex-looking flag testing into a
separate function, and move some constant checks out of loops.
* Renamed BKE_pbvh_raycast_project_ray_root to
BKE_pbvh_clip_ray_ortho for greater
clarity.
* BKE_pbvh_clip_ray_ortho no longer strictly clips
within the input ray interval. This is not necassary
for orthographic views and was too prone to floating
point error. The function is only called to clip
brush rays for orthographic views so this is acceptable.
This introduces an alias target `bf::intern::atomic` for
`bf_intern_atomic`. This has the following benefits:
- Any target name with `::` in it will be recognized as an actual
target by cmake, rather than a library name it may not know about.
and will be validated by cmake to exist. Which means if you make
a typo in the LIB section, CMake will error out telling you it
doesn't know about this specific target rather than passing it on
to the build system, where you'll either get build or linker errors
because of said typo.
- Given there is quite a cleanup still to do in the build system,
it won't always be obvious which targets have been updated to
modern targets and which still need to be done. Having a namespaced
target name is a good indicator there.
Pull Request: https://projects.blender.org/blender/blender/pulls/109784
Split much of BKE_pbvh.h into BKE_pbvh_api.hh.
BKE_pbvh.h is included by BKE_paint.h, which in
turn is included by large amounts of code including
RNA.
This makes it extremely difficult to change
or clean up the PBVH API, since each modification
of BKE_pbvh.h can take 20-30 minutes to compile,
even on a quad-core system with an SSD. This
commit fixes that by moving most of BKE_pbvh.h
into another file and just having the core,
external-facing interfaces in BKE_pbvh.h.
This utility counts the number of occurrences of each index in an array.
This is used for building mesh topology maps offsets, or for counting
the number of connected elements. Some users are geometry nodes,
the subdivision draw cache, and mesh to curve conversion.
See #109628
Renames `OB_MODE_EDIT_GPENCIL`, `OB_MODE_PAINT_GPENCIL`, `OB_MODE_SCULPT_GPENCIL`, `OB_MODE_WEIGHT_GPENCIL`, `OB_MODE_VERTEX_GPENCIL, and the context modes` to `*_LEGACY`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109648
Replace `typedef struct X {} X;` with `struct X {};`
In some cases the first and last name didn't match although this
is rarely useful, even a typo in some cases, e.g. TrachPathPoint.
The new drawing operator uses the `paint_stroke` API which didn't
know about grease pencil yet. This simple change causes the redraw
to happen on every(?) event, which did not happen before.
This moves the `stroke_cache` that was previously stored on every
drawing to the `GreasePencilRuntime` struct.
Since this cache is only used for when a user is drawing a stroke, there
can only ever be one. It makes more sense to have this cache on the
data-block runtime data, rather than every drawings runtime data.
Before this change the ImBuf struct had dedicated fields for the
buffer data. Now the color space is stored inside of the struct
which wraps around the buffer information.
This only changes the field placement, without changing the way
it is handled. In the future one might imagine that operations
like stealing buffer data should null-ify the buffer colorspace
pointer. Such changes would need to have more accurate thinking
before implementation.
Should be no functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/109291
Adds a new UI template to view the current layer tree of the active Grease Pencil object.
This UI tree view implements the following features (for now):
- Displaying all the layers with their names and highlighting the active layer.
- Changing the active layer by clicking on an item.
- Adding new layers (using a new operator).
- Removing the active layer (using a new operator).
- Renaming a layer.
Pull Request: https://projects.blender.org/blender/blender/pulls/109197
More consistently return geometry bounds with the `Bounds` type that
holds the min and max in one variable. This simplifies some code and
reduces the need to initialize separate min and max variables first.
Meshes now use the same `bounds_min_max()` function as curves and
point clouds, though the wrapper mesh isn't affected yet.
The motivation is to make some of the changes for #96968 simpler.
Store subdivision surface creases in two new named float attributes:
- `crease_vert`
- `crease_edge`
This is similar to 2a56403cb0.
The attributes are naming conventions, so their data type and domain
aren't enforced, and may be interpolated when necessary. Editing tools
and the subdivision surface modifier use the hard-coded name. It might
be best if these were edited as generic attributes in the future, but
in the meantime using generic attributes helps.
The attributes are visible in the list, which is how they're now meant
to be removed. They are now interchangeable with any tool that works
with the generic attribute system-- even tools like vertex paint can
affect creases now.
This is a breaking change. Forward compatibility isn't preserved for
versions before 3.6, and the `crease` property in RNA is removed in
favor of making a smaller API surface area with just the attribute API.
`Mesh.vertex_creases` and `Mesh.edge_creases` now just return the
matching attribute if possible, and are now implemented in Python.
New functions `*ensure` and `*remove` also replace the operators to
add and remove the layers for Python.
A few extrude node test files have to be updated because of different
(now generic) attribute interpolation behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/108089
The problem was that the attribute layers may not exist when the operator ran.
The fix is to use `lookup_or_add_for_write_span` instead of `lookup_for_write_span`.
Pull Request: https://projects.blender.org/blender/blender/pulls/108851
Face maps were added as a prototype of a new rigging solution during
2.8 development. Their storage is redundant with the newer generic
attribute system (specifically with integer face attributes), and
they were never used much. This commit removes the face map list
and converts the storage to an attribute with the name `face_maps`.
There is nowhere to store the face map names anymore, so those
are not kept.
It probably still makes sense to have a feature like mesh face gizmo
selection for rigging. But the design and implementation woulds likely
have to change significantly, including possibly changing the storage
type, and making use of the generic attribute system instead of a
special type.
See #105317 for more discussion.
The "Fill" message can be either a noun or a verb. This commit
disambiguates the verb usages for translation through various
translation contexts.
The more involved change is in the generation of keymaps from paint
modes. By default, the enums defining brush names are in the default
context, but this commit changes the ones including a "Fill" item to
"Brush". In order to get the same contexts in the keymap, we introduce
a specific function in `paint.cc` to return the appropriate context
depending on the tool.
Issue reported by Gabriel Gazzán (@GabrielGazzan) in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/108561
When adding a texture paint slot to an object, the object could have no
material, this patch handles that by checking the material first in
`default_paint_slot_color_get`, if material is null, then it will return a
fallback default color so the operator can proceed normally.
Pull Request: https://projects.blender.org/blender/blender/pulls/108592
Add loop selection identical to the behavior of ALT+Click in Edit Mode.
* ALT click: select loop
* ALT Shift click: add loop while retaining current selection
* ALT Shift Ctrl click: deselect loop
Pull Request: https://projects.blender.org/blender/blender/pulls/107653
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
This function replaced the evaluated mesh with a new one with the given
custom data type mask. That doesn't work in general anymore for a few
reasons: the increased dependence on named attributes (a opposed to
custom data types), and the "all or nothing" approach to reevaluating
the depsgraph. Other objects might depend on the object's evaluated
geometry, so it shouldn't just be replaced. Pushed a bit further, this could
give nice simplifications to mesh modifier evaluation.
There are two breaking changes, `bmesh_from_object` and BVH tree
`FromObject` require the source object to have a proper evaluated
mesh now.
If this causes a regression, it's likely that the object is missing
an update tag when a mode is entered that requires extra evaluated data.
Pull Request: https://projects.blender.org/blender/blender/pulls/106186
Adds the initial stage for the grease pencil 3.0 project.
This patch includes:
* New ID and new object type.
* New DNA structures.
* New drawing engine for grease pencil (gpencil-next).
* Tests for the new grease pencil data-type.
* A few operators for conversion, switching modes and (simple) drawing.
Exposed to the user:
* An experimental option to switch to the new grease pencil.
* This will switch the grease pencil render engine to gpencil-next which can only render the new object type.
Current grease pencil objects will no longer render.
* Changing this option currently requires a restart of blender (for the keymap to update).
* A conversion setting in the `Object` > `Convert To` operator.
* A drawing operator in `Draw Mode`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106848
Pass the curves and points to keep instead of delete. In the same test
file as the previous commit, this gave an increase from 50 to 60 FPS
when deleting curves.
In several nodes, and sculpt brushes, use the proper `IndexMask` type
instead of a span of ranges to encode a selection. This allows deleting
the duplicate data copying utilities using the second format.
Unify the handling of masks for affected curves in a few of the sculpt
brushes. In the grow shrink brush, replace a more custom "influences
per thread" solution. In the puff brush, use a full array of weights,
and build the mask earlier. In the snake hook brush, use the selection
properly (I observed a 2-3x improvement with a small selection).
Goals of this refactor:
* Reduce memory consumption of `IndexMask`. The old `IndexMask` uses an
`int64_t` for each index which is more than necessary in pretty much all
practical cases currently. Using `int32_t` might still become limiting
in the future in case we use this to index e.g. byte buffers larger than
a few gigabytes. We also don't want to template `IndexMask`, because
that would cause a split in the "ecosystem", or everything would have to
be implemented twice or templated.
* Allow for more multi-threading. The old `IndexMask` contains a single
array. This is generally good but has the problem that it is hard to fill
from multiple-threads when the final size is not known from the beginning.
This is commonly the case when e.g. converting an array of bool to an
index mask. Currently, this kind of code only runs on a single thread.
* Allow for efficient set operations like join, intersect and difference.
It should be possible to multi-thread those operations.
* It should be possible to iterate over an `IndexMask` very efficiently.
The most important part of that is to avoid all memory access when iterating
over continuous ranges. For some core nodes (e.g. math nodes), we generate
optimized code for the cases of irregular index masks and simple index ranges.
To achieve these goals, a few compromises had to made:
* Slicing of the mask (at specific indices) and random element access is
`O(log #indices)` now, but with a low constant factor. It should be possible
to split a mask into n approximately equally sized parts in `O(n)` though,
making the time per split `O(1)`.
* Using range-based for loops does not work well when iterating over a nested
data structure like the new `IndexMask`. Therefor, `foreach_*` functions with
callbacks have to be used. To avoid extra code complexity at the call site,
the `foreach_*` methods support multi-threading out of the box.
The new data structure splits an `IndexMask` into an arbitrary number of ordered
`IndexMaskSegment`. Each segment can contain at most `2^14 = 16384` indices. The
indices within a segment are stored as `int16_t`. Each segment has an additional
`int64_t` offset which allows storing arbitrary `int64_t` indices. This approach
has the main benefits that segments can be processed/constructed individually on
multiple threads without a serial bottleneck. Also it reduces the memory
requirements significantly.
For more details see comments in `BLI_index_mask.hh`.
I did a few tests to verify that the data structure generally improves
performance and does not cause regressions:
* Our field evaluation benchmarks take about as much as before. This is to be
expected because we already made sure that e.g. add node evaluation is
vectorized. The important thing here is to check that changes to the way we
iterate over the indices still allows for auto-vectorization.
* Memory usage by a mask is about 1/4 of what it was before in the average case.
That's mainly caused by the switch from `int64_t` to `int16_t` for indices.
In the worst case, the memory requirements can be larger when there are many
indices that are very far away. However, when they are far away from each other,
that indicates that there aren't many indices in total. In common cases, memory
usage can be way lower than 1/4 of before, because sub-ranges use static memory.
* For some more specific numbers I benchmarked `IndexMask::from_bools` in
`index_mask_from_selection` on 10.000.000 elements at various probabilities for
`true` at every index:
```
Probability Old New
0 4.6 ms 0.8 ms
0.001 5.1 ms 1.3 ms
0.2 8.4 ms 1.8 ms
0.5 15.3 ms 3.0 ms
0.8 20.1 ms 3.0 ms
0.999 25.1 ms 1.7 ms
1 13.5 ms 1.1 ms
```
Pull Request: https://projects.blender.org/blender/blender/pulls/104629
Combine the newer less efficient C++ implementations and the older
less convenient C functions. The maps now contain one large array of
indices, split into groups by a separate array of offset indices.
Though performance of creating the maps is relatively unchanged, the
new implementation uses 4 bytes less per source element than the C
maps, and 20 bytes less than the newer C++ functions (which also
had more overhead with larger N-gons). The usage syntax is simpler
than the C functions as well.
The reduced memory usage is helpful for when these maps are cached
in the near future. It will also allow sharing the offsets between
maps for different domains like vertex to corner and vertex to face.
A simple `GroupedSpan` class is introduced to make accessing the
topology maps much simpler. It combines offset indices and a separate
span, splitting it into chunks in an efficient way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107861
Covers the macro ARRAY_SIZE() and STRNCPY.
The problem this change is aimed to solve it to provide cross-platform
compiler-independent safe way pf ensuring that the functions are used
correctly.
The type safety was only ensured for GCC and only for C. The C++
language and Clang compiler would not have detected issues of passing
bare pointer to neither of those macros.
Now the STRNCPY() will only accept a bounded array as the destination
argument, on any compiler.
The ARRAY_SIZE as well, but there are a bit more complications to it
in terms of transparency of the change.
In one place the ARRAY_SIZE was used on float3 type. This worked in the
old code because the type implements subscript operator, and the type
consists of 3 floats. One would argue this is somewhat hidden/implicit
behavior, which better be avoided. So an in-lined value of 3 is used now
there.
Another place is the ARRAY_SIZE used to define a bounded array of the
size which matches bounded array which is a member of a struct. While
the ARRAY_SIZE provides proper size in this case, the compiler does not
believe that the value is known at compile time and errors out with a
message that construction of variable-size arrays is not supported.
Solved by converting the field to std::array<> and adding dedicated
utility to get size of std::array at compile time. There might be a
better way of achieving the same result, or maybe the approach is
fine and just need to find a better place for such utility.
Surely, more macro from the BLI_string.h can be covered with the C++
inlined functions, but need to start somewhere.
There are also quite some changes to ensure the C linkage is not
enforced by code which includes the headers.
Pull Request: https://projects.blender.org/blender/blender/pulls/108041
Many "UV island" style operations internally use #UvElementMap, including:
- Transform tools
- Smart-Stitch
- UV Pinch, UV Grab and UV Relax sculpt tools.
Normally, every UV in the mesh is included in the #UvElementMap.
However, with hidden geometry, only the visible geometry is included in the map. [0]
This change enforces stricter usage, reducing the chance of crashes in other areas.
Regression from [0] which was a fix for "UV Island calculation doesn't ignore hidden faces" [1].
[0]: 8f543a73ab
[1]: #99659
Pull Request: https://projects.blender.org/blender/blender/pulls/108130
Store bevel weights in two new named float attributes:
- `bevel_weight_vert`
- `bevel_weight_edge`
These attributes are naming conventions. Blender doesn't enforce
their data type or domain at all, but some editing features and
modifiers use the hard-coded name. Eventually those tools should
become more generic, but this is a simple change to allow more
flexibility in the meantime.
The largest user-visible changes are that the attributes populate the
attribute list, and are propagated by geometry nodes. The method of
removing this data is now the attribute list as well.
This is a breaking change. Forward compatibility is not preserved, and
the vertex and edge `bevel_weight` properties are removed. Python API
users are expected to use the attribute API to get and set the values.
Fixes#106949
Pull Request: https://projects.blender.org/blender/blender/pulls/108023
The goal is to make it more explicit and centralized operation to
assign and steal buffer data, with proper ownership tracking.
The buffers and ownership flags are wrapped into their dedicated
structures now.
There should be no functional changes currently, it is a preparation
for allowing implicit sharing of the ImBuf buffers. Additionally, in
the future it is possible to more buffer-specific information (such
as color space) next to the buffer data itself. It is also possible
to clean up the allocation flags (IB_rect, ...) to give them more
clear naming and not have stored in the ImBuf->flags as they are only
needed for allocation.
The most dangerous part of this change is the change of byte buffer
data from `int*` to `uint8_t*`. In a lot of cases the byte buffer was
cast to `uchar*`, so those casts are now gone. But some code is
operating on `int*` so now there are casts in there. In practice this
should be fine, since we only support 64bit platforms, so allocations
are aligned. The real things to watch out for here is the fact that
allocation and offsetting from the byte buffer now need an explicit 4
channel multiplier.
Once everything is C++ it will be possible to simplify public
functions even further.
Pull Request: https://projects.blender.org/blender/blender/pulls/107609
Using the topology map gives a constant time lookup, since it has a map
of nodes per type. The collada code used the old function, but had been
ifdef'd for four years, so it's removed here.
Two new messages are extracted:
- "New" in the context of paint curves. Used for the template_ID to
create a new curve;
- "PaintCurve", the default name of a newly-created paint curve.
Pull Request: https://projects.blender.org/blender/blender/pulls/107888
See: https://projects.blender.org/blender/blender/issues/103343
Changes:
1. Added `BKE_node.hh` file. New file includes old one.
2. Functions moved to new file. Redundant `(void)`, `struct` are removed.
3. All cpp includes replaced from `.h` on `.hh`.
4. Everything in `BKE_node.hh` is on `blender::bke` namespace.
5. All implementation functions moved in namespace.
6. Function names (`BKE_node_*`) changed to `blender::bke::node_*`.
7. `eNodeSizePreset` now is a class, with renamed items.
Pull Request: https://projects.blender.org/blender/blender/pulls/107790
For derived mesh triangulation information, currently the three face
corner indices are stored in the same struct as index of the mesh
polygon the triangle is part of. While those pieces of information are
often used together, they often aren't, and combining them prevents
the indices from being used with generic utilities. It also means that
1/3 more memory has to be written when recalculating the triangulation
after deforming the mesh, and that the entire triangle data has to be
read when only the polygon indices are needed.
This commit splits the polygon index into a separate cache on `Mesh`.
The triangulation data isn't saved to files, so this doesn't affect
.blend files at all.
In a simple test deforming a mesh with geometry nodes, the time used
to recalculate the triangulation reduced from 2.0 ms to 1.6 ms,
increasing overall FPS from 14.6 to 15.
Pull Request: https://projects.blender.org/blender/blender/pulls/106774
The fact that blenlib doesn't know about the set of attribute types is
actually an important detail right now that can influence how things
are designed. Longer term it would be good to consolidate many of
these attribute propagation algorithms anyway.
A regression since 2d2f4d9d28b: the sculpt session is re-used by the
weight paint, so changes to semantic in one place requires same
changes in another.
Before the change the `original` was intiialized to false (due to the
clear-alloc), but after the change it was the accum with an inverted
meaning which was initialized to false.
Pull Request: https://projects.blender.org/blender/blender/pulls/107533
Use bl_run_operators to detect cases when operators would crash
when run in an expected context for the following operators:
- GIZMOGROUP_OT_gizmo_select
- GIZMOGROUP_OT_gizmo_tweak
- GPENCIL_OT_time_segment_move
- OBJECT_OT_add_named
- OBJECT_OT_data_instance_add
- OBJECT_OT_drop_named_material
- SCULPT_OT_mask_by_color
- SEQUENCER_OT_delete
- SEQUENCER_OT_rename_channel
- SEQUENCER_OT_retiming_handle_move
- SPREADSHEET_OT_change_spreadsheet_data_source
- UI_OT_drop_color
Note that some of these situations users were unlikely to encounter,
however there were cases script authors could run into such as deleting
sequence strips without a region or masking by color without a 3D view.
Generally, one does not know if the sharing info is currently shared
and should therefore be const. Better keep it const almost all the
time and only remove the constness when absolutely necessary
and the code has checked that it is valid.
This patch adds several tools and options to the weight paint mode of Grease Pencil.
* Blur tool: smooths out vertex weights, by calculating a gaussian blur of adjacent vertices.
* Average tool: painting the average weight from all weights under the brush.
* Smear tool: smudges weights by grabbing the weights under the brush and 'dragging' them.
* With the + and - icons in the toolbar, the user can easily switch between adding and subtracting weight while drawing weights.
* With shortcut `D` you can toggle between these two.
* The auto-normalize options ensures that all bone-deforming vertex groups add up to 1.0 while weight painting.
* With `Ctrl-F` a radial control for weight is invoked (in addition to the radial controls for brush size and strength).
* With `Ctrl-RMB` the user can sample the weight. This sets the brush Weight from the weight under the cursor.
* When painting weights in vertex groups for bones, the user can quickly switch to another vertex group by clicking on a bone with `Ctrl-LMB`.
For this to work, follow these steps:
* Select the armature and switch to Pose Mode.
* Select your Grease Pencil object and switch immediately to Weight Paint Mode.
* Select a bone in the armature with `Ctrl-LMB`. The corresponding vertex group is automatically activated.
Pull Request: https://projects.blender.org/blender/blender/pulls/106663
The typical order is vertex, edge, face(polygon), corner(loop), but in
these three functions polys and loops were reversed. Also use more
typical "num" variable names rather than "len"
Add the ability to retrieve implicit sharing info directly from the
C++ attribute API, which simplifies memory usage and performance
optimizations making use of it. This commit uses the additions to
the API to avoid copies in a few places:
- The "rest_position" attribute in the mesh modifier stack
- Instance on Points node
- Instances to points node
- Mesh to points node
- Points to vertices node
Many files are affected because in order to include the new information
in the API's returned data, I had to switch a bunch of types from
`VArray` to `AttributeReader`. This generally makes sense anyway, since
it allows retrieving the domain, which wasn't possible before in some
cases. I overloaded the `*` deference operator for some syntactic sugar
to avoid the (very ugly) `.varray` that would be necessary otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/107059
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
Default settings changed for Sculpt mode's
Paint Brush, Smear Brush, and Smear Brush.
~~This includes updates of PR review #105691.~~
Updated to only include commits relevant to this PR.
Reviewed by: Joseph Eagar & Julian Kaspar
Pull Request: #105759
commit 7aa5e65dcbda862dcb17ecfc6727eb241a12c316
Merge: c08a9ec19f 7c9e493da55
Author: Joseph Eagar <joeedh@gmail.com>
Date: Sun Apr 16 15:11:53 2023 -0700
Merge branch 'main' of https://projects.blender.org/ChengduLittleA/blender into ChengduLittleA-main
commit 7c9e493da55a4adbfa2415b711e6d0daa2720ad9
Author: YimingWu <xp8110@outlook.com>
Date: Fri Mar 31 17:46:32 2023 +0800
Fix#106358: Handles null evaluated object when entering sculpting workspace.
The setup where everything in the scene is invisible/not enabled could
trigger a crash when switched to sculpting workspace, triggered when
opening the file.
This patch handles such situation.
Cleaned up sculpt code to store lists of `PBVHNodes` with
`blender::Vector` instead of simple pointer arrays. This is much
simpler and eliminates memory leaks caused by forgetting to free
the result of `BKE_pbvh_search_gather`.
Notes:
* `BKE_pbvh_search_gather` is now `blender::pbvh::search_gather`.
* `FilterCache` and `ExpandCache` have ownership over their .nodes
members; as a result they're no longer pure C structs and
are allocated with `MEM_new`/`MEM_delete`.
* The word 'totnode' no longer occurs anywhere in
`source/blender/editors/sculpt_paint`
Todo (not for this PR): create a new properly C++ task API for sculpt
(with lambdas) and use it for brushes.
Pull Request: https://projects.blender.org/blender/blender/pulls/106884
Similar to 7eee378ecc, this change decreases memory usage and
improves performance when copying curves and meshes without changing
their topology. The same change used for custom data layers is applied
to face and curve offset indices, which aren't stored as a custom data
layer.
The implicit sharing info for the offsets is stored in the mesh and
curve runtime structs, since it doesn't need to be written to files
directly. When changing the offsets pointer directly, the sharing info
must be updated accordingly. To make that easier, a few utility
functions take care of common operations like making an array mutable,
resizing an array, and creating sharing info for allocated data.
This commit also clarifies the intention to not allocate the offsets
at all when there are no curves/faces. That slightly complicates some
of the logic, but there's no reason for the single `0` integer to be
allocated.
Pull Request: https://projects.blender.org/blender/blender/pulls/106907
This integrates the new implicit-sharing system (from fbcddfcd68)
with `CustomData`. Now the potentially long arrays referenced by custom
data layers can be shared between different systems but most importantly
between different geometries. This makes e.g. copying a mesh much cheaper
because none of the attributes has to be copied. Only when an attribute
is modified does it have to be copied.
Also see the original design task: #95845.
This reduces memory and improves performance by avoiding unnecessary
data copies. For example, the used memory after loading a highly
subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25%
less which is the expected amount because in `main` there are 4 copies
of the data:
1. The original data which is allocated when the file is loaded.
2. The copy for the depsgraph allocated during depsgraph evaluation.
3. The copy for the undo system allocated when the first undo step is
created right after loading the file.
4. GPU buffers allocated for drawing.
This patch only gets rid of copy number 2 for the depsgraph. In theory
the other copies can be removed as part of follow up PRs as well though.
-----
The patch has three main components:
* Slightly modified `CustomData` API to make it work better with implicit
sharing:
* `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are
meaningless when implicit-sharing is used.
* `CD_ASSIGN` has been removed as well because it's not an allocation
type anyway. The functionality of using existing arrays as custom
data layers has not been removed though.
* This can still be done with `CustomData_add_layer_with_data` which
also has a new argument that allows passing in information about
whether the array is shared.
* `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It
only existed because of `CD_REFERENCE`.
* `CustomData_copy` and `CustomData_merge` have been split up into a
functions that do copy the actual attribute values and those that do
not. The latter functions now have the `_layout` suffix
(e.g. `CustomData_copy_layout`).
* Changes in `customdata.cc` to make it actually use implicit-sharing.
* Changes in various other files to adapt to the changes in `BKE_customdata.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106228
I cleaned up the cube brush tip code quite a bit; more remains
to be done. There is a new function to initialize cube
tip matrices, SCULPT_cube_tip_init. It's currently only
used by the paint brush, I'll need to do a bit of testing
before using it for clay strips and multiplane scrape.
Note: SCULPT_cube_tip_init uses the brush local matrix code
to avoid code duplication (and to take advantage of the debouncing
that is done there).
The existing utility cleared vertex group names and active attribute
names, which doesn't always make sense when the geometry is
replaced but the custom data layout remains mainly unchanged.
It was that names of related "combo" operations
like Hue/Saturation/Value, *Dilate/Erode*
and Brightness/Contrast should be separated
by slashes in their names.
This patch changes this for the multiple nodes
and operators concerning Hue/Saturation/Value
across Blender.
Note1: This patch should only touch UI names
which do not need versioning and should not
break scripts.
Note2: This breaks first letter fuzzy search
for "hsv". It was noted by @HooglyBoogly that
the "/" character needs to be added to the
fuzzy search split list. Note however that such
search is already broken in Main for nodes like
Brightness/Contrast and Dilate/Erode which
already use slash separators
Pull Request: https://projects.blender.org/blender/blender/pulls/106721
Since e3801a2bd4, we would always respect
hiding for vertex paint and weight paint (drawing code and stroke based
painting), leaving an inconsistency between the different paintmodes.
To rectify this, now also always respect edit mode hiding for projection
painting as well.
Some feedback was gathered in #sculpt-paint-texture-module to ensure
this is desired behavior.
Note: this does not change the (experimental) texture painting in
sculptmode [this already respects hiding via PBVH, albeit in a manner
that bleeds into hidden faces if the brush center is over visible faces]
ref #106354
Pull Request: https://projects.blender.org/blender/blender/pulls/106544
Implements #95967.
Currently the `MPoly` struct is 12 bytes, and stores the index of a
face's first corner and the number of corners/verts/edges. Polygons
and corners are always created in order by Blender, meaning each
face's corners will be after the previous face's corners. We can take
advantage of this fact and eliminate the redundancy in mesh face
storage by only storing a single integer corner offset for each face.
The size of the face is then encoded by the offset of the next face.
The size of a single integer is 4 bytes, so this reduces memory
usage by 3 times.
The same method is used for `CurvesGeometry`, so Blender already has
an abstraction to simplify using these offsets called `OffsetIndices`.
This class is used to easily retrieve a range of corner indices for
each face. This also gives the opportunity for sharing some logic with
curves.
Another benefit of the change is that the offsets and sizes stored in
`MPoly` can no longer disagree with each other. Storing faces in the
order of their corners can simplify some code too.
Face/polygon variables now use the `IndexRange` type, which comes with
quite a few utilities that can simplify code.
Some:
- The offset integer array has to be one longer than the face count to
avoid a branch for every face, which means the data is no longer part
of the mesh's `CustomData`.
- We lose the ability to "reference" an original mesh's offset array
until more reusable CoW from #104478 is committed. That will be added
in a separate commit.
- Since they aren't part of `CustomData`, poly offsets often have to be
copied manually.
- To simplify using `OffsetIndices` in many places, some functions and
structs in headers were moved to only compile in C++.
- All meshes created by Blender use the same order for faces and face
corners, but just in case, meshes with mismatched order are fixed by
versioning code.
- `MeshPolygon.totloop` is no longer editable in RNA. This API break is
necessary here unfortunately. It should be worth it in 3.6, since
that's the best way to allow loading meshes from 4.0, which is
important for an LTS version.
Pull Request: https://projects.blender.org/blender/blender/pulls/105938
Sergey Sharybin
Campbell Barton
Amelie Fondevilla
Hans Goudey
Germano Cavalcante
Falk David
Pratik Borhade
Ray molenkamp
Ray Molenkamp
Alexander Gavrilov
Joseph Eagar
Jacques Lucke
Philipp Oeser
Jeroen Bakker
Casey Bianco-Davis
Chris Blackbourn
Bastien Montagne
Damien Picard
Nathan Vegdahl
YimingWu
Christoph Lendenfeld
Iliya Katueshenock
Sietse Brouwer
Dalai Felinto
Henry Chang
Tianhui-Huang
zanqdo