Age | Commit message (Collapse) | Author |
|
Differential Revision: https://developer.blender.org/D3719
|
|
|
|
|
|
This completes twist feature, which is now possible to also control by
texture. Since textures can not easily contain negative values as well,
same trick with 0.5 neutral as vertex groups is used.
All in all, this twist features allows to do following things.
Original hair:
{F2287535}
Hair with scientifically calculated twist value of 0.5:
{F2287540}
And we can also twist braids in opposite directions dependent on left/right
side:
{F2287548}
|
|
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.
|
|
Particles were ignoring the lattice modifier visibility, and
"influence" property.
|
|
This feature is extremely useful for layering multiple cloth objects,
and there is no reason there shouldn't be the same kind of feature for softbody.
|
|
location.
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
|
|
|
|
child hairs.
This allows disabling the curves temporarily without losing the setup.
Conflicts:
source/blender/blenkernel/BKE_blender.h
|
|
frequency).
|
|
specific.
|
|
|
|
Conflicts:
source/blender/blenkernel/intern/particle.c
|
|
This is BAD code, but the particle kinking does not make it easy to
write a non-local modifier that requires neighboring positions,
curvature, etc. The feature is needed for Gooseberry.
|
|
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_twists
http://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 helps to create some variation in a hair system, which can
otherwise become very uniform and boring. It's yet another confusing
setting in a system that should have been nodified, but only option for
now (broken windows ...)
Conflicts:
source/blender/blenkernel/intern/particle_system.c
source/blender/physics/intern/BPH_mass_spring.cpp
|
|
|
|
Without this the particle system only shows the actual non-simulated
hairs ("guide hairs") during edit mode. These hairs are used for goals
as well, so showing them in the regular viewport is pretty important.
Also the usual hair curves are interpolated along the entire length,
which makes it very difficult to see exact vertex positions, unless
using exact powers of 2 for the segment number and match the display
steps.
Conflicts:
source/blender/blenkernel/intern/particle.c
|
|
amount and crashes after Cycles render.
This is a hack to fix this, but at this point the system is hopelessly
broken anyway and no good fix other than total rewriting is possible.
|
|
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.
|
|
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).
|
|
|
|
also fully remove freestyle raycasting_algorithm
|
|
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.
|
|
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
|
|
* Removed "rotfrom" from particle RNA/DNA, was not used anywhere.
|
|
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.
|
|
After 2.63 there was a bugfix to take object scale into account for the duplicated
objects, but this breaks compatibility on earlier files. Now there is an option to
control if the scale should be used or not.
Scale is used by default on newer files, and not used on older ones.
|
|
|
|
|
|
problem was that BMesh had tessellation call when undo pushes were called.
if python called an operator with no undo push, tessfaces would not be created.
fix this by making it the responsibility of each editmesh operator to re-tessellate, as it is with notifiers and depsgraph.
added EDBM_update_generic() function to add notifier, tag for depsgraph update and optionally re-tessellate.
|
|
- More angular velocity modes to support creative effects.
- Renamed "Initial Rotation" to "Initial Orientation" to better reflect the functionality
- Renamed "Spin" angular velocity mode to "Velocity".
- Organized the rotation panel a bit better.
- Also some better names and tooltips for the different rotation values.
|
|
the cache end frame would reset to the previous state on confirm. Was an issue
with object animation being evaluated unnecessarily, now make check more
precise.
|
|
- The main problem was that in order to be accurate all particle
rotations have to be calculated incrementally so the only working
solution is to store rotations to the point cache (previously
this was only done for dynamic rotations). This can nearly double
the point cache size so it's not ideal to have this as a default
as in many cases you don't care about particle rotations.
- Particle rotation panel now has a new "enable" checkbox that
enables rotation calculations and the storing of rotations to
point cache.
- Old files will have rotations enabled via do_versions so that in
the worst case old files will only get bigger point caches, but no
sudden loss of particle rotations.
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
This commit extends limit of ID and objects to 64 (it means 63 meaning
characters and 1 for zero-terminator). CustomData layers names are also
extended.
Changed DNA structures and all places where length constants were hardcoded.
All names which are "generating" from ID block should be limited by MAX_ID_NAME-2,
all non-id names now has got own define called MAX_NAME which should be used all
over for non-id names to make further name migration stuff easier.
All name fields in DNA now have comment with constant which corresponds to
hardcoded numeric value which should make it easier to further update this
limits or even switch to non-hardcoded values in DNA.
Special thanks to Campbell who helped figuring out some issues and helped a lot
in finding all cases where hardcoded valued were still used in code.
Both of forwards and backwards compatibility is stored with blender versions newer
than January 5, 2011. Older versions had issue with placing null-terminator to
DNA strings on file load which will lead to some unpredictable behavior or even
crashes.
|
|
|
|
edits in DNA
|
|
this means use of deprecated struct members gives a warning.
- makesdna.c preprocessor skips this.
- DNA_DEPRECATED_ALLOW is used so readfile.c can do versioning without warnings.
- this exposes some use of deprecated struct members, will deal with this after.
|
|
smoke had this same bug too
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
There has been quite a bit of fuss about particle dupliobject rotation in 2.59, so here are some changes to make things work a bit more consistently and predictably in 2.60.
Much of the confusion has been about what the "Initial rotation" for particles actually means. Simply put it's just a vector that that the particles (and the dupliobjects) are aligned to and around which they can be rotated with the phase controls. I've now renamed these controls under a label "Rotation axis".
In 2.59 and previous versions the dupliobject's global x-axis was aligned to the particle rotation axis for non-hair particles. This meant that the object's own rotation (in addition to the particle rotation) could effect the dupliobjects' rotations. This old behavior can still be used with the "Rotation" option in the particle render panel when object/group is set as the visualization. This option is also activated automatically for old files to maintain backwards compatibility.
Now the default dupliobject rotations ignore the object's own rotation completely and align the object's tracking axis to the particle rotation axis. The tracking axis can be found under the Object tab -> Animation Hacks panel.
In 2.58 the way of calculating the rotation for hair didn't work as intended and enabled many non-functional combinations of options. For this reason I removed most of the rotation options for hair in 2.59. Now the options have been reimplemented better and the dupliobject's tracking axis is aligned to the hair direction by default (Rotation axis = Velocity / Hair). All the other axis options work too along with the phase controls.
|
|
subframes can now be altered automatically while an SPH (fluid particle)
simulation is running.
|
|
file-load.
* New object pointers can't be loaded properly for library linked groups, so the weight groups now store an index to the group objects at save time. This index is used at load time to set the objects without relying on the old pointers.
* If the library linked group is modified the indices can be wrong, but this can't really be avoided easily as there's no way to relate objects in a linked group between loads.
|
|
for width and height of billboards, relative to the particle size. It's useful when the particle size is primarily used for collision and the like, so the billboard appearance can be adjusted independently. Also allows non-square billboards.
In addition the billboards can be scaled by the particle velocity with optional head and tail factors (similar to line drawing options). This allows for pseudo-motionblur effects.
|