| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
source/blender/editors/transform/transform_manipulator.c
|
|
frame (for editing)
|
|
|
|
D1651 (own patch)
|
|
Conflicts:
source/blender/makesrna/RNA_enum_types.h
source/blender/makesrna/intern/rna_sculpt_paint.c
|
|
|
|
Conflicts:
source/blender/blenloader/intern/versioning_270.c
|
|
|
|
The issue is caused by transform tool temporary affecting on the pose
constraints, which actually changes the way how pose is to be evaluated.
This isn't ideal patch from the performance point of view, but only
limited to the new depsgraph, so we've got some time to work on partial
graph updates.
|
|
Calculating normals is called often (sculpting for eg),
so avoid using high-level iterator here.
|
|
|
|
|
|
|
|
Initial mouse position was saved in two different places
D1588 by @mauge
|
|
transform ops when editing GP Strokes
Now that we've got a dedicated mode for this, we can now safely check this from
the context settings and set the relevant flags internally instead.
|
|
|
|
didn't work on the first frame
As a convenience feature, it is possible to jump to a frame without any existing
GP keyframe, and just use the transform tools to modify the stroke to create a new
keyframe on that frame. However, if the current frame was before the first GP keyframe,
the newly created keyframe would not work (if you scrub away), as it was getting
incorrectly added at the end of the list of keyframes, instead of in-order as expected.
|
|
|
|
selected, in EditMode.
Regression from rB312cb0a957b81233ea, now we make an exception for TFM_ROTATION mode...
|
|
Issue is, when 'Rotate Aroud Selection' is set, in Edit mode we do a fake transform operation
to get center point around which to rotate. For curves, most transform operations involve
a check of handle types. For now, added 'TFM_DUMMY' as an exception here.
Think it would be best to actually undo those changes in case of cancelled operation,
but this is much more involved, while this fix is safe enough to be included in final 2.76.
|
|
These warnings are false-positives
|
|
We had too many warnings lately... was awaiting that someone would kill them - didn't happen -> goes to my commit ratio! :P
|
|
Was an issue with individual-origins + snap
|
|
|
|
- place return args last position
- move crazyspace function out of DerivedMesh header
- use bool for args
- flow control on own lines to ease debugging
|
|
|
|
Transform code had duplicate aspect checking,
now store aspect in TransInfo.aspect for reuse.
|
|
This meant front/back faces from a projection would be seen as separate islands.
|
|
Only count each UV to influence the center once.
|
|
Useful for scaling all UV islands
|
|
- was doing 2x spin-locks, multi-view check and hash-lookup per face-corner.
- avoid doing customdata layer lookup per face.
|
|
|
|
|
|
working
(it would behave like 'bone envelope resize' instead).
Issue comes from the fact this transform op shares some common points with both BoneResize
and BoneEnvelope operations. However, trying to re-use `TFM_BONE_ENVELOPE` itself in this case
is bad idea, since this mode gets stored in transform op and is directly re-used for redo,
by-passing the whole init phase that shall be done in `TFM_BONESIZE` mode... So now,
we add a real new mode, `TFM_BONE_ENVELOPE_DIST`, while keeping most of existing code
and all existing behavior.
This is slightly hackish - but was already anyway, and avoids creating a full new set of
function for pretty much the same thing. As a side note, also makes it possible to
resize envelope distance outside of envelope viewing mode (from py or by adding a custom
shortcut).
|
|
|
|
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
|
|
matching convention for fixed length api, eg: copy_v3_fl
|
|
|
|
|
|
|
|
Transforming the center after transforming a handle would continuously
flush an extra offset to the handles.
Also use normalization range of -1.0 to 1.0 instead of -0.5 to 0.5 (not
really important, just for better comparisons)
|
|
Normalization feature now uses the full range of the data instead of
just one semiaxis for the maximum size.
|
|
Fix crash when extending instead of translating
|
|
region.
It's -really- hard getting the center of selection here in the y axis, I
feel this is the best compromise.
|
|
There are a few things here which are not so nice:
* Position of proportional edit circle is not centered on data
(difficult to predict positions here since those are completely custom,
will probably be positioned at center of area later instead)
* Result is flushed to curve handles only at the end of the transform,
so if people have the graph editor open they will see handles lagging behind.
|
|
|
|
This works by using the distance in the x axis only (usually artists want to influence nearby
keyframes based on timing, not value). Tweaking handles is the same as tweaking
the central handle. It's a bit ambiguous if proportional editing is really meaningful
for handles but will leave that for artists to decide.
|
|
Using the standard "FCurve" animchannel type didn't work that well for
the control FCurves on NLA Strips, as the paths would not resolve correctly,
and the indentation was wrong. Also, there would likely be issues down the
track with applying NLA mapping. Hence, it's easier to just create a separate
type for this case, and adapt the rest of the code to also consider these (todo).
|
|
Calculating connected data can be slow,
it still lags with heavy meshes but perform some optimizations (nearly twice as fast)
|
|
thickness) of strokes
|
