The idea is to give a control over direction of twist, and maybe amount of
twist as well. More concrete example: make braids on left and right side of
character head to be twisting opposite directions.
Now, tricky part: we need some negative values to flip direction, but weights
can not be negative. So we use same trick as displacement map and tangent normal
maps, where 0.5 is neutral, values below 0.5 are considered negative and values
above 0.5 are considered positive.
It allows to have children hair to be twisted around parent curve, which is
quite an essential feature when creating hair braids.
There are currently two controls:
- Number of turns around parent children.
- Influence curve, which allows to modify "twistness" along the strand.
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.
Even strands that were excluded by the density texture were being added
to the DM passed to cloth, but these ended up having some invalid data,
because they were not fully constructed.
This simply excludes `UNEXISTED` particles from the DM generation, as
would be expected.
Better to have clear way to tell whether flag is parameter for
BKE_library_foreach_ID_link(), parameter for its callback function, or
return value from this callback function.
Those 'never null' ID pointers are really a PITA to handle... luckily we don't have much of those around!
Found by Sybren, thanks.
Should be backported to 2.78.
Point cache read code contains checks designed to prevent it reading
stale data when the relevant simulation code should instead compute
the next frame from the previous one. However in some situations like
motion blur subframes the simulation can't possibly do it and just
exits. This causes completely incorrect motion blur at or after the
last cached frame.
To fix, add a parameter that tells the cache code whether it should
apply the checks and exit, or read what it can even if stale (true
means exactly same as old behavior).
Doing this in cache rather than clamping the frame number better in
the caller lets it handle the case of incomplete cache that stops
before the official last frame.
Reviewed By: mont29, lukastoenne
Maniphest Tasks: T49004
Differential Revision: https://developer.blender.org/D2144
There were two issues here. One is that the fix done originally for this
bug only checks for colliding with the same face as the single preceeding
hit. If the particle hits an edge or vertex of the collider, it in fact
hits two or more faces, so the loop ends up cycling between first two
of them and reaches the max collision limit.
The fix is to disable the collider for the sim step once a permeability
roll succeeds, by adding it to a skip list. Skipping just one face causes
some particles to bounce at odd angles in case of partial permeability.
The second problem was that the collider bounced back a small percentage
of particles, and the cause seemed to be that the code was set to flip
the velocity if the particle was just past the collider but still within
collision distance. Inverting both values causes a half permeable collider
to stop particles, so it seems that this if branch shouldn't bounce at all.
Test file: {F327322}
Reviewers: lukastoenne, brecht
Reviewed By: brecht
Subscribers: brecht, #physics
Maniphest Tasks: T26658
Differential Revision: https://developer.blender.org/D2120
The cause seems to be that despite dt_frac being computed as
1/(subframes+1) with integer subframes value, it doesn't always
add up to exactly 1.0 due to precision limitations. If the sum
is similar to 1.00000???, the last subframe is skipped, and all
particles that were supposed to be emitted in that interval are
emitted next frame, with the code working incorrectly due to
skewed time range.
To fix, separate the code from the dynamic timestep feature that
adjusts the last subframe length into a separate function, and
use it even when dynamic timestep is disabled.
Replaces `G.is_rendering` with `use_render_params` argument.
This is needed for Cycles, which attempts to restore render-preview settings from particles,
after it gets its own particle data, but fails to restore because
`G.is_rendering` was being checked in psys_cache_paths (and other places).
Point-cached particles (those using simulations) would not update at all outside of
first frame, due to PSYS_RECALC_RESET flag being ingnored in `system_step()`...
For some mysterious reasons, udate is still non-fully functional outside of startframe
(e.g. changing face distribution between random and jittered), but at least when choosing
'Vertices' you get particles from verts and not faces!
Problem was, during initialization of boids particles in `dynamics_step()`,
psys of target objects was not obtained with generic `psys_get_target_system()`
as later in code, which could lead to some uninitialized `psys->tree` usage...
Think it's safe enough for 2.77, though not a regression.
Static schedule was responsible here...
Also, made a minor optimization in case adaptative (auto) subframes are enabled,
gives a few percent of speedup here.
The threaded code is twice quicker now (from an average of 20ms/frame to 10ms/frame
while baking 10000 particles here e.g.)!
Think this is mostly due to usage of 'dynamic' scheduler in OMP code though,
from my experience so far this tends to have dramatic effects over performances,
static scheduler is usually much much more efficient.
It also fixes another issue (crash) related to symmetric editing.
Quite involved, we (try to!) fix complete broken logic of parts of particle code, which would use poly index
as tessface one (or vice-versa). Issue most probably goes back to BMesh integration time...
This patch mostly fixes particle editing mode:
- Adding/removing particles when using generative modifiers (like subsurf) should now work.
- Adding/removing particles with a non-tessellated mesh (i.e. one having ngons) should also mostly work.
- X-axis-mirror-editing particles over ngons does not really work, not sure why currently.
- All this in both 'modes' (with or without using modifier stack for particles).
Tech side:
- Store a deformed-only DM in particle modifier data.
- Rename existing DM to make it clear it's a final one.
- Use deformed-only DM's tessface2poly mapping to 'solve' poly/tessface mismatches.
- Make (part of) mirror-editing code able to use a DM instead of raw mesh, so that we can mirror based on final DM
when editing particles using modifier stack (mandatory, since there is no way currently to find orig tessface
from an final DM tessface index).
Note that this patch is not really nice and clean (current particles are beyond hope on this side anyway),
it's more like some urgency bandage. Whole crap needs complete rewrite anyway,
BMesh's polygons make it really hard to work with current system (and looptri would not help much here).
Also, did not test everything possibly affected by those changes, so it needs some users' testing & validation too.
Reviewers: psy-fi
Subscribers: dfelinto, eyecandy
Maniphest Tasks: T47038
Differential Revision: https://developer.blender.org/D1685
By default watertight intersections are used,
For callbacks where its not needed,
BLI_bvhtree_ray_cast_ex can be called without the BVH_RAYCAST_WATERTIGHT flag.
Fixes T45286
Note that the collision modifier doesn't have any use for Loop indices,
so to avoid duplicating the loop array too,
MVertTri has been added which simply stores vertex indices (runtime only).
This is a regression since dced56f and root of the issue comes to the fact
that grid distribution sets UNEXIST flag during distribution, which is then
being reset in initialize_all_particles().
This commit solves the issue, but it's not really nice and some smart guy
might want to revisit it.
This commit only adds callbacks which then later be used with major dependency
graph commit, keeping the upcoming commit more clean to follow.
Should be no functional changes so far still.
This way it is possible to have viewport simplification bumped all the way up,
making viewport really responsive but still have final render to use highest
subdivision possible.
Reviewers: lukastoenne, campbellbarton, dingto
Reviewed By: campbellbarton, dingto
Subscribers: dingto, nutel, eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1273
"Unexisting" particles must be freed after the unexist flag has been set,
which was no longer the case after 78c491e62a.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D1213
The issue was caused by phase being limited from 0 to 1, which gave only
0..M_PI distribution which is not good enough for good randomness.
Now the phase is being randomized across full 0..2*M_PI range.
Added some guards to prevent clumping to non existing particles. Also, adjusted threaded child path evaluation, so each child is evaluated once - previously virtual parents were done twice.
Fix for T43768
This way it works consistent with cloth, softbodys, etc.
Reviewers: lukastoenne
Differential Revision: https://developer.blender.org/D1134
