From recent experience, turns out we often do want to use something else than basic
range of parallelized forloop as control parameter over threads usage, so now BLI func
only takes a boolean, and caller defines best check for its own case.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
Usual 10%-15% speedup. Note that here OMP was rather erratic, with typical
timing about 10% slower than BLI_task, but having some 'burnouts' (~10% of times)
were it would be over ten times slower than usual... BLI_task looks much more stable.
Reasons:
- Only parallelized piece of code gives little local speedup (code block only about 25% quicker even on 1M polys cube).
- No gain nor loss using new BLI_task system.
- At 10% of build, parallelized piece of code is only about 5% of total func runtime (run-time explodes as build proportion increases).
See no point in adding (in utmost best optimistic case, in real use-case, when depsgraph will likely already fire several evaluations in parallel,
speedup would be even smaller) 1% speedup here at the cost of threading complexity...
Note that since later code uses hashes, I don't think it's easy to thread it, so think we can leave with it for now.
Binding code was re-building its own DM for the cage, now it uses given one instead.
I cannot see really any good reason not to use 'visual' modified cage for binding process,
using base mesh instead was breaking any 'advanced' binding as described in the report.
This uses a bmesh-intersection, BLI_kdtree and watertight intersections to perform boolean operations.
For now keep both BMesh and Carve booleans usable at once for testing & bug reports,
however we plan to phase out Carve by next release.
Would be true in most cases (and in particular with own generated geometry),
but in case one would be using original geometry this could have crashed badly.
Note that I tried to parallelize the loops porting result of the simulation to the
DM data itself, but that ended up being 20% slower than non-threaded code!
Compared to previous revision, this gives 20% speedup on the whole modifier evaluation!
Wondering a bit how improvement can be so impressive here, would have expected very
small increases given how simple is the code here... Maybe it's the fact we get rid
of many additional OMP threads (tests are done with ten Ocean mod evaluated in parallel)?
This mimics OpenMP's 'firstprivate' feature. It is sometimes handy to have some persistent local data during a whole chunk.
Reviewers: sergey
Reviewed By: sergey
Subscribers: campbellbarton
Differential Revision: https://developer.blender.org/D1635
Otherwise user may have a hard time understanding why their modifier is no more working
after they e.g. deleted some vertices... including the root one. ;)
Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and
loop normals of a given shapekey.
This will be used e.g. in FBX exporter (shapekeys need normal data too).
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1510
Also, fix own stupidity, no need to define ID callback in case we only have objects,
calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
For now simply show warning in the interface and fallback to regular subsurf
code. Supporting OpenSubdiv in edit mode in possible but not high priority
currently.
Mirror modifier was reporting that it depends on geometry of the object
used for mirror center which is incorrect -- only object matrix is needed
for modifier evaluation.
