User preference "Rotate around selection" now works for all input operators.
(Didnt for new default)
Note: the default will only rotate around selection, zooms remain to view center.
Our view pivot methods are not well definied at all...
- UV Image editor and other 2d views didn't zoom for CTRL+swipe yet.
(2 finger trackpad, 1 finger mighty mouse)
- Switched defaults for 3D window swiping...
- default rotate view
- SHIFT for translate
- CTRL for zooms
This makes all editors use 'swipe' like 'middle mouse', and not
like scrollwheel (as in releases).
This is nice for consistancy, but it still feels a bit weird...
Of course users can config this in keymaps. We need a sensible
default though, and to make a 2D input input device behave like
middle mouse seeems more sensible than like a 1D wheel...
Proposal therefore for defaults:
- 1D scrollwheels: zoom in 3d, zoom in 2d, but scroll for list views.
- 2D trackpads: pan for all 2d views, rotate for 3D
I'll check with frequent trackpad users about this and we can freeze it
before release. Give it a try :)
In 2.64, input for using an NDOF device included all 6 DOFs - including panning.
That makes using it for many people (including beginners like me) too hard, you
very quickly lose the 3d view rotation pivot, as if you are in free fly mode.
Fredrik provided an updated patch, which restores the 2.63 method to only
dolly and rotate by default. The new "all dof" operator is hidden in the keymaps
behind modifier keys SHIFT + CTRL. Users can set this in their configs of course.
As usual, we should be careful changing accepted defaults, and provide new
options as additional choice only.
A useful todo is to make user preference "around selection" work well.
Will check on this now too.
scrolling and inertia.
Now Blender uses this - if you have 10.7. Otherwise it just falls back on the
old code.
Try it, makes a huge difference :)
Next todo: how to configure this well, so you can have trackpad (or mighty mouse)
zoom as default in 3d views.
Now:
- code is wrapped for OS X releases (10.6 and 10.7)
- It now detects scrollwheel (old mouse) and gesture strokes (mighty mouse or trackpad).
If you have 10.6, things will work as for release.
Next todo for tomorrow: make trackpad work actually smooth and not with steps.
Will also try to figure out the device type, to handle mighty mouse differently.
Patch [#33445] - Experimental Cycles Hair Rendering (CPU only)
This patch allows hair data to be exported to cycles and introduces a new line segment primitive to render with.
The UI appears under the particle tab and there is a new hair info node available.
It is only available under the experimental feature set and for cpu rendering.
bake_action tries to make kind of a 'visual keying'... On one side, this is rather stupid when you keep constraints (in this case, keying actual loc/rot/scale transforms, i.e. matrix_basis, is enough, doing more would lead to unexpected behavior with some constraints). On the other one, making a good visual keying of bones is *really* tricky, so now using the new object's convert_space() func to compute that (when the user chooses to remove the constraints).
Incidentally, this greatly simplifies the code of bake_action!
Blender didn't detect properly whether event came from a mouse-wheel or
from a trackpad in OS X.
Now you can both, and both are handled independently.
Removed back hack from 2 years ago - which disabled mouse wheel for laptops.
Add asserts when CTX_data_pointer_get/CTX_data_collection_get are incorrectly used.
disable context inspection for now, Will enable again when its working properly.
It introduces a new (py-extendable and registrable) RNA type, UIList (roughly similar to Panel one), which currently contains only "standard" list's scroll pos and size (but may be expended to include e.g. some filtering data, etc.). This now makes lists completely independent from Panels!
This UIList has a draw_item callback which allows to customize items' drawing from python, that all addons can now use. Incidentally, this also greatly simplifies the C code of this widget, as we do not code any "special case" here anymore!
To make all this work, other changes were also necessary:
* Now all buttons (uiBut struct) have a 'custom_data' void pointer, used currently to store the uiList struct associated with a given uiLayoutListBox.
* DynamicPaintSurface now exposes a new bool, use_color_preview (readonly), saying whether that surface has some 3D view preview data or not.
* UILayout class has now four new (static) functions, to get the actual icon of any RNA object (important e.g. with materials or textures), and to get an enum item's UI name, description and icon.
* UILayout's label() func now takes an optional 'icon_value' integer parameter, which if not zero will override the 'icon' one (mandatory to use "custom" icons as generated for material/texture/... previews).
Note: not sure whether we should add that one to all UILayout's prop funcs?
Note: will update addons using template list asap.
