Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature openxr #2012

Draft
wants to merge 18 commits into
base: master
Choose a base branch
from

Conversation

Starcommander
Copy link
Contributor

@Starcommander Starcommander commented May 15, 2023

This pull-request adds the feature for using openxr in jme3.
It is a working first implemention and some improvements are still necessary.

  • Moving HMD (currently only rotating)
  • Controllers
  • View perspective is not correctly

I tested it (and works) with OSVR-HMD on Debian 11 (Bullseye) with running monado-service.
I also tested it (and works) with my HTC-VIVE.

To get it running:

  • In main function modify app settings with: XrHmd.setRendererForSettings(appSettings);
  • In simpleInitApp(): XrHmd.initHmd(this);
  • Add your stuff into rootNode
  • Start monado-service
  • Start app.

@stephengold stephengold added this to the Future Release milestone May 15, 2023
Starcommander pushed a commit to Starcommander/jmonkeyengine-openxr that referenced this pull request May 16, 2023
stephengold pushed a commit that referenced this pull request May 16, 2023
New PullRequest as suggested in #2012

Co-authored-by: Starcommander <starcommander@gmx.at>
@stephengold
Copy link
Member

stephengold commented May 16, 2023

Given JME's staffing constraints, I worry about adding to the project's maintenance burden.

  • Has adding OpenXR support been discussed at the JME Hub/Forum?
  • Is there a good reason develop the jme3-xr library in the jmonkeyEngine repo, instead of as a separate project (like Blocks, Lemur, Minie, and ShaderBlow)?

@Starcommander
Copy link
Contributor Author

@stephengold
Here is a Forum, where openxr was discussed.
https://hub.jmonkeyengine.org/t/solved-vr-launch-title-and-icon-in-steamvr/43706/14

When we have openvr included in jme3-vr (that needs steam binary blob "steamvr"), then why not openxr that is open source, and should be the successor of openvr?

@neph1
Copy link
Contributor

neph1 commented May 17, 2023

I think it would be a great contribution to add openxr. Adding just openxr as a separate project is probably not feasible as it relies on jme-vr.

At the same time I share @stephengold 's concerns. The vr package hasn't had a proper maintainer since 2015 and has relied on sporadic contributions since.

I wonder if it would make sense to break it put of core to a separate project. It could still reside in the jme project, but not alongside the core packages. That way, updating it would be a little less sensitive.

Commenting on the pr itself, I think proper hmd translation and controller support would be minimum requirements for it to be considered. Otherwise the use case is very limited.

@jseinturier
Copy link
Contributor

Integrating OpenXR to JMonkey is a good idea for me. However, i've some concerns regarding the proposed method:

  • jme3-vr module has been thinked in order to provide a high level abstraction of existing VR API (at the beginig OpenVR and VRAPI). Integrating OpenXR should be achieved by extending the current jme3-vr module instead of removing it and providing an OpenXR exclusive module. At this time, OpenVR and VRAPI are supported and are binded by LWJGL. Removing these functionnalities from JMonkey can be problematic for end users.

  • OpenXR provide Virtual Reality and Augmented Reality functionnalities. In the "real life" we are not offen use VR / AR at the same time so for me it is not relevant to create a new module that embed all the functionnalities. I think we could split VR / AR functionnalities within separated modules (jme3-vr, jme3-ar ?)

@richardTingle
Copy link
Member

Very cool, I will take a look at this PR properly on Friday (and can test on an occulus quest). But I would vote yes to having openXR be an engine feature rather than a seperate library. It's a fundamental capability like android launch that might then have libraries build around it to produce advanced functionality.

I'm also pro this being seperate from the existing VR stuff because that was written in a very different time where there were many competing standards that needed to be abstracted over

@Ali-RS
Copy link
Member

Ali-RS commented May 17, 2023

Adding just openxr as a separate project is probably not feasible as it relies on jme-vr.

From a quick look at this PR (in the gradle build), I do not see how the jme3-xr project relies on jme3-vr.

@neph1
Copy link
Contributor

neph1 commented May 17, 2023

Adding just openxr as a separate project is probably not feasible as it relies on jme-vr.

From a quick look at this PR (in the gradle build), I do not see how the jme3-xr project relies on jme3-vr.

Damn. I thought I saw it was when I checked on my phone last night. Disregard that part.

@Starcommander
Copy link
Contributor Author

@Ali-RS Yes, you are right, jme3-vr is not necessary to launch an app with jme3-xr.
So, maybe jme3-xr can be a successor of jme3-vr in future.
I will also still work on improvements of this project, for example controller support, and so on.

@richardTingle
Copy link
Member

If we do want it in a seperate library I'd be happy to have it in Tamarin (as a Tamarin 2 that is only openXR and Tamarin 1 keeping legacy support for openVR) and then I'd maintain it

@richardTingle
Copy link
Member

I've been working on actions and am making a fair bit of progress. Have got basic button presses registered and working (I mention this to avoid us duplicating work).

I have no idea why I'm getting the weird lensing effects when I turn my head and have given up trying to understand why (at least for now)

@stephengold
Copy link
Member

Could you please convert this PR to a "draft"?
That would make it obvious that the PR isn't ready to be integrated.

@Starcommander2
Copy link

Could you please convert this PR to a "draft"? That would make it obvious that the PR isn't ready to be integrated.

Yes, when I am back on Friday I will switch to draft.
Unfortunately I have no access to my account currently.

@Starcommander Starcommander marked this pull request as draft May 24, 2023 21:09
@Starcommander
Copy link
Contributor Author

@richardTingle
You made some interesting progress regarding actions and some little changes in hmd-moving
How would you suggest, we should continue the work?
I would really like to see jme3-xr in next release of jmonkeyengine 😉

@richardTingle
Copy link
Member

richardTingle commented May 28, 2023

@richardTingle You made some interesting progress regarding actions and some little changes in hmd-moving How would you suggest, we should continue the work? I would really like to see jme3-xr in next release of jmonkeyengine 😉

@Starcommander yes, actions are going well, I have basic button presses and haptics working. Getting hand skeletons and hand poses working next; then I'll try to get tamarin's bound hands and grab interactions working with it. I much prefer openXR's approach to actions; suggested bindings specified in code, rather than openVRs manifest file that must be specified by an absolute path.

I found a method to get openXR to suggest eye positions and angles which is what I used in that hmd change.

On camera stuff I'm much less good, are you happy to tackle that? I couldn't get to the bottom of the lensing effects I was seeing. Do you see that too? That if you look directly at something it's in the right place but as you move your head it seems to move.

I'm fairly relaxed on it being a jme3-xr or incorporated into Tamarin (im less keen on a non Tamarin non jme library but thats just me being selfish as Tamarin is my library so if other people want that I'll go with the flow). 2024 does sound like a long time to wait though; that said an OpenVr to OpenXR migration looks like it would be quite easy for existing projects. I will at the very least want to keep the more opinionated bound hand, grab and lemur support within Tamarin.

bob0bob added a commit to bob0bob/jmonkeyengine that referenced this pull request May 31, 2023
* Android: Implemented AndroidNativeBufferAllocator - Deprecated AndroidBufferAllocator (jMonkeyEngine#1821)

* [skip ci] update natives snapshot

* Add GL debug capabilities (jMonkeyEngine#1790)

* Add GL debug capabilities

* Fix: check for null names

* Add java types to VarType and type checks to MatParam (jMonkeyEngine#1797)

* SettingsDialog: Fixed LAF

* SettingsDialog: Updated jme3 copyright

* README.md:  add a link to Chatter Games website

* Update README.md to include Exotic Matter (jMonkeyEngine#1838)

Would be great to have our game Exotic Matter also mentioned as its engine is based on jME. Thanks!

* jme3-examples:  update the fallback URLs for "TerrainGridTestData.zip"

* Improved code readability: ParticlePointMesh and ParticleTriMesh (jMonkeyEngine#1831)

* jme3-core:  add tests for Transform.toString()

* Fix issue  jMonkeyEngine#1839 (Memory Leak in DefaultLightFilter)

Co-authored-by: Lukas Habring <lukas@Lukas-PC>

* Added getter & setter for FilterPostProcessor.depthFormat (jMonkeyEngine#1841)

* Added setter for FilterPostProcessor.depthFormat

* Added getter for FilterPostProcessor.depthFormat

* update the Gradle wrapper to v7.5.1

* main.yml:  GitHub Action's ubuntu-18.04 environment is deprecated

* bugfix:  mergedJavadoc task is incompatible with Gradle v7

* main.yml:  udate "actions/setup-java" to v3

* main.yml:  add JDK 17 tests

* build.gradle: update gradleVersion in case user runs the "wrapper" task

* Fix jMonkeyEngine#1843 (java.util.zip.ZipException in HttpZipLocator) (jMonkeyEngine#1842)

* HttpZipLocator:fix invalid code lengths set & invalid distance too far back ZipExceptions.

* Get file name length and extra field length from local file header to calculate file data offset.

* Make fields `byteBuf`, `charBuf`, `utf8Decoder` non-static because they are not thread-safe.

* Surround streams with try-with-resources block.

* Clean up the display modes parsing

* No need to separately test for the contains

* README.md:  SDK v3.4 has been released

* Some enhancement to new animation system (jMonkeyEngine#1845)

* Some enhancement to new animation system, including:
* Option to enable/disable animation mask propagation to child actions.
* Option to control max transition weight. For example useful for controlling smooth animation transition when an animation is removed from an upper layer.
* Added animation loop support in AnimLayer.
* AnimLayer can now also keep action name, so one can easily lookup currently playing action name in an specific layer.

* Minor Javadoc fix.

* AnimLayer: clear `currentActionName` inside `cloneFields` method.

* Added a Loop tween to Tweens factory class (jMonkeyEngine#1846)

* Added a Loop tween to Tweens factory class. Supports looping by count or duration.

* Redesigned the Loop tween to work similar to Sequence tween. Now fast forwarding the loop will also try to catch up the loops left behind making sure they always see their 'length'.

* Added the missing Override annotation.

* Added Tweens.cycle() and Tweens.invert() methods (jMonkeyEngine#1849)

Cycle is used for running delegate tween back and force and Invert is used to run delegate tween backward.

* BlendAction: resolve slow-motion side effect caused by stretching actions (jMonkeyEngine#1848)

* BlendAction: resolve slow motion side effect caused by stretching any action that doesn't have the same length. It generates speed factor for each child animation that are dynamically interpolated and applied to base speed based on the blend weight taken from blend space.

* Add missing javadoc.

* Add Copyright.

* Renamed calculateSpeedFactors() to applyDefaultSpeedFactors() and made it non static.

* Fix issue jMonkeyEngine#1850 (JmeSystem.writeImageFile() throw java.nio.BufferUnderflowException) (jMonkeyEngine#1851)

* jme3-jogg:  upgrade the j-ogg-all library to v1.0.2

* jMonkeyEngine#1569 Fix license file to be better detected by GitHub (jMonkeyEngine#1855)

* jme3-plugins:  update the "gson" library to v2.9.1

* workflows/main.yml:  update the "checkout" action to v3

* fix: broken link in README.md (jMonkeyEngine#1858)

Signed-off-by: Kasper Aaquist Johansen <kasperaaquist@gmail.com>

Signed-off-by: Kasper Aaquist Johansen <kasperaaquist@gmail.com>

* workflows/main.yml:  update wrapper-validation-action to v1.0.5

* update wrapper-validation-action to v1.0.5 (one more place)

* README.md:  SDK v3.5.2 has now been published

* Quaternion:  javadoc

* Add instance culling function in InstancedGeometry (jMonkeyEngine#1865)

* Added a workaround to prevent shadow disappearing on instanced geometries away from camera by introducing an instance culling function on InstancedGeometry. There also is a default implementation provided.

* Removed the bound-scale hack for shadow disappearing issue from DefaultInstanceCullingFunction. The “right” solution is to have it pay attention to the frustums of whatever shadow-casting lights are around… but anyway developers now can implement their own frustum culling however they like or even "unset" it to disable instance culling which should also resolve the shadow issue.

* Remove unused imports.

* Fix: make the stencil test functions usable. (jMonkeyEngine#1866)

* Fix: make the stencil test functions usable.

* Fix: formatting

* Fix: formatting

* Fix: formatting

* Fix: copyright year

* upgrade to Gradle v7.6 (for its Java 19 support)

* Read shorts properly

* More efficient logging

* Read unsigned byte properly

* Remove unnecessary byte and call the variable c as in the formulas

* move SettingsDialog and ErrorDialog to new jme3-awt-dialogs module (jMonkeyEngine#1876)

* Refactory Settings/Error dialogs in JmeDialogsFactory and jme3-awt-dialogs

* add build.gradle

* Add copyright headers

* Fix formatting and documentation

Co-authored-by: riccardobl <riccardo0blb@gmail.com>

* JmeSurfaceView: Package migration (jMonkeyEngine#1819)

* JmeSurfaceView: migration to new package (com.jme3.view.surfaceview)

* JmeSurfaceView: migration to new package (com.jme3.view.surfaceview)

* upgrade the groovy-test library to v3.0.13

* jme3-core:  correct/clarify javadoc

* Implementation of a glTF extension loader for KHR_texture_transform (jMonkeyEngine#1869)

* Implementation of a glTF extension loader for KHR_texture_transform

* Thread-safe version of the glTF extension loader for KHR_texture_transform

* Updated thread-safe version of the glTF extension loader for KHR_texture_transform

* Fix (switched indices of the translation matrix): thread-safe version of the glTF extension loader for KHR_texture_transform

* Added support for texCoord, fixed matrix comparison

* Simplified matrix comparison, removed trailing whitespaces

* Update to differentiate transformations applied to different UV sets

* Improved memory usage for transformMap

* Specified Map generic types & removed unnecessary cast

Co-authored-by: Manuel <Manuel@DESKTOP-6RJH3UF>

* jme3-core:  test the com.jme3.math.Triangle class

* bugfix:  Mesh.getTriangle() may yield an incorrect centroid

* Fix jMonkeyEngine#1867 (LightFilter gets applied even if not needed) (jMonkeyEngine#1872)

* Add NullLightFilter.java

* Add usage of null light filter when rendering shadowmaps

* Fix formatting

* Make static NullLightFilter final

* Fix formatting and author

* BlendableAction: Fix JavaDoc for setMaxTransitionWeight & replace assert with IllegalArgumentException (jMonkeyEngine#1881)

* Fix jMonkeyEngine#1412 (GltfLoader does not support AO packed in MetallicRoughnessMap) (jMonkeyEngine#1880)

* Fix jMonkeyEngine#1882 (J3MLoader always generates mips ignoring MinFilter) (jMonkeyEngine#1884)

* Get texture mips generation flag from MinFilter specified in j3m file.

* Update copyright date.

* Fix J3MLoaderTest failing.

* Fix TestMaterialWrite failing.

* Update copyright date.

* Use Trilinear if no min filter is specified in j3m file.

* Add copyright note in J3MOutputCapsule.

* Fix J3MLoaderTest failing.

* Made extension loaders non-static to avoid concurrency issues (jMonkeyEngine#1886)

Now each GltfLoader instantiated via ThreadLocal will have its own instances of extension loaders.

* Fix jMonkeyEngine#1883 (Image class wrongly setting GL mips flags inside the constructor) (jMonkeyEngine#1885)

* AreaUtils: Migrated package to `com.jme3.util` (jMonkeyEngine#1826)

* AreaUtils: Migrated package to `com.jme3.util`

* com.jme3.uitl.AreaUtils: removed code duplicates - added `final` class specifier

* com.jme3.util.AreaUtils: fixed duplication build error

* utils/AreaUtils.java: full migration to the utility package

* scene/control/AreaUtils.java: removed utility methods - delegated functionality to `jme3.utils.AreaUtils`

* scene/AreaUtils: fixed `jme3.util` package linking typo

* Renderer:  javadoc correction

* update the groovy-test library to v3.0.14

* LICENSE.md:  add 2023 to copyright years

* Fix jMonkeyEngine#1892 (TestChooser does not show classes list when run with java 8) (jMonkeyEngine#1893)

* TestChooser:fix class list not showing when run with java 8.

* Update copyright date.

* main.yml: use "temurin" openjdk. Fix jMonkeyEngine#1896 (jMonkeyEngine#1897)

* README.md:  add Demon Lord to the list of published games

* Fix jMonkeyEngine#1773 (Wrong particle position when `worldSpace` flag equals to true) (jMonkeyEngine#1889)

* Add test case for issue jMonkeyEngine#1773.

* Fix wrong particle position when using 'EmitterMeshVertexShape' or 'EmitterMeshFaceShape' and worldSpace flag equal to true. The old code was interpolating particles position toward emitter world position and this was only working fine for EmitterPointShape and in the other shapes this was causing particles not keep the shape because they were being dragged toward emitter position. The new code calculates the distance vector from emitter last location to the current emitter location and subtracts it from particles position to generate a hypothetical position that is used for interpolation.

* Add javadoc to TestIssue1773.

* Minor javadoc fix.

* jme3-niftygui: solve issue jMonkeyEngine#1891 (incorrect fullscreen layout)  (jMonkeyEngine#1895)

* jme3-lwjgl:updated to lwjgl v2.9.4 hosted by org.jmonkeyengine. Fix jMonkeyEngine#1247, jMonkeyEngine#1215, jMonkeyEngine#947 (jMonkeyEngine#1902)

* Fix jMonkeyEngine#1890 (crashes attempting to run example apps in fullscreen with LWJGL v2) (jMonkeyEngine#1898)

* jme3-lwjgl:fallback to standard 60Hz fullscreen display mode if the specified frequency in the AppSettings is not available and log a warning.

* Fallback to whatever bps or frequency is available. Added a wild-card value to let selecting any bps or frequency available by passing -1.

* Support AWT display frequency model. Looks like AWT uses mathematics round to convert float frequency values to int while lwjgl 2 uses mathematics floor. For example if frequency is 59.83, AWT will return 60 but lwjgl 2 will return 59.

* Remove redundant check.

* Added documentation for getFullscreenDisplayMode method.

* When in VR attach the debug scene to the two eye's scenes. Fix#1795  (jMonkeyEngine#1888)

* jMonkeyEngine#1795 When in VR attach the debug scene to the two eye's scenes

This ensures they show up correctly

* jMonkeyEngine#1795 Whitespace corrections

* jMonkeyEngine#1795 Further whitespace corrections

* jMonkeyEngine#1795 Yet more whitespace corrections

* jMonkeyEngine#1795 Add explanatory comment as to why VR and non-VR have totally different approaches

* Refactored PBR Terrain to use new for-loops. Fix jMonkeyEngine#1785 (jMonkeyEngine#1901)

Drastically reduced code by utilizing JME's new potential for define-compatible for-loops in shaders. Also cleaned up some other little things like indentations, comments, and code placement so that the code is much more organized and easier to understand.

* add the Spatial.addControlAt() method (jMonkeyEngine#1899)

* JmeContext:  add a getSystemListener() method (jMonkeyEngine#1894)

* jme3-examples:  add tests for issue jMonkeyEngine#1903

* Refactored Advanced PBR Terrain to use new for-loops (jMonkeyEngine#1904)

* Refactored Advanced PBR Terrain to use new for-loops

Similar to my recent pull request doing the same for the base PbrTerrain shader (jMonkeyEngine#1901) this PR also adds for-loop support to the advanced version of the pbr shader that uses texture arrays

* Update PBRTerrain.frag

* Update AdvancedPBRTerrain.frag

* Update AfflictionLib.glsllib (jMonkeyEngine#1905)

This PR goes along with my last PR cleaning up the AdvancedPBRTerrain.j3md shader. The method getTriPlanarBlendFromTexArray() was put into this glsllib that contains all of the other commonly used functions for the pbr terrain shaders.

* common.gradle: set class files compatible with Java 8 using "release" option (jMonkeyEngine#1907)

* common.gradle: set class files compatible with Java 8. This will keep java 8 compatibility when it is compiled with newer java versions.

* Merge with existing block.

* Reformat code.

* common.gradle: add "Created-By" jar manifest to show Java version and vendor name (jMonkeyEngine#1913)

* common.gradle: add Created-By in jar manifest to show java version used to create the jar.

* Also add vendor name.

* ParticleEmitter: improve code readability. Apply the DRY principle (jMonkeyEngine#1912)

* add 4 getters to JmeContext for screen position and frame-buffer size (jMonkeyEngine#1911)

* test and fix for jMonkeyEngine#1909 (NPE while generating tangents) (jMonkeyEngine#1910)

* add a JUnit test for issue 1909 (NPE while generating tangents)

* solve issue jMonkeyEngine#1909 (NPE while generating tangents)

* jme3-lwjgl: bump to lwjgl 2.9.5 (jMonkeyEngine#1914)

* Fix jMonkeyEngine#1917 (RendererException in ScreenshotAppState: Attempting to upload empty buffer) (jMonkeyEngine#1918)

* PBRLighting: fix comment describing packed MetallicRoughnessMap (jMonkeyEngine#1921)

Updated a comment about the MetallicRoughness map that previously said the Red channel is unused - changed to instead say that the red channel of MR map stores the AO value if AoPackedInMRMap is true.

* solve issue jMonkeyEngine#1919 (underflow while generating tangents) (jMonkeyEngine#1920)

* jme-core:  add a test for issue jMonkeyEngine#1919 (underflow generating tangents)

* MikktspaceTangentGenerator: solve jMonkeyEngine#1919 (underflow generating tangents)

* main.yml: deploy with jdk17 (jMonkeyEngine#1922)

* Fix jMonkeyEngine#1923 (OSSRH artifacts are build with different java version) (jMonkeyEngine#1924)

* main.yml: build on pushes to the new v3.6 branch

* gradle.properties: next release from "master" branch should be v3.7.0

* resolve issue jMonkeyEngine#1926 (unnecessary dependencies) (jMonkeyEngine#1927)

* buildscript: move def of "niftyVersion" to "common.gradle" (shared between projects)

* jme3-testdata:  rm dependency on "nifty-style-black" (redundant with "jme3-niftygui")

* buildscript: mv "nifty-examples" dependency from "jme3-testdata" to "jme3-examples"

* solve issue jMonkeyEngine#1928 (OutOfMemoryError in FBX importer) (jMonkeyEngine#1929)

* solve issue jMonkeyEngine#1928 (OutOfMemoryError in FBX importer)

* tweak the new javadoc

* solve issue jMonkeyEngine#1930 (NPE in FbxLayerElement) (jMonkeyEngine#1931)

* solve issue jMonkeyEngine#1932 (class cast exceptions in FBX importer) (jMonkeyEngine#1934)

* solve issue jMonkeyEngine#1933 (unsupported operation in FbxNode) (jMonkeyEngine#1936)

* solve issue jMonkeyEngine#1937 (NPE in FbxObject) (jMonkeyEngine#1938)

* solve issue jMonkeyEngine#1939 [NPE in FbxMesh.applyCluster()] (jMonkeyEngine#1940)

* FBXCluster:  create empty arrays if the cluster contains no keyframes

* FbxLoader:  don't construct an animation if there are no keyframes

* update Groovy to v3.0.15

* Update Application.start javadoc. (jMonkeyEngine#1947)

* Update RenderState.setLineWidth javadoc. (jMonkeyEngine#1948)

* Fix jMonkeyEngine#1945 (IllegalStateException when running TestAWTPanels with LWJGL 3) (jMonkeyEngine#1949)

* solve issue jMonkeyEngine#1879 (compile-time error in Skinning.glsllib) (jMonkeyEngine#1942)

* Fix issue jMonkeyEngine#1558 (TestAWTPanels crashes with LWJGL v3 on Linux) (jMonkeyEngine#1944)

* TestAwtPanels: apply swing system LAF. This is needed to prevent JVM crash on Linux and LWJGL 3. (See issue jMonkeyEngine#1558)

* Use single class imports.

* solve issue jMonkeyEngine#1806 (global FrameInterpolator violates threading model) (jMonkeyEngine#1943)

* solve issue jMonkeyEngine#1806 (global FrameInterpolator violates threading model)

* FrameInterpolator:  deprecate the global instance

* Fix a typo in LwjglWindow (jMonkeyEngine#1953)

* Add WaterFilter.getReflectionView method (jMonkeyEngine#1951)

* Added WaterFilter.getReflectionView method.

* Update javadoc.

* README.md:  delete a dead link (Maker's Tale)

* README.md:  add a link to Wild Magic

* resolve issue jMonkeyEngine#1955 (Can not play vorbis audio on Android API 31+) (jMonkeyEngine#1956)

* android-native-vorbis: fix double asset file descriptor closure

* NativeVorbis: better names and javadocs

* NativeVorbisFile#readIntoBuffer: specifies the start and the end of the read

* NativeVorbisFile: better explanation for the output buffer on read functions

* com_jme3_audio_plugins_NativeVorbisFile.c: refactored logs

* NativeVorbisFile: some docs enhances

* NativeVorbisLoader: added updated jme3-copyright

* [skip ci] update natives snapshot

* jme3-jogg: remove dependency on Java Media Framework (jMonkeyEngine#1962)

* solve issue jMonkeyEngine#1960 (use jme3-jogg for loading ogg files on android) (jMonkeyEngine#1961)

* solve issue jMonkeyEngine#1963 (TestMusicPlayer fails to load AL library on lwjgl2) (jMonkeyEngine#1964)

* TestMusicPlayer: fix UnsatisfiedLinkError when using lwjgl2. Solves issue jMonkeyEngine#1963

* Add missing load function for "openal" natives.

* Removed the unnecessary check for lwjgl 2 in classpath.

* Fix comment

* Replace Exception with warning in TerrainPatch (jMonkeyEngine#1966)

* Replace Excpetion with warning in TerrainPatch

PR following up on the discussion in this thread: 
https://hub.jmonkeyengine.org/t/terrain-collision-exception/46491/6

* Update TerrainPatch.java

* Update TerrainPatch.java

* Update TerrainPatch.java

* Update TerrainPatch.java

* Update TerrainPatch.java

* Update TerrainPatch.java

* Update TerrainPatch.java

* Cleanup NativeLibraryLoader & fix wrong library path  (jMonkeyEngine#1967)

* Cleanup NativeLibraryLoader

* Fix wrong library path

* solve issue jMonkeyEngine#1969:  missing check in GLRenderer.clearVertexAttribs() (jMonkeyEngine#1970)

* solve issue jMonkeyEngine#1975:  TestAttachDriver doesn't reset properly (jMonkeyEngine#1976)

* Improve NativeLibraryLoader (jMonkeyEngine#1973)

* Improve NativeLibraryLoader.

* Add javadoc.

* Moved library extraction requirement check into a separate method.

* Fix javadoc.

* Refactor library extraction check method.

* Extract natives to system temp directory retrieved by System.getProperty("java.io.tmpdir") instead of working directory.

* Renamed enum "Openal" to "OpenAL" and added javadoc on NativeLibraries.

* Update comments.

* Deploy master branch commits as snapshot (jMonkeyEngine#1983)

* Deploy main branch commits as snapshot

* Snapshot builds don't have a Release artifact

* restrict snapshot to actual commits on master branch

* Deploy steps don't actually use test-run maven artifacts

* Partial Revert. We need that artifact

* Fix sonatype snapshots repo url

as mentioned in https://central.sonatype.org/publish/publish-guide/

* Allow use of Emissive color as a multiplier with EmissiveMap in PBRLighting (jMonkeyEngine#1979)

* Add support for NormalScale in PBRLighting & GltfLoader (jMonkeyEngine#1980)

* Added NormalScale factor in PBRLighting. The scalar parameter applied to each normal vector of the normal map. This value scales the normal vector in X and Y directions using the formula: `scaledNormal =  normalize((<sampled normal texture value> * 2.0 - 1.0) * vec3(<normal scale>, <normal scale>, 1.0))`.

* Add support for reading NormalScale in GltfLoader.

* Add support for AoStrength in PBRLighting & GltfLoader (jMonkeyEngine#1981)

* Added AoStrength factor in PBRLighting. A scalar multiplier controlling the amount of occlusion applied.

* Add support for reading AoStrength in GltfLoader.

* Fix ao calculation to follow gltf specs.

* Update comment on AoStrength mentioning the min and max values.

* Clamp ao to 0 for negative values that might cause by applying AoStrength > 1.

* Use glsl clamp instead of max.

* update Groovy to v3.0.16

* Some javadoc cleanup (jMonkeyEngine#1986)

* Fix some invalid HTML tags

* Correct deprecation annotations

* Doc-comments cleanup

- Corrected some typos, grammar, etc.
- reflowed egregiously long comment lines to comply with column limits

* README.md: latest stable version of Engine

* LwjglContext: re-initialize renderer on context restart (lwjgl 2) (jMonkeyEngine#1988)

* LwjglContext: initialize renderer on context restart (lwjgl 2).

* Reset GL objects in renderer when context restart.

* README.md:  add Mravelous Marbles to the list of JME-powered games

* update the LWJGL3 libraries from v3.3.1 to v3.3.2

* update Groovy to v3.0.17

* correctly handle negative IDs in getUniqueId() methods (jMonkeyEngine#1991)

* NativeLibraryLoader:  more detailed exception in computeNativesHash() (jMonkeyEngine#2001)

* README.md:  add "Boxer" to the project list

* solve issue jMonkeyEngine#2003 (ParticleDepositionHeightMap.load return value) (jMonkeyEngine#2005)

* solve issue jMonkeyEngine#2002 (TerrainGridTileLoaderTest fails to load tiles) (jMonkeyEngine#2006)

* solve issue jMonkeyEngine#2002 (TerrainGridTileLoaderTest fails to load tiles)

* TerrainGridTileLoaderTest:  add a clarifying comment

* solve issue jMonkeyEngine#2011 (app crashes when using OpenGL version 3.0 and 3.1 with LWJGL 3) (jMonkeyEngine#2009)

* fix system crush issue when set desktop AppSetting.setRenderer below 3.2

* Revert "fix system crush issue when set desktop AppSetting.setRenderer below 3.2"

This reverts commit 11b7c9e.

* fix system crush issue when set desktop AppSetting.setRenderer below 3.2. This fix is reedited by instruction of ali_rs

---------

Co-authored-by: ray <raymond.yang@cottonwoodanalytics.com>

* solve issue jMonkeyEngine#2007 (instanced objects are culled when using WaterFilter) (jMonkeyEngine#2008)

* Fix issue with InstancedGeometry that uses the wrong camera for "instance culling" check.

* Minor javadoc update.

* Variables should start with lower-case. (jMonkeyEngine#2013)

New PullRequest as suggested in jMonkeyEngine#2012

Co-authored-by: Starcommander <starcommander@gmx.at>

* solve issue jMonkeyEngine#1992: better messages in spatial assertions (jMonkeyEngine#1993)

* jMonkeyEngine#1992 Improve the messages being reported from spatial assertions

* jMonkeyEngine#1992 Make clear what name is in the assertion messages

* jMonkeyEngine#1992 Whitespace correction

* solve issue jMonkeyEngine#2015 (Picture class lacks 2 getters)

* CloneableSmartAsset:  clarify the setKey() javadoc (jMonkeyEngine#2018)

* update Gradle to v7.6.1

---------

Signed-off-by: Kasper Aaquist Johansen <kasperaaquist@gmail.com>
Co-authored-by: Scrappers Team <60224159+Scrappers-glitch@users.noreply.github.com>
Co-authored-by: Github Actions <actions@users.noreply.github.com>
Co-authored-by: Riccardo Balbo <riccardo0blb@gmail.com>
Co-authored-by: Scrappers <scrappers.tm@gmail.com>
Co-authored-by: Stephen Gold <sgold@sonic.net>
Co-authored-by: Florian Frankenberger <f.frankenberger@mobiuscode.de>
Co-authored-by: Wyatt Gillette <jefferydeaver2010@gmail.com>
Co-authored-by: Lukas-Habring <102620478+Lukas-Habring@users.noreply.github.com>
Co-authored-by: Lukas Habring <lukas@Lukas-PC>
Co-authored-by: JosiahGoeman <31492985+JosiahGoeman@users.noreply.github.com>
Co-authored-by: Paul Speed <pspeed42@users.noreply.github.com>
Co-authored-by: Ali-RS <ali_codmw@yahoo.com>
Co-authored-by: Toni Helenius <helenius.toni@gmail.com>
Co-authored-by: Jan Schäfer <j@nschaefer.net>
Co-authored-by: Kasper Aaquist Johansen <kasperaaquist@gmail.com>
Co-authored-by: Michael Zuegg <zzuegg@users.noreply.github.com>
Co-authored-by: manuelrmo <118840772+manuelrmo@users.noreply.github.com>
Co-authored-by: Manuel <Manuel@DESKTOP-6RJH3UF>
Co-authored-by: Noeri Huisman <8823461+mrxz@users.noreply.github.com>
Co-authored-by: richardTingle <6330028+richardTingle@users.noreply.github.com>
Co-authored-by: Ryan McDonough <peanut64646@gmail.com>
Co-authored-by: Sailsman63 <lukejsails@gmail.com>
Co-authored-by: Raymond Young <gongxi83@163.com>
Co-authored-by: ray <raymond.yang@cottonwoodanalytics.com>
Co-authored-by: Paul Kashofer <soundmodul@gmx.at>
Co-authored-by: Starcommander <starcommander@gmx.at>
XrReferenceSpaceCreateInfo.malloc(stack)
.type$Default()
.next(NULL)
.referenceSpaceType(XR_REFERENCE_SPACE_TYPE_LOCAL)
Copy link
Member

@richardTingle richardTingle May 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be XR_REFERENCE_SPACE_TYPE_LOCAL or XR_REFERENCE_SPACE_TYPE_STAGE. I found that it was surprising that my face was in the floor when I tried this; because XR_REFERENCE_SPACE_TYPE_LOCAL puts the origin at the headset position when the application is started but XR_REFERENCE_SPACE_TYPE_STAGE puts it at the origin of the play area (usually at floor level). Or maybe we should let the applications choose.

I thought this was a useful explanation

The difference between XR_REFERENCE_SPACE_TYPE_STAGE and XR_REFERENCE_SPACE_TYPE_LOCAL in OpenXR comes down to the origin and orientation of the coordinate system that the application will use to represent the position and orientation of devices, like headsets and controllers, within the virtual world.

In XR_REFERENCE_SPACE_TYPE_LOCAL, the origin is typically located at the position where the XR system was initialized. For example, in a seated VR experience, this could be the location of the headset at the time the application was started. The Y-axis is typically up, and the orientation is typically such that the forward direction (negative Z-axis) is facing in the initial direction of the user.

XR_REFERENCE_SPACE_TYPE_STAGE, on the other hand, is designed for standing, room-scale experiences. The origin is typically located at the center of the user's designated play area (if one has been defined), with the Y-axis pointing up, and the forward direction (negative Z-axis) is often facing a user-defined forward direction in the play area (like the direction facing the computer or the front of the room).

The practical differences a user might experience would depend on the application, but here are some examples:

In a room-scale VR game, if XR_REFERENCE_SPACE_TYPE_LOCAL is used, the user's initial position in the game might not be in the center of the play area, but somewhere near the edge or corner, because the origin is where the system was initialized, not the center of the play area. If the user moves around in the play area, they might move out of the game's designated area. Using XR_REFERENCE_SPACE_TYPE_STAGE in this case would be better, because it ensures the user starts in the center of the game's area and can freely move around within it.

If the user is sitting at a desk and not moving around (like in a cockpit simulator game), the difference between XR_REFERENCE_SPACE_TYPE_LOCAL and XR_REFERENCE_SPACE_TYPE_STAGE might not be noticeable, because the user is not using the play area. But if XR_REFERENCE_SPACE_TYPE_STAGE is used and the user's chair is not in the center of the play area, they might find themselves starting off-center in the game, which could be disorienting.

In general, the choice between XR_REFERENCE_SPACE_TYPE_LOCAL and XR_REFERENCE_SPACE_TYPE_STAGE should be based on the type of experience the application provides (seated vs. room-scale) and the user's physical environment.

Personally I always use stage even for seated applications because its easy to move the origin of the environment (what OpenVR era called the observer) to place the players head; but the local frame makes it really hard to figure out where to put the floor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least it should be configurable for app-developers.
I tried it with XR_REFERENCE_SPACE_TYPE_STAGE, and still moving does not work.
Just the rotation starts initial in wrong direction.

@Starcommander
Copy link
Contributor Author

I found a method to get openXR to suggest eye positions and angles which is what I used in that hmd change.

On camera stuff I'm much less good, are you happy to tackle that? I couldn't get to the bottom of the lensing effects I was seeing. Do you see that too? That if you look directly at something it's in the right place but as you move your head it seems to move.

When you found a method, then where do you use it?
I only see changes, where you just removed the rotation+distance code.
So, I also tested your modifications:

  • No eye-rotation/eye-distance, so I can only see the same on left and right eye
  • Moving HMD does still not work (does nothing)

Regarding the "lensing-effect" you mentioned:

  • I think I can see it now, since the fieldOfView is now set to a value, that makes a better sense.
  • But it has nothing to do with moving HMD, instead it appears when rotating the HMD, right?

@richardTingle
Copy link
Member

richardTingle commented Jun 2, 2023

@Starcommander That's odd. I definitely can move my head and the cameras move (and closing and opening alternating eyes gives different angles on scene, as you'd expect. This is all on the openxr-actions branch.

And in HelloOpenXRGL it sets the position and rotation for each eye

        viewPos.set(pos.x(), pos.y(), -pos.z());
        viewRot.set(orientation.x(), orientation.y(), -orientation.z(), orientation.w());
        
        Eye eye = viewIndex == 0 ? xrHmd.getLeftEye() : xrHmd.getRightEye();

        eye.setRotation(viewRot.inverse());
        eye.setPosition(viewPos);

I'm not very happy with those coordinate transformations, as JME and OpenXR are supposed to have the same coordinate system. I might try putting in the observer (the reference node from OpenVR implementation) and see if I can use that instead to get consistent directions with the axes.

But it has nothing to do with moving HMD, instead it appears when rotating the HMD, right?

True, its when you rotate your head that the lensing becomes apparent.

This is the test application I have been using (It only has suggested bindings for Oculus because that's what I've been using to test)

public class XRTestMain extends SimpleApplication{

    public static void main(String[] args){

        XRTestMain app = new XRTestMain();
        AppSettings settings = new AppSettings(true);
        XrHmd.setRendererForSettings(settings);
        app.setSettings(settings);
        app.start();
    }

    @Override
    public void simpleInitApp() {
        XrHmd.initHmd(this);

        for(int i = 0; i < 5; i++){
            Box b = new Box(0.1f, 0.1f, 0.1f);
            Geometry geom = new Geometry("Box", b);
            Material mat = new Material(assetManager,
                    "Common/MatDefs/Light/Lighting.j3md");
            geom.setMaterial(mat);
            geom.setLocalTranslation(i,0,0);
            rootNode.attachChild(geom);
        }
        for(int i = 1; i < 5; i++){
            Box b = new Box(0.05f, 0.1f, 0.1f);
            Geometry geom = new Geometry("Box", b);
            Material mat = new Material(assetManager,
                    "Common/MatDefs/Light/Lighting.j3md");
            geom.setMaterial(mat);
            geom.setLocalTranslation(0,i,0);
            rootNode.attachChild(geom);
        }
        for(int i = 1; i < 5; i++){
            Box b = new Box(0.1f, 0.1f, 0.1f);
            Geometry geom = new Geometry("Box", b);
            Material mat = new Material(assetManager,
                    "Common/MatDefs/Light/Lighting.j3md");
            geom.setMaterial(mat);
            geom.setLocalTranslation(0,0,i);
            rootNode.attachChild(geom);
        }

        rootNode.attachChild(checkerboardFloor(assetManager));

        DirectionalLight directionalLight = new DirectionalLight(new Vector3f(0.4f,-0.3f,0.6f).normalizeLocal());
        AmbientLight al = new AmbientLight();
        al.setColor(ColorRGBA.White.mult(0.3f));
        rootNode.addLight(al);
        rootNode.addLight(directionalLight);
    }

    boolean started = false;

    @Override
    public void simpleUpdate(float tpf) {
        OpenXRActionState state = getStateManager().getState(OpenXRActionState.ID, OpenXRActionState.class);

        if (!started) {
            Action teleport = Action.builder()
                    .actionName("teleport")
                    .translatedName("teleportTranslation")
                    .actionType(ActionType.BOOLEAN)
                    .withSuggestedBinding(OculusTouchController.PROFILE, OculusTouchController.pathBuilder().leftHand().xClick())
                    .build();


            Action trigger = Action.builder()
                    .actionName("fire")
                    .translatedName("fireTranslation")
                    .actionType(ActionType.BOOLEAN)
                    .withSuggestedBinding(OculusTouchController.PROFILE, OculusTouchController.pathBuilder().leftHand().triggerValue())
                    .withSuggestedBinding(OculusTouchController.PROFILE, OculusTouchController.pathBuilder().rightHand().triggerValue())
                    .build();

            Action haptic = Action.builder()
                    .actionName("haptic")
                    .translatedName("haptic")
                    .actionType(ActionType.HAPTIC)
                    .withSuggestAllKnownHapticBindings()
                    .build();

            Action pose = Action.builder()
                    .actionName("pose")
                    .translatedName("pose")
                    .actionType(ActionType.POSE)
                    .withSuggestAllKnownGripPoseBindings()
                    .build();

            ActionSet testActionSet = ActionSet.builder()
                    .name("test")
                    .translatedName("testTranslation")
                    .withAction(teleport)
                    .withAction(trigger)
                    .withAction(haptic)
                    .withAction(pose)
                    .build();

            ActionManifest manifest = ActionManifest.builder()
                    .withActionSet(testActionSet)
                    .build();


            state.registerActions(manifest, "test");


            started = true;
        }else{
            {
                BooleanActionState booleanActionState = state.getBooleanActionState("test", "teleport", null);
                if(booleanActionState.hasChanged()){
                    System.out.println(booleanActionState.getState());
                }
            }
            {
                BooleanActionState booleanActionState = state.getBooleanActionState("test", "fire", null);
                if(booleanActionState.hasChanged()){
                    System.out.println("fire"+ booleanActionState.getState());
                }
            }
            for(HandSide handSide : HandSide.values()){
                BooleanActionState booleanActionState = state.getBooleanActionState("test", "fire", handSide.restrictToInputString);
                if(booleanActionState.hasChanged()){
                    System.out.println("fire " + handSide + booleanActionState.getState());
                    state.triggerHapticAction("test", "haptic", 0.1f, 50, 0.2f, handSide.restrictToInputString);
                }
            }
        }
    }

    public static Geometry checkerboardFloor(AssetManager assetManager){
        Quad floorQuad = new Quad(10,10);
        Geometry floor = new Geometry("floor", floorQuad);

        Texture floorTexture = assetManager.loadTexture("Textures/checkerBoard.png");
        floorTexture.setMagFilter(Texture.MagFilter.Nearest);
        Material mat = new Material(assetManager,"Common/MatDefs/Misc/Unshaded.j3md");
        mat.setTexture("ColorMap", floorTexture);
        mat.getAdditionalRenderState().setFaceCullMode(RenderState.FaceCullMode.Off);

        floor.setMaterial(mat);
        Quaternion floorRotate = new Quaternion();
        floorRotate.fromAngleAxis(-FastMath.HALF_PI, Vector3f.UNIT_X);
        floor.setLocalRotation(floorRotate);
        floor.setLocalTranslation(-5,-1,5);

        return floor;
    }
}

There is definitely something wrong with the scene, the boxes seem like they are being looked at from the inside

@richardTingle
Copy link
Member

I've got hand skeletons more or less working. Weirdly they are mirror images (So the left hand has a right hand and vice versa). Might be more coordinate incompatibilities between JME and OpenXR.

This shows the hand joints (each cube is a joint), the large green cube is the overall pose location

image

I don't want to go too much further without getting the cameras sorted out (especially given the coordinate transformations that seem to be being needed). Do you mind if we look at that in parallel and see what we both find?

@richardTingle
Copy link
Member

I've asked a question about the lensing at https://hub.jmonkeyengine.org/t/openxr-vr-rendering-cameras-into-eyes/46837

stephengold pushed a commit that referenced this pull request Jun 8, 2023
New PullRequest as suggested in #2012

Co-authored-by: Starcommander <starcommander@gmx.at>
@Starcommander
Copy link
Contributor Author

@richardTingle I found out, why we see the boxes from inside.
See at HelloOpenXRGL.java: glFrontFace(GL_CW); //Clockwise
This should be: glFrontFace(GL_CCW); //Counter-Clockwise as in jme3
I will commit this modification now.

…ault in jme3.

Fixes the issue, that object are only visible from inner side.
@richardTingle
Copy link
Member

@Starcommander Nice! I bet that was why the hands were showing mirror imaged. I should be able to remove a bunch of nasty fudge factors from the actions stuff now which will put me in a much better place for getting tamarin hands working.

@Starcommander2
Copy link

Starcommander2 commented Jun 19, 2023 via email

@stephengold
Copy link
Member

What's the status of this PR? Is this still a work in progress, or has it stalled out?

@richardTingle
Copy link
Member

I tried to figure out where the lensing effect was coming from, but in the end I gave up. I think to solve that I'd have to start from scratch to really understand what's going on. I'm not actively working on it, not sure if @Starcommander2 is

@Starcommander
Copy link
Contributor Author

Is still work in progress.
Last time i fixed the issue, that we see the boxes from inside.

Also I am very interested in the configuration (Hardware, OS, xr-runtime) that @richardTingle uses.
Because I have moving not working currently, where it works for richardTingle.
Seems there is a difference in xr-runtime, where I use monado-service on Debian11.

@richardTingle
Copy link
Member

I'm on and Oculus Quest 2, over virtual desktop to a windows 10 PC using Steam VR as my xr-runtime

@richardTingle
Copy link
Member

I have had another go at this. I started again from the openXR HelloOpenXRGL example making sure I understood what it was doing but taking what we learned from this attempt as well.

I think I've solved it this time. I found why I was getting lensing effects; the OpenXR runtime was requesting an asymmetrical field of view (with angleLeft != angleRight) but I was using the standard camera#setFrustumPerspective which doesn't support asymmetrical field of view but when I instead calculated a projection matrix and used camera#setProjectionMatrix it stopped lensing. It makes sense to me now that @Starcommander didn't see the lensing as presumably your headset didn't request an asymmetrical field of view (or al least not so heavily asymmetric) and so the problem didn't occur for you.

We were talking before about whether this should be in JMonkey proper or in a library. I did my attempt in a tamarin 2.x branch. Are we ok with that as an approach @Starcommander & @stephengold ?

My approach adopts the existing JMonkey OpenGL context rather than creating its own which means it can be a pure app state attached "whenever" in the applications running process rather than needing to be booted up before JMonkey.

An ultra minimal example application would look like this

public class MinimalOpenXr extends SimpleApplication {
    public static void main(String[] args) {
        AppSettings settings = new AppSettings(true);
        settings.put("Renderer", AppSettings.LWJGL_OPENGL45);
        MinimalOpenXr app = new MinimalOpenXr();
        app.setSettings(settings);
        app.start();
    }

    @Override
    public void simpleInitApp(){ 

        getStateManager().attach(new XrAppState());
        // below is optional to get actions working (including hand bones). A manifest needs to be created to describe the available actions
        getStateManager().attach(new OpenXrActionState(manifest(), ActionSets.TEST_SET));

        Geometry geom = new Geometry("Box", new Box(1, 1, 1)); 
        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue); 
        geom.setMaterial(mat);
        geom.setLocalTranslation(new Vector3f(3,0,0));
        rootNode.attachChild(geom);  
    }
}

I already have these things working:

  • Non distorted visuals
  • Cameras tracking headset position
  • Button press actions
  • Hand Pose actions (aka hand positions)
  • Hand Bone positions

I am now working on these

  • Moving the observer (aka moving the offset between where the player is in the real world to where in the virtual world - teleporting etc)
  • Getting the hand models to pair correctly to the bones. The OpenXR bones seem slightly different to the OpenXR ones so despite already having the bone positions this doesn't seem to immediately give me working hand models. I always thought the OpenVR bones were eccentric so if openXR has fixed this I think that's fine and I'll update my model's bones.

Once I get those working I'll start updating the TamarinTestBed examples to use this. Once that all works we'll be approaching parity with OpenVR

@stephengold
Copy link
Member

stephengold commented Oct 1, 2023

We were talking before about whether this should be in JMonkey proper or in a library. I did my attempt in a tamarin 2.x branch. Are we ok with that as an approach @Starcommander & @stephengold ?

As far as I'm concerned, the decision whether to be an Engine library or a 3rd-party library is up to you. I see a lot of advantages to being a 3rd-party library, especially if the codebase is changing rapidly. But in principle I have no objection to making jme3-xr part of the Engine.

@Starcommander
Copy link
Contributor Author

@richardTingle Thanks for working this out.

I found out, why moving does not work with my configuration.
Seems monado-service has to be compiled with libsurvive to support moving.
https://monado.freedesktop.org/libsurvive.html
https://github.com/cntools/libsurvive
I will try this out soon next time.

When this project is working well, I still prefer to include it into the engine.

@pspeed42
Copy link
Contributor

pspeed42 commented Oct 3, 2023

re: "When this project is working well, I still prefer to include it into the engine."

...better get it 100% perfect then since then it will go into 1.5 year release cycles and be painful to update as VR tech changes. "Sorry, that bug will be fixed next time the giant monolithic JME releases again..."

@richardTingle
Copy link
Member

I do think I agree with @pspeed42 and @stephengold ; I think I plan to continue with a Tamarin 2. But that doesn't preclude other XR projects like this one. It might make sense to have a move-fast-and-break-things Tamarin 2 and a more stable JME3-XR

@Starcommander
Copy link
Contributor Author

I have now compiled monado-service with libsurvive support.
Now moving is also working well in my configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants