| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Differential Revision: https://developer.blender.org/D3719
|
|
|
|
bvhtree_from_mesh_get`.
The value of epsilon was never used to create this bvhtree because whenever we activate this constraint, a bvhtree with parameter epsilon 0.0 was created and cached.
|
|
|
|
This will allow greater control of the bvhtrees that are obtained, and helps identify problems.
It is also an additional step to unify the functions.
|
|
identifier type.
Reviewed By: @campbellbarton
Differential Revision: https://developer.blender.org/D3192
|
|
|
|
Those pointers are never to be aliased, so let's be explicit about this and hope
compiler does save some CPU ticks.
|
|
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
|
|
Wrap all arguments into TLS type of argument. Avoids some branching and also
makes it easier to extend things in the future.
|
|
Shrinkwrap must check it does have valid target data.
Safe for 2.79 release.
|
|
object_get_derived_final shouldn't have been assuming mesh objects.
It's even valid to use a curve as a target for a shrink-wrap modifier.
|
|
|
|
a non-mesh target, you can still circumvent this... Causing Crash
|
|
0b5a0d84 caused regression since edit-mesh BVH wasn't cached,
each shrink-wrap modifier created its own BVH.
|
|
Error in 0b5a0d84
|
|
Gives little to no speedup (a few percents at best).
|
|
Separate the creation of trees from EditMesh from the creation of trees from DerivedMesh.
This was meant to simplify the API, but didn't work out so well.
`bvhtree_from_mesh_*` actually is working as `bvhtree_from_derivedmesh_*`.
This is inconsistent with the trees created from EditMesh. Since for create them does not use the DerivedMesh.
In such cases the dm is being used only to cache the tree in the struct DerivedMesh. What is immediately released once
bvhtree is being used in functions that change(tag) the DM cleaning the cache.
- Use a filter function so users of SnapObjectContext can define how edit-mesh elements are handled.
- Remove em_evil.
- bvhtree of EditMesh is now really cached in the snap functions.
- Code becomes organized and easier to maintain.
This is an important patch for future improvements in snapping functions.
|
|
|
|
D1839 from @Orgold
|
|
We cannot use FLT_MAX as initi distance for raycast...
Renamed TRANSFORM_DIST_MAX_RAY to BVH_RAYCAST_DIST_MAX, moved it into BLI_kdopbvh,
and use in RNA raycast callbacks (and all other places using that API).
|
|
Own regression caused by fix for T46067,
edit-mode bvh only contained unselected faces.
This commit adds support for an edit-mode bvh containing all faces.
|
|
Note that allocating DM arrays from an editmesh is currently not threadsafe,
however even if were resolved, its more efficient to avoid having to do it in the first place.
|
|
|
|
|
|
|
|
|
|
Note this func needs some love, but this will be for later (should never have been in shrinkwrap code!).
|
|
meshes with shaped keys
Same issue as revious one -- need to start OMP threads only
when there's enough data to crunch.
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
|
|
|
|
|
|
|
|
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
|
|
|
|
|
|
- ability to change the space the axis is projected in (so you can choose worldspace or -space, was always local-space before).
- support projecting on a negative axis, without this some very simple clamping is not possible if the direction happened not to be positive.
- add distance limit (same as modifier), without this single meshes surrounding an object would make the constraint impossible to use in some cases (it would snap to the wrong side).
note: this removes the ability to project on multiple axes at once but this option only added up directions and didnt project on multiple axes as you might expect.
|
|
some minor style edits
|
|
|
|
EditDerivedBMesh.tc -> em. ('tc' is odd name which isn't used elsewhere).
|
|
it was problematic for vertices to fire rays out and hit some unrelated-far-off geometry which is often not what users want.
|
|
style edits.
|
|
both positive and negative projection.
- don't attempt to convert the 'dist' value between local/target space, since all the projections are done in target space
and dist isnt used afterwards. Also, this could fail with non uniform scale - overwriting ray casts with larger dist values.
- added an assert to check larger dist values never overwrite smaller ones.
- remove use of sasqrt() since the value is checked beforehand anyway.
|
|
checking on this code further it still isn't working correctly, will commit other changes next.
|
|
|
|
|
|
|
