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
A mistake in the recent ImBuf API refactor: the Libmv image accessor
was copying destination to destination (possibly using the wrong
number of channels as well).
Pull Request: https://projects.blender.org/blender/blender/pulls/108070
While strcpy is safe in this case, it's use requires extra scrutiny
and can cause problems if the strings are later translated.
Also move the ID code assignment into material_init_data
as the ID-code is more of an internal detail.
If there are no loose vertices or edges, it's basically free to
propagate that information to the result and save calculating
it later in case it's necessary. I observed a peformance increase
from 3.6 to 4.1 FPS when extruding a 1 million face grid.
Used to be https://archive.blender.org/developer/D17123.
Internally these are already using the same code path anyways, there's no point in maintaining two distinct nodes.
The obvious approach would be to add Anisotropy controls to the Glossy BSDF node and remove the Anisotropic BSDF node. However, that would break forward compability, since older Blender versions don't know how to handle the Anisotropy input on the Glossy BSDF node.
Therefore, this commit technically removes the Glossy BSDF node, uses versioning to replace them with an Anisotropic BSDF node, and renames that node to "Glossy BSDF".
That way, when you open a new file in an older version, all the nodes show up as Anisotropic BSDF nodes and render correctly.
This is a bit ugly internally since we need to preserve the old `idname` which now no longer matches the UI name, but that's not too bad.
Also removes the "Sharp" distribution option and replaces it with GGX, sets Roughness to zero and disconnects any input to the Roughness socket.
Pull Request: https://projects.blender.org/blender/blender/pulls/104445
Since 44e4f077a9 and related commits, geometry nodes doesn't
try to hide the difference between real geometry data and instances from
the user. Other nodes were updated to only support real geometry, but
the "Mesh Boolean" node was never updated and still implicitly gathered
all the instances. This commit removes the special instance behavior in the
boolean node and adds realize instances nodes to keep existing behavior
in most cases. Typically this doesn't make a difference in the result,
though it could in the union mode for instance inputs. Shifting more of
the work to realizing instances should generally be better for
performance, since it's much faster.
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
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.
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.
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
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
Caused by 2fb31f34af.
Since above commit, we are now calling `BKE_mesh_orco_verts_transform`
not only from `psys_face_mat` and `psys_mat_hair_to_orco`, but now also
from `psys_particle_on_dm` > `psys_interpolate_face`, so we get double
transforms with mirror.
Remove the "extra" call in `psys_mat_hair_to_orco`.
Should be backported to 3.3 LTS as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/107804
