| Age | Commit message (Collapse) | Author |
|---|
|
The issue was that the new span still referenced data that was potentially
stored in the old VArray_Span.
|
|
This error was introduced in 176d7bcc2eb47b9820861037f90a7fb26de8c9a0
Fix provided by @deadpin
|
|
Cop paste mistake from rB3cd283a424ec92ef85e1856d66f0baa4d2253fc5
|
|
- Adds python 3.10 support
- Slightly improves performance
|
|
Scaling handles while dragging could be distracting, especially at
extreme values where handles could become large on-screen.
Now all gizmos are shown while scaling.
GIZMO_GT_arrow_3d now now support changing their length while being
dragged as well as negative lengths.
|
|
|
|
Avoid the conversion to and from the old type, which could
be a substantial improvement in somce cases.
|
|
|
|
Curve attributes were allocated to the size of the point domain, which
wouldn't cause bad behavior, just potentially worse performance.
|
|
|
|
This allows the use of C++ data structures to simplify code and
improve performance.
|
|
The separate geometry and delete geometry nodes often invert the
selection so that deleting elements from a geometry can be implemented
as copying the opposite selection of elements. This should make the two
nodes faster in some cases, since the generic versions of selection
creation functions (i.e. from d3a1e9cbb92cca04e) are used instead
of the single threaded code that was used for this node.
The change also makes the deletion/separation code easier to
understand because it doesn't have to pass around the inversion.
|
|
This resolves a minor inconsistency displaying the scale gizmo handles
since they're cubes it's noticeable when they're not axes aligned.
|
|
When interacting with translate/rotate/scale gizmo, show the gizmo while
it's in use. There are some exceptions to this, as showing all scale
gizmos while scaling causes the gizmos to become large & distracting so
in this case only the gizmo being dragged is shown.
Resolves T63743.
|
|
Some operators OR'ed the existing flags in a way that made it seem
the value might already have some values set.
Replace this with assignment as no flags are set and the convention
with almost all operators is to write the value directly.
|
|
|
|
Also remove accidentally committed WIP commented code.
|
|
This implements the new way to attach curves to a mesh surface using
a uv map (based on the recent discussion in T95776).
The curves data block now not only stores a reference to the surface object
but also a name of a uv map on that object. Having a uv map is optional
for most operations, but it will be required later for animation (when the
curves are supposed to be deformed based on deformation of the surface).
The "Empty Hair" operator in the Add menu sets the uv map name automatically
if possible. It's possible to start working without a uv map and to attach the
curves to a uv map later on. It's also possible to reattach the curves to a new
uv map using the "Curves > Snap to Nearest Surface" operator in curves sculpt
mode.
Note, the implementation to do the reverse lookup from uv to a position on the
surface is trivial and inefficient now. A more efficient data structure will be
implemented separately soon.
Differential Revision: https://developer.blender.org/D15125
|
|
After this commit, all mesh data extraction and drawing code is in C++,
including headers, making it possible to use improved types for future
performance improvements and simplifications.
The only non-trivial changes are in `draw_cache_impl_mesh.cc`,
where use of certain features and macros in C necessitated larger
changes.
Differential Revision: https://developer.blender.org/D15088
|
|
|
|
This implements transform modes for the transform tool and Elastic
Transform. This mode uses the Kelvinlets from elastic deform to apply
the transformation to the mesh, using the cursor radius to control the
elasticity falloff.
{F9269771}
In order for this to work, the transform tool uses incremental mode when
elastic transform is enabled. This allows to integrate the displacement of
the Kelvinet in multiple steps.
Review By: Sergey Sharbin & Daniel Bystedt & Julian Kaspar & Campbell
Barton
Differential Revision: https://developer.blender.org/D9653
Ref D15041
|
|
Shifted flag for buttons changed was incorrectly compared with
unshifted packet flag to determine button press state.
Also fix button tracking storage; button flags are 32 bits whereas the
member variable was 8.
Differential Revision: https://developer.blender.org/D14915
|
|
|
|
|
|
The code that checked whether vertex normals needed to be recalculated
was checking the dirty tag for face normals and vertex normals, in an
attempt at increased safety. However, those tags are always set
together anyway. Only checking the vertex dirty tag allows potentially
allocating or updating the normals on the two domains independently,
which could allow further skipping of calculations in some cases.
|
|
|
|
|
|
Fixes bug where clicking in empty space resets
viewport pivot in rotate around active mode
to zero.
|
|
|
|
|
|
Rendering directly to a resource using OpenGL interop and Hgi
doesn't work in Houdini, since it never uses the resulting resource
(it does not call `HdRenderBuffer::GetResource`). But since doing
that simultaneously disables mapping (`HdRenderBuffer::Map` is
not implemented then), nothing was displayed. To fix this, keep
track of whether a Hydra viewport does support displaying a Hgi
resource directly, by checking whether
`HdRenderBuffer::GetResource` is ever called and only enable use
of OpenGL interop if that is the case.
Differential Revision: https://developer.blender.org/D15090
|
|
The fix is to unify with the name we had for the old Curves objects.
That means that we will see them bothi (old and new curves) in the outliner
(under two different categories but with different names).
This is considered to be a temporary solution until we remove the old
curve system entirely.
|
|
|
|
Simple typo in rB55e3930b253e.
|
|
|
|
|
|
This was leading to some crashes and warnings such as:
"Code marked as unreachable has been executed. Please report this as a bug."
Differential Revision: https://developer.blender.org/D15116
|
|
Collection operand and Fast mode.
Code handling repetitive boolean operations when using several objects
from a Collection would not handle result mesh properly, re-creating for
each object without properly freeing it.
Further more, existing code was effectively converting the BMesh to mesh
twice, including a modification of the initial (input) mesh, which
modifiers should never do!
Removed the extra useless conversion, which also gives a small
improvement in performances:
With as simple of a scene as four objects (three operands in a
collection, and the modified one) totalling 20k vertices/faces, this
commit:
* Avoids 2MB memory leak per evaluation (!).
* Speeds up boolean evaluation by 5-10%.
Found while investigating some production files of the Project Heist
here at the Blender Studio.
|
|
|
|
Test basic Difference operation with both a single Objetc and a
collection of three objects as operands, using BMesh (aka 'FAST') mode.
|
|
|
|
In the latest discussions about curves/hair mesh attachement
information (T95776), it was decided to use UV coordinates to
store where on the mesh each root is. For that, we have to specify
which of the UV map attributes to use for UV lookups.
This property isn't used yet, but it will be shortly when refactoring
the attachement information in the add brush and the to particle
system conversion.
Differential Revision: https://developer.blender.org/D15115
|
|
|
|
Must include the AOV writing feature in background shader evaluation.
Differential Revision: https://developer.blender.org/D15114
|
|
Same as in Cycles, this is needed for some color space conversions that don't
compress well to byte sRGB, like for example Filmic sRGB.
Ref T68926
|
|
|
|
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
|
|
The packed image loader was not aware of the fact that UDIM tiles
can be of a different size.
Exposed Python API required to access this information. It has the
same complexity as the "regular" packed files: in both cases the
ImBuf will be acquired and released to access the information.
While the current workflow of packing UDIMs is not very streamlined,
it is still possible and is something what the studio is using here.
Test file:
{F13130516}
Expected behavior achieved with this patch: a bigger checker board
pattern in viewport render
Actual behavior prior to this patch: either memory corruption, or
wrong/black render result on the plane
Differential Revision: https://developer.blender.org/D15111
|
|
|
|
This did not refresh the Image editor, but more importantly this now
appeared cropped (a regression from the partial image updater).
Solved in the RNA function by:
- calling BKE_image_partial_update_mark_full_update
- sending appropriate notifier
Maniphest Tasks: T98573
Differential Revision: https://developer.blender.org/D15110
|
