Don't template size for matrix is_negative. These are causing random
build failures on the Windows buildbot.
Note that these already have the assumption of 3D coordinates baked
in. For 2D or 4D coordinates the implementation would have to be
different. So templating these for arbitrary dimensions does not
make much sense.
Pull Request: https://projects.blender.org/blender/blender/pulls/134137
This patch refactors the Result class in the compositor to use
GMutableSpan and std::variant to wrap the result's data. This reduces
the complexity of the code and slightly optimizes performance. This will
also make it easier to add new types and interface with other code like
multi-function procedures.
Pull Request: https://projects.blender.org/blender/blender/pulls/134112
User may think of the `radius` vector value as RGB color, however it's
meant to be the depth of scattering for R/G/B channels. Now clarified in
the desctiption.
Pull Request: https://projects.blender.org/blender/blender/pulls/134088
It already doesn't work in a very fairly simple case when the Grease Pencil
geometry is transformed. This simple case used to work before we changed
the Transform Geometry node to transform layers instead of points.
Pull Request: https://projects.blender.org/blender/blender/pulls/134131
The issue was that the topology of the drawing changes when the bezier
curves get resampled to poly curves in the armature modifier.
This means that the crazyspace code fails to find deformed positions
with the same length as the original positions.
The fix does multiple things:
* First, we make sure that we create an `GeometryComponentEditData` in
weight paint mode.
* When the armature modifier runs, we remember the current positions in
this component.
* Then, we store the curve offsets and weights _before_ converting the
bezier curves.
* Finally we deform the positions stored in the edit hint component
(which have the same length as the original positions).
Since the resampling just adds new points, there might be a way to
avoid running the armature deformation a second time on the edit
hints, but I'll leave that for another day as a performance improvement.
In any case, this is only done when we actually need the deformation
(e.g. in weight paint mode when we paint the weights).
Pull Request: https://projects.blender.org/blender/blender/pulls/134030
The issue was that the topology of the drawing changes when the bezier
curves get resampled to poly curves in the armature modifier.
This means that the crazyspace code fails to find deformed positions
with the same length as the original positions.
The fix does multiple things:
* First, we make sure that we create an `GeometryComponentEditData` in
weight paint mode.
* When the armature modifier runs, we remember the current positions in
this component.
* Then, we store the curve offsets and weights _before_ converting the
bezier curves.
* Finally we deform the positions stored in the edit hint component
(which have the same length as the original positions).
Since the resampling just adds new points, there might be a way to
avoid running the armature deformation a second time on the edit
hints, but I'll leave that for another day as a performance improvement.
In any case, this is only done when we actually need the deformation
(e.g. in weight paint mode when we paint the weights).
Pull Request: https://projects.blender.org/blender/blender/pulls/134030
Yet another remaining case of non-trivial data created with C-style
allocation.
While 4.4 and previous did not exhibit the crash, the invalid code
responsible for this crash is present here as well, and it would be
dangerous not to fix it.
As indicated by pablovazquez , operators that open a pop up should end with `...`.
I decided to change the operator name instead of doing it in python with `text=`
This seemed more reasonable to me because it can't be forgotten when adding this operator
somewhere else, but I am not sure if this is the right way to do it.
Pull Request: https://projects.blender.org/blender/blender/pulls/134062
Mistake in recent RNA refactor (45f231141d), not sure why I ended up
returning empty PointerRNA with non-null type when calling
`RNA_id_create_pointer` with a null ID...
In general, PointerRNA with no data ==> no type either, we are trying to
get rid of the very few exceptions in our codebase relying on a
different behavior!
Blender crashes when appending a Bloom node. This is because the scene
is needed to infer the render size while versioning, and the scene
doesn't exist while appending, so we need to fallback to a default
render size in those cases.
- Hide the axis guide when not orbiting
this drew a permanent blue-dot in the middle of the viewport
which is distracting & unnecessary.
- Hide the orbit center when it's invalid or unused because of
object/3d-cursor viewport locks.
Also use Vector to store menu search items instead of a linked
list. And extend the change into the autocomplete API slightly.
The main benefit is to avoid measuring the length of strings over
and over, but the code also gets simpler.
Add support for dynamic NDOF orbit center calculation.
- When "Auto" NDOF preference is enabled:
All visible objects in the viewport are used to calculate a
bounding box center, if the bounds are outside the view or the center
is behind the viewport, use a Z-Buffer test to calculate the depth in
the middle of the region.
- When "Use Selected Items" NDOF preferences is enabled,
calculating the bounds from the selection.
- An option to show the orbit center as a guide has also been added.
Ref !129594
Co-authored-by: Kamil Galik <kgalik@3dconnexion.com>
Caused by 45f231141d.
The problem was that the now non-trivial PointerRNA type was used inside
of a union. To fix that, replace it with a variant, and generally move
the file towards proper C++ patterns. Also replace the memory arena with
a ResourceScope, of change from dynstr to the fmt::memory_buffer, and
use a destructor instead of manually freeing memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/134144
Most event icons shown on the status bar are made up of an icon with
text inside of it. The icon sizing used 2D zoom aspect value, but the
text does not. I had not noticed any use of these outside of Status Bar
so this wasn't tested. Using aspect requires much more precise
measurement and placement of the text using calculated margin values.
Pull Request: https://projects.blender.org/blender/blender/pulls/134146
Caused by 45f231141d.
The non-trivial nature of `RadialControl` was hidden behind
C-style allocation. Now write the default values for `RadialControl`
explicitly since it isn't allocated by calloc anymore.
This was caused by the input matrix not being used.
Instead EEVEE was trying to derive the projection matrix
again based on the actual viewport state. But this state
was not reflecting the input matrix.
To fix this, we remove any camera setup from the rv3d during
the offscreen drawing and set the lens param to 0.
This ensure EEVEE loads the input projection matrix.
Second part to fix#130007, after 50f7666785.
When saving a new file with the current file asset library loaded, the
library wasn't converted properly to an on-disk library. While the
library was loaded again as on-disk library, the previous runtime
version of it wasn't cleared, so catalog definitions could be duplicated
across available libraries.
Make sure the runtime only library is destructed properly, and the UI
refreshed.
There seem to be more issues with converting the runtime current file library to
a on-disk current file library, but these can be addressed after the crashes and
hangs are fixed, see report.
Pull Request: https://projects.blender.org/blender/blender/pulls/133341
If "Playback Frame Rate" is enabled (Preferences / ViewPort / Display)
and showing the "Text Info" viewport overlay, then "fps" is shown in
the place of the View Name while the animation is played. Every time
this starts there is a jiggle where the Object Info line is drawn at
the first line instead. This is because the FPS can early exit and not
update the vertical line position. This PR fixes that.
Pull Request: https://projects.blender.org/blender/blender/pulls/134074
Helps identify the active mesh/armature data, useful for instances or
when dealing with multiple data-blocks per object, as in the Keymesh
add-on.
More details and screenshots in the pull request.
Pull Request: https://projects.blender.org/blender/blender/pulls/133403
The general idea is to store an array of (type, data) pointers of all
PointerRNA ancestors of the current one.
This will help solving cases in our code where the owner (or sometimes
even the owner of the owner) of a random PointerRNA needs to be
accessed. Current solution mainly relies on linear search from the owner
ID, which is sub-optimal at best, and may not even be possible in case a
same data is shared between different owners.
This lead to refactoring quite a bit of existing PointerRNA creation code.
At a high level (i.e. expected usages outside of RNA internals):
* Add `RNA_pointer_create_with_parent` and
`RNA_pointer_create_id_subdata` to create RNA pointers with
ancestors info.
* `RNA_id_pointer_create` and `RNA_main_pointer_create` remain
unchanged, as they should never have ancestors currently.
* Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer
from the nth ancestor of another PointerRNA.
* Add basic python API to access this new ancestors data.
* Update internal RNA/bpy code to handle ancestors generation in most
common generic cases.
- The most verbose change here is for collection code, as the owner of the
collection property is now passed around, to allow collection items to get
a valid ancestors chain.
Internally:
* `PointerRNA` now has an array of `AncestorPointerRNA` data to store
the ancestors.
* `PointerRNA` now has constructors that take care of setting its data for
most usual cases, including handling of the ancestor array data.
* Pointer type refining has been fully factorized into a small utils,
`rna_pointer_refine`, that is now used from all code doing that operation.
* `rna_pointer_inherit_refine` has been replaced by
`rna_pointer_create_with_ancestors` as the core function taking care of
creating pointers with valid ancestors info.
- Its usage outside of `rna_access` has been essentially reduced to custom
collection lookup callbacks.
Implements #122431.
--------------
Some notes:
* The goal of this commit is _not_ to fully cover all cases creating
PointerRNA that should also store the ancestors' chain info. It only
tackles the most generic code paths (in bpyrna and RNA itself mainly).
The remaining 'missing cases' can be tackle later, as needs be.
* Performances seem to be only marginally affected currently.
* Currently `AncestorPointerRNA` only stores PointerRNA-like data.
This will help `StructPathFunc` callbacks to more efficiently generate
an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will
not be enough info to build these paths without these callbacks. And some
cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA`
pointer, and for RNA collection ones, an index and string identifier, to store
a complete unambiguous 'RNA path' info. This is probably not needed, nor
worth the extra processing and memory footprint, for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122427
Previous approach was using non-evaluated meshes to find the closest edge from a face index retrieved from the selection buffer.
This can fail though if the mesh is deformed or even altered to not have the same indices anymore (e.g. generating/masking modifiers).
In order to make this work, added `ED_mesh_pick_edge` which switches the selection context to edges directly
and picks from those. No need to map anything back and forth between original and evaluated, the selection buffer contains the original indices already.
Further logic (following the face loop) is untouched (and happens on the original geometry which is fine)
Should go into 4.2 LTS as well
Pull Request: https://projects.blender.org/blender/blender/pulls/132803
The changes from 29356e2bf7
fixed a readability issue with loose wire not being as prominent as
regular surface wireframe.
But also added a regression where the object color wireframe mode
made the object color imperceivable when the object is selected.
This commit fixes the issue by setting the facing factor to 0.5 for
loose wires. This way, both the theme color and object color wireframe
more are blended enough to be distinguishable and still retain the
object color hint.
The issue was that the code did not handle input sockets that are fields
implicitly correctly. It just retrieved a single from them, instead of
treating them as having an unknown value.
