| Age | Commit message (Collapse) | Author |
|---|
|
|
|
onionskinning in that direction
This is an experimental option that I found would have been useful to have,
when making my earlier anim test. The only contentious point is whether it's
better to use a separate boolean flag (perhaps bound to the labels) instead
of overloading this setting (and describing the usage in the tooltip).
|
|
the layers UI
|
|
In the nodes editor, Ctrl-LMB-drag is taken by "Cut", and it seems impossible
for any other keymap to override that. Instead, the default lasso select hotkey
there is Ctrl-Alt-LMB-drag instead.
To get Grease Pencil lasso select (in GP Editmode) to work in the Nodes Editor too,
this commit adds the Ctrl-Alt-LMB-drag binding here too. However, to make things easier,
this extra binding will be part of the Grease Pencil keymap everywhere. There doesn't
seem to be any conflicts with having this in place - until we find them, this should
be ok to have.
|
|
|
|
This commit adds some of the initial support for a properties region in the
Action Editor. There are currently no panels to display, as there is still
a lot of work required to port over the required internal architecture to
support the panels seen in the Graph Editor.
|
|
After some test, a new iteration parameter has been added in order to
apply repetitive smoothing to the stroke. By default 1 iteration is applied,
but can used any number between 1 and 3.
The repetition uses different levels of intensity from 100% of the defined smooth
factor for the first loop, 50% for the second and 25% for the third. We use in each
loop a smaller value in order to avoid deform too much the stroke.
|
|
glitches in some situations
|
|
There is still some instability in how the triangulations are happening,
where the triangle count of the resulting triangulation fluctuates resulting
in weird artifacts sometimes.
To reproduce, try drawing some U-shapes, and keep reloading the file.
|
|
While trying to track down why I still keep getting some random "extra" triangles
showing up when reloading files with fills, I noticed that there's an index mismatch
here that may cause problems in some rare cases:
There are "gps->totpoints" items in tmp_triangles, but there should only be
"gps->tot_triangles" triangles in the gps->triangles array. If for whatever reason
some of the triangles in tmp_triangles are invalid, this could have meant that
while a tmp_triangles candidate was skipped, a corresponding slot for a valid
triangle also got skipped.
|
|
|
|
Improve filling for concave shapes using a triangulation of the stroke.
The triangulation information is saved in an internal cache and only is
recalculated if the stroke changes.
The triangulation is not saved in .blend file.
Reviewers: aligorith
Maniphest Tasks: T47102
Differential Revision: https://developer.blender.org/D1705
|
|
`dynamicPaint_doMaterialTex` was called from inside an omp parallel section with brush->dm
itself, and not the local dm copy. Generating looptri data is not thread safe at all...
|
|
|
|
|
|
Typo in rBrBa48d74079, spin tool was now using the wrong view axis.
|
|
popups have no wm_region in context, using wm_menu here.
Not working perfect, but at least it prevents crash.
|
|
|
|
Use Shift-B, UV border-select-pinned is now Ctrl-B.
Patch from @rav66
|
|
The derivedMesh could free a tree stored by the cache.
Now check the cached tree is valid.
|
|
|
|
|
|
It's handy to merge eyes before reaching the zenith.
|
|
This commit avoids draw of invisible parts of image in image editor,
making it faster to re-draw the image.
Especially handy when painting on a high-res image when zoomed-in.
|
|
The idea of pole merge is to fade interocular distance after a certain
altitude to zero when altitude goes closer to a pole. This should prevent
annoyances looking up in the sky.
Not optimal or something, but sohuld be good enough for testing.
|
|
Previous number of digits after point was not really useful, especially
for the interocular distance where it's quite common to go sub-cm precision.
|
|
|
|
Yet another commit which makes painting aware of multi-threaded systems.
|
|
Enable dynamic restlen recomputation based on sew flag and update the
shrink factor math within it to call the new utility function.
|
|
Originally the value was only needed when building the springs,
so a pointer to the input data was somewhat ok. However, recalculating
spring length dynamically requires keeping the actual value around.
|
|
A function that recalculates cloth spring lengths.
|
|
The average length is used to adjust self-collision and stiffness
to match mesh density, and in either case considering the always zero
restlen sewing springs doesn't actually make much sense.
The struct_springs variable is also used for other things like total
spring count, so a new one needed for the true struct springs.
|
|
This comes out of considering a one-dimensional transition in weight
on a rectangular cloth grid. At the transition face loop, one side
of each rectangular face would be scaled by k1, and the opposite one
by k2, thus turning the rectangle into a trapezoid. Averaging would
be used to choose the scale factor for the remaining two sides.
If Geometrical Mean, i.e. sqrt(k1*k2) is used, it so happens that the
diagonals of the trapezoid also end up scaled by sqrt(k1*k2) compared
to the original rectangle. This means that the same scale factor is
correct for both structural and shear springs, which is not the case
with simple average.
|
|
Previously it was all over the place: without a vertex group it was
always enabled, and with it it depended on the Self Collision option
due to a likely editing mistake. Now it should be in sync with what
disables the fields in the UI.
The verts->shrink_factor field is changed to just cache the vertex
weight, with the shrink_min/shrink_max interpolation done later.
This is because cloth_apply_vgroup only runs if there are vertex
groups, and thus the factor may not update after property changes.
In addition, bending springs are now also affected by the shrink
factor to avoid visible distortion in object shape at high shrink.
|
|
|
|
From description, Use Coordinates evaluates the texture using
target coordinates in the local space of the force field object.
2D is supposed to ignore the Z coordinate. Thus one would assume
that if both are enabled, the force field effect would move with
the force field object, and Z would be 0.
However, instead first the 2D option projects points onto a plane
passing through the global zero and orthogonal to the local Z,
and only then the resulting point is transformed into local space.
Z is not locked at 0, so procedural textures like Spherical Blend
don't work as expected.
To fix this, apply local transform first, and then just clear Z if 2D.
|
|
This speeds up update of display buffer when affected area is big enough.
Mainly helpful for cases when doing long fast strokes when painting.
|
|
Values set but not used
|
|
When loops are planar to eachother, initialize their winding based on surrounding geometry.
|
|
Calculating the winding failed when faces exist on both sides of the edge.
|
|
Gives about 2x speedup on laptop when creating new hires generated image,
regardless of it's type (color, color grid, uv grid).
|
|
Snap targets can't contain vertices which are being transformed
|
|
Re-activating transform would overwrite previous context, leaking memory.
|
|
|
|
|
|
All callers pass in valid number
|
|
|
|
Would have prevented previous error going unnoticed.
|
|
|
|
headers.
|
