https://github.com/KhronosGroup/OpenXR-Tutorials/blob/main/tutorial/1-introduction.rst?plain=1#L214

Go to the Build menu and select "Build Solution". The projects will be compiled, and the output from ``openxr_loader.vcxproj`` should be a library called ``openxr_loaderd.lib``.

is this still accurate with the switch to fetch dependency?

We need a solution for linear algebra. There's a file "xr_linear.h" in the OpenXR SDK which we could use.
We can copy it directly into the project, that obviously separates it from its intended source, plus it's PDX-License-Identifier: Apache-2.0, and copyright Khronos and "Oculus VR LLC" i.e. Meta.
We could add a new minimal header-only lib, or we could use something like glm.

If I were to write it I'd begin with a preamble which would frame the action system. i.e. why does it exist? What problems is it trying to solve? Why does it need to be so abstract and weird? Why can't I just access controller hardware directly etc...? The questions that developers may have going into this weird and unconventional system if they have NEVER seen it before. I think its crucial for developer understanding to get them into the right head space and framing for this and for that we need to give context.

There is also no mention of subaction paths, which is a huge point of confusion from developers. I believe that should also be given some context (motivation and history), and potentially an example as to why it would be used.

I'd prefer that the examples of actions given were not just controller button actions, but rather game / app actions like "teleport" "interact" "shoot" "jump" etc...

Currently the ABI filter is set for ARM, there are devices out there that are not ARM based

https://github.com/KhronosGroup/OpenXR-Tutorials/blob/simul-pitch/Chapter2.1_Android/app/build.gradle#L14

abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a', 'arm64-v8a'

XR_REFERENCE_SPACE_TYPE_LOCAL_FLOOR_EXT is commonly used in Unity to define the origin of local space on the floor.
Thank you, Andreas Selvik for the suggestion.

OS Selector tabs -> Color Icon when selected, Black&White when not selected ( do keep tab highlighted functioning currently)

Remove: 6 views - Multi-wall projection-based (CAVE-like) VR system.

Since nothing at this point supports this.

During early meetings discussed adding a "Copy" button to each source code text box. Can this be done?

1. The space section is missing nuances of re-localization that might occur.

2. https://github.com/KhronosGroup/OpenXR-Tutorials/blob/main/tutorial/4-actions.rst?plain=1#L14

Spec defines local space as:

The LOCAL reference space establishes a world-locked origin, gravity-aligned to exclude pitch and roll, with +Y up, +X to the right, and -Z forward. This space locks in both its initial position and orientation, which the runtime may define to be either the initial position at application launch or some other calibrated zero position.

The tutorial says:

the XR hardware’s “local” space - either the headset’s starting position or some other world-locked origin.

We should probably clarify this a bit.

Instead of describing how to download the OpenXR SDK manually and set various paths in CMake should we use this automatic fetched dependency?

set(BUILD_ALL_EXTENSIONS ON CACHE INTERNAL "Build loader and layers with all extensions")
set(BUILD_TESTS OFF CACHE INTERNAL "Build tests")
set(BUILD_CONFORMANCE_TESTS OFF CACHE INTERNAL "Build conformance tests")
set(BUILD_API_LAYERS ${USE_OPENXR_LAYERS} CACHE INTERNAL "Use OpenXR layers")
FetchContent_Declare(
        oxr
        URL_HASH MD5=390455e9395a92d6b730afb8f23fac8e
        URL openxr_source_sdk,https://github.com/KhronosGroup/OpenXR-SDK-Source/archive/refs/tags/release-1.0.27.zip)```

Then the application can use this simply via:

target_link_libraries(openxrtutorialch2 PUBLIC
        openxr_loader

EDIT: Doing this will remove a lot of explanation code from the tutorial on how to build and install the OpenXR SDK which is just distracting from the purpose.

Move actions before interaction profiles. From a game developer perspective actions are the hero, understanding actions is the abstraction your game uses without caring what's behind it, thats the important bit.

Define good actions, build your game based on those actions.

Than interaction profiles are just a means to map those actions to controllers you're using.

Interaction profiles are just how you customize exposing those actions on specific controllers
getting your actions (and sub-action paths) and action sets right is critical

It appears the source code is mixing tabs and spaces.

indentation = 4 spaces ... Not tabs.

Due by 5pm UK Time June 29

https://github.com/KhronosGroup/OpenXR-Tutorials/blob/main/tutorial/1-introduction.rst?plain=1#L258

still talks about pre-compiling the SDK, that should no longer be needed.

If the Runtime supports it, you might have more than one Instance at a time, if more than one XR device is in use.

See also

https://registry.khronos.org/OpenXR/specs/1.0/loader.html#functional-flow

The loader supports a single XrInstance at a time in order to avoid tracking handle values and their relationship to the LoaderInstance. Every XR function call is assumed to be for the single XrInstance that has been created. This enables the loader to work with future extensions and handle types without change.

The inline Windows OS selector button stays highlighted regardless of which OS has been selected.

Instead of describing how to build monado for windows just instruct them to download the CI binaries:

Windows: https://gitlab.freedesktop.org/monado/monado/-/jobs/44532444/artifacts/download?file_type=archive

Hi, while going through the tutorial, I did found that the code examples are rendered on top of the top menu, rest of the content seems to go behind the top menu.

I don't know what the design that was decided, is the top meny supposed to be sticky or is it supposed to scroll with the text? Just wanted to put this here for discussion.

Tested on current Edge.

On Android the Loader requires the JVM pointers. For example:

#ifdef XR_USE_PLATFORM_ANDROID
bool init_android(struct android_app *state) {
  PFN_xrInitializeLoaderKHR xrInitializeLoaderKHR = nullptr;
  xrGetInstanceProcAddr(
      nullptr, "xrInitializeLoaderKHR",
      reinterpret_cast<PFN_xrVoidFunction *>(&xrInitializeLoaderKHR));
  if (xrInitializeLoaderKHR == nullptr) {
    ALOGE("Unable to find xrInitializeLoaderKHR");
    return false;
  }

  XrLoaderInitInfoAndroidKHR init_loader{
      .type = XR_TYPE_LOADER_INIT_INFO_ANDROID_KHR,
      .next = nullptr,
      .applicationVM = state->activity->vm,
      .applicationContext = state->activity->clazz};

  XR_CHECK_RET(xrInitializeLoaderKHR(
      reinterpret_cast<XrLoaderInitInfoBaseHeaderKHR *>(&init_loader)));

  return true;
}
#endif

https://github.com/KhronosGroup/OpenXR-Tutorials/blob/simul-pitch/Chapter2.1_Android/app/src/main/AndroidManifest.xml#L22

      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.LAUNCHER" />
        <category android:name="org.khronos.openxr.intent.category.IMMERSIVE_HMD" />
      </intent-filter>

and broker permission

<uses-permission android:name="org.khronos.openxr.permission.OPENXR_SYSTEM" />

Given that this is a tutorial, I think it's important that there be an abundance of comments in the code explaining (perhaps in high detail) exactly what is going on.

In particular I think each and every function should have a comment that describes what that function/method does, how it's used, and probably even why it's needed.

Plus I'd like to see more comments throughout the code in general.

Currently debug output is being written to std::cout. On android that goes nowhere special. Please add a small class that abstracts debug output so it is redirected to the appropriate location ( e.g. logcat on Android / std::cout elsewhere )

Chapter 3 needs an update to the way environment blend mode is selected. This should be a negotiation between the what the application can support and what the runtime supports. See pull request #24

Text: (c) 2023, Khronos Group. CC-BY 4.0 International
Code: (c) 2023, Khronos Group. Apache License 2.

Footer not visible.

Can we add a work in progress disclaimer just in case google finds the site.

Windows section is leaking into Linux and Android in Chapter 2.1

It seems to be somewhat more focused on using the interaction profiles than explaining the why...

It would be good to have something in there describing why interaction profiles exist / why this pattern is used.

For the graphics API selection tabs, we have logos relating to their respective APIs. Khronos APIs are well-supported, but at present we don't have a good solution for Microsoft's DirectX APIs.
We are already in discussion with Microsoft for the usage of the Windows 10 logo, but we should also ask what would be best to use for the DirectX APIs.

As Chapter 2 stand currently, the first half of the text is just setting up the project/build files and getting a debuggable application, which feels disconnected from the second half where we set up the XrInstance and XrSession and get going on OpenXR code and ideas.

Should we move Project Setup to its own separate chapter or add it as Chapter 1.4?
I feel it would be clearer for reading the text and for a user to follow.

For Android, we currently using this version of the Android NDK.

Unfortunately, VK_MAKE_API_VERSION is not defined in this version of the Vulkan headers. As a workaround, I have defined VK_MAKE_API_VERSION to wrap over VK_MAKE_VERSION.

Is this workaround suitable or bad practice?
I haven't checked, but do later versions of the NDK have newer Vulkan headers that have the VK_MAKE_API_VERSION macro?
If so, do we want to upgrade our NDK version for the tutorial?

I meant to make a formal submission, but just ran out of time. There are some issues with building the tutorial on Linux, and even more troublesome issues with running it -- at least for me. My apologizes for bunching this all in one issue, but it does all have to do with getting Chapter 2 to build and run on Linux.

First some issues with header files:

• For starters, I think it's cleaner to include the standard C++ headers in the source file that requires them rather than all bunched into HelperFunctions.h, so I'd move that block to "main.cpp".
• That said, there is actually a missing include of that does need to go in "HelperFunctions.h" for the use of "stdcmp()" -- I guess the MS-Windows compiler must be more lenient.
• Also in "HelperFunctions.h", there is no need to include <unordered_map>.
• The final issue with includes is that "main.cpp" also needs to include for the declaration of "unique_ptr".

The only other issue with compiling is:

• The type "DebugOutput" is not declared anywhere in the Linux build, so I removed the line at the top of the "OpenXRTutorial_Main()" function. After that the build completed.

Unfortunately, when I then run "./OpenXRTutorialChapter2" it outputs the title of the tutorial, and then crashes on the line:
const std::vector<int64_t> &supportSwapchainFormats = GetSupportedSwapchainFormats();
I'm not sure whether this is the cause of the error, but in gdb, I was given this information:
(gdb) print supportSwapchainFormats
$4 = std::vector of length -525420, capacity -525420 = {6620760227972, 962689011016, -8895937474100832024,
-5437172960282474460, -4068641623515267036, -4519086758524671672, 6826918609914, -18360, [,,,]

A negative vector length seems like it could be a problem, but I don't know whether this is a cause or a symptom.

I tried a few more experiments:

• Changing the example version from 2.3 to 2.1:
  #define XR_DOCS_CHAPTER_VERSION XR_DOCS_CHAPTER_2_1
• and I tried forcing a graphics API setting -- which worked on the version from 07/25/23:
  #define XR_USE_GRAPHICS_API_OPENGL
  (also tried "VULKAN")

And one final thought -- last week I was able to get version Chapter 2.1 to build and run, and connect to the Monado OpenXR runtime, so that's a slight regression, but I'm happen to take a step back if it ultimately means we get where we want.

Okay, I must be doing something wrong, because I can't get the simplest tutorial code to build.

In my first attempt, I was following along in section 2.1, but it's not always clear what file code snippets are supposed to go in -- for example, there's code that the instructions indicate go into the files "OpenXRHelper.h" and "HelperFunctions.h", but then a short while later it's stated that only three files should have been created by then "CMakeLists.txt" "Chapter2/CMakeLists.txt" and "Chapter2/main.cpp". And after running CMake (in my case "ccmake"), I try a build, but there are all sorts of things missing. Also, the code for "HelperFunctions.h" comes immediately after I'm told to open a new file called "main.cpp" -- this is confusing.

At one point I thought I read that at the end of each chapter I might be able to download the completed code files, but I don't see that now, so maybe I was imagining it. So instead I want to the github page, and started grabbing code from the "Chapter 2" section, but it seems like the "main.cpp" there is missing some header inclusions -- I'm getting a ton of errors. But also, it seems I need to download/copy several files to do a build, which seems to be overly complicated for the first Chapter with code. So perhaps we can start with something a lot simpler.

If we could have a tar/zip file with just the files/code needed for Chapter 2, I think that would be immensely helpful.

I have other issues too, but I'll save some of them for later, but one of them is comments -- there needs to be a lot more comments in the code.

Search results text is light gray on white background, this is hard to read, make the text the same color as normal body text.

Hey all,

I did a rebuild today on the Linux branch of the github repo, and I encountered two issues.

1. There's still a hard-coded directory for Roderick in the "Chapter2/main.cpp" code -- the logic implies that it should be overridden, but that doesn't seem to happen, and so since I don't have that path, it errors out.

2. When building Chapter4, I get this error:
   [ 66%] Building CXX object CMakeFiles/OpenXRTutorialChapter4.dir/home/wrs1/Apps/OpenXR/Tutorial/SimulTut/OpenXR-Tutorials_git20230918/Common/OpenXRDebugUtils.cpp.o
   [ 68%] Linking CXX executable OpenXRTutorialChapter4
   GLSL ../Shaders/VertexShader.glsl
   make[2]: Vulkan_GLSLANG_VALIDATOR_EXECUTABLE-NOTFOUND: Command not found
   make[2]: *** [CMakeFiles/OpenXRTutorialChapter4.dir/build.make:219: OpenXRTutorialChapter4] Error 127
   make[2]: *** Deleting file 'OpenXRTutorialChapter4'
   make[1]: *** [CMakeFiles/Makefile2:190: CMakeFiles/OpenXRTutorialChapter4.dir/all] Error 2

Create 3D diagrams for XrSpaces to be used in Chapter 3.

It might also be good to have some discussion of the difference between aim and grip pose ; why they both exist; what the different purposes are, etc.

If the session goes away from underneath an application it should exit gracefully, currently it fails in an infinite loop.

XR_ERROR_SESSION_LOST in xrWaitFrame: Session is lost
ERROR: OPENXR: -17(XR_ERROR_SESSION_LOST) Failed to wait for XR Frame.
Breakpoint here to debug.
XR_ERROR_SESSION_LOST in xrBeginFrame: Session is lost
ERROR: OPENXR: -17(XR_ERROR_SESSION_LOST) Failed to begin the XR Frame.
Breakpoint here to debug.
XR_ERROR_SESSION_LOST in xrEndFrame: Session is lost
ERROR: OPENXR: -17(XR_ERROR_SESSION_LOST) Failed to end the XR Frame.
Breakpoint here to debug.

you can recreate this by running against monado and closing monado before the application.

I propose we use the following code style guide:

.clang-format

---
BasedOnStyle:  Google
Language:        Cpp
AllowShortFunctionsOnASingleLine: None
Standard: Cpp11
TabWidth: '4'
UseTab: Never
...

  void OnPreRender(const XrFrameState &state) override {
    UpdateGaze(state.predictedDisplayTime);
    XrVector3f wind{-0.001f, 0.0f, 0.0f};
    for (auto &bubble : bubbles_) {
      if (bubble->Update(state.predictedDisplayTime, wind)) {
        missed_++;
      }
    }
  }


    for (auto &bubble : bubbles_) {
      if (bubble->TestHitRay(head_pos, gaze_dir)) {
        score_++;
        auto snd = sound_node_->GetComponent<Components::Sound>();
        if (snd) {
          sound_node_->SetTranslation(gaze_target);
          snd->Play();
        } else {
          ALOGE("Hmm no sound component");
        }
      }
    }

I left a number of comments on 7738eb6

My overall concern is that there is a lot of prose being spent on things to remove and add, when:

• Google frequently changes the Android gradle plugin so it's hard to keep up with the contents of the template (stuff to remove)
• Several of the changes actually add back deprecated Android gradle plugin usage
• Only a few details are actually important here for the details of using OpenXR in native code on Android: the other parts are just "normal native code on android" things or "stuff you don't actually want to do but that's what we did to match our example"

Basically in nearly every release we have to adjust stuff in our Gradle files to work with the latest Android Studio changes. It's preferable, at least to me, if the text sticks to just those things that are OpenXR-specific (which haven't had to change in quite a while) so updates can just be to the build, not to the text as well.

cc @rbessems

So I've been working through the OpenXR tutorial in as small of steps as I can, as though (and in fact) a naive developer for OpenXR, and I'm only part-way through section 2.1, and have it building, but when running it doesn't connect to my OpenXR runtime (Monado), running on Linux.

I've had to make some changes here and there to the code in order to get it to compile, so it's possible my changes were not correct -- but the original code seems to have some mistakes in it. One mistake in particular is that there seems to be inconsistent usage of "XrInstance" vs "xrInstance" vs. "instance" and I think even "xr_instance". I think many uses of "XrInstance" should be just "instance" so that is the change I made.

If anyone wants to look at my changes, I put a tar file of my version at:

Any place where I made changes to what's in the online tutorial are commented with "WRS".

NDK 4.2.2 is pretty old and I believe throwing warnings in newer Android Studio versions. Let's get some more recent in here.

Member variables currently have no special distinction. I propose we follow hello_xr's pattern and name class member variables

m_snakeCase

The current method of graphics api selection is fairly static and will fail to run if the underlying device doesn't support whatever was hard coded even though the code supports alternate API's.

Ideally the code has an ordered set of graphics API's and selects the first from that list that the underlying runtime supports.

I did a test this evening from the current github clone on my Linux system, and encountered an error building Chapter 2 where:
error: ‘struct ksGpuWindow’ has no member named ‘hDC’
And I found that in "gfxwrapper_opengl.h" this field only exists for MS-Windows, so the correct value needs to be selected for the Linux build.

Bill

Hi,

The navigation button in mobile view does not seem to respond to mouse clicks or touch events.

Tested with Chrome 116 and Edge 116.

I've had an icon made as a test, this is to represent an XR hand controller for Chapter 4.

You can see it at a more usual size in-place at Chapter 4

Please post any feedback on general design, colour (this one is grey but most will use pastels) etc.