Was using some threaded queue on top of task pool, tssk...
Now using properly task pool directly to crunch chunks of smooth fans.
No noticable changes in speed.
Tried to completely get rid of the 'no threading with few loops' code,
but even just creating/freeing the task pool, without actually pushing
any task, is enough to make code 50% slower in worst case scenario (i.e.
few thousands of simple cube objects).
The root of the issue was in custom normal code, so far it assumed that
we could only have one cyclic smooth fan around each vertex, which is...
blatantly wrong (again, the two cones sharing same vertex tip e.g.).
This required a rather deep change in how smooth fans/clnor spaces are processed,
took me some time to find a 'good' solution.
Note that new code is slightly slower than previous one (maybe about 5%),
not much to be done here, am afraid.
Tested against all older report files I could find, seems OK.
Use expanded names for bmesh primitive operations
(urmv jvke semv jfke).
Use 'bmesh_kernel_' prefix,
these functions aren't intended for wide use so favor readability.
Remove BM_face_vert_separate,
it wasn't used and only skipped step of finding correct loop of face.
It might be useful to keep the search string stored in some cases, but
in most it's not useful but confusing. Especially if the string is taken
from a menu showing a different enum.
When the loop region passed in had no loops to edge-split from,
it was assumed nothing needed to be done.
This ignored the case where loops share a vertex
without any shared edges.
Now BM_face_loop_separate_multi behaves like BM_face_loop_separate.
Fixed error where faces remained connected by verts in BM_mesh_separate_faces.
This commit adds new features to the breakdowner, giving animators more
control over what gets interpolated by the breakdowner. Specifically:
"Just as G R S let you move rotate scale, and then X Y Z let you do that
in one desired axis, when using the Breakdower it would be great to be
able to add GRS and XYZ to constrain what transform / axis is being
breakdowned."
As requested here:
https://rightclickselect.com/p/animation/csbbbc/breakdowner-constrain-transform-and-axis
Notes:
* In addition to G/R/S, there's also B (Bendy Bone settings and C (custom properties)
* Pressing G/R/S/B/C or X/Y/Z again will turn these constraints off again
- Connectivity length was overwritten by distance to closest selected.
- Vertices used the 'island' center of the closest vertex,
even if it wasn't connected.
Now optionally keep track of the original index of used as the closest
connected distance.
To support this needed to add optional support for islands of 1 vertex.
The changes introduced in rB3e628eefa9f55fac7b0faaec4fd4392c2de6b20e
made the non-subframe frame change behaviour less intuitive, by always
truncating downwards, instead of rounding to the nearest frame instead.
This made the UI a lot less forgiving of pointing precision errors
(for example, as a result of hand shake, or using a tablet on a highres scren)
This commit restores the old behaviour in this case only (subframe inspection
isn't affected by these changes)
Selection loop would draw the selection ignoring xray.
Now draw in a separate pass after clearing the depth buffer,
as with regular drawing.
Also disable depth sorting,
caller can sort the hit-list by depth if needed.
Intended to replace legacy GL_SELECT, without the limitations of
sample queries which can't access depth information.
This commit adds VIEW3D_SELECT_PICK_NEAREST and VIEW3D_SELECT_PICK_ALL
which access the depth buffers to detect whats under the pointer,
so initial selection is always the closest item.
The performance of this method depends a lot on the OpenGL
implementations glReadPixels.
Since reading depth can be slow, buffers are cached for object picking
so selecting re-uses depth data, performing 1 draw instead of 3
(for 24, 18, 10 px regions, picking with many items under the pointer).
Occlusion queries draw twice when picking nearest,
so worst case 6x draw calls per selection.
Even with these improvements occlusion queries is faster on AMD hardware.
Depth selection is disabled by default, toggle option under select method.
May enable by default if this works well on different hardware.
Reviewed as D2543
The issue was caused by sometimes negative color returned by the filter node.
Seems to be caused by precision issues. Don't see any reason why we would want
negative colors in output. Those only causing issues later on.
Suspended pools allows to push huge amount of initial tasks
without any threading synchronization and hence overhead.
This gives ~50% speedup of cached rigid body with file from
T50027 and seems to have no negative affect in other scenes
here.
The idea is to allow some amount of tasks to be pushed from working
thread to it's local queue, so we can acquire some work without doing
whole mutex lock.
This should allow us to remove some hacks from depsgraph which was
added there to keep threads alive.
This allows us to avoid TLS stored in pool which gives us advantage of
using pre-allocated tasks pool for the pools created from non-main thread.
Even on systems with slow pthread TLS it should not be a problem because
we access it once at a pool construction time. If we want to use this more
often (for example, to get rid of push_from_thread) we'll have to do much
more accurate benchmark.
Basically move all thread-specific data (currently it's only task
memory pool) from a dedicated array of taskScheduler to TaskThread.
This way we can add more thread-specific data in the future with
less of a hassle.
This feature was adding extra complexity to task scheduling
which required yet extra variables to be worried about to be
modified in atomic manner, which resulted in following issues:
- More complex code to maintain, which increases risks of
something going wrong when we modify the code.
- Extra barriers and/or locks during task scheduling, which
causes extra threading overhead.
- Unable to use some other implementation (such as TBB) even for
the comparison tests.
Notes about other changes.
There are two places where we really had to use that limit.
One of them is the single threaded dependency graph. This will
now construct a single-threaded scheduler at evaluation time.
This shouldn't be a problem because it only happens when using
debugging command line arguments and the code simply don't
run in regular Blender operation.
The code seems a bit duplicated here across old and new
depsgraph, but think it's OK since the old depsgraph is already
gone in 2.8 branch and i don't see where else we might want
to use such a single-threaded scheduler.
When/if we'll want to do so, we can move it to a centralized
single-threaded scheduler in threads.c.
OpenGL render was a bit more tricky to port, but basically we
are using conditional variables to wait background thread to
do all the job.
