Tests files are based on test from D8393
Test files should be in `lib\tests\sequence_editing`
These are files, I will add few more tests including animation test.
{F9155273}
Using generic tool to compare rendered vs reference image as other render engines.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9394
This reverts commit 6527a14cd2ceaaf529beae522ca594bb250b56c9.
Some 3rd party scripts made use of this so scripts can work with
2.90 to 2.92, although eventually this can still be removed.
For the fast solver, there was an optimization carried over
from the non-collection case for empty meshes which did not
work in the chained boolean code for collection operands.
Removed that optimization in the collection case.
For the fast solver, there was an optimization carried over
from the non-collection case for empty meshes which did not
work in the chained boolean code for collection operands.
Removed that optimization in the collection case.
The code that decided to use a faster double version of plane
side testing forgot to take an absolute value, so half the time
the exact code was being used when it was unnecessary.
The code that decided to use a faster double version of plane
side testing forgot to take an absolute value, so half the time
the exact code was being used when it was unnecessary.
While Cycles already supports using both CPU and GPU at the same time, there
currently is a large problem with it: Since the CPU grabs one tile per thread,
at the end of the render the GPU runs out of new work but the CPU still needs
quite some time to finish its current times.
Having smaller tiles helps somewhat, but especially OpenCL rendering tends to
lose performance with smaller tiles.
Therefore, this commit adds support for tile stealing: When a GPU device runs
out of new tiles, it can signal the CPU to release one of its tiles.
This way, at the end of the render, the GPU quickly finishes the remaining
tiles instead of having to wait for the CPU.
Thanks to AMD for sponsoring this work!
Differential Revision: https://developer.blender.org/D9324
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>
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>
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>
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
This introduces a new operator to edit the detail size of constant
detail mode in dyntopo. The way this operator works and the
functionality it provides is similar to the "Voxel size edit" operator
for the voxel remesher.
It also includes a sample mode. When pressing Ctrl, the detail size
will be sampled from the surface under the cursor, updating the
preview in real time. This allows quick resolution changes without
using the operator multiple times.
The operator is set to Shift + D, replacing the old way to change
the constant detail size of dyntopo. Shift + R will remain available to
be enabled when the voxel remesher works with dyntopo. Deciding
if both detail sizes can be unified needs a separate discussion as the
new dyntopo can work with detail sizes in parts of the mesh that can
easily crash the remesher.
The structure of these operators is similar, but the data they control,
ranges, drawing and setup functions are completely different, making it
hard to merge them into one.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9355
Global automasking options are usually turned on/off for quick
adjustments both in brushes and filters, so it is convenient to have them
in a pie menu.
This uses the Alt + A shortcut.
Reviewed By: dbystedt, HooglyBoogly
Differential Revision: https://developer.blender.org/D9282
