- state.features.overlay should remain a bool since it just indicates
whether the extension is supported/enabled.
- split the config value into a bool/u32 pair so the full u32 range can
be used for the order (seems important to coordinate with other apps).
- Also you can use a boolean now like before, which uses 0 as the order.
LOVR doesn't require OpenXR to run. When the headset module is enabled
and the openxr headset driver is enabled, LOVR tries to initialize
OpenXR, and if it fails then it will try the next driver.
The OpenXR loader will print error messages to stderr by default. This
is undesirable because someone who is unfamiliar with OpenXR will see a
bunch of messages in their console that say "ERROR" and think something
is wrong, even though the messages are innocuous and don't indicate an
actual problem.
The only way to silence these messages from the OpenXR loader, to my
knowledge, is to set the XR_LOADER_DEBUG environment variable to 'none'.
This is only done when the environment variable isn't set, so it's still
possible to set XR_LOADER_DEBUG to see the logs.
Recent SteamVR versions have bugs with it, especially after triggering a
recenter operation.
In SteamVR, recentering fires referenceSpaceChangePending for the LOCAL
space, then the STAGE space, then the LOCAL space again, all with
different changeTimes. No poseInPreviousSpace is given.
Recreating the main reference space whenever this event is received
leads to strange, inconsistent issues. Sometimes the local/stage spaces
end up on top of each other, other times one or both will be way up in
the air (putting the headset at negative y coordinates).
This bug is even present when recentering in the compositor, so it's not
an issue with lovr. Cautiously disabling the local-floor emulation on
SteamVR runtimes and just always using the STAGE space until things are
sorted out.
The "vec3 is 4 floats" thing was consistently confusing to people. It's
reverted everywhere except for Curve.
maf now has full sets of methods for vec2/vec3/vec4, for consistency.
Vector bindings now use luax_readvec* helper functions for the
number/vector variants, and use maf for most functionality, which cleans
things up a lot.
Quest added a thing where they emulate grip pose when hand tracking is
active. This is actually pretty cool, and maybe LÖVR should do it too
on other runtimes, but it messed up the Quest hand mesh animation, for
some complicated reasons:
- Previously, getPose('hand/*') was returning the wrist pose because
LÖVR fell back to hand tracking data when the controller wasn't
tracked.
- Because of this, coupled with the fact that hand/controller models are
expected to be drawn at the hand pose, hand meshes were animated such
that the root node was located at the wrist pose.
- When Oculus added grip pose emulation for hand tracking, it caused a
discrepancy:
- Hand meshes were still being animated relative to their wrist pose
- getPose was now returning grip-style poses
- This resulted in hand meshes being off by approximately 90 degrees.
The fix is to locate skeletal joints relative to the grip pose when
animating Oculus hand meshes, and to place the origin/wrist at its real
pose instead of assuming it's the origin.
Origin type used to be a query-able property of the VR system that
indicated whether the tracking was roomscale or seated-scale.
The t.headset.offset config value could be used to design an
origin-agnostic experience, which by default shifted content up 1.7
meters when tracking was seated-scale. That way, stuff rendered at
y=1.7m was always at "eye level". It worked pretty well.
It's getting replaced with a t.headset.seated flag.
- If seated is false (the default), the origin of the coordinate space
will be on the floor, enabling the y=1.7m eye level paradigm. If
tracking is not roomscale, a floor offset of 1.7m will be emulated.
- If seated is true, the origin of the coordinate space will be y=0
at eye level (where the headset was when the app started). This is
the case on both roomscale and seated-scale tracking.
So basically 'seated' is an opt-in preference for where the app wants
its vertical origin to be.
One advantage of this is that it's possible to consistently get a y=0
eye level coordinate space, which was not possible before. This makes
it easier to design simpler experiences that only need to render a
floating UI and don't want to render a full environment or deal with
offsetting everything relative to a 'floor'. This also makes it easier
to implement hybrid VR+flatscreen experiences, because the camera is at
y=0 when the headset module is disabled.
The opt-in nature of the flag, coupled with the fact that it is
consistent across all types of tracking and hardware, is hopefully a
more useful design.
You can do lovr.headset.getPose('floor') to get the offset of the stage
relative to the local origin if you want to draw something at the center
of the play area.
Also lovr.headset.isTracked('floor') basically tells you if it's roomscale.
- lovr.headset.getPassthrough returns current passthrough mode
- lovr.headset.setPassthrough sets the passthrough mode
- nil --> uses the default passthrough mode for the headset
- bool --> false = opaque, true = one of the transparent modes
- string --> explicit PassthroughMode
- lovr.headset.getPassthroughModes returns a table of supported modes
Pass stores draw commands rather than sending them to Vulkan
immediately.
The main motivation is to allow more flexibility in the Lua API. Passes
are now regular objects, aren't invalidated whenever submit is called,
and can cache their draws across multiple frames. Draws can also be
internally culled, sorted, and batched.
Some API methods (tallies) are missing, and there are still some bugs to
fix, notably with background color.
View count is well-defined to be 2 with the current view configuration,
and people should be able to rely on getViewCount even before the views
are tracked. It returns the number of views in the view configuration,
not the number of views with valid data.
- If timestamp is zero (before .update is called), return empty data
instead of erroring.
- Check for valid position/orientation separately, and return empty data
for anything that's invalid. Previously both position/orientation
were used if either was valid, which returns undefined results.
bjorn
BabbleBones
duinodu