| Age | Commit message (Collapse) | Author |
|---|
|
Small fixes to the drawing of multi input sockets:
- Make the outline thickness consistent with normal node sockets,
independent from the screen DPI.
- Only highlight multi input sockets when they are actually selected.
- Skip selected multi inputs when drawing normal selected sockets.
Differential Revision: https://developer.blender.org/D14192
|
|
Also move eDupli_ID_Flags doc-string to it's declaration.
|
|
Changing the radius does not invalidate a cache on
`CurvesGeometry`.
|
|
Currently the code expects the radius attribuet to always exist on the
input Curves. This won't be true in the future though, so the correct
default value of one should be used when creating the data on CurveEval,
where the data is not optional.
|
|
Avoids the need to use the attribute API to access this commonly
used builtin attribute.
|
|
This patch was tested on the buildbot first, it builds on all platforms.
|
|
This commit improves the drawing of selected node links:
- Highlight the entire link to make it easier to spot where the link
is going/coming from.
- Always draw selected links on top, so they are always clearly
visible.
- Don't fade selected node links when the sockets they are connected
to are out out view.
- Dragged node links still get a partial highlight when they are only
attached to one socket.
Differential Revision: https://developer.blender.org/D11930
|
|
Add a std::move in some places to prevent arrays from being copied.
These cases were potentially optimized by the compiler, but this makes
it more explicit.
Differential Revision: https://developer.blender.org/D14129
|
|
|
|
|
|
This add-on now conforms to the distribution requirements, see: T95442.
|
|
|
|
New code from the vertex normal refactor cfa53e0fbeed combined with older code
from 592759e3d62a that disabled instancing for custom normals and autosmooth
meant that instancing was always disabled.
However we do not need to disable instancing for custom normals and autosmooth
at all, this can be shared between instances just fine.
|
|
The constraint operators for delete, apply, copy and copy to selected
were missing null checks and could crash blender when called wrongly
from the python api.
Differential Revision: http://developer.blender.org/D14195
|
|
Ref T95355
|
|
This commit changes `CurveComponent` to store the new curve
type by adding conversions to and from `CurveEval` in most nodes.
This will temporarily make performance of curves in geometry nodes
much worse, but as functionality is implemented for the new type
and it is used in more places, performance will become better than
before.
We still use `CurveEval` for drawing curves, because the new `Curves`
data-block has no evaluated points yet. So the `Curve` ID is still
generated for rendering in the same way as before. It's also still
needed for drawing curve object edit mode overlays.
The old curve component isn't removed yet, because it is still used
to implement the conversions to and from `CurveEval`.
A few more attributes are added to make this possible:
- `nurbs_weight`: The weight for each control point on NURBS curves.
- `nurbs_order`: The order of the NURBS curve
- `knots_mode`: Necessary for conversion, not defined yet.
- `handle_type_{left/right}`: An 8 bit integer attribute.
Differential Revision: https://developer.blender.org/D14145
|
|
This was an oversight in rB06ac5992618a75c453e495e06af7c5faf30499a7.
|
|
Something went wrong here in 61776befc3f8.
|
|
This patch was tested on the build bots on all platforms.
|
|
|
|
The usual 'shape keys snowflake' nightmare again...
|
|
Add a new `EDITOR_VIEW3D` context to those view orientations.
|
|
|
|
The UI context was only set for the operator polls, but not for the
drop-box polls. Initially I thought this wouldn't be needed since the
drop-boxes should leave up context polls to the operator, but in
practice that may not be what API users expect. Plus the tooltip for the
drop-boxes will likely have to access context anyway, so they should be
able to check it beforehand.
|
|
Motion paths can now be initialised to more sensible frame ranges,
rather than simply 1-250:
- Scene Frame Range
- Selected Keyframes
- All Keyframes
The Motion Paths operators are now also added to the Object context menu
and the Dopesheet context menu.
The scene range operator was removed, because the operators now
automatically find the range when baking the motion paths.
The clear operator now appears separated in "Selected Only" and "All",
because it was not clear for the user what the button was doing.
Reviewed By: sybren, looch
Maniphest Tasks: T93047
Differential Revision: https://developer.blender.org/D13687
|
|
|
|
Caused by 0f89bcdbebf5 and was not fully addressed by 6f9828289f39:
tagging an ID with flag 0 is to be seen as an explicit tag for copy
on write.
Would be nice to either consolidate code paths of flag 0 and explicit
component tag, or get rid of tagging with 0 flag, but that is above of
what we can do for the upcoming release.
|
|
|
|
Image users have a multi_index that wasn't updated in case it is a normal
image.
|
|
When using ancored stroked the diameter of the stroke can be 0 what
leads to a division by zero that on certain platforms wrap to a large
negative number that cannot be looked up. This fix will clamp the size
of the brush to 1.
|
|
This fixes a crash on selected platforms.
|
|
Now drag & tweak can have modifier keys to be released while dragging.
without this, modifier keys needs to be held which is more noticeable
for tablet input or whenever the drag threshold is set to a large value.
Resolves T89989.
|
|
Return early if a curve has a domain size of 0.
T96060
|
|
The attribute data might be null if the number of curves is zero.
While that is not common, an empty curves data-block is valid.
|
|
|
|
This fixes T93051, T76405 and maybe others.
Characters like '²', '<' are not recognized in Blender's shortcut keys.
And sometimes simple buttons like {key .} and {key /} on the Windows
keyboard, although the symbol is "known", Blender also doesn't
detect for shortcuts.
For Windows, some of the symbols represented by `VK_OEM_[1-8]` values,
depending on the language, are not mapped by Blender.
On Mac there is a fallback reading the "actual character value of the
'remappable' keys". But sometimes the character is not mapped either.
On Windows, the solution now mimics the Mac and tries to read the button's
character as a fallback.
For unmapped characters ('²', '<', '\''), now another value is chosen as a
substitute.
More "substitutes" may be added over time.
Differential Revision: https://developer.blender.org/D14149
|
|
|
|
|
|
Some logic and comments in the vertex normal calculation were
left over from when normals were stored in MVert, before
cfa53e0fbeed7178c7. Normals are never allocated and freed
locally anymore.
|
|
|
|
In some cases, the normal edit modifier calculated the normals on one
mesh with the "ensure" functions, then copied the mesh and retrieved
the layers "for write" on the copy. Since 59343ee1627f4c369e23, normal
layers are never copied, and normals are allocated with malloc instead
of calloc, so the mutable memory was uninitialized.
Fix by calculating normals on the correct mesh, and also add a warning
to the "for write" functions in the header.
|
|
The check to see if newly requested attributes are not already in the
cache was not taking into account the possibility that we do not have
new requested attributes (`num_requests == 0`). In this case, if
`attr_used` already had attributes, but `attr_requested` is empty, we
would consider the cache as dirty, and needlessly rebuild the attribute
VBOs.
|
|
|
|
|
|
These features are complicated to support on GPU and hardly compatible
with subdivision in the first place. In the future, with T68891 and
T68893, subdivision and custom smooth shading will be separate workflows.
For now, and to better prepare for this future (although long term
plan), we should discourage workflows mixing subdivision and custom
smooth normals, and as such, this disables GPU subdivision when
autosmoothing or custom split normals are used.
This also adds a message in the modifier's UI to indicate that GPU
subdivision will be disabled if autosmooth or custom split normals are
used on the mesh.
Differential Revision: https://developer.blender.org/D14194
|
|
Reuse the same vertex normals calculation as for the GPU code, by
weighing each vertex normals by the angle of the edges incident to the
vertex on the face.
Additionally, remove limit normals, as the CPU code does not use them
either, and would also cause different shading issues when limit surface
is used.
Fixes T95242: shade smooth artifacts with edge crease and limit surface
Fixes T94919: subdivision, different shading between CPU and GPU
|
|
|
|
The custom data code checks for `LayerTypeInfo.defaultname` before
adding a second layer with a certain type. This was missed in
e7912dfa1959be671f77e4e67eab. In practice, this default name
is not actually used.
|
|
Added call to ensure that the USD plugins are registered
when opening a USD cache archive. This is to avoid USD
load errors due to missing USD file format plugins when
opening blender files that contain USD transform cache
constraints and mesh sequence cache modifilers.
Fixes T94396
|
|
|
