| Age | Commit message (Collapse) | Author |
|---|
|
|
|
into enums
The transformation snapping code contains a bunch of `#define`s, some ambiguously or incorrectly named attributes. This patch contains refactored code to improve this. This patch does (should) not change functionality of snapping.
Clarified ambiguously / incorrectly named attributes.
- "Target" is used to refer to the part of the source that is to be snapped (Active, Median, Center, Closest), but several other areas of Blender use the term "target" to refer to the thing being snapped to and "source" to refer to the thing getting snapped. Moreover, the implications of the previous terms do not match the descriptions. For example: `SCE_SNAP_TARGET_CENTER` does not snap the grabbed geometry to the center of the target, but instead "Snap transforamtion center onto target".
- "Select" refers to the condition for an object to be a possible target for snapping.
- `SCE_SNAP_MODE_FACE` is renamed to `SCE_SNAP_MODE_FACE_RAYCAST` to better describe its affect and to make way for other face snapping methods (ex: nearest).
Refactored related `#define` into `enum`s. In particular, constants relating to...
- `ToolSettings.snap_flag` are now in `enum eSnapFlag`
- `ToolSettings.snap_mode` are now in `enum eSnapMode`
- `ToolSettings.snap_source` (was `snap_target`) are now in `enum eSnapSourceSelect`
- `ToolSettings.snap_flag` (`SCE_SNAP_NO_SELF`) and `TransSnap.target_select` are now in `enum eSnapTargetSelect`
As the terms became more consistent and the constants were packed together into meaningful enumerations, some of the attribute names seemed ambiguous. For example, it is unclear whether `SnapObjectParams.snap_select` referred to the target or the source. This patch also adds a small amount of clarity.
This patch also swaps out generic types (ex: `char`, `short`, `ushort`) and unclear hard coded numbers (ex: `0`) used with snap-related enumerations with the actual `enum`s and values.
Note: I did leave myself some comments to follow-up with further refactoring. Specifically, using "target" and "source" consistently will mean the Python API will need to change (ex: `ToolSettings.snap_target` is not `ToolSettings.snap_source`). If the API is going to change, it would be good to make sure that the used terms are descriptive enough. For example, `bpy.ops.transform.translate` uses a `snap` argument to determine if snapping should be enabled while transforming. Perhaps `use_snap` might be an improvement that's more consistent with other conventions.
This patch is (mostly) a subset of D14591, as suggested by @mano-wii.
Task T69342 proposes to separate the `Absolute Grid Snap` option out from `Increment` snapping method into its own method. Also, there might be reason to create additional snapping methods or options. (Indeed, D14591 heads in this direction). This patch can work along with these suggestions, as this patch is trying to clarify the snapping code and to prompt more work in this area.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D15037
|
|
This could happen when switching between custom action sets that both
had controller pose actions. Problem was that controller data is
cleared when changing action sets, and this clearing was done when
handling WM events, which always occurs after XR controller data is
updated from GHOST.
Now, instead of activating the action set immediately, delay activation
until just before the next XR actions sync.
|
|
The use-case is to allow an event handler (in C or a plugin) to
distinguish which hand produced the XR event.
The alternative is to register separate actions for each hand (e.g.
"trigger_left" and "trigger_right"), and duplicate the device bindings
(Oculus, HTC Vive, etc) for each action. Other than the problem of code
duplication, this isn't conceptually efficient since "trigger_left" and
"trigger_right" both represent the same event "trigger", and the
identity of the hand that produced that event is just a property of
that event.
Adds two string fields to the XrEventData called user_path and
user_path_other. The user_path_other field will be populated if the
event is a bimanual one (i.e. two-handed). This follows the pattern
used by the rest of the XrEventData struct for bimanual events (e.g.
state, state_other).
Reviewed By: muxed-reality
|
|
This allows object extras such as image-empties to be shown in the VR
viewport/headset display. Being able to see reference images in VR can
be useful for architectural walkthroughs and 3D modeling applications.
Since users may not want to see all object extras (lights, cameras,
etc.), per-object-type visibility settings are also added as session
options.
By slightly refactoring the definition of the 3D View object types
visibility panel (note: no functional changes), the VR Scene Inspection
add-on can show a similar panel without duplicating code. When VR
selection is possible in the future, the object type select options can
also be enabled.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14220
|
|
Add blank lines after file references to avoid them being interpreted as
doc-strings the following declarations.
|
|
Use <pre>..</pre> for pseudo-code.
|
|
|
|
After using MEM_dupallocN() on the original item/binding, the
user/component path ListBase for the new item/binding needs to be
cleared and each path copied separately.
|
|
|
|
Previously, the number of action map subactions was limited to two per
action (identified by user_path0, user_path1), however for devices with
more than two user paths (e.g. Vive Tracker) it will be useful to
support a variable amount instead.
For example, a single pose action could then be used to query the
positions of all connected trackers, with each tracker having its own
subaction tracking space.
NOTE: This introduces breaking changes for the XR Python API as follows:
- XrActionMapItem: The new `user_paths` collection property
replaces the `user_path0`/`user_path1` properties.
- XrActionMapBinding: The new `component_paths` collection property
replaces the `component_path0`/`component_path1` properties.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D13949
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
|
|
|
|
Dead-lock when VR viewport drawing and depsgraph updates would fight for
the draw-manager GL lock. This didn't usually cause issues because the
depsgraph would be evaluated at this point already, except in rare
exceptions like after file writing.
Fix this by ensuring the XR surface gets its depsgraph updated after
handling notifiers, which is where regular windows also do the depsgraph
updating.
|
|
After using MEM_dupallocN() on the original item, the bindings ListBase
for the new item needs to be cleared and each binding copied separately.
|
|
Ref T92709
|
|
|
|
|
|
|
|
|
|
|
|
`NULL` instead of `nullptr` in cpp code, and `else` statements after
returns.
|
|
|
|
|
|
Adds navigation transforms (pose, scale) to the XR session state that
will be applied to the viewer/controller poses. By manipulating these
values, a viewer can move through the VR viewport without the need to
physically walk through it.
Add-ons can access these transforms via Python
(XrSessionState.navigation_location/rotation/scale) to use with custom
operators.
Also adds 3 new VR navigation operators that will be exposed to users
as default actions in the VR Scene Inspection add-on. While all three
of these operators have custom properties that can greatly influence
their behaviors, for now these properties will not be accessible by
users from the UI. However, other add-ons can still set these custom
properties if they desire.
1). Raycast-based teleport
Moves the user to a location pointed at on a mesh object. The result
can optionally be constrained to specific axes, for example to achieve
"elevation snapping" behavior by constraining to the Z-axis. In
addition, one can specify an interpolation factor and offset.
Credit to KISKA for the elevation snapping concept.
2). "Grab" navigation
Moves the user through the viewport by pressing inputs on one or two
held controllers and applying deltas to the navigation matrix based on
the displacement of these controllers. When inputs on both controllers
are pressed at the same time (bimanual interaction), the user can scale
themselves relative to the scene based on the distance between the
controllers.
Also supports locks for location, rotation, and scale.
3). Fly navigation
Navigates the viewport by pressing a button and moving/turning relative to
navigation space or the VR viewer or controller. Via the operator's
properties, one can select from a variety of these modes as well as
specify the min/max speed and whether to lock elevation.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D11501
|
|
|
|
|
|
Addresses T77127 (Controller Drawing).
Adds VR controller visualization and custom drawing via draw
handlers. Add-ons can draw to the XR surface (headset display) and
mirror window by adding a View3D draw handler of region type 'XR' and
draw type 'POST_VIEW'. Controller drawing and custom overlays can be
toggled individually as XR session options, which will be added in a
future update to the VR Scene Inspection add-on.
For the actual drawing, the OpenXR XR_MSFT_controller_model extension
is used to load a glTF model provided by the XR runtime. The model's
vertex data is then used to create a GPUBatch in the XR session
state. Finally, this batch is drawn via the XR surface draw handler
mentioned above.
For runtimes that do not support the controller model extension, a
a simple fallback shape (sphere) is drawn instead.
Reviewed By: Severin, fclem
Differential Revision: https://developer.blender.org/D10948
|
|
|
|
|
|
Integrates XR input actions with the WM event system. With this commit,
all VR action functionality (operator execution, pose querying, haptic
application), with the exception of custom drawing, is enabled.
By itself, this does not bring about any changes for regular users,
however it is necessary for the upcoming VR add-on update that will
expose default controller actions to users.
For add-on developers, this updates the Python API with access to XR
event data (input states, controller poses, etc.), which can be
obtained via the "xr" property added to the bpy.types.Event struct.
For XR events, this property will be non-null and the event will have
the type XR_ACTION.
Further details:
XR-type window events are queued to the regular window queues after
updating and interpreting VR action states. An appropriate window is
found by either using the window the VR session was started in or a
fallback option.
When handling XR events, mouse-specific processing is skipped and
instead a dedicated XR offscreen area and region (see 08511b1c3de0) is
used to execute XR event operators in the proper context.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D10944
|
|
|
|
|
|
This adds an offscreen View3D window area for the VR view in order to
execute XR events/operators in the proper context. The area is created
as runtime data before XR events are dispatched and set as the active
area during XR event handling.
Since the area is runtime-only, it will not be saved in files and since
the area is offscreen, it will not interfere with regular window areas.
The area is removed with the rest of the XR runtime data on exit, file
read, or when stopping the VR session.
Note: This also adds internal types (EVT_DATA_XR, EVT_XR_ACTION) and
structs (wmXrActionData) for XR events.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D12472
|
|
Addresses T76082.
Since the DirectX backend does not work for AMD gpus
(wglDXRegisterObjectNV() fails to register the shared OpenGL-DirectX
render buffer, displaying a pink screen to the user), the original
solution was to use SteamVR's OpenGL backend, which, as tested
recently, seems to work without any issues on AMD hardware.
However, the SteamVR OpenGL backend (on Windows) was disabled in
fe492d922d6d since it resulted in crashes with NVIDIA gpus (and still
crashes, as tested recently), so SteamVR would always use the
AMD-incompatible DirectX backend (on Windows).
This patch restores use of the SteamVR OpenGL backend for non-NVIDIA
(AMD, etc.) gpus while maintaining the DirectX workaround for NVIDIA
gpus. In this way, issues are still resolved on the NVIDIA side but
AMD users can once again use the SteamVR runtime, which may be their
only viable option of using Blender in VR.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D12409
|
|
Line endings are already added.
|
|
This reverts 151eed752b01. Originally thought it was necessary to
initialize selected/active indices to -1 to prevent out-of-bounds
list access, but this is not needed since null checks are already
performed after obtaining list members via BLI_findlink().
In addition, leaving indices zero-initialized facilitates use of the
Python API, for example when displaying action map information in a
UI list.
|
|
Add null check for runtime data since it could already have been
freed via wm_xr_exit() (called on file read) prior to the session
exit callback.
Also, fix potential memory leak by freeing session data in
wm_xr_runtime_data_free() instead of session exit callback.
|
|
This fixes two memory leaks related to XR action maps.
1. Freeing of action maps needs to be moved from wm_xr_exit() to
wm_xr_runtime_data_free() since the runtime may have already been
freed when calling wm_xr_exit().
2. Action bindings for action map items were not being freed. This
was mistakenly left out of e844e9e8f3bb since the patch needed to be
updated after d3d4be1db3a0.
|
|
This addresses reduced visibility of scenes (as displayed in the VR
headset) that can result from the 8-bit color depth format currently
used for XR swapchain images.
By switching to a swapchain format with higher color depth (RGB10_A2,
RGBA16, RGBA16F) for supported runtimes, visibility in VR should be
noticeably improved.
However, current limitations are lack of support for these higher
color depth formats by some XR runtimes, especially for OpenGL.
Also important to note that GPU_offscreen_create() now explicitly
takes in the texture format (eGPUTextureFormat) instead of a
"high_bitdepth" boolean.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D9842
|
|
No functional changes.
|
|
Although the relevant structs (wmXrRuntime/XrActionMap/
XrActionMapItem) are zero-allocated, the selected and active action
map indices need to be initialized to -1 to prevent potential
out-of-bounds list access.
|
|
Addresses the remaining portions of T77137 (Python API for Controller
Interaction), which was partially completed by D10942.
Adds an XR "action maps" system for loading XR action data from a
Python script. Action maps are accessible via the Python API, and are used
to pass default actions to the VR session during the
xr_session_start_pre() callback.
Since action maps are stored only as runtime data, they will be
cleaned up with the rest of the VR runtime data on file read or exit.
Reviewed By: Julian Eisel, Hans Goudey
Differential Revision: https://developer.blender.org/D10943
|
|
Provides two key improvements to runtime controller data.
1. Separates controller poses into two components, "grip" and "aim",
which are both required to accurately represent the controllers
without manual offsets.
Following their OpenXR definitions, the grip pose represents the
user's hand when holding the controller, and the aim pose represents
the controller's aiming source.
2. Runtime controller data is now stored as a dynamic array instead
of a fixed array. This makes the API/functionality more adaptable to
different systems.
Does not bring about any changes for users since only internal
runtime functionality is currently affected.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D12073
|
|
Provides several important improvements to the runtime action
bindings operation and internal API.
Moves input-specific action data (input thresholds, input regions,
pose offsets/spaces) from actions to more granular action bindings.
This allows a single action to be mapped to a variety of inputs,
without having to share a single input threshold, region, or space.
Also removes the need for action space creation API, as spaces for
pose actions will be automatically created with the bindings.
The correct action data for the current inputs is set by calling
xrGetCurrentInteractionProfile() to get the current profile and then
retrieving the corresponding mapped data.
Does not bring about any changes for users since only internal
runtime functionality is currently affected.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D12077
|
|
|
|
|
|
Addresses T76003. When using VR with Eevee and viewport denoising,
scene geometry could sometimes be occluded for one eye. Solution is
to use a separate GPUViewport/GPUOffscreen for each VR view instead
of reusing a single one for rendering.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D11858
|
|
Improves control over the XR reference space by using the stage ref
space (user-defined tracking bounds) instead of local ref space
(position at application launch), if available. Also adds an
"absolute tracking" session option to skip applying eye offsets that
are normally added for placing users exactly at landmarks.
By enabling absolute tracking, users can define the tracking origin
in a way that is not linked to the headset position. Instead, the
tracking values given by the XR runtime are left unadjusted and a
user can manually calibrate an "origin" landmark object to adjust to
their real world space.
Can be useful for applications that use external tracking systems
and those that primarily only need to use controllers and not the
headset (e.g. motion capture).
The absolute tracking option requires an update to the VR
Scene Inspection addon to be accessible by regular users.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D10946
|
