This is mostly a cleanup to avoid hardcoding the eager calculation of
normals it isn't necessary, by reducing calls to `BKE_mesh_calc_normals`
and by removing calls to `BKE_mesh_normals_tag_dirty` when the mesh
is newly created and already has dirty normals anyway. This reduces
boilerplate code and makes the "dirty by default" state more clear.
Any regressions from this commit should be easy to fix, though the
lazy calculation is solid enough that none are expected.
This adds support for rendering motion blur for volumes, using their
velocity field. This works for fluid simulations and imported VDB
volumes. For the latter, the name of the velocity field can be set per
volume object, with automatic detection of velocity fields that are
split into 3 scalar grids.
A new parameter is also added to scale velocity for more artistic control.
Like for Alembic and USD caches, a parameter to set the unit of time in
which the velocity vectors are expressed is also added. For Blender gas
simulations, the velocity unit should always be in seconds, so this is
only exposed for volume objects which may come from external OpenVDB
files.
These parameters are available under the `Render` panels for the fluid
domain and the volume object data properties respectively.
Credits: kernel advection code from Tangent Animation's Blackbird based
on earlier work by Geraldine Chua
Differential Revision: https://developer.blender.org/D14629
The fix ensures that the reference count for `IShellItem *pSI` is decremented,
preventing a memory leak. For `IFileOperation *pfo` the decrement of the
reference count is only attempted when `CoCreateInstance` is successful.
Additionally, the gotos have been replaced with nested if/else statements.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14681
Since shader sources are now parsed on demand via `GPUShaderCreateInfo`,
sources are not available to be read via
`GPU_shader_get_builtin_shader_code`.
Currently this results in a crash as the code tries to read `NULL`
pointers.
`GPU_shader_get_builtin_shader_code` was created with the intention of
informing the user how a builtin shader works, thus "replacing"
detailed documentation.
Therefore this function doesn't really have a practical use in an addon.
So, instead of updating the function (which would require several
changes to the gpu module), remove it and improve the documentation.
Release Notes: https://wiki.blender.org/wiki/Reference/Release_Notes/3.2/Python_API#Breaking_Changes
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D14678
Noted as part of T94775 investigation by Wayde Moss (@GuiltyGhost),
thanks!
NOTE: this mistake probably did not have any pratical impact in current
code, at least for overrides.
This is to make the codegen and shading nodes object type agnostic. This
is essential for flexibility of the engine to use the nodetree as it see
fits.
The essential volume attributes struct properties are moved to the
`GPUMaterialAttribute` which see its final input name set on creation.
The binding process is centralized into `draw_volume.cc` to avoid
duplicating the code between multiple engines. It mimics the hair attributes
process.
Volume object grid transforms and other per object uniforms are packed into
one UBO per object. The grid transform is now based on object which simplify
the matrix preparations.
This also gets rid of the double transforms and use object info orco factors
for volume objects.
Tagging @brecht because he did the initial implementation of Volume Grids.
Continuing the refactors described in T93602, this commit moves
the face dot tag set by the subdivision surface modifier out of
`MVert` to `MeshRuntime`. This clarifies its status as runtime data
and allows further refactoring of mesh positions in the future.
Before, `BKE_modifiers_uses_subsurf_facedots` was used to check
whether subsurf face dots should be drawn, but now we can just check
if the tags exist on the mesh. Modifiers that create new new geometry
or modify topology will already remove the array by clearing mesh
runtime data.
Differential Revision: https://developer.blender.org/D14680
The UI description for the `bpy.types.ActionFCurves.remove` was incorrect;
seemingly a copy-paste typo from the `rna_Action_groups_remove` function.
Reviewed By: sybren, Blendify
Differential Revision: https://developer.blender.org/D14659
Preserve multi socket link order when copying nodes or adding a new
group input sockets by linking directly to multi inputs from the group
input node's extension socket.
This is done by also copying the `multi_input_socket_index` when
the new links are created by copying existing or temporary links.
Reviewed By: Hans Goudey
Differential Revision: http://developer.blender.org/D14535
Reimplement copy geometry node groups in C. The version implemented in
Python could also manually copy the animation data, but it's more
standard to do this with `BKE_id_copy_ex` and `LIB_ID_COPY_ACTIONS`.
Differential Revision: https://developer.blender.org/D14615
`rna_NodeSocket_refine` and `rna_Node_refine` take significant time
when building the `NodeTreeRef` acceleration data structure, but they
aren't used at all. This commit removes their eager calculation and
instead creates them on-demand in the `rna()` functions. They also
aren't inlined to avoid including `RNA_prototypes.h` in the header.
Differential Revision: https://developer.blender.org/D14674
Continued improvements to the new C++ based OBJ importer.
Performance: about 2x faster.
- Rungholt.obj (several meshes, 263MB file): Windows 12.7s -> 5.9s, Mac 7.7s -> 3.1s.
- Blender 3.0 splash (24k meshes, 2.4GB file): Windows 97.3s -> 53.6s, Mac 137.3s -> 80.0s.
- "Windows" is VS2022, AMD Ryzen 5950X (32 threads), "Mac" is Xcode/clang 13, M1Max (10 threads).
- Slightly reduced memory usage during import as well.
The performance gains are a combination of several things:
- Replacing `std::stof` / `std::stoi` with C++17 `from_chars`.
- Stop reading input file char-by-char using `std::getline`, and instead read in 64kb chunks, and parse from there (taking care of possibly handling lines split mid-way due to chunk boundaries).
- Removing abstractions for splitting a line by some char,
- Avoid tiny memory allocations: instead of storing a vector of polygon corners in each face, store all the corners in one big array, and per-face only store indices "where do corners start, and how many". Likewise, don't store full string names of material/group names for each face; only store indices into overall material/group names arrays.
- Stop always doing mesh validation, which is slow. Do it just like the Alembic importer does: only do validation if found some invalid faces during import, or if requested by the user via an import setting checkbox (which defaults to off).
- Stop doing "collection sync" for each object being added; instead do the collection sync right after creating all the objects.
Cleanup / Robustness:
This reworking of parser (see "removing abstractions" point above) means that all the functions that were in `parser_string_utils` file are gone, and replaced with different set of functions. However they are not OBJ specific, so as pointed out during review of the previous differential, they are now in `source/blender/io/common` library.
Added gtest coverage for said functions as well; something that was only indirectly covered by obj tests previously.
Rework of some bits of parsing made the parser actually better able to deal with invalid syntax. E.g. previously, if a face corner were a `/123` string, it would have incorrectly treated that as a vertex index (since it would get "hey that's one number" after splitting a string by a slash), instead of properly marking it as invalid syntax.
Added gtest coverage for .mtl parsing; something that was not covered by any tests at all previously.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14586
- Was not exporting "Poly" curves at all,
- Had a crash when a single object contains multiple curves of different types -- it had a check for "is this nurbs compatible?" only for the first curve, and then proceeded to treat the other curves as nurbs as well, without checking for validity.
Fixed both issues by doing the same logic as in the old python exporter:
- Poly curves are supported,
- Treat object as "nurbs compatible" only if all the curves within it are nurbs compatible.
Added test coverage in the gtest suite. While at it, made "all_curves" test use the "golden obj file template" style test, instead of a manually coded test that checks intermediate objects but does not check the final exported result.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14611
The new 3.1 OBJ exporter code had incorrect code to determine which vertex group a polygon belongs to -- for each vertex, it was only looking at the first vertex group it has, and not using the group weight either.
This 99% fixes T96824, but not 100% on the user's submitted mesh -- exactly two faces from that mesh get assigned a different group compared to the old exporter. Either choice is "correct" given that on these two faces there are two vertex groups with equal contribution. The old Python exporter was picking the group based on internal python group name map order, whereas the new C++ exporter is picking the group with the lowest index, in case of ties. I'm not sure if it's possible to fix this TBH, will have to wait until the importer is also C++.
While at it, the new vertex group calculation code was doing a lot of redundant work for each and every face (traversing group lists several times, allocating & freeing memory), so I fixed that. Exporting a 6-level subdivided Monkey mesh with 30 vertex groups was taking 810ms, now takes 330ms.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14500
This adds a basic unit test to check USD has been correctly
build with imaging components to support building both with
the old and new libs, it automatically adds the test when it
detects a library with imaging enabled. (platform devs will
have to pay attention it runs the test to validate the libs
build correctly)
For future use in the code it also defines a USD_HAS_IMAGING
define one could check if we're building against an USD lib
that has it (just because we build/ship with it, doesn't
mean downstream builds will ship with it, so we'll have
to be a little pro-active there)
Reviewed By: sybren
Differential Revision:https://developer.blender.org/D14456
In some circumstances singular files with numbers in their name (like
turntable-1080p.png or frame-1042.png) might be detected as a UDIM.
The root cause in this particular instance was because `BKE_image_get_tile_info`
believed this file to be a tiled texture and replaced the filename with
a tokenized version of it. However, later on, the code inside `image_open_single`
did not believe it was tiled because only 1 file was detected and our
tiled textures require at least 2. This discrepancy lead to the broken
filename situation.
This was a regression since rB180b66ae8a1f as that introduced the
tokenization changes.
Differential Revision: https://developer.blender.org/D14667
If the `wpoly` vector was small, the `wpoly_new` pointer could point
to part of its inline buffer on the stack, which becomes invalid out of
that scope. Instead, store `wpoly_new` as a span, and assign it properly
from the moved vector.
The HIG mentions that redundant words like "Enables" or "Activates"
shouldn't be used for tooltips of boolean properties. In this case
"When checked" was the redundant language that was implied by
the checkbox itself-- convention is to just state what the property
does when it's on.
Also change a few conjugations to the imperative and simplify
wording slightly, in order to be more consistent with language
elsewhere in Blender, and to be a bit more direct.
Differential Revision: https://developer.blender.org/D14644
Introduced by my recent commit: {rB3acbe2d1e933}
Lead to crash when insert_keyframe_direct() was called. Keyframing
crashed for NLA special properties (influence, animated_time),
driven properties, etc.
This commit changes the Curve to Mesh node to work with `Curves`
instead of `CurveEval`. The change ends up basically completely
rewriting the node, since the different attribute storage means that
the decisions made previously don't make much sense anymore.
The main loops are now "for each attribute: for each curve combination"
rather than the other way around, with the goal of taking advantage
of the locality of curve attributes. This improvement is quite
noticeable with many small curves; I measured a 4-5x improvement
(around 4-5s to <1s) when converting millions of curves to tens of
millions of faces. I didn't obverse any change in performance compared
to 3.1 with fewer curves though.
The changes also solve an algorithmic flaw where any interpolated
attributes would be evaluated for every curve combination instead
of just once per curve. This can be a large improvement when there
are many profile curves.
The code relies heavily on a function `foreach_curve_combination`
which calculates some basic information about each combination and
calls a templated function. I made assumptions about unnecessary reads
being removed by compiler optimizations. For further performance
improvements in the future that might be an area to investigate.
Another might be using a "for a group of curves: for each attribute:
for each curve" pattern to increase the locality of memory access.
Differential Revision: https://developer.blender.org/D14642
This is a partial fix to the fact that rendering with EEVEE or other GL
render engines is currently blocking the whole UI when asking to redraw
a viewport.
This patch just bypasses the viewport bind (containing the Draw Context
lock) and the following drawing. There is an update tagging to not
loose a viewport update if there was one asked.
Other queries other than view redraw (such as selection depth drawing or
offscreen drawing) will still block the whole UI as they need immediate
data feedback.
Ping @Severin for the change in `WM_draw_region_viewport_bind()`.
I'm assuming this is not an issue because it's highly unlikely to
bring up this operator during rendering. But in this case, it would just
lock as usual.
The bypassing in `DRW_notify_view_update` might be a bit overparanoid.
The ported normal calculation from ceed37fc5c neglected to
use the tilt attribute to rotate the normals around the tangents.
This commit adds that behavior back, adding a new math header file
to avoid duplicating the rotation function for normalized axes.
Differential Revision: https://developer.blender.org/D14655
