| Age | Commit message (Collapse) | Author |
|---|
|
When verts were shared by 2+ face-islands, the number of allocated edges was wrong.
Cleanup the logic for new verts/edges.
|
|
|
|
bounds indices of vertices.
Issue here is that if we copy edge customdata the MEdge data that were
previously written get overwritten, solution is to write indices and
flags last (probably writing flags is superfluous here).
|
|
Overwritting Data of Base Mesh
The issue was actually affecting all data types that are not regular CDLayer ones, since by default
DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies
modifying edges' sarpness too).
Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**!
So we detect whether we are copying data types that may affect non-CDlayers data, and whether
verts array of org dm is same as mesh one - in which case we copy the DM. This avoids
useless copying in most cases.
Note Edit Normals was quite obviously suffering the same issue.
|
|
- don't resize ghash buckets (reserve maximum size)
- get vert, edge arrays instead of DM getVert, getEdge
- calloc -> malloc
|
|
Error in custom split normals work, non-autosmooth normals != vertex normals!
Loops from flat faces shall take normal of their face, not their vertex.
Tsst...
|
|
|
|
|
|
|
|
Nothing much to say here, basic tool to make normals point toward a target,
or to make them point 'outward' as if object was a spheroid (useful for game bushes etc.).
Also, forgot a big thank you to Campbell for the extensive review work he has done on this project!
|
|
- Add falloff types & curves (matching warp-modifier)
- Add uniform scale option,
important when adding hooks to non-uniform scaled objects,
especially for use with lattice objects which can't avoid uneven scaling.
This uses relative transformation set when the hook is assigned,
when measuring the distances.
|
|
Similar to 'Root' but without noticeable spike/pinch in the center.
|
|
|
|
|
|
|
|
|
|
Nice stupid error in low-level `get_cddm` helper, was probably affecting other
modifiers too actualy!
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
This way it doesn't have to be stored as DNA runtime pointers or passed
down as a function argument. Currently there is now no property or
button to enable debugging, this will be added again later.
|
|
|
|
layer is available.
Otherwise particle mapping to the new mesh cannot work with subdivided
and constructively-modified meshes.
|
|
parent amount.
|
|
|
|
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
|
|
These were not orthonormal and tended to flip with changing hair
direction, now use the particle hair matrix which is stable wrt. the
mesh surface.
|
|
framing method instead of the Frenet frame.
The Frenet frame is very succeptible to sudden twists along straight
sections of a curve where the second derivative (curvature) becomes 0.
|
|
This returns a general status (success/no-convergence/other) along with
basic statistics (min/max/average) for the error value and the number
of iterations. It allows some general estimation of the simulation
quality and detection of critical settings that could become a problem.
Better visualization and extended feedback can follow later.
|
|
This will allow us to implement moving reference frames for hair and
make "fictitious" forces optional, aiding in creating stable and
controllable hair systems.
Adding data in this place is a nasty hack, but it's too difficult to
encode as a DM data layer and the whole cloth modifier/DM intermediate
data copying for hair should be removed anyway.
|
|
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.
|
|
|
|
same file names with ED_object's one.
|
|
These warnings are false positives & confuses intended logic to set dummy values.
|
|
|
|
Not much to add, modifier uses same code as operator basically, only key difference
is that modifier will never create data layers itself, you have to use dedicated operator
for that.
|
|
|
|
This is an old option which wasn't working in over a year without complaint.
|
|
|
|
|
|
Was own mistake in handling custom data layers in boolean modifier.
Campbell, do you mind double-checking if it's all correct?
|
|
|
|
|
|
|
|
|
|
|
|
The issue was caused by render engine duplicating the curve object because
it then converts the object to mesh. The mesh deform duplication code didn't
duplicate binded data, so after duplication modifier is no longer applyable.
So now copyData of mesh deform would copy data needed for binding. This solves
reported render bug and also solves possible frustration when duplicating an
object with mesh deform in the viewport with Shift-D.
Checked other modifiers and laplacian deform already was copying binded data.
Didn't see other modifiers which might also need to copy extra data.
|
|
|
|
|
|
Thanks to @PatB for the fix.
|
|
It now supports different scheduling schemas: dynamic and static.
Static one is the default and it splits work into equal number of
range iterations.
Dynamic one allocates chunks of 32 iterations which then being
dynamically send to a thread which is currently idling.
This gives slightly better performance. Still some tricks are
possible to have. For example we can use some smarter static scheduling
when one thread might steal tasks from another threads when it runs
out of work to be done.
Also removed unneeded spin lock in the mesh deform evaluation,
on the first glance it seemed to be a reduction involved here but
int fact threads are just adding value to the original vertex
coordinates. No write access to the same element of vertexCos
happens from separate threads.
|
|
Mostly harmless things, though the 'multires' error was a real bug.
|
