The function was checking the psys flag for this, but since for
disconnect/connect the same psys is used as source and target, the flag
must be passed explicitly.
By default this now copies from one object's local space to another
object's local space (instead of the previous world space). This is
more useful when transferring particles between objects, because it
doesn't require moving objects on top of each other, as long as they
have similar shapes.
another, including edit data (grooming).
This uses basically the same method as the existing connect/disconnect
feature. The main difference is that it allows working with multiple
objects and transferring the //particle/hair data// instead of the
//mesh// data (which is what connect/disconnect expects). This is a much
more realistic workflow when rigging, topology etc. changes and
groomed hair has to be transferred to the changed model.
shape instead of a brush tool.
The brush cutting tool for hair, while useful, is not very accurate and
often requires rotating the model constantly to get the right trimming
on every side. This makes adjustments to a hair shape a very tedious
process.
On the other hand, making proxy meshes for hair shapes is a common
workflow. The new operator allows using such rough meshes as boundaries
for hair. All hairs that are outside the shape mesh are removed, while
those cutting it at some length are shortened accordingly.
The operator can be accessed in the particle edit mode toolbar via the
"Shape Cut" button. The "Shape Object" must be set first and stays
selected as a tool setting for repeatedly applying the shape.
Along with some minor cleanup and simplifications.
Reviewers: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D903
This was a ToDo item, for mesh-based rigid body shapes (trimesh, convex)
the operator was simply using the bounding box volume, which can grossly
overestimate the volume and mass.
Calculating the actual volume of a mesh is not so difficult after all,
see e.g.
http://research.microsoft.com/en-us/um/people/chazhang/publications/icip01_ChaZhang.pdf
This patch also allows calculating the center-of-mass in the same way.
This is currently unused, because the rigid body system assumes the CoM
to be the same as the geometric object center. This is fine most of the
time, adding such user settings for "center-of-mass offset" would also
add quite a bit of complexity in user space, but it could be necessary
at some point. A number of other physical properties could be calculated
using the same principle, e.g. the moment of inertia.
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).
This check prevents using empty (no faces) meshes as rigid bodies.
While the idea makes sense, it also prevents using modifier-constructed
meshes, where faces are added only by the modifiers.
Further the check is very easy to circumvent, by removing faces after
making the rigid body, or by assigning a different mesh datablock
afterward.
Suggested by Fabian Emmes (@der_fab).
Issue here is complex (Of course, this is particles!)
First issue is that use_modifier_stack will use the num parameter of the
particles instead of num_dmcache, something the brush code did not
account for at all. Now correctly set DMCACHE_ISCHILD in that case.
Second issue is that make_derived_deform will return a mesh with less
indices than the particle system derived mesh. This would mean that
subsequent sampling of the particle derived mesh to initialize the
particles woould also produce garbage. This was being done for
optimization but in that case it broke the system.
Reviewers: lukastoenne
Differential Revision: https://developer.blender.org/D429
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.
