Both the Alembic and USD libraries use double precision floating
point numbers internally to store time. However the Alembic I/O
code defaulted to floats even though Blender's Scene FPS, which is
generally used for look ups, is stored using a double type. Such
downcasts could lead to imprecise lookups, and would cause
compilation warnings (at least on MSVC).
This modifies the Alembic exporter and importer to make use of
doubles for the current scene time, and only downcasting to float
at the very last steps (e.g. for vertex interpolation). For the
importer, doubles are also used for computing interpolation weights,
as it is based on a time offset.
Although the USD code already used doubles internally, floats were used
at the C API level. Those were replaced as well.
Differential Revision: https://developer.blender.org/D13855
This patch adds color attributes to TexPaintSlot. This allows an easier selection
when painting color attributes.
Previously when selecting a paint tool the user had to start a stroke, before the
UI reflected the correct TexPaintSlot. Now when switching the slot the active
tool is checked and immediate the UI is drawn correctly.
In the future the canvas selector will also be used to select an image or image texture node
to paint on. Basic implementation has already been done inside this patch.
A limitation of this patch is that is isn't possible anymore to rename images directly from
the selection panel. This is currently allowed in master. But as CustomDataLayers
aren't ID fields and not owned by the material supporting this wouldn't be easy.
{F12953989}
In the future we should update the create slot operator to also include color attributes.
Sources could also be extended to use other areas of the object that use image textures
(particles, geom nodes, etc... ).
Reviewed By: brecht
Maniphest Tasks: T96709
Differential Revision: https://developer.blender.org/D14455
Avoid Blender overwriting artist's choices. The automatic change from
"Hold" (i.e. bidirectional extrapolation) to "Hold Forward" (i.e. only
extrapolate forward in time) has been removed.
This patch does not change strip evaluation. Between two strips, the
first with `None` extrapolation and the next with `Hold`, neither strip
will evaluate, which matches previous behavior. A future patch can
change the evaluation behavior.
Reviewed By: RiggingDojo, sybren
Maniphest Tasks: T82230
Differential Revision: https://developer.blender.org/D14230
The problem was the original file had some vertex weight information, but the weights array was empty, so the duplication was not done and the free memory crashed.
To avoid this type of errors, now before duplicate weights the function checks the pointer and also the number of weights elements in the array to avoid the duplicatiopn of empty data.
Currently, only Lightgroups that exist in the current view layer can be
selected from object or world properties.
The internal UI code already has support for search fields that accept
unknown input, so I just added that to the API and use it for lightgroups.
When a lightgroup is entered that does not exist in the current view layer
(e.g. because it's completely new, because the view layer was switched or
because it was deleted earlier), a new button next to it becomes active and
adds it to the view layer when pressed.
Differential Revision: https://developer.blender.org/D14540
This seems to serve no purpose anymore, I don't see anywhere that
CD_MFACE is requested for modifier evaluation, and it's confusing
to have this in this final normals computation function.
Found while looking into D14579.
Differential Revision: https://developer.blender.org/D14580
The mechanism to instance meshes when there are no modifiers did not take
into account that modifiers might get re-evaluated from an operator that
requests loop normals. Now check for that case and no longer use the
instance then.
In the future, a better solution may be to compute loop normals on demand
as is already done for poly and vertex normals, but that would be a big
change.
Differential Revision: https://developer.blender.org/D14579
This implements two optimizations:
* Reduce virtual function call overhead when a non-standard virtual
array is used as input.
* Use a lambda in `type_conversion.cc`.
In my test setup, which creates a float attribute filled with the index,
the running time drops from `4.0 ms` to `2.0 ms`.
Differential Revision: https://developer.blender.org/D14585
The first element of the iterator was not being tested against the flag.
So in some cases it would lead to more objects been made into
single-user than the active (or selected) ones.
Change the modifier name in the modifier stack to "Curvature 3D"
to be consistent with the modifier name in the drop-down.
Differential Revision: https://developer.blender.org/D14476
Set the curve resolution to Bezier and Nurbs curves when converting
data using `curves_to_curve_eval`. This was missed in 9ec12c26f1.
Differential Revision: https://developer.blender.org/D14577
Add "for_write" on function names that retrieve mutable data arrays.
Though this makes function names longer, it's likely worth it because
it allows more easily using the const functions in a non-const context,
and reduces cases of mistakenly retrieving with edit access.
In the long term, this situation might change more if we implement
attributes storage that is accessible directly on `CurvesGeometry`
without duplicating the attribute API on geometry components,
which is currently the rough plan.
Differential Revision: https://developer.blender.org/D14562
Original rework of caches during undo/redo (see D8183) had a very bad
flaw hidden in it: using the key of a ghash as source of data.
While this was effectively working then (cache pointer itself being part
of the key, and said cache pointers not being cleared on file write),
this is a general very bad way to do things.
Now that cache pointers are more and more cleared on file write (as part
of clearing runtime-data to reduce false-positives when checking if an
ID has changed or not), this has to be fixed properly by:
* Not storing the cache pointer itself in the IDCacheKey.
* In undo context, in readfile code trying to preserve caches, store the
cache pointers as values of the mapping, together with the usages counter
The first change potentially affects all usages of
`BKE_idtype_id_foreach_cache`, but in practice this code is only used by
memfile reading code (i.e. undo) currently.
Related to T97015.
Reviewed By: brecht
Maniphest Tasks: T97015
Differential Revision: https://developer.blender.org/D14559
Python exceptions are now shown in the info editor,
this also resolves an old bug where errors were printed twice.
This was originally based on D9752 by @ShadowChaser although many
changes have been made from the original patch.
Details:
- BPy_errors_to_report no longer prints additional output.
- BKE_report_print_test was added so it's possible to check if calling
BKE_report also printed to the stdout.
- Callers to BPy_errors_to_report are responsible for ensuring output
is printed to the stdout/stderr.
- Python exceptions no longer add a trailing newline,
needed to avoid blank-space when displayed in the info-editor.
The `BVHCacheType bvh_cache_type` parameter defines specific
`BVHTrees` that cannot be customized.
So it doesn't make sense to pass this value to any
`*bvhtree_from_[...]_ex` function as the `BVHTrees` created in these
cases are custom and cannot be saved in the cache.
This also resulted in a nice cleanup in the code.
Differential Revision: https://developer.blender.org/D14479
In summary the changes are:
- Merge all `bvhtree_from_mesh_*.*_setup_data` in a single utility
- Create `bvhtree_from_editmesh_setup_data`
- Setup data only once in `BKE_bvhtree_from_mesh_get` and `BKE_bvhtree_from_editmesh_get`
Also the behavior of `BKE_bvhtree_from_mesh_get` and
`BKE_bvhtree_from_editmesh_get` changed a bit:
- If a null tree is cached, don't set the `data` to zero. This tree is not an error and the others data can still be used.
- If a null tree is returned, don't set the `data` to zero. Matches the previous change.
Differential Revision: https://developer.blender.org/D14549
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
This adds missing cases to detect edit mode for Curves objects.
Unlike other object types, Curves do not have specific edit data,
rather we edit the original data directly, and rely on `Object.mode`.
For this, `BKE_object_data_is_in_editmode` had to be modified to
take a pointer to the object. This affects two places: the outliner
and the dependency graph. For the former place, the object pointer
is readily available, and we can use it. For the latter, the object
pointer is not available, however since it is used to update edit
mode pointers, and since Curves do not have such data, we can
safely pass null to the function here.
This also fixes the assertion failure that happens when closing a file
in edit mode.
Differential Revision: https://developer.blender.org/D14330
Instead of using `CurveEval` to draw the curve wire edges, use
the new `Curves` data-block, which is already built as part of
an object's evaluated geometry set whenever there is a
`CurveComponent`.
This means that we can remove `Curve`'s temporary ownership
of `CurveEval` for drawing (added in 9ec12c26f1),
which caused a memory leak as described in T96498.
In my testing this improved performance by around 1.5x during
viewport playback, back to the performance of 3.1 before the
curve data structure transition started.
The next step of using the GPU to do the final curve evaluation
for the viewport is described in T96455, but is unrelated.
Differential Revision: https://developer.blender.org/D14551
This commit furthers some of the changes that were started in
rBb9febb54a492 and subsequent commits by changing the way surface
objects are presented to render engines and other users of evaluated
objects in the same way. Instead of presenting evaluated surface objects
as an `OB_SURF` object with an evaluated mesh, `OB_SURF` objects
can now have an evaluated geometry set, which uses the same system
as other object types to deal with multi-type evaluated data.
This clarification makes it more obvious that lots of code that dealt
with the `DispList` type isn't used. It wasn't before either, now it's
just *by design*. Over 1100 lines can be removed. The legacy curve
draw cache code is much simpler now too. The idea behind the further
removal of `DispList` is that it's better to focus optimization efforts
on a single mesh data structure.
One expected functional change is that the evaluated mesh from surface
objects can now be used in geometry nodes with the object info node.
Cycles and the OBJ IO tests had to be tweaked to avoid using evaluated
surface objects instead of the newly exposed mesh objects.
Differential Revision: https://developer.blender.org/D14550
This adds a new Grow/Shrink brush which is similar to the Length
brush in the old hair system.
* It's possible to switch between growing and shrinking by hold
down ctrl and/or by changing the direction enum.
* 3d brush is supported.
* Different brush falloffs are supported.
* Supports scaling curves uniformly or shrinking/extrapolating
them. Extrapolation is linear only in this patch.
* A minimum length settings helps to avoid creating zero-sized curves.
Differential Revision: https://developer.blender.org/D14474
The internal camera used to render the thumbnails also has to consider
`clip_start` and `clip_end`.
Reviewed By: Severin
Maniphest Tasks: T95678
Differential Revision: https://developer.blender.org/D14138
This patch adds channel region to VSE timeline area for drawing channel
headers. It is synchronizedwith timeline region. 3 basic features are
implemented - channel visibility, locking and name.
Channel data is stored in `SeqTimelineChannel` which can be top-level
owned by `Editing`, or it is owned by meta strip to support nesting.
Strip properties are completely independent and channel properties are
applied on top of particular strip property, thus overriding it.
Implementation is separate from channel regions in other editors. This
is mainly because style and topology is quite different in VSE. But
also code seems to be much more readable this way.
Currently channels use functions similar to VSE timeline to draw
background to provide illusion of transparency, but only for background
and sfra/efra regions.
Great portion of this patch is change from using strip visibility and
lock status to include channel state - this is facilitated by functions
`SEQ_transform_is_locked` and `SEQ_render_is_muted`
Originally this included changes in D14263, but patch was split for
easier review.
Reviewed By: fsiddi, Severin
Differential Revision: https://developer.blender.org/D13836
Add support for the Curves object to the "Set Origin" and "Apply Object
Tansform" operators. Also change the automatic handle calculation to
avoid adding Bezier attributes if they don't need to be added.
Differential Revision: https://developer.blender.org/D14526
These functions are very simple, but some of them were showing up in
in profiles for curves sculpt mode and various curve nodes. Making sure
they are inlined will allow avoiding the compiler to optimize this logic
much better.
Differential Revision: https://developer.blender.org/D14529
Light groups are a type of pass that only contains lighting from a subset of light sources.
They are created in the View layer, and light sources (lamps, objects with emissive materials
and/or the environment) can be assigned to a group.
Currently, each light group ends up generating its own version of the Combined pass.
In the future, additional types of passes (e.g. shadowcatcher) might be getting their own
per-lightgroup versions.
The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render
engines could make use of it in the future.
Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup
in the View Layer and the name that's set in an object's settings must match for it to be
included.
Currently, changing a Lightgroup's name does not update objects - this is planned for the
future, along with other features such as denoising for light groups and viewing them in
preview renders.
Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97).
Differential Revision: https://developer.blender.org/D12871
Also solves two warnings from the previous similar commit,
f688e3cc31. The change to the grease pencil
modifier is quite suspicious, but doesn't change the behavior,
which was already broken.
The Alembic procedural was only enabled during viewport renders
originally because it did not have any caching strategy. Now that
is does, we can allow its usage in final renders.
This also removes the `dag_eval_mode` argument passing to
`ModifierTypeInfo.dependsOnTime` which was originally added to detect if
we are doing a viewport render for enabling the procedural.
Differential Revision: https://developer.blender.org/D14520
This commit moves declarations that depend on `FN_field.hh` out of
`BKE_geometry_set.hh` into `BKE_geometry_fields.hh`. This helps to
reduce the number of areas that need to depend on the functions module,
which recently came in in review of D11591.
In the future we may have a library of standard field inputs in order to
make composing algorithms easier, so it makes sense to have a header
that could contain them and some basic related utilities relating the
concepts of geometry and fields.
Reducing use of unnecessary headers may also reduce compilation time.
Differential Revision: https://developer.blender.org/D14517
This commit ports the "Set Handle Positions" and "Set Hanle Type"
nodes to use the new curves data-block. The nodes become simpler
and likely much faster too, though they're usually not the bottleneck
anyway.
Most of the code is ported from `BezierSpline` directly. The majority
of the complexity comes from the interaction between different
automatically calculated handle types. In comparison `BezierSpline`,
the calculation of auto handles is done eagerly-- mostly because it's
simpler. Eventually lazy calculation might be good to add.
Differential Revision: https://developer.blender.org/D14464
Direct replacement of code:
- memcpy of a single point is done as a shallow_copy() assignment.
- memcpy of a range of points is done with an explicit cast to void*
to tell compiler that we really want to memcpy even a non-trivial
type.
In some cases it seems that memcpy can be used more (points are copied
in a loop). Those left as-is since this is supposed to be a simple
cleanup.
Differential Revision: https://developer.blender.org/D14505
