| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Added missing function documentation.
|
|
|
|
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
Wintab.
|
|
Previously Wintab was handled by saving the most recent tablet pressure and tilt information and deferred appending tablet infromation to Windows mouse events. This caused synchronization issues evident at the beginning and ending of strokes where pressure and tilt were either ahead or behind in time from mouse button up or down events. This also dicarded swaths of data which resulted in blockly grease pencil lines most apparent when a context switch resulted in several coalesced mouse events.
This patch changes the behavior of Wintab to instead rely entirely on Wintab information for pressure, tilt, position, and button input.
Wintab has several design decisions and conventions which complicate relying soley on it's input while retaining current workflows reliant on non-API behavior. For example, many device optionally allow the user to map barrel buttons to non-mouse actions. These mappings may or may not modify the intended behavior when touching the stylus down, such as scroll vs alt mappings. This behavior is not exposed in the Wintab API, but Wintab will continue updating button state sans this necessary context.
To work around the problem, this refactor synchronizations tablet input to Windows mouse down and up events, this captures events which should result in pen input while allowing events such as pen scrolling. Until a Windows mouse down event fires Wintab input is left unprocessed; when a Windows up event occurs Wintab is processed until a corresponding button up event is found.
Wintab allows for either button state or changes to be reported, but not both. An earlier refactor tried to use button changes to let state to be managed by Wintab. This was replaced when it was found that button change events were unreliable at corner cases such as switching windows. It was also found that with Wacom drivers Wintab peek functions would modify events in the queue causing errant and loss of button events.
For the latter stated reason this patch opts to read all Wintab events into a queue as they arrive, removing events as they become stale. This was chosen over using Wintab peek functions due to the afformentioned issue. As a bonus this seems to work better as it prevents the queue in Wintab from filling, thus neither a flood of events need to be handled when Wintab processing begins and a Wintab implementation need not be trusted to overwrite old events in it's queue.
Maniphest Tasks: T75566
Differential Revision: https://developer.blender.org/D7840
|
|
event to the button down location as this should be a more accurate point
of contact than the last mouse move event.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
for Pointer input even when Wintab should be preventing Pointer events.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
events until one is found. This prevents errant cursor moves that occur
before the Wintab button event is reported. We need to skip these events
because if no button event exists, we generate one assuming it will either
arrive later in the Wintab queue or that the button was from a non-Wintab
device. For the case that this was generated by a non-wintab device, such
as buttons mapped to mouse on the tablet pad, these cursor move events can
significantly move the cursor from the intended click position.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
the issue with Wintab button events are more significant than simply
setting what buttons should receive button up/down events during context
initialization.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
handling mouse input. This Wintab to mouse synchronization issues, and
likely prevents queue exhaustion for some Wintab implmenetations.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
window intitialization can specify whether it will be visible regardless
of whether it is yet visible.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
This reverts commit 045aaf6f78f1fbb6e2bbefd234b7bae04844d42b.
|
|
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
and GHOST_EventCursor.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
discourage reducing their scope to the only place they're used internally.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
Button events now include tabletdata, so move is unnecessary.
Generate mouse button events when the system has an event but Wintab did not find a correlated event.
Only filter mouse button events, not Win32 Pointer events.
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
Maniphest Tasks: T75566
Differential Revision: https://developer.blender.org/D7404
|
|
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
This reverts commit e90d8422d0ed38743390f2184fde27550d7b48a7.
|
|
This hack is no longer required. It was fixed in rB52b38d9c3d84 and temporarily disabled in rBa877248ac203.
|
|
|
|
|
|
This change is required since rB52b38d9c3d84. Why a bpy reference is there in the first place is to be investigated.
|
|
|
|
No effect on the Blender integration yet, but needs to be solved for the
upcoming change to encapsulate sockets.
|
|
|
|
Basic support for velocity updates with the APIC method.
This commit adds APIC to the already existing dropdown menu for the simulation method. The APIC plugin within Mantaflow has been updated to the latest version.
|
|
Don't use the current mouse position at the time the event is handled, but
rather the position at the time of the event. This should make e.g. brush
stroke paths more accurate.
In addition, this may solve issues with other software that does mouse
position smoothing. Ref T82143.
Use of the current mouse position was added in 12b642062c6f as part of a
large commit that also made continuous grab work. But it appears to still
work getting the mouse position from the event.
|
|
|
|
|
|
The issue stems from the fact that scene arrays are not cleared when rendering is done. This was not really an issue before the introduction of the ownership system (rB429afe0c626a) as the id_map would recreate scene data arrays based on their new content. However, now that the id_maps do not have access to the scene data anymore the arrays are never created.
Another related issue is that the BlenderSync instance is never freed when the persistent data option is activated.
To fix this, we delete nodes created by the id_maps in their destructors, and delete the BlenderSync instance before creating a new one, so the id_maps destructors are actually called.
Reviewed By: brecht
Maniphest Tasks: T82129
Differential Revision: https://developer.blender.org/D9378
|
|
Rather than just printing a message and falling back to the CPU. For render
farms it's better to avoid a potentially slow render on the CPU if the intent
was to render on the GPU.
Ref T82193, D9086
|
|
Reviewed By: sergey, ankitm
Differential Revision: https://developer.blender.org/D9377
|
|
Not exposed in Blender yet.
Ref D2057
|
|
The existing code for this was incomplete. Each instance can now have a set
of attributes stored separately from geometry attributes. Geometry attributes
take precedence over instance attributes.
Ref D2057
|
|
Ref D2057
|
|
Previously only float3 and byte4 was supported.
Ref D2057
|
|
This avoids OpenCL inlining heavy volume interpolation code once for every
data type, which could cause a performance regression when we add a float4
data type in the next commit.
Ref D2057
|
|
Previously, only predefined and limited set of intrinsics combinations
could have been refined. This was caused by a bundle adjustment library
used in the early days of the solver.
Now it is possible to fully customize which intrinsics are to be refined
during camera solving. Internally solver supports per-parameter settings
but in the interface they are grouped as following:
* Focal length
* Optical center
* Radial distortion coefficients (which includes k1, k2, k3, k4)
* Tangential distortion coefficients (which includes p1, p2)
Differential Revision: https://developer.blender.org/D9294
|
|
Was using doing an implicit cast of floating point value to boolean.
Was not noticed before because the boolean value was never never used.
|
|
Follow our code style for doxygen sections.
|
|
This reverts commit 527f8b32b32187f754e5b176db6377736f9cb8ff. It is causing
motion blur test failures and crashes in some renders, reverting until this is
fixed.
|
|
This encapsulates Node socket members behind a set of specific methods;
as such it is no longer possible to directly access Node class members
from exporters and parts of Cycles.
The methods are defined via the NODE_SOCKET_API macros in `graph/
node.h`, and are for getting or setting a specific socket's value, as
well as querying or modifying the state of its update flag.
The setters will check whether the value has changed and tag the socket
as modified appropriately. This will let us know how a Node has changed
and what to update, which is the first concrete step toward a more
granular scene update system.
Since the setters will tag the Node sockets as modified when passed
different data, this patch also removes the various `modified` methods
on Nodes in favor of `Node::is_modified` which checks the sockets'
update flags status.
Reviewed By: brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D8544
|
|
|
|
|
|
the camera is shifted
Code was assuming frustrum planes are symmetrical which is not the case
for shifting. This lead to a shrinking region if shift was negative (and
a growing region if shift was positive)
So instead of only keeping track of plane on one side (and mirroring
over in code) get the actual planes after shifting and use these
instead.
This code corrects this for ortho and perspective cameras, it does not
touch panoramic cameras.
Reviewed By: brecht
Maniphest Tasks: T69911
Differential Revision: https://developer.blender.org/D9342
|
