Age | Commit message (Collapse) | Author |
|
|
|
Fluid sims have a very nasty feature for interaction, in which a psys
can directly update the bvhtree for //another object's psys//. This
breaks with threaded depsgraph evaluation and is generally a no-go.
To avoid crashes for now, use a global mutex to avoid concurrent writes
to an object psys' bvhtree.
|
|
|
|
Normals for each kdtree node were allocated but never used,
and search args only use in particles/boids code.
|
|
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).
|
|
updates.
This file crashes on loading with NULL pointer access to curve_cache:
{F77132}
The pdInitEffectors function was amalgamating the simple
collection of effector objects with an automatic precalculation for
curve guides and the like. This precalculation requires object data
that may not be available until the DAG has finished.
Since for DAG dependencies only the list of effectors is required,
added an argument to disable precalculation when collecting effectors.
|
|
|
|
of particles
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.
|
|
|
|
(@plasmasolutions): When the particle emitter is parented to a fast
moving object, the emission locations will not be interpolated over
subframes. This works if the particle emitter is animated itself.
Particle system evaluates the emitter location for each subframe, but
has to do this for the parent objects as well to get reliable results.
|
|
|
|
|
|
|
|
using a texture with "Particles/Strands" coordinates that in turn has a "Lifetime" influence on the particles, the texture eval
accesses the particle lifetime/dietime data before it is actually defined! This is a design flaw, but to avoid corrupted data for now just initialize the lifetime/dietime values for particles in advance
before evaluating the texture.
|
|
Problem was introduced with r54648, which determined the initial interval for the Newton-Raphson method using the "total_time" of the collision - but this info is only defined for regular collisions, not
for the raycasting used in boids to find the "ground object". To ensure correct behavior, now clear the collision info before using it (good practice in any case), then check the inv_total_time variable
and use the standard 0.001 step if not defined.
|
|
also replace callocs with mallocs since zeroing memory can be avoided.
|
|
pass in the argument to reserve the size.
|
|
|
|
Particle system code used global variable to sort hair by orig index,
which is not safe for threading at all.
Replaced this with usage of reentrant version of qsort, which is
now implemented in BLI. It was moved from recast navigation code
to BLI, so more areas could use it (if needed).
--
svn merge -r59086:59087 ^/branches/soc-2013-depsgraph_mt
|
|
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
|
|
might not want (even though in general I think its an improvement).
split this into 2 options, added 'Normal-Tangent' orientation that makes the mesh orient towards the tangent, otherwise it uses Z-Up as before.
|
|
to follow emitter object rotation
With deformations and on a simple cube you could get axis flipping with normal-particle alignment.
now use the normal & tangent to create the orientation to give a stable matrix that wont flip.
|
|
emitter object rotation
|
|
|
|
well together.
|
|
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.
|
|
caused by partial revert of r56073.
|
|
The Emission panel now has a Use Modifier Stack option to emit particles from
the mesh with modifiers applied. Previously particles would only be emitted from
faces that exist in the original mesh. There are some caveats however:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.68/Tools#Particles
|
|
56073.
|
|
Now it works for blender internal, cycles and other multithreading code in
Blender in both background and UI mode.
|
|
|
|
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.
|
|
Fixes small precision problems.
|
|
This was left over from 2.4x days and is not used anymore.
Now simulations are always interactive.
|
|
be speed of sound squared; now just speed of sound.
The classical SPH solver was not in 2.65, so this change is unlikely to affect many users. But beta users who have been trying it out will need to change the stiffness parameter to sqrt(old value).
|
|
|
|
Particle mass was being used incorrectly by DDR solver (my fault).
|
|
|
|
|
|
|
|
function: BM_vert_calc_shell_factor_ex
|
|
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.
|
|
the time step size) for fluid simulations. Previously, the "subframes" parameter was not available when the adaptive time step was enabled; now they can both be set. The two settings can be used together to greatly increase simulation stability.
|
|
|
|
|
|
|
|
files since its done throughout the code in some places.
|
|
reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer
for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces.
(CD_POLYINDEX and CD_ORIGINDEX).
as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on
the same derived mesh, and polygons only store the original index values.
|