Was using edge-slide & remove-doubles but this was error prone since remove doubles could fail in some cases or find doubles where it shouldn't (with very small scale objects).
This gives more predictable behavior when the edges of a loop wouldnt slide (in that case they would just drag over to one of the sides with no user control)
and multiple edge loops work better too. eg:
- http://www.graphicall.org/ftp/ideasman42/edge_loop_del_update.png
- made precision configurable.
- report a warning when doubles are found since they cause problems.
added Polygon.center attribute to avoid calculating in python.
An optional 'internal' argument was added to the bpy.data.texts.load() operator.
The changes in revision 57153 were reverted, so that the is_in_memory and is_dirty
properties of text datablocks are not editable again.
In the C API layer, BKE_text_load_ex() was introduced to allow for optionally
making text datablocks internal after loading.
This is hopefully the ultimate solution against smoke blockiness near emitter.
Previously high resolution flow/emitter voxels were generated based on the low resolution ones. So if you had 32 resolution and 4 division high resolution, it still used smoke flow generated from those 32 resolution voxels. Now I introduced a new sampling method called "Full Sample" that generates full resolution flow for for high resolution domain as well.
Read more about it in my blog post: https://www.miikahweb.com/en/blog/2013/05/10/getting-rid-of-smoke-blockiness
Also changed "quick smoke" operator default voxel data interpolation mode to "Cubic B-Spline" to smoothen out it even more.
Made keyap use the same select_or_deselect_all operator
as used for maya keymap instead of tricks with deselect_all.
Solves issue with selection in editor mode (reported as #3
in the original bug report).
Two main things:
- Made a python operator for selection in a viewport
which will de-select everything if nothing is under
the mouse.
To do so needed to modify VIEW3D_OT_select, so invoke
sets mouse location which is later used by exec
function.
This way it's possible to select stuff from python
defined operator.
Not best-ever solution since ideally exec() shall not
do OpenGL stuff, but we've got this issue in some
other operators. We'll solve this later.
- Used a keymap from Gianmichele Mariani as a reference,
updated his keymap to latest changes in operators.
We shall match Maya keymap much better now, thanks
for the keymap dude!
Workaround for an issue with python: strings generated by py scripts should also exist in python as long as they are used in C. Else C code may access freed memory.
Simply store the generated list of items in the class, for now. :/
As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading.
To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py).
There are a number of additional features that become possible with this implementation:
1) Node Toolbar can be populated!
The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible.
2) Each node item is a true operator call.
The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes.
3) Node Items support additional settings.
Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C.
4) Node items can be generated with a function.
A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image.
WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
* Mark Preset operator as 'Internal' only, so it does not show up inside the search menu. We cannot be sure if we meet the context requirements otherwise (unless we add a poll to each subclass).
- "Add node" was showing on wrong location when used via pulldown menus.
Now this option will put the nodes in center of the view.
- The Curves widget was making itself smaller/bigger based on width of region.
That messes up the layout engine now - especially the code that checks if
there's a scroller needed or not (it went into an eternal feedback loop).
Now this widget has fixed height (like the other larger widgets).
Better would be to allow such large widgets to be scaled vertically individually.
That's for the todo!
