February 23, 2021, 21:51 (GMT) |
Attribute Search: Mirror fix from rB1239cab11ff97f I tried adding this as one of the fixes to fix the interaction with the attribute name buttons. It didn't fix that problem, but I'm not sure I should remove it since it seemed to fix a valid situation where the button pointer changed for RNA collection search. |
February 23, 2021, 21:36 (GMT) |
Sculpt: Add extra options to Face Set pie menu |
February 23, 2021, 21:29 (GMT) |
Revert Automatic Tablet API dynamic fallback. Removes fallback to Windows Ink when Wintab reports no devices present. Returns to old behavior of using only Wintab if Wintab.dll exists. |
February 23, 2021, 21:29 (GMT) |
Fix T85844: high pressure at start of line. m_tabletInRange is no longer set for Wintab after 2e81f2c01abd21fdbc reverted Wintab changes. This reverts most button processing to behavior present in 2.91.2. Left in place is a bugfix for Windows Ink: button events while a Windows Ink pen is in range should still be processed. Events processed by Windows Ink and not passed to DefWindowProc do not create WM_*BUTTON events, but button events from e.g. tablet pad express keys do create WM_*BUTTON events and should be handled. |
February 23, 2021, 21:29 (GMT) |
Revert high fequency mouse input for Windows. Windows mouse history function GetMouesMovePointsEx has well documented bugs where it receives and returns 32 bit screen coordinates, but internally truncates to unsigned 16 bits. For mouse (relative position) input this is not a problem as motion events and the resulting screen coordinates reliably fit within 16 bit precision. For tablets (absolute position) the 16 bit truncation results in corrupt history when tablet drivers use mouse_event or SendInput from the Windows API to move the mouse cursor. Both of these functions take absolute mouse position as singed 32 bit value on the range of 0-65535 (or 0x0-0xFFFF) inclusive. Values larger than 0x7FFF (the largest signed 16 bit value) are reliably corrupt when retrieved from GetMouesMovePointsEx history. This is true regardless of whether mouse history is retrieved using display resolution (GMMP_USE_DISPLAY_POINTS) or high resolution points (GMMP_USE_HIGH_RESOLUTION_POINTS), the latter of which should return points in range 0-65535. Reviewed By: brecht Maniphest Tasks: T85874 Differential Revision: https://developer.blender.org/D10507 |
February 23, 2021, 19:47 (GMT) |
WM_MOUSEMOVE cleanup. |
February 23, 2021, 19:27 (GMT) |
Revert Automatic Tablet API dynamic fallback. Removes fallback to Windows Ink when Wintab reports no devices present. Returns to old behavior of using only Wintab if Wintab.dll exists. |
February 23, 2021, 19:27 (GMT) |
Fix T85844: high pressure at start of line. m_tabletInRange is no longer set for Wintab after 2e81f2c01abd21fdbc reverted Wintab changes. This reverts most button processing to behavior present in 2.91.2. Left in place is a bugfix for Windows Ink: button events while a Windows Ink pen is in range should still be processed. Events processed by Windows Ink and not passed to DefWindowProc do not create WM_*BUTTON events, but button events from e.g. tablet pad express keys do create WM_*BUTTON events and should be handled. |
February 23, 2021, 19:25 (GMT) |
Revert high fequency mouse input for Windows. Windows mouse history function GetMouesMovePointsEx has well documented bugs where it receives and returns 32 bit screen coordinates, but internally truncates to unsigned 16 bits. For mouse (relative position) input this is not a problem as motion events and the resulting screen coordinates reliably fit within 16 bit precision. For tablets (absolute position) the 16 bit truncation results in corrupt history when tablet drivers use mouse_event or SendInput from the Windows API to move the mouse cursor. Both of these functions take absolute mouse position as singed 32 bit value on the range of 0-65535 (or 0x0-0xFFFF) inclusive. Values larger than 0x7FFF (the largest signed 16 bit value) are reliably corrupt when retrieved from GetMouesMovePointsEx history. This is true regardless of whether mouse history is retrieved using display resolution (GMMP_USE_DISPLAY_POINTS) or high resolution points (GMMP_USE_HIGH_RESOLUTION_POINTS), the latter of which should return points in range 0-65535. Reviewed By: brecht Maniphest Tasks: T85874 Differential Revision: https://developer.blender.org/D10507 |
February 23, 2021, 18:19 (GMT) |
Cycles: work towards writing directly to render buffer instead of PathRadiance This only has basic writing to the combined pass for the new kernels. A significant change is that we now accumulate transparency instead of alpha. This means we only have to write transparency for background and holdouts, rather than writing alpha on path termination, which happens in many places. |
February 23, 2021, 17:58 (GMT) |
Merge branch 'master' into sculpt-dev |
February 23, 2021, 17:56 (GMT) |
Merge branch 'master' into temp-gpencil-bezier-v2 |
Revision 796c599 by Julian Eisel (asset-browser, asset-browser-poselib, asset-system-filelist, temp-pose-flipping-fix-attempt, ui-asset-view-template) February 23, 2021, 17:50 (GMT) |
Add initial asset-view template, with dummy contents (palette colors) Idea is to be able to display a list of assets in a layout, by giving it some custom filtering settings (not done yet). This would be just a uiList managed by Blender, displaying previews similar to the Asset Browser. I decided to use uiLists for this because it already deals with stuff like writing its UI data to .blends (e.g. filtering and sort settings), filtering and scrolling. But I think we'll have to do a number of general improvements to them. Here I just added a new (C-only for now) "flexible grid" list display type, which uses bigger previews and behaves much better than the currend "grid" one. There's a bit of hacking going on here and things will probably change. For now I'm just interested in getting the basics done to see if the direction is good. |
February 23, 2021, 17:32 (GMT) |
Fix T85895: Viewing value passes in Image Editor displays the value as alpha There was a similar report prior to the introduction of the Image Engine, see T74586. This was fixed by rB6a5bd812b569 at that time, but got lost in the refactor it seems. Above commit introduced the `ED_space_image_get_display_channel_mask` function that will determine the valid bitflags for the display channel of a given ImBuf. But since the refactor, this is not called anymore (`draw_image_main` is not called anymore) Now it seems we can safely reuse that said function `ED_space_image_get_display_channel_mask` also for the Image Engine. Maniphest Tasks: T85895 Differential Revision: https://developer.blender.org/D10510 |
February 23, 2021, 17:25 (GMT) |
Cleanup: Remove unecessary double negative |
February 23, 2021, 16:33 (GMT) |
Sculpt: Initial support for bend deformations in Pose |
February 23, 2021, 16:18 (GMT) |
Merge branch 'master' into temp-geometry-nodes-attribute-search |
Revision 1868880 by Jacques Lucke (temp-spreadsheet-editor, temp-spreadsheet-editor-python-prototyping) February 23, 2021, 16:07 (GMT) |
enable scrollbars |
Revision 247707c by Jacques Lucke (temp-spreadsheet-editor, temp-spreadsheet-editor-python-prototyping) February 23, 2021, 16:07 (GMT) |
cleanup |
February 23, 2021, 16:03 (GMT) |
Get branch into compling state again. There are some changes in Materials in the exporter that make compiling the importer fail. I fixed one and several others are just ifdef'd out for now so that the branch compiles. TODO to fix the rest. |
|
|
|


Master Commits
MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021