Revision 1cd20b0 by Antonio Vazquez September 17, 2021, 09:01 (GMT) |
Fix T91448: GPencil Fill simplify not working in render The simplify was hardcode to be disabled in render. |
Revision 9dee0a1 by Philipp Oeser September 17, 2021, 07:13 (GMT) |
Fix T85564: FCurve modifier zero influence on restrict range borders When using FModifier `Restrict Frame Range`, the resulting influence was zero being exactly on `Start` / `End` range borders (so borders were **exclusive**). This made it impossible to chain FModifers together (forcing the user to specify values slightly below the desired border in following FModifiers). This is now corrected to be **inclusive** on Start / End range borders. Before {F10234864} After {F10234865} Testfile {F10234866} In the case of touching open borders (so [frame A frame B] followed by [frame B frame C]) both modifiers are evaluated (in stack order). If the later modifier has full influence (and is not additive) this simply means the result is the same as the later modifier's value. If influences below 1 are used (or modifiers are additive) both modifier's values are interpolated/added accordingly. technical notes: - this was caused by the introduction of FModifier Influence/BlendIn-Out in rB185663b52b61. - for comparison, see other occurrences of `FMODIFIER_FLAG_RANGERESTRICT`. - the following conditions in `eval_fmodifier_influence` for blend in/ out have been changed accordingly. Maniphest Tasks: T85564 Differential Revision: https://developer.blender.org/D10401 |
Revision 06ac655 by Campbell Barton September 17, 2021, 06:52 (GMT) |
WM: expose the "any" state of KeyMapItem modifiers Change KeyMapItem.alt/ctrl/shift/oskey to integer types, where -1 is used to ignore the modifier when matching key-map items. It was only possible to set all modifiers to -1 at once from RNA using the 'any' property. Afterwards individual modifiers could be set back to true/false. Although these key-map items could not be exported/imported. Exposing the values directly avoids the need for cumbersome workarounds. |
Revision 6dca61b by Campbell Barton September 17, 2021, 03:20 (GMT) |
Cleanup: remove KM_MOD_SECOND & KM_SHIFT2, KM_CTRL2.. etc These were added in a1c8543f2acd7086d412cb794b32f96794b00659 (2007) but never used. Nor did they have any meaning in practice. Note that versioning keymap items isn't needed as these values were never set. The code-paths that set these values also set KM_MOD_FIRST causing `keymap_event_set` to only ever assign values of 0 or 1. These flags complicate further exposing KM_ANY (-1) which is also a valid value for modifiers. |
Revision da2ba40 by Campbell Barton September 17, 2021, 02:57 (GMT) |
UI: wait for input for operators that depend on cursor location Support waiting for input so operators that depend on the cursor location are usable from menus / buttons. Use an operator type flag which the user interface code checks for, waiting for input when run from a menu item. This patch only supports this feature, there are no functional changes. The motivation for this change is discoverability since some actions were either hidden or broken when accessed from menus (where the behavior of the operator depended on the menu location). In general, waiting for input is *not* an efficient way to access tools, however there are over 50 operators with a "wait_for_input" property so this isn't introducing a new kind of interaction, rather exposing this in a way that does not need to be hard-coded into each operator, or having modal callbacks added for the sole purpose of waiting for input. Besides requiring boiler plate code using a "wait_for_input" property has the added down-side of preventing key shortcuts from showing. Only the menu items will enable the property, causing them not to match key-map items. Reviewed By: Severin Ref D12255 |
Revision 180bafe by Campbell Barton September 17, 2021, 02:57 (GMT) |
UI: split screenshot area into a separate operator While the screenshot operator showed an "Area" option, it wasn't usable from the main menu (unless accessed via menu search). Split screenshot area into an operator that depends on cursor. |
Revision f8b51f7 by Campbell Barton September 17, 2021, 02:57 (GMT) |
UI: enable the depend-on-cursor flag for some operators - Bend (Transform). - Extrude to Cursor. - Lasso Select (related operators such as node-cut links, mask.. etc). - Rip Mesh / UV's. - Vertex/Edge Slide. |
Revision 8bc27c5 by Campbell Barton September 17, 2021, 02:57 (GMT) |
UI: expose "Lasso Select" & "Extrude to Cursor" in menus - Show "Lasso Select" in menus (along with Box & Circle select) - Show "Extrude to Cursor" (along with other extrude actions). - Rename operators that add/extrude on Ctrl-Click since their names were inconsistent. This is mainly for discoverability. |
Revision 633c29f by Hans Goudey September 17, 2021, 02:54 (GMT) |
Fix: Nodes modifier ignores input value with new property missing An issue with the previous commit-- the default value of the type was used instead of the property value when the "use_attribute" property was missing. |
Revision 8e21d52 by Hans Goudey September 17, 2021, 01:49 (GMT) |
Geometry Nodes: Add a toggle to use attributes as input values This adds a toggle to node group inputs exposed in the modifier to use an attribute instead of a single value. When the toggle is pressed, the button switches to a text button to choose an attribute name. Attribute search isn't implemented here yet. One confusing thing is that some values can't be driven by attributes at all, like the size of a primitive node. In that case, we should have a node warning, but that will be separate since it's more general. We can also have an option to turn off this toggle in node group input settings. The two new properties for each input are stored with the same name as the value, but with `"_use_attribute"` and `"_attribute_name"`` suffixes. The properties are not added for socket types that don't support attribute input, like object sockets. Differential Revision: https://developer.blender.org/D12504 |
Revision 4fa0bbb by Harley Acheson September 17, 2021, 00:40 (GMT) |
UI: Automatic Blend Thumbnail Selection Adds an "Auto" option to blend thumbnail types that will automatically use Screenshot if there is no camera and 3dview, or workbench render with shading settings from the largest 3dview. See D12407 for more details. Differential Revision: https://developer.blender.org/D12407 Reviewed by Campbell Barton |
Revision a1c6574 by Hans Goudey September 16, 2021, 23:23 (GMT) |
Cleanup: Pass const mesh argument Also remove unnecessary parantheses. |
Revision 8e2e44b by Hans Goudey September 16, 2021, 20:44 (GMT) |
Cleanup: Move mesh_convert.c to C++ This should allow easier changes when it's helpful to use C++ types. The diff is for a test on the buildbot. Differential Revision: https://developer.blender.org/D12528 |
Revision 7a9cfd0 by Harley Acheson September 16, 2021, 20:13 (GMT) |
UI: Remove Menus & Show Wait Cursor When Saving When saving blend files close any menus that might be open, show "waiting" mouse cursor right away, before creating preview. See D12507 for more details. Differential Revision: https://developer.blender.org/D12507 Reviewed by Campbell Barton |
Revision db7fca3 by Hans Goudey September 16, 2021, 17:32 (GMT) |
Cleanup: Remove unnecessary manual of move constructor Turns out this isn't actually necessary. |
Revision f81bacd by Hans Goudey September 16, 2021, 17:25 (GMT) |
Geometry Nodes: Transfer attributes in the curve to mesh node This patch allows point and spline attributes to be transferred to the mesh generated by the curve to mesh node. All dynamic named and anonymous attributes are transferred. So a user-created attribute will be transferred, but "radius", "tilt" or the handle position attributes won't be transferred by default and will need to be copied first. This trade-off is made for performance, since most of the time, users won't need these attributes copied. Generally, attributes are transferred to the point/vertex domain. However, if they have the same name as a built-in mesh attribute that only exists on a different domain, like "shade_smooth", then they can be transferred directly to that domain as well. Conversion directly to the face corner domain is not necessary because there are no builtin face corner attributes. I see this conversion directly to other domains as an optimization we could use behind the scenes in the future as well, when named attributes are less common. For performance, I haven't tested which of the following is better: ``` for each spline combination: for each attribute: for each attribute: for each spline combination: ``` For now I used the existing loop to avoid more threading overhead. Differential Revision: https://developer.blender.org/D12363 |
Revision ddb7cb7 by Hans Goudey September 16, 2021, 17:03 (GMT) |
Geometry Nodes: Simplify using OutputAttribute in a vector Store the optional temporary span storage as a unique_ptr and move it in the move constructor, to avoid the need to add a special move constructor that clears the "show_warning" fields from it. Maybe this is very slightly slower, but we'll need this class less often in the future anyway. |
Revision 31a0708 by Hans Goudey September 16, 2021, 16:56 (GMT) |
Cleanup: Add built-in check for an attribute ID |
Revision 58043c0 by Dalai Felinto September 16, 2021, 16:48 (GMT) |
Rename App Menu to Blender Menu "App" is a name reserved for the application templates at the moment. It may become its own term in the near future if Templates are separated from "Apps". So since this is a name not exposed to the users we should renamed it sooner than later. Note that this will require scripts to update since the name of the class is renamed here. This also requires an update in the User Manual. Differential Revision: https://developer.blender.org/D12523 |
Revision c9daab7 by Julian Eisel September 16, 2021, 14:41 (GMT) |
Assets: Recursive reading of asset libraries With this, asset libraries can be directory structures and all assets in sub-directories will show up in an Asset Browser. With complex directory structures and many .blend files inside, asset library reading will be quite slow for now. There's initial work being done to introduce indexing for this (T82979), other optimizations are being discussed as well. Addresses T91406. Differential Revision: https://developer.blender.org/D12139 |
|