Previously, BKE level preview image code was in `BKE_icons.h` and `icons.hh`.
While these types are related, I always found this quite hard to navigate since
preview image stuff was just in the middle of icon functions. Plus, people
don't expect preview image functions in icon files, the relationship is not
obvious.
Instead, use focused files that make it easy to quickly navigate them
and see what they are dealing with.
Pull Request: https://projects.blender.org/blender/blender/pulls/111709
The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
The `expand` callback is 'trivial' to replace, since it is only iterating
over ID pointers and calling a callback.
The only change in behavior here is that some pointers that were not
processed previously will now be.
In practice this is not expected to have any real effect (usually
the IDs used by these pointers would have been expanded through other
usages anyway). But it may solve a few corner cases, undocumented issues
though.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
This commit adds a new option flag to the lib_query foreach_id code,
which will make deprecated ID pointers to be processed as well.
NOTE: Currently there is no report to the callbakcs about the fact that
it is processing a deprecated ID. This can be easily added later if it
becomes necessary.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
There is no reason at all for each ID read/write callbacks to have to
deal with this generic, common data explicitely. Generic ID read/write
code is the place to handle such data (just like asset, liboverride,
etc. data are handled already).
Note behavioral change expected here.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
First implementation of node previews in the shader node editor. Using
the same user interface as compositor node previews, most shader nodes
can now be previewed (except group in/output and material output).
This is currently still an experimental feature, as polishing of the
user experience and performance improvements are planned. These will
be easier to do as incremental changes on this implementation.
See #110353 for details on the work that remains to be done and known
limitations.
Implementation notes:
We take advantage of the `RenderResult` available as `ImBuf` images to
store a `Render` for every viewed nested node tree present in a
`SpaceNode`. The computation is initiated at the moment of drawing nodes
overlays.
One render is started for the current nodetree, having a `ViewLayer`
associated with each previewed node. We separate the previewed nodes in
two categories: the shader ones and the non-shader ones.
- For non-shader nodes, we use AOVs which highly speed up the rendering
process by rendering every non-shader nodes at the same time. They are
rendered in the first `ViewLayer`.
- For shader nodes, we render them each in a different `ViewLayer`, by
rerouting the node to the output of the material in the preview scene.
The preview scene takes the same aspect as the Material preview scene,
and the same preview object is used.
At the moment of drawing the node overlay, we take the `Render` of the
viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass
for each previewed node.
Pull Request: https://projects.blender.org/blender/blender/pulls/110065
References to data-blocks in a material were stored in-memory and could
crash if the data-blocks referenced by the material no longer existed
when pasting.
Resolve by using a blend-file for material copy/paste, matching how the
clipboard works in the 3D view-port.
Currently there is no support for including indirectly linked
data-blocks when pasting the material. Instead, data-blocks are restored
by name, by inspecting the current file.
This also fixes a crash where the `SpaceNode::nodetree` could point to
freed memory when pasting a material.
Ref !108496.
Includes contributions by @mont29.
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/
Follow up to [0], some material data wasn't accounted for.
- The embedded node-tree's owner_id wasn't set.
- Animation data (both the material & it's embedded node-tree).
- Updating depsgraph relations is needed when animation data is freed
as part of paste too.
Also report when paste fails.
[0]: 5b5a1e3581
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
- Pasting a material would free the materials local node-tree,
leaving it in the depsgraph which would then tag the freed ID
(from deg_graph_clear_id_recalc_flags).
- texpaintslot, gp_style pointers were copied into the clipboard without
being cleared or duplicated, allowing for freed memory access later on.
- A shallow copy from the cliboard into the material could also cause
these pointers to be overwritten and leak memory.
Resolve by calling material_free_data before performing a shallow copy
and adding material_clear_data which ensures these pointers aren't
copied into the clipboard.
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.
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.
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
Embedded IDs did not benefit from any of the recent optimizations
(especially for undo case) when writing regular IDs (cleaning up of some
pure runtime data that would generate a lot of fake 'changed on undo'
status).
Now factor out of `write_file_handle` this part of the code generating
temp ID copy with cleaned-up data for writing, and expose it in BLO API
such that IDs owning embedded ones can also use it.
Refactoring mesh code, it has become clear that local cleanups and
simplifications are limited by the need to keep a C public API for
mesh functions. This change makes code more obvious and makes further
refactoring much easier.
- Add a new `BKE_mesh.hh` header for a C++ only mesh API
- Introduce a new `blender::bke::mesh` namespace, documented here:
https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces
- Move some functions to the new namespace, cleaning up their arguments
- Move code to `Array` and `float3` where necessary to use the new API
- Define existing inline mesh data access functions to the new header
- Keep some C API functions where necessary because of RNA
- Move all C++ files to use the new header, which includes the old one
In the future it may make sense to split up `BKE_mesh.hh` more, but for
now keeping the same name as the existing header keeps things simple.
Pull Request: https://projects.blender.org/blender/blender/pulls/105416
Use a consistent style for declaring the names of struct members
in their declarations. Note that this convention was already used in
many places but not everywhere.
Remove spaces around the text (matching commented arguments) with
the advantage that the the spell checking utility skips these terms.
Making it possible to extract & validate these comments automatically.
Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo`
which were using brief descriptions.
Expands Color Mix nodes with new Exclusion mode.
Similar to Difference but produces less contrast.
Requested by Pierre Schiller @3D_director and
@OmarSquircleArt on twitter.
Differential Revision: https://developer.blender.org/D16543
