A to add the current snapping point to the list
Alt-A to remove the last one
The resulting snapping point is the average of all snap points in the list (and the one under the mouse pointer, if valid).
Snapping between two verts is a matter of moving over the first, pressing A, moving over the other, confirming transform.
Adding events for X/Y/Z axis and planar constraints (always use the user orientation, not global first) and for turning constraints off.
Built-in keys (toggle between global, user and off) are not in the map but can be overridden (any events handled by the modal keymap will not enter the built-in map).
modal operators should return RUNNING_MODAL|PASSTHROUGH for unhandled events to be able to receive clicks correctly (this needs to be fixed for other modal operators).
Maybe it's time to have "handled" flag in event instead.
http://wiki.blender.org/index.php/User:Theeth/Snapping
The new widget isn't there yet, but the rest works, including:
Increment (gears) is now a snap mode
Ctrl click to toggle snap on or off (in transform and 3d view)
Shift+Ctrl click to select snap mode (3d view only)
Snap status (on/off) is persisted in tool settings, no need to always turn it back on when entering transform.
It's still possible to have something resembling the old system by editing the transform modal keymap to snap on on ctrl press and snap off on key release.
With help from Patch [#19757] by Michael Jefferies.
-------------
Also, following talks with Matt and Campbell, make pressing Ctrl in transform toggle snap/gears instead of having to hold it down.
Important note: holding it down will no longer work correctly because of key repeats (it will toggle it constantly). It's possible to edit the modal keymap to bring back the old behavior (perhaps it should even be default).
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
Reordering some function calls in transform cleanup to make it simpler (that means other fixes are possible too, sequencer probably don't need it's own freeing function anymore).
- Generated and uploaded api docs - http://www.blender.org/documentation/250PythonDoc
- Added Edit docs menu item & operators as discussed with Mindrones, Brecht, Stani & Letterip @ bconf, needs some web backend. python operator can aparently use xml/rpc to upload docstrings.
- Added operator invoke function - context.manager.invoke_props_popup(self.__operator__, event)
this calls a popup for invoke by default (which intern calls execute())
- Own recent commit to game framing applied to non-camera views too.
- v3d->persp is deprecated but still used in some places.
- Transforming strips could overlap 1 frame if moving them below frame 0
- Transforming overlapping strips could go into an eternal loop (though overlapping strips should not exist)
The previous order is correct, the new order forced all global scale on local axis (in object mode).
The "problem" with scaling (or mirroring) in object mode along an axis that is not aligned along one of the local axis is that the result has to be decomposed (as best it can by TransMat3ToSize) into scaling factors along local axis. The more axis aligned the object is, the more "correct" it will look, with the worse being a scale along two local axis when the scaling axis is right between them.
One "solution" could be to make all Mirror transform in object mode work on local axis only (but I don't think that would be correct, since it still works correctly on aligned axis).
* RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope.
* Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
* Transform code was not properly fixed to work with the new way that axis-angle data was stored
* The order of the args for the conversion function when switching rotation representations was wrong, causing problems when switching from quaternion to axis angle (i.e. these occurred for newly created bones).
part. This fixes a bug where transform help line drawing would not
work with view clipping and mess up the z-buffer. This avoids the
transform code having to figure out what kind of opengl state is
enabled and disable it temporarily.
Actions on press is used everywhere in Blender, lets not make an exception here because there's something missing in the event system.
Bug report and potential solution is here, if anyone wants to have a go at it: http://projects.blender.org/tracker/index.php?func=detail&aid=19510
Made the confirm keymap for transforms use KM_RELEASE instead of KM_ANY (I didn't see any case where this failed yet?), and restored the "ctrl-click" as it was before r23903
This is similar to the old retopo all option but uses the snapping code and not the openGL depth buffer (it's thus more precise).
Not sure if making it available as a snap option is sensible, this is up for discussion.
NOTE: it will get slow fast on large meshes, we need to plug in an acceleration structure into snapping.
This will need an icon too.
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
* Compo node backdrop works again.
* Compo node previews and backdrop now get correct color management
float to byte conversion.
* Compo nodes got unecessarily recalculated while moving nodes.
* Fix compo node viewer nodes not getting activated correctly.
* Main compo node preview render computations are now outside of
mutex lock, so better for multithreading.
* Tex node outputs did not work in some files loaded from 2.4.
* Change RNA updates to take into account groups that may be shared
between multiple node trees.
* Make Ctrl+M key work for mirror in 3D view.
* Fix mirror along global axis, was mirroring around all axes when
the object was rotated, due to wrong matrix order, was also not
working in 2.4.
* Pressing e.g. X twice still doesn't go to local mode, would fix
but don't know how the code is intended to work.
This (biggish) commit generalises the rotation modes functionality added for Bones, allowing Objects to use the various Euler Rotation orders, Axis-Angle, and Quaternion rotation representations.
I've also cleaned up the nomenclature of the rotation-related settings so that the naming styles are more consistent with each other. Unfortunately, this will break all files involving object or bone rotation animation made in 2.5 versions (2.4x will still get correctly converted).
General Notes:
* By default, Objects still default to using Eulers, while Bones will use Quaternions by default still.
* I've fixed all areas that I'm currently aware of to work with these changes. However, there are probably a few places where I've missed a few changes (i.e. auto-keyframing will need attention later).
* Removed the old "IPO-Keys" stuff from Transform code. I'm unlikely to restore this in the near future, and trying to fix that to include support for this commit would have been too much work.
* Added Transform Locks panel. The layout for rotation I'm not satisfied with yet, though it is the best alternative so far.
* Rotations can now be locked per-component for quats/axis-angle instead of going through eulers. This is currently enabled by the checkbox for the 'label' of the Lock Rotation column.
- The naming of the property in RNA + the way this is presented in the UI can get some work done.
- The setting for the 'w' component for quats/axis-angle is currently a separate flag in RNA, since I can't figure out how to lump this in under the 'lock_rotation' property instead (i.e. getting that to be either 3 or 4 components, depending on whether per-component locking is enabled).
- Editing values directly should not be possible when these locks are set...
* Fixed some tools which made use of this
* Added a few new methods for axis-angle conversions, and used these instead of manually performing those steps elsewhere
* Axis-angles to other representations now get their axes normalised to make sure that odd scaling doesn't occur.
* Made a few more tools work with axis-angles properly
The support for this is really quite hacky, and I might disable this later if we cannot get some parts to work nicely.
Some notes:
* This is currently stored in the same variable that quaternions are stored in, since they both have 4 components. However, in RNA, I've added 2 properties specially for this.
* There are some shearing issues using certain axes - i.e. (1,1,0) - that will need to be checked on.
* Transform code is really quite temporary for this. Just a quick demo of what can be done...
* Make mirror operator and menus work.
* Added TFM_OT_mirror transform operator specific for mirror.
* Assign image from image space when unwrapping in 3d view.
* Rotation order code should be more correct now. Previously was only shuffling axes, and was also doing some evil things to provided that that it shouldn't have been doing, which was causing some flipping issues.
* Built-in keyingsets for 'visual' options should now be more correct. The old code had typos, giving wrong array indices to start from.
Notifiers
---------
Various fixes for wrong use of notifiers, and some new notifiers
to make things a bit more clear and consistent, with two notable
changes:
* Geometry changes are now done with NC_GEOM, rather than
NC_OBJECT|ND_GEOM_, so an object does need to be available.
* Space data now use NC_SPACE|ND_SPACE_*, instead of data
notifiers or even NC_WINDOW in some cases. Note that NC_SPACE
should only be used for notifying about changes in space data,
we don't want to go back to allqueue(REDRAW..).
Depsgraph
---------
The dependency graph now has a different flush call:
DAG_object_flush_update(scene, ob, flag)
is replaced by:
DAG_id_flush_update(id, flag)
It still works basically the same, one difference is that it now
also accepts object data (e.g. Mesh), again to avoid requiring an
Object to be available. Other ID types will simply do nothing at
the moment.
Docs
----
I made some guidelines for how/when to do which kinds of updates
and notifiers. I can't specify totally exact how to make these
decisions, but these are basically the guidelines I use. So, new
and updated docs are here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersUpdateshttp://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataNotifiers
* All tools where rotation order matters for armature bones have now been adjusted to use the new code
* Transform now uses the new code for bones too. However, there are some jumping issues here that I'm not too sure how to solve yet. Help fixing this is welcome.
This commit is the start of an implementation of (euler) rotation orders for Bones (later to be extended to Objects too).
Technical details and references can be found at:
http://wiki.blender.org/index.php/User:Aligorith/EulerRotationOrder
In short, I've added a new set of Euler conversion functions (EulO... and ...EulO), coexisting with the old functions for now, which can handle different rotation orders.
Changes have only been made to the basic evaluation code. However, the following places will still need modifications:
* Transform code - needs to be made to use functions which take rotation order into account instead of using XYZ only
* Rotation constraints - same story
* Other rotation editing tools for armatures also need a check up, since there might have been some missing code when I ported eulers earlier
- use the scene context for the unit settings since there isn't a better place for it currently.
- added 'chain' to imperial units
- set more rna props to be distances and angles.
* Separated value and range sliders for the value into two separate rows. Value comes before the range settings since it's used more often, and is drawn as a slider instead.
* Tweaked ranges for the sliders so that they will work sanely.
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
Disable manipulator drawing while moving. This still use G.moving, but that's acceptable for now (it's sort of a weird display option, after talk with Ton, we couldn't find a good place to set it).
Confirm on LMB up but cancel on RMB down.
This works well with hotkeys, manipulator, RMB+drag and gesture (when they are added back).
The question is do we stick with one scheme for all or have separate keymaps for different "calling mode".
