Split the algorithms that find duplicates.
This improves readability and helps us find areas for optimization.
It may also facilitate the implementation of generic utilities.
No functional changes.
Differential Revision: https://developer.blender.org/D16918
Code authored by Michael B Johnson (drwave).
Reviewed by Sybren and makowalski.
This patch addresses a crash that occurs when exporting a
scene to a USD file, when that scene includes a point cloud
object or hair.
Added OB_POINTCLOUD and OB_CURVES enums and a default case
statement in the switch statement in
USDHierarchyIterator::create_data_writer, to avoid dereferencing
a NULL pointer.
Differential Revision: https://developer.blender.org/D16776
`batch_for_shader` is an utility function that creates the correct
vertex buffer based on the given shader. In the shader interface
the `attr_types_` contains the GPUType for each location in the
vertex buffer.
When using Metal, the `attr_types_` was never updated, resulting
in using incorrect or non-existing data types. This patch fixes
this by updating the `attr_types_` when building the shader
interface.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D17042
When using the "normalized" display of FCurves in the
Graph Editor, and also turning on the preview range,
the normalized display would break.
The preview frame range was assumed to be bezt indices,
which is only true when every frame has a key.
Reviewed by: Colin Basnett
Differential Revision: https://developer.blender.org/D16987
Ref: D16987
Similar to rBe97443478e32 and rBe772087ed664, exit early when
texture, collection and world ID has no parent to unlink from.
Reviewed by: Severin, lichtwerk
Differential Revision: https://developer.blender.org/D17017
The line art modifier added a wmNotifier in it's
GpencilModifierTypeInfo.generateStrokes callback which isn't thread-safe
when called from the depsgraph. This was from the original inclusion
of the feature [0] however a more recent optimization to notifier
lookups [1] made the crash occur more frequently.
Remove the notifier as modifiers should not be adding WM level events
and it works without it.
[0]: 3e87d8a431
[1]: 0aaff9a07d
This was the case when using the operator outside of the modifiers panel.
Caused by {rBeae36be372a6}.
In above commit, `DT_layer_items` shared both `DT_TYPE_MPROPCOL_LOOP` |
`DT_TYPE_MLOOPCOL_LOOP` in a single EnumPropertyItem value "Colors".
This is a bit unusual, but probably allowed.
As a consequence, checks for specific datatypes would fail when selecting
such EnumPropertyItem:
- `DT_DATATYPE_IS_MULTILAYERS` (uses `ELEM` to check distinct entries --
would return false)
- `BKE_object_data_transfer_dttype_to_srcdst_index` (would return
`DT_MULTILAYER_INDEX_INVALID`)
These places have now been corrected to take these "special" values into
account.
Another issue was that multiple EnumPropertyItems with the same value
could be created in dt_add_vcol_layers() if attributes of the same
domain, but different color types are in play (could lead to crashes)
and that has also been corrected.
Also: above commit did not give the choice of transfering color
attributes from the vertex domain (only face corner attributes could be
chosen), this has now been added. DT_layer_vert_items (used from the
modifier) already had this included so this was only an issue when using
the operator outside of the modifiers panel.
Since we now feature two domains, the single "VCOL" in the enum has been
split into "COLOR_VERTEX" and "COLOR_CORNER". This will break existing
scripts calling bpy.ops.object.datalayout_transfer and will be marked as
a breaking change in the release notes.
NOTE: there is another bug here when attributes of the same domain, but
different color types are in play and you want to transfer just a single
specific layer (but that is for a separate commit)
Maniphest Tasks: T103400
Differential Revision: https://developer.blender.org/D16935
Goal of this patch is to stop the invocation of OpenGL calls via the bgl module
on a none OpenGL GPU backend, report this as a python deprecation warning
and report this to the user.
## Deprecation warning to developers
```
>>> import bgl
>>> bgl.glUseProgram(0)
<blender_console>:1: DeprecationWarning: 'bgl.glUseProgram' is deprecated and will be removed in Blender 3.7. Report or update your script to use 'gpu' module.
```
## Deprecation message to users
The message to the user is shown as part of the Info Space and as a message box.
{F14159203 width=100%}
{F14158674 width=100%}
During implementation we tried several ideas:
# Use python warning as errors: This isn't fine grained enough and can show incorrect information to the user.
# Throw deprecation as error and use sys.excepthook to report the user message.
This required a custom exception class to identify the bgl deprecation and a CPython handler function to
be set during python initialization. Although this is the most flexible there was a disconnect between the
exception class, exception function and the excepthook registration.
# A variant how we handle autoexec failures. A flag is stored in Global and when set the user message is reported.
Not that flexible, but code is more connected to the boolean stored in the Global struct.
Although using Global struct isn't nice I chose this solution due to its traceability. It is clear to developers
reading the code how the mechanism works by using search all functionality of your IDE.
Reviewed By: MichaelPW, campbellbarton
Maniphest Tasks: T103863
Differential Revision: https://developer.blender.org/D16996
This makes it convenient to build blender without referencing
pre-compiled libraries which don't always work on newer Linux systems.
Previously I had to rename ../lib while creating the CMakeCache.txt
to ensure my systems libraries would be used.
This change ensures LIBDIR is undefined when WITH_LIBS_PRECOMPILED is
disabled, so any accidental use warns with CMake's `--warn-unused-vars`
argument is given.
These warnings can reveal errors in logic, so quiet them by checking
if the features are enabled before using variables or by assigning
empty strings in some cases.
- Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs
note that this may be left unset if it's not needed.
- Remove BOOST/OPENVDB/VULKAN references when disable.
- Define INC_SYS even when empty.
- Remove PNG_INC from freetype (not defined anywhere).
The original code used `BLI_polyfill_calc` which can create degenerate
triangles during triangulation per T103913. This causes the subsequent
overlap test to produce incorrect results in certain cases. Change to
using a "beauty" fill instead.
Differential Revision: https://developer.blender.org/D17015
There is a utility method on `CurvesGeometry` to build a map of the
curve for each point. Use that in two more places and make sure its
implementation is multithreaded, which gives a slight speedup
in a simple test file.
When doing partial reloads of asset libraries (only reload assets from
the current file, e.g. after undo re-allocated ID pointers), we'd end up
with assets that don't have their asset data read correctly. It would
execute a branch that didn't set the asset library object necessary to
create and store asset representations.
Steps to reproduce were:
* Open .blend file with geometry node assets in there
* In a geometry node editor, press Shift+A to open the add menu
* Cancel
* Move a node
* Undo
* Press Shift+A again
This allows an engine to perform GPU side view specification and let the
draw manager extract the culling informations (bounds).
To this end, the matrices ubo gets exposed to be able to write to it.
`compute_procedural_bounds()` need to be explicitely called before any
main pass using the culling result.
This abstraction is rarely used. It could be replaced by some more
general "query" API in the future. For now it's easier to just compare
pointers in the Set Position node where this was used.
This is possible now, because mesh positions are stored as flat `float3`
arrays (previously, they were stored as `MVert` with some other data
interleaved).
This changes how we access the points that correspond to each curve in a `CurvesGeometry`.
Previously, `CurvesGeometry::points_for_curve(int curve_index) -> IndexRange`
was called for every curve in many loops. Now one has to call
`CurvesGeometry::points_by_curve() -> OffsetIndices` before the
loop and use the returned value inside the loop.
While this is a little bit more verbose in general, it has some benefits:
* Better standardization of how "offset indices" are used. The new data
structure can be used independent of curves.
* Allows for better data oriented design. Generally, we want to retrieve
all the arrays we need for a loop first and then do the processing.
Accessing the old `CurvesGeometry::points_for_curve(...)` did not follow
that design because it hid the underlying offset array.
* Makes it easier to pass the offsets to a function without having to
pass the entire `CurvesGeometry`.
* Can improve performance in theory due to one less memory access
because `this` does not have to be dereferenced every time.
This likely doesn't have a noticable impact in practice.
Differential Revision: https://developer.blender.org/D17025
Struct members loc/size were misleading as they read as if the object
data stored object level transform channels. Rename these to match RNA
with a `texspace_*` prefix to make it clear these struct members only
apply to texture-space transform.
Also rename ME_AUTOSPACE & ME_AUTOSPACE_EVALUATED to
ME_TEXSPACE_FLAG_AUTO & ME_TEXSPACE_FLAG_AUTO_EVALUATED.
Give the "Value" input a higher search weight than the "Index"
input, since it's more likely that users will want to connect to
that. Based on feedback from Simon Thommes.
Socket declarations exist all the time and it would be useful to use
them for tooltips at all times, not just when there is a computed log.
Differential Revision: https://developer.blender.org/D16846
Avoid calling `interpolate_to_evaluate` while evaluating normals,
which has to look up attributes by name for every curve. Also avoid
duplicating the curve type switch in a few functions. I didn't observe
a performance difference, but theoretically this could reduce
overhead for many small curves.
Due to precision issues, the cosine value calculated with
`dot_v3v3(start, end)` can be outside the -1, 1 range causing `acosf`
to return `nan(ind)`.
Use `angle_signed_on_axis_v3v3_v3` instead. It returns more accurate
values, deduplicates code, and avoids these `nan` issues.
