Split the code, use preconditions, use rather plain language for
function names and add comments where it is not totally obvious, what
the code is supposed to do.
This refactors `SocketValueVariant` with the following goals in mind:
* Support type erasure so that not all users of `SocketValueVariant` have
to know about all the types sockets can have.
* Move towards supporting "rainbow sockets" which are sockets whoose
type is only known at run-time.
* Reduce complexity when dealing with socket values in general. Previously,
one had to use `SocketValueVariantCPPType` a lot to manage uninitialized
memory. This is better abstracted away now.
One related change that I had to do that I didn't see coming at first was that
I had to refactor `set_default_remaining_outputs` because now the default value
of a `SocketValueVariant` would not contain any value. Previously, it was
initialized the zero-value of the template parameter. Similarly, I had to change
how implicit conversions are created, because comparing the `CPPType` of linked
sockets was not enough anymore to determine if a conversion is necessary.
We could potentially use `SocketValueVariant` for the remaining socket types in the
future as well. Not entirely sure if that helps yet. `SocketValueVariant` can easily be
adapted to make that work though. That would also justify the name
"SocketValueVariant" better.
Pull Request: https://projects.blender.org/blender/blender/pulls/116231
Add a utility to set attribute values to their default, use it in a few
places that have already done this samething. Also:
- Don't create resolution or cyclic attributes unnecessarily
- Use API function to set new curve's type
- Always create the new selection on the curve domain
- Remove selection before resize to avoid unnecessary work
Before #108014, toggling "Auto Smooth" was an easy way to disable
evaluation of custom normals and face corner normals for faster
viewport playback performance. Now that corner normals are calculated
automatically as necessary, it's helpful to still have a way to disable
expensive normal computation for faster playback.
This commit adds a "Normals" scene simplify setting. To avoid a bunch
of complexity, it just influences which normals are requested from the
object by viewport rendering. In my tests, skipping calculating at
least doubled viewport FPS in a few test files with a large mesh with
custom normals. This works well because normals are cached and lazily
calculated.
Pull Request: https://projects.blender.org/blender/blender/pulls/113975
USD: optionally author subdivision schema on export
This PR adds support for exporting USD assets which have the subdivision
schema applied. Current behavior prior to this PR is that the effects of
Subdivision Surface modifiers are always applied to their mesh prior to
export, such that it is not possible to recover the original base mesh.
In this PR we provide three options for the subdiv schema type:
Ignore - Export base mesh without subdivision with USD Scheme = None
Tessellate - Export subdivided mesh with USD Scheme = None
Best Match (default) - Export base mesh with USD Scheme = Catmull-Clark
"Best Match" here means that Blender will set a subdiv scheme type in
the exported USD asset when it is possible to closely match the
subdivision surface type that was authored in Blender. At this time
Blender provides two subdivision types: Catmull-Clark and Simple.
Because Simple does not have a corresponding subdivision type in USD, we
do not attempt to convert or represent it, and instead the Simple subdiv
modifier will be evaluated and applied to the mesh during export.
Whenever a Catmull-Clark Subdivision Surface modifier is applied to an
object, and is the last modifier in the stack, it is possible to set the
subdiv scheme to Catmull-Clark for the respective prim in the exported
USD file.
Authored by Apple: Matt McLin
Co-authored-by: Matt McLin <mmclin@apple.com>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/113267
The main problem is, that retiming key frame index is defined in strip
content space (0 <> seq->len -1), but API functions must rescale this
index by applying `SEQ_time_media_playback_rate_factor_get()` and return
value in timeline space.
This wasn't done properly, in many places, some had challenges:
- `SEQ_retiming_key_timeline_frame_get()` returned floats, but UI
expects integers. Otherwise keys may be drawn inbetween frames.
- Function `right_fake_key_frame_get()` must return exact frame of
keys, otherwise lookup by frame would fail. But `retime_key_draw()`
can not compensate position of last fake key, so this has to be done
in `fake_keys_draw()` and `try_to_realize_virtual_key()`.
- For transformation to work as expected, double precision value has
to be used for frame index.
- For UI either API would had to be extended to provide helper functions
to deal with FPS mismatch, or it needs to know the FPS difference.
I have opted to put `SEQ_time_media_playback_rate_factor_get()` in
"public" headers. Neither solution is great.
No functional changes.
Extracting the section inside the `LISTBASE_FOREACH`
that inserts keyframes based on a `KS_Path`.
This moves variables closer to where they are used and
will allow to simplify the code later.
This also improves variable names by spelling out
the words instead of using abbreviations.
e.g. `ks` -> `keying_set`
Pull Request: https://projects.blender.org/blender/blender/pulls/116224
Whenever movie frame encoding needs to be in non-RGBA format (pretty much
always, e.g. H.264 uses YUV etc.), the ffmpeg code has been using
sws_scale() since 2007. But that one is completely single threaded.
It can be multi-threaded by passing "threads" option to SwsContext
(in a cumbersome way), combined with sws_scale_frame API. Which however
requires frame data buffers to be allocated via AVBuffer machinery.
Rendering a 300-frame part of Sprite Fright Edit (target H.264 Medium):
- Windows Ryzen 5950X: 16.1 -> 12.0 seconds (generate_video_frame part
4.7 -> 0.7 sec).
- Mac M1 Max: 13.1 -> 12.5 sec. Speedup is smaller, but comparatively,
entirely other part of movie rendering (audio resampling inside audaspace)
is way more expensive compared to the windows machine.
The asserts added in b840ba1f59 revealed the bug, which was passing the
wrong Scene pointer to `BKE_view_layer_synced_ensure` in affected code.
Issue likely introduced in 68589a31eb, was probably never actually a
crash-case because the viewlayer would always be in sync already when
this was called from the Outliner (besides perhaps some extremely rare
edge cases).
To be backported to potential bugfix release of 4.0 together with
b840ba1f59 commit.
Add support for enum values in ID properties.
This is needed for the "Menu Switch" node implementation (#113445) which
relies on ID properties for the top-level modifier UI.
Enums items can optionally be added to the UI data of integer
properties. Each property stores a full set of the enum items to keep
things simple.
Enum items can be added to properties using the `id_properties_ui`
function in the python API. A detailed example can be found in the
`bl_pyapi_idprop.py` test.
There is currently no support yet for editing enum items through the UI.
This is because the "Edit Property" feature is implemented entirely
through a single operator (`WM_OT_properties_edit`) and its properties.
Buttons to add/remove/move items would be operators changing another
operator's properties. A refactor of the custom properties UI is likely
required to make this work.
Pull Request: https://projects.blender.org/blender/blender/pulls/114362
Remove abstract edge and face types. The design is to not abstract away
the code data structures like this and focus on sharing code more with the
rest of Blender rather than within sculpt mode.
Before this happened as two steps: first allocating the PBVH with a type,
then calculating the BVH and filling it with data. This just confused things,
so change to allocating the struct when building it. Also move the functions
to the C++ namespace, and fix some cases of requiring the PBVH to be set
when it wasn't yet.
This `update_vertex_data` only found nodes with the color update
tag and also added redraw tags. But whenever nodes are marked
for a color update, those redraw tags are already set anyway.
It appears this was meant to solve problems switching active
color attributes during undo and redo, but it doesn't make a
difference when this function is removed.
