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 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.
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.
Particle textures always override timing information of particles.
Previously particle times could be scripted, but now these changes are
discarded by the texture evaluation function.
The patch disables texture overriding when no textures are defined, this
way at least some old scripts can keep working.
This adds another level of clumping on child hairs. When enabled, child
hairs chose a secondary clumping target using a Voronoi pattern. This
adds visual detail on a smaller scale, which is useful particularly when
the number of parents is relatively small.
Natural fibres behave in a similar way when they become sticky and
intertwined. Hairs close to each other form a first twisted strand, then
combine into larger strands. Similar features can be found in ropes:
http://en.wikipedia.org/wiki/Hair_twistshttp://en.wikipedia.org/wiki/Rope
Conflicts:
source/blender/blenloader/intern/versioning_270.c
This is an alternative method to the current fixed function with a
clump factor and "shape" parameter. This function is quite limited and
does not give the desired result in many cases (e.g. long, parallel
rasta strands are problematic). So rather than trying to add more
parameters there is now a fully user-defined optional curve for setting
the tapering shape.
This contains a few pieces of code for a future "modifier" system that
would allow more flexible combination of effects. Eventually a node
system is the way to go, but the current code makes that impossible.
to prevent double-freeing/invalid mem access.
This can happen with the "virtual parents" feature, which generates both
parent and child paths. Each task free function also freed the shared
context, leading to double freeing.
easier.
This code is badly broken and needs to be replaced, but at least having
a workable code structure might help with quick hacks to fix the worst
cases.
distribution and path caching for child particles.
This gives a significant improvement of viewport playback performance
with higher child particle counts. Particles previously used their own
threads and had a rather high limit for threading. Also threading
apparently was disabled because only 1 thread was being used ...
In rB78c491e the `initialize_particle` function was split into 2 parts for particle texture initialization.
The texture init part however also initializes birth times, which is now missing in the main init function
in some cases (notably when setting start/end directly without a subsequent time step).
in threaded depgraph updates and effector list construction.
Gathering effectors during depgraph updates will call the
psys_check_enabled function. This in turn contained a DNA alloc call
for the psys->frand RNG arrays, which is really bad because data must be
immutable during these effector constructions.
To avoid such allocs the frand array is now global for all particle
systems. To avoid correlation of pseudo-random numbers the psys->seed
value is complemented with random offset and multiplier for the actual
float array. This is not ideal, but work sufficiently well (given that
random numbers were already really limited and show repetition quite
easily for particle counts > PSYS_FRAND_COUNT).
Root of the issue goes to the order of particle initialization which does
texture evaluation (which does depend on particle coordinate) and particle
birth coordinate calculation. So basically what happened is:
* Changing number of particles re-allocated all the particles,
which sets their coordinate to (0,0,0)
* Texture evaluation used this non-initialized coordinate
* Coordinates were calculated for particles
Reshuffled code a bit so now texture evaluation happens after particles.
coordinate calculation. Basically moved texture evaluation to particle
reset function. Reset happens after initialization anyway and it does
know particle coordinates. Also, if reset is being called without init
then it's also kind of logical to re-evaluate texture because particle
coordinates might change.
Lattice deformation used to store some runtime data
inside of lattice datablock itself. It's something
which is REALLY bad. Ideally DNA shouldn't contain
and runtime data.
For now solved it in a way that initialization of
lattice deform will create a structure which contains
lattice object for which deformation is calculating
and that runtime data which used to be stored in
lattice datablock itself.
It works really fine for mesh deform modifier, but
there's still runtime data stored in particle system
DNA, It didn't look something easy to be solved, so
leaving this as-is for now.
--
svn merge -r58277:58278 -r58795:58796 ^/branches/soc-2013-depsgraph_mt
rendering. This used to happen in an unneeded frame change update which was
removed. For heavy particle systems this could have a bad impact on viewport
performance after rendering.
generator with a local one. It's not thread safe and will not give repeatable
results, so in most cases it should not be used.
Also fixes#34992 where the noise texture of a displacement modifier was not
properly random in opengl animation render, because the seed got reset to a
fixed value by an unrelated function while for final render it changed each
frame.
This was caused by a floating point precision error. During collision detection, Newton-Raphson iteration is used to find the exact time of the collision. But when using subframes, the initial Newton step was too small. Now the initial step is given in absolute units. When subframes = 0, this should behave almost the same as before.
Thanks to Janne Karhu, Lukas Toenne and Ton Roosendaal for their help with this patch, and to AutoCRC for funding.
http://projects.blender.org/tracker/index.php?func=detail&aid=29681&group_id=9&atid=127
The solver was mostly implemented by John Mansour at VPAC, with help from me and with funding from the AutoCRC. The SPH formulation is due to Gingold and Monaghan, and the smoothing kernel is due to Wendland.
This solver does not replace the old one; it is available as an option. Note that the new solver uses different units than the old one. The patch page has a couple of attachments that can be used to test the new solver, particularly sphclassical_dam_s0.01_grav.blend (ignore the earlier tests). The simulation in that file compares well with a physical experimental dam break; details in a paper by Changhong Hu and Makoto Sueyoshi, also referred to on that page.
- define array sizes for functions that take vectors.
- quiet some -Wshadow warnings.
- some copy/paste error in readfile.c made it set the same particle recalc flag twice.
