After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
When using multiple materials in a single mesh the most time is spend in
counting the offsets of each material for the sorting.
This patch moves the counting of the offsets to render mesh data and
caches it as long as the geometry doesn't change.
This patch doesn't include multithreading of this code.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D11612
Clear the runtime data structs instead of individual members,
this simplifies adding new runtime members as there are at least
two places they would need to be cleared.
Resolves error in D8883.
This commit lets the join geometry node transfer dynamic attributes
to the result, the same way that point cloud and mesh attributes are
joined. The implementation is different though, because of an
optimization implemented for curves to avoid copying splines.
The result attribute is added with the highest priority domain (points
over splines), and the highest complexity data type. If one curve had
the attribute on the spline domain but not others, the point domain
values will be used.
Generally this is a bit lower level than I would have liked this code
to be, but should be efficient, and it's really not too complicated.
Differential Revision: https://developer.blender.org/D11491
Instead of building a set and then determining the final domain and
type for every attribute separately in the loop, construct a map with
the necessary data in the first place. This is simpler and should be
slightly more efficient.
Split from D11491
This is an implementation of T88722. It accepts a curve object and
for each spline, reverses the order of the points and all attributes.
This is more of a foundational node to support other nodes in the
future (like curve deform)
Selection takes spline domain attributes to determine which splines
are selected. If no selection is present all splines are reversed.
Differential Revision: https://developer.blender.org/D11538
This node implements the second option of T87429, creating points
along the input splines with the necessary evaluated information
for instancing: `tangent`, `normal`, and `rotation` attributes.
All generic curve point and spline attributes are copied to the
result points as well.
The "Count" and "Length" methods are just like the current options
in the resample node, but the output is points instead of a curve.
The "Evaluated" method uses the points you see on the curve directly,
and therefore should be the fastest.
The rotation data is retrieved from a transform matrix built with the
same method that the curve to mesh node uses. The radius attribute is
divided by 10 so the points don't look absurdly huge in the viewport.
In the future that could be an option.
For the implementation, one thing that could use an improvement
is the amount of temporary allocations while resampling to evaluated
points before the final points. I expect that reusing a buffer for
each thread would give a nice improvement.
Differential Revision: https://developer.blender.org/D11539
This patch allows Windows users to specify that their current blender
installation should be used to create thumbnails and be associated
with ".blend" files. This is done from Preferences / System. The only
way to do this currently is from the command-line and this is sometimes
inconvenient.
Differential Revision: https://developer.blender.org/D10887
Reviewed by Brecht Van Lommel
If the last decoded frame had the same timestamp as the GOP current
packet, then we would skip over this frame when fast forwarding and we
would seek until the end of the file.
This would could only be triggered reliably in single threaded mode.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11601
The warning would appear when using the `ENUM_OPERATORS()` macro inside
of an `extern "C"` block.
Didn't cause a warning in master currently, but in the
`asset-browser-poselib` branch.
After macro expansion, there would be C++ code in code with C linkage
(`extern "C"`). So make sure the expanded C++ code always uses C++
linkage.
The syntax used is totally C++ compliant: the C++ standard requires that
in such nested linkage specifications, the innermost one determines the
linking language (e.g. see
https://timsong-cpp.github.io/cppwp/n4659/dcl.link#4).
On the Windows platform there will be some errors printed to the
console if the user's thumbnail cache folder doesn't already exist.
While creating those folders there is an attempt to do so multiple
times and so we get errors when trying to create when exists. This
is caused by paths that have hard-coded forward slashes, which causes
our path processing routines to not work correctly. This patch defines
those paths using platform-varying separator characters.
Differential Revision: https://developer.blender.org/D11505
Reviewed by Brecht Van Lommel
Support calculating face normals when tessellating. When this is done
before updating vertex normals it gives ~20% performance improvement.
Now vertex normal calculation only needs to perform a single pass on the
mesh vertices when called after tessellation.
Extended versions of normal & looptri update functions have been added:
- BM_mesh_calc_tessellation_ex
- BM_mesh_normals_update_ex
Most callers don't need to be aware of this detail by using:
- BKE_editmesh_looptri_and_normals_calc
- BKE_editmesh_looptri_and_normals_calc_with_partial
- EDBM_update also takes advantage of this,
where calling EDBM_update with calc_looptri & calc_normals
enabled uses the faster normal updating logic.
Bypass stored edge-vectors for ~16% performance gains.
While this increases unit-length edge-vector calculations by around ~4x
the overhead of a parallel loop over all edges makes it worthwhile.
Note that caching edge-vectors per-vertex performs better and may be
worth investigating further, although in my tests this increases code
complexity with barley measurable benefits over not using cache at all.
Details about performance and possible optimizations are noted in
bm_vert_calc_normals_impl.
Rename function EDBM_update_generic to EDBM_update, use a parameters
argument for better readability.
Also add calc_normals argument, which will have benefits when
calculating normals and tessellation together is optimized.
For some custom rendering engines it's advantageous not to write the image files to disk.
An example would be a network rendering engine which does it's own image writing.
This feature is only supported when bl_use_postprocess is also disabled, since render
engines can't influence the saving behavior of the sequencer or compositor.
Differential Revision: https://developer.blender.org/D11512
Better to avoid explicit vectors components direct manipulation when a
generic operation for whole vector exists, if nothing else it avoids
potential mistakes in indices.
Those were caused by various tools used on degenerate geometry, see
T79775.
Note that fixes are as low-level as possible, to ensure they cover as
much as possible of unreported issues too.
We still probably have many more of those hidden in BLI_math though.
This commit does two things:
* Disallows creating more than one link from one socket to a multi socket input.
* Properly count links if there happen to be more than one link between the same sockets.
The new link counting should also be more efficient asymptotically.
Differential Revision: https://developer.blender.org/D11570
