Before 9f78530d80, the -1 coarse_edge_index values in the
foreach_edge calls would return false in BLI_BITMAP_TEST_BOOL,
which made them look like loose edges. BitSpan doesn't have this
problem, so the return for negative indices must be explicit.
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
Finish the transition from #95966 and fe38715600 by
writing files with the new format for meshes and some movie clip fields.
This removes overhead when saving files, and makes meshes saved in
files smaller (a file with a 1 million face grid changed from 32 to 28 MB).
3.6 can still read files saved with this format, but older versions will
crash. Older files are automatically converted by versioning code when
opened.
This also allows removing all the code that converts from the new
format to the legacy format, previously used when saving files.
Pull Request: https://projects.blender.org/blender/blender/pulls/108015
The usage of the lib pointer was cryptic to say the least, it was
essentialy used to allow or not local IDs results in the mapping
old_id_pointer -> new_id_pointer lookup result.
Now:
- Explicitely pass a boolean to allow or not local ID as result in
lower-level code.
- Pass the 'self ID' pointer instead of its library to the whole
liblinking code (that was already the case in a few places).
Note that naming of the 'self id' pointer is currently very inconsistent
throughout the readfile liblink code, this will have to be cleaned up in
a separate step later. For now, `self_id` has been chosen for new code
as it matches the terminology in lib_query code.
The later change can also allow finer handling of lookup on undo, based
on how it was re-read (or not), should the need for this arise.
This function handles cleaning valid system paths that are functional
when passed to `open(..)` but may be relative to the current working
directory or have redundant slashers that can be normalized.
This feature implements smooth transition between 2 retimed segments.
A transition can be added by dragging retiming handle while holding
shift key. When any handle defining transition is removed, the
transition segment is removed and 2 linear segments are restored to
state before transition was created.
These transitions work with video and sound and changes are reflected
in waveforms with correct seeking, therefore it replaces usage of
`speed_factor` or earlier sound `pitch` property.
Smooth transition is achieved by evaluating Y value of circular arc,
that is tangent to lines of linear retimed segments. Because of this,
when transition length is changed both handles are moved symetrically.
This way it is possible to make transition without affecting content in
linear segments.
When linear segment after transition is further retimed, this shifts
content inside of a transition segment.
To support sound, `SEQ_retiming_sound_animation_data_set` and related
data structures has been updated to build speed table for each smooth
transition segment. Layering of retiming data via meta strips is still
fully supported.
Pull Request: https://projects.blender.org/blender/blender/pulls/107197
This commit adds a new experimental node "Sample Volume".
It's purpose is to be able to sample values from a volume grid given
a position field.
The 'Grid' input accepts a named attribute input with the name
of the volume grid to sample. Values will be implicitly converted
from the grid type to the specified value type.
Pull Request: #107656
Internal private struct was using `owner_id`/`self_id`, while the public
callback data struct was using `id_owner`/`id_self`.
Now using internal naming everywhere in lib_query related code, as
`owner_id` is already used in very low-level 'fundamental' part of the
code, e.g. in the `PointerRNA` struct, or in ID's 'loopback' pointers
for embedded data.
Note that this is only a very small first step toward proper naming
consistency for these type of data, the mismatch is currently spread all
over the code base.
We also need to document more formally the meaning and differences
between `self` and `owner` here.
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.
Functions were moved as part of f7388e3be5, which was
unnecessarily noisy. Instead of reverting, move the definitions back
to their original place in node.cc. Also move a few more things to
the blender::bke namespace.
Since a generic snap cursor was implemented (which can be used by Tools and by DragDrop), the Placement Settings are no longer a settings of the "VIEW3D_OT_interactive_add" Operator.
With that implementation, those properties started to be defined in a
static struct, filled in at runtime and accessed in the UI through
workarrounds.
As they are properties initialized at runtime, they are not saved in
the file.
The solution is to move the Placement Settings to `ToolSettings`.
Co-authored-by: Germano Cavalcante <germano.costa@ig.com.br>
Pull Request: https://projects.blender.org/blender/blender/pulls/107951
Include the term "overwrite" so users of this function are aware
this function will delete the destination file (unlike LIBC rename).
- Add BLI_rename_overwrite (previously called BLI_rename).
- BLI_rename is now a wrapper for rename.
Use BLI_rename when renaming in the file selector.
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
The issue was that in case an ID was only related to its liboverride
hierarchy through a 'to' pointer (e.g. the parent pointer of an object),
it would now be tagged as 'isolated' from its hierarchy, since nothing
in said hierarchy actually points to it. It would then be deleted during
resync process.
This is once again the infamous 'inverted dependency logic of object
parenting' case...
Note that this did not have any consequences on typical liboverride
usages (based on using a hierarchy of collections0, since all objects
would then be referenced by one or more collection.
Reported by @dr.sybren while investigating #102662.
Add a new flag that determines whether root bones (i.e. bones without a
parent) should be translated to the armature object's origin. This can
be found in the Armature's IK properties panel.
By default this flag is disabled, so new rigs will not see this 'locking
to the origin' behaviour. Versioning code ensures that the flag is
enabled on older files, to preserve the behaviour of existing rigs.
This also bumps the Blender subversion and at the same time fixes an
incorrect bump in ee08b2ddff (where the
'minimum compatible version' was updated instead of the current Blender
version).
Pull request: https://projects.blender.org/blender/blender/pulls/107869
GCC documented FILENAME_MAX is the maximum length of a file that can
be opened, not to be used for allocation as it may be INT_MAX for e.g.
Even though this wasn't the case on supported systems,
prefer FILE_MAX which is used for full paths in most places.
Making the custom data API const correct in 3a3d9488a1 caused
the issue, because it previously relied on non-threadsafe behavior. As a
workaround, just restore the thread-unsafety, and note the issue in a
new comment.
There was even one case in BLI ListBase tests!
Order was opposite of the one expected by the BLI ListBase code... Not
sure how, but this did not cause any issue apparently? But would expect
it to at least affect the order in which items in the list would be
iterated.
`BKE_library_id_can_use_filter_id` would not handle properly cases where
the ID is a liboverride - it's hierarchy root pointer can point back to
virtually any kind of ID (although typically a Collection or Object).
This was breaking liboverride resync process in some rare cases, by
failing to remap the 'hierarchy root' pointer of some liboverrides.
This makes the Blender binary 350 KB smaller. The largest change comes
from using `FunctionRef` instead of a template when gathering indices to
mix in the extrude node (which has no performance cost). The rest of the
change comes from consolidating uses of code generation for all
attribute types. This brings us a bit further in the direction of
unifying attribute propagation.
Pull Request: https://projects.blender.org/blender/blender/pulls/107823
Adds an input node Signed Distance that can
be used to refer to the distance-grid of an SDF volume.
Right now it's experimental and can be enabled by enabling
"New Volume Nodes" in the preferences.
It returns a float AttributeFieldInput called 'distance' which
can tell Volume nodes which grid to get.
See #103248.
LibOverride resync process would not properly 'make local' newly created
overrides (copied from their linked reference). The main consequence was
that some linked data used by these new liboverrides would not be
properly tagged as directly linked.
While this would not be an issue in current codebase, this was breaking
upcomming readfile undo refactor, since some linked data did not get
their local 'placeholder reference' data written in memfile blendfiles.
NOTE: this is more of a quick fix, whole handling of library data in
complex copying cases like that need some more general work, see #107848
and #107847.
Issue was that, when UI-related code _is_ requested in foreach_id
processing, `ID_SCR` screen ID type can actually use any kind of ID
(through e.g. the Outliner space).
So `BKE_library_id_can_use_filter_id` had to be updated with a new
parameter (whether UI-related data should be taken into account or not).
The root of the issue was that while reading a new blendfile, the
current `G_MAIN` is still the old one, not the one in which new data is
being read.
Since the remapping callback taking care of UI data during ID remapping
is using `G_MAIN`, it is processing the wrong data, so when deleting the
invalid shapekey (from `BLO_main_validate_shapekeys`), the UI data of
the new bmain would not be properly remapped, causing invalid memory
access later when recomputing user counts (calls to
`BKE_main_id_refcount_recompute`).
This is fixed by adding a new `BKE_id_delete_ex` function that takes
extra remapping options parameter, and calling it from
`BLO_main_validate_shapekeys` with extra option to enforce handling of
UI data by remapping code.
NOTE: At some point we have to check if that whole UI-callback thing is
still needed, would be good to get rid of it and systematically process
UI-related ID pointers like any others. Current situation is... fragile
to say the least.
For realtime use cases, storing the geometry's state in memory at every
frame can be prohibitively expensive. This commit adds an option to
disable the caching, stored per object and accessible in the baking
panel. The default is still to enable caching.
Pull Request: https://projects.blender.org/blender/blender/pulls/107767
