This commit adds a new "Image Info" node to retrieve various
information from an image like its width, height, and whether
it has an alpha channel. It is also possible to retrieve the FPS
and frame count of video files.
Differential Revision: https://developer.blender.org/D15042
Selection range is +/-7 pixels to actual clicked position, but strip selection
was biased towards rightmost strip.
To make selection more intuitive, select closest strip to clicked position, and
stop iterating when strip intersects clicked pixel.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D15728
Though they are sometimes used by users of the BVH tree, mostly
vertex normals when building the BVH tree is unnecessary. Skip it
instead and avoid storing the vertex normals in the BVH tree cache.
They are just calculated in the few places they are actually needed.
This should save at least a few percent of the runtime in some cases
where the normals weren't needed otherwise.
This gives a friendlier interface, an inline buffer, RAII, etc.
Also switch some BMesh functions that were only used by the snap
system's use of BVH utils.
The anims data is a runtime cache similar to the image buffer or GPU texture
and needs to be preserved through undo in the same way.
Found as part of D15042 development.
Adds a new `source/blender/asset_system` directory and moves asset
related files from BKE to it. More asset related code can follow
(e.g. asset indexing, ED_assetlist stuff) but needs further work to
untangle it. I also kept `BKE_asset.h` and `asset.cc` as is, since they
deal with asset DNA data mostly, thus make sense in BKE.
Motivation:
- Makes the asset system design more present (term wasn't even used in
code before).
- An `asset_system` directory is quite descriptive (trivial to identify
core asset system features) and makes it easy to find asset code.
- Asset system is mostly runtime data, with little relation to other
`Main`/BKE/DNA types.
- There's a lot of stuff in BKE already. It shouldn't be just a dump for
all stuff that seems core enough.
- Being its own directly helps us be more mindful about encapsulating
the module well, and avoiding dependencies on other modules.
- We can be more free with splitting files here than in BKE.
- In future there might be an asset system BPY module, which would then
map quite nicely to the `asset_system` directory.
Checked with some other core devs, consensus seems that this makes
sense.
Implement a new topology-based copy and paste solution for UVs.
Usage notes:
* Open the UV Editor
* Use the selection tools to select a Quad joined to a Triangle joined to another Quad.
* From the menu, choose UV > UV Copy
* The UV co-ordinates for your quad<=>tri<=>quad are now stored internally
* Use the selection tools to select a different Quad joined to a Triangle joined to a Quad.
* (Optional) From the menu, choose UV > Split > Selection
* From the menu, choose UV > UV Paste
* The UV co-ordinates for the new selection will be moved to match the stored UVs.
Repeat selection / UV Paste steps as many times as desired.
For performance considerations, see https://en.wikipedia.org/wiki/Graph_isomorphism_problem
In theory, UV Copy and Paste should work with all UV selection modes.
Please report any problems.
A copy has been made of the Graph Isomorphism code from https://github.com/stefanoquer/graphISO
Copyright (c) 2019 Stefano Quer stefano.quer@polito.it GPL v3 or later.
Additional integration code Copyright (c) 2022 by Blender Foundation, GPL v2 or later.
Maniphest Tasks: T77911
Differential Revision: https://developer.blender.org/D16278
* Support bidirectional type lookups. E.g. finding the base type of a
field was supported, but not the other way around. This also removes
the todo in `get_vector_type`. To achieve this, types have to be
registered up-front.
* Separate `CPPType` from other "type traits". For example, previously
`ValueOrFieldCPPType` adds additional behavior on top of `CPPType`.
Previously, it was a subclass, now it just contains a reference to the
`CPPType` it corresponds to. This follows the composition-over-inheritance
idea. This makes it easier to have self-contained "type traits" without
having to put everything into `CPPType`.
Differential Revision: https://developer.blender.org/D16479
A Loop to poly map was passed as an optional output to the loop normal
calculation. That meant it was often recalculated more than necessary.
Instead, treat it as an optional argument. This also helps relieve
unnecessary responsibilities from the already-complicated loop normal
calculation code.
This test is disabled for the following reasons:
This test is one of the longer ones in this suite (2979 out of 3559ms total)
and nothing is currently monitoring the performance, if this test were to be
20% slower one day, no-one would actually notice.
there are no asserts, the test actually cannot fail.
it's good to have some benchmark code, so like some of the other mesh
benchmark code, exclude it using an `#ifdef` guard so i can be easily
re-enabled when needed.
reviewed by: jbakker
Differential Revision: https://developer.blender.org/D16314
This is a clean-up pass that eliminates a few problematic patterns:
* Eliminating redundant parentheses around simple expressions.
* Combing declaration and assignment of variables where appropriate.
* Moving variable declarations closer to their first use.
* Many variables and arguments have been marked as `const`.
* Using `LISTBASE_FOREACH_*` variants where applicable instead of
manually managing loop control flow.
There are no functional changes.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D16459
The "visibility_instances.blend" cycles test was failing..
The stack of dupli generator types added in e508de0417
wasn't "popped" correctly after recursive duplis were generated.
Previously the `CustomData_add_layer` function always returned
the existing layer data when used for types that can only have one
layer. This made it work like an "ensure layer exists" function for those
types. That was used in various places to make code more concise.
0a7308a0f1 changed that to always "recreate" the layer even
when it existed. Maybe this is more logical for an "add layer" function,
but that's not clear, and it breaks a bunch of existing code that relied
on the current behavior. Rather than spending a bunch of time going
through uses of the CustomData API, this patch resets the behavior
to what it was before, but adds an assert and a comment to help
avoid memory leaks and other issues. We should focus on moving
to the attribute API instead.
Differential Revision: https://developer.blender.org/D16458
Code in `deg_object_hide_original` uses the dupli object type to decide
whether to hide the original object. The geometry component system
changed the dupli object generator types, which made this not work.
To maintain existing behavior, maintain a stack of non-geometry-nodes
generator types while building the dupli list, and assign that to the
dupli object instead.
I think this code is on its last legs. It can't handle too many more
hacky fixes like this, and should be replaced soon. Hopefully that is
possible by using a `bke::Instances` type instead. However, this
bug is bad enough that it's worth fixing like this.
Differential Revisions: https://developer.blender.org/D16460
This random number is intended to be unique for every instance, however for
some cases with more than one level of nesting this was failing. This also
affected curves after they were refactored to use geometry sets.
For simple cases the random number is the same as before, however for more
complex nesting it will be different than before, changing the render result.
This was caused by rBc39eb09ae587e1d9. The optimization broke the case
when the socket is not in the provided node tree. Now there are two separate
functions, one that always does the slow check to see of the socket is really
in the node tree and a potentially much faster version when we are sure
that the socket is in the tree.
Instead of CustomDataLayer, which exposes the internal implementation
more than necessary, and requires that the layer is always available,
which isn't always true.
Properly initialize clump curve mapping tables for duplis and other cases
where this was missed by making a generic init/free function instead of
duplicating the same logic in multiple places. Also fold lattice deform
init into this.
