responses.
The S matrix together with the z Vector encodes the degrees of freedom
of a colliding hair point and the target velocity change. In a collision
the hair vertex is restricted in the normal direction (when moving
toward the collider) and the collision dynamics define target velocity.
This simply uses the position above the triangle instead of the
intersection point of the vertex path. The other method was broken
anyway, but also has a problem catching all the contacts reliably. The
new method might have a few false positives but that is acceptable.
solver that properly supports constraints with some degrees-of-freedom.
The previous solver implementation only used the S matrix (constraint
filter matrix) for pinning vertices, in which case all elements are
zero and the error doesn't show up. With partial constraints (useful for
collision contacts) the matrix has non-zero off-diagonal elements and
the algorithm easily diverges.
There are also initial steps for implementing collision prevention as
described in the Baraff/Witkin paper "Large Steps in Cloth Simulation"
(http://www.cs.cmu.edu/~baraff/papers/sig98.pdf).
This is a first test, the contacts are very explosive atm because they
basically pin hair vertices globally on collision, which leads to
stretching of the springs which is then suddenly released in the next
frame.
Instead of handling contact tests and collision response in the same
function in collision.c, first generate contact points and return them
as a list, then free at the end of the stepping function. This way the
contact response can be integrated into the conjugate gradient method
properly instead of using the hackish and unstable double evaluation
that is currently used.
The original BLI method for line/triangle intersection returns false
in case the line does not actually intersect, but in order to generate
repulsion forces we need to also handle contacts inside the margin.
timestep segment.
This ensures the distance for a collision pair is the one of the current
point position, and the response gets calculated accordingly.
simulation.
Note that this currently generates an extreme amount of points, by
making a edit pathcache curve for each hair in every frame! But at least
doesn't simply crash now.
This implements a penalty force as well as a repulsion force to avoid
further penetration, as suggested in
"Simulating Complex Hair with Robust Collision Handling"
(http://graphics.snu.ac.kr/publications/2005-choe-HairSim/Choe_2005_SCA.pdf)
Friction forces are still missing. More problematic is handling of
moving colliders, when face swap places with the hair vertex and a
collision is missed, putting the vertex inside the mesh volume. Larger
margins might help, but ultimately using Bullet collision detection is
probably more reliable and failsafe.
as forces, velocities, contact points etc.
This uses a hash table to store debug elements (dots, lines, vectors at
this point). The hash table allows continuous display of elements that
are generated only in certain time steps, e.g. contact points, while
avoiding massive memory allocation. In any case, this system is really
a development feature, but very helpful in finding issues with the
internal solver data.
This is still using the old BVH tree collision methods to generate
contact points, similar to what cloth does. This should be replaced
by a Bullet collision check, but generating contacts in this way is
easier for now, and lets us test responses and stability (although in
more complex collision cases the BVH method fails utterly, beside being
terribly inefficient with many colliders).
on itself.
This uses the same voxel structure as the hair smoothing algorithm.
A slightly different method was suggested in the original paper
(Volumetric Methods for Simulation and Rendering of Hair), but this is
based on directing hair based on a target density, which is another
way of implementing global goals. Our own approach is to define a
pressure threshold above which the hair is repelled in the density
gradient direction to simulate internal pressure from collisions.
This is an important hair interaction feature that simulates friction
between hairs in an efficient way. The method is based on the paper
"Volumetric Methods for Simulation and Rendering of Hair"
( http://graphics.pixar.com/library/Hair/paper.pdf )
It was partially implemented already, but didn't work in this simplified
version. The same voxel structure can be used for implemeting repelling
forces on hair based on density, which can help a hair system maintain
volume instead of collapsing in on itself.
the suggested tent function from the original paper.
Plain float->int conversion for the grid location otherwise leads to
skewed data and unnecessary loss of information.
Both were maked as temp, but used often.
Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple,
since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
The compostor used a fixed size of 4 floats to hold pixel data. this
patch will select size of a pixel based on its type.
It uses 1 float for Value, 3 float for vector and 4 floats for color
data types.
When benchmarking on shots (opening shot of caminandes) we get a
reduction of memory of 30% and a tiny speedup as less data
transformations needs to take place (but these are negligable.
More information of the patch can be found on
https://developer.blender.org/D627 and
http://wiki.blender.org/index.php/Dev:Ref/Proposals/Compositor2014_p1.1_TD
Developers: jbakker & mdewanchand
Thanks for Sergey for his indept review.
Issue was, when requesting (building) lnors for a mesh that has
autosmooth disabled, one would expect to simply get vnors as lnors.
Until now, it wasn't the case, which was bad e.g. for normal projections
of loops in recent remap code (projecting along split loop normals
when you would expect projection along vertex normals...).
Also, removed the 'angle' parameter from RNA's `mesh.calc_normals_split`.
This should *always* use mesh settings (both autosmooth and smoothresh),
otherwise once again we'd get inconsistencies in some cases.
Will update fbx and obj addons too.
The problem here was that when a Grease Pencil datablock is shared between
the 3D view and another one of the editors, all the strokes were getting handled
by the editing operators, even if those strokes could not be displayed/used
in that context. As a result, the coordinate conversion methods would fail,
as some of the needed data would not be set.
The fix here involves not including any offending strokes in such cases...
