Skip to content
This repository has been archived by the owner on Nov 8, 2019. It is now read-only.

WorldSense (6DOF) Frame of Reference #592

Closed
michaeltheory opened this issue Nov 24, 2018 · 8 comments
Closed

WorldSense (6DOF) Frame of Reference #592

michaeltheory opened this issue Nov 24, 2018 · 8 comments

Comments

@michaeltheory
Copy link

Hi there,

I'm developing on the Java SDK for World Sense on the Lenovo device. The frame of reference for the head position is centered at Y=0.

On other 6DOF systems, and even on the same device in WebXR, the frame of reference puts Y=0 at floor level. I scoured through both the SDK and NDK and couldn't find anything about how to use the "room" frame of reference.

Seeing as how WebXR in Chrome uses the GVR SDK, it must be possible. Can someone point me in the right direction?

@sigmaxipi
Copy link

sigmaxipi commented Nov 27, 2018

https://github.com/googlevr/gvr-android-sdk/blob/master/samples/ndk-hellovr/src/main/jni/hello_vr_app.cc#L453 has

float ground_y = gvr_api_->GetCurrentProperties().Get(
                       GVR_PROPERTY_TRACKING_FLOOR_HEIGHT, &floor_height)
                       ? floor_height.f
                       : kDefaultFloorHeight;

https://developers.google.com/vr/reference/android/com/google/vr/ndk/base/GvrApi#getCurrentProperties() and https://developers.google.com/vr/reference/android/com/google/vr/ndk/base/Properties.PropertyType#TRACKING_FLOOR_HEIGHT are the matching Java APIs.

However, after looking through the code, I see that there is a bug where the properties object isn't refreshed and it's possible for the floor height to change while the app is running as the tracking system adapts. This bug is being tracked internally and will be fixed in an upcoming release.

@michaeltheory
Copy link
Author

I guess I didn't scour enough :) Thank you!

@michaeltheory
Copy link
Author

Sorry, trying to use this with Kotlin and struggling a bit with Value.

private val value = Value()
....
gvrView.gvrApi.currentProperties.get(Properties.PropertyType.TRACKING_FLOOR_HEIGHT, value)
Log.d("GVR", value.asFloat().toString())

That seems to prevent rendering with logs like Missed vsync by 36444us (CPU load is too high)

Am I using it wrong?

@sigmaxipi
Copy link

I've attached a patch for code that will go into a future version of sdk-hellovr. I've verified that it works on a Mirage Solo. I'm not familiar with Kotlin and it's not a supported language for GVR, but the snippet you provided appears correct. Does the .get call return true? And are you calling it each frame? My comment above about the value not refreshing was incorrect and the Java API appears to be working as expected.

FLOOR_HEIGHT.patch.txt

@michaeltheory
Copy link
Author

Thanks for that. It looks like the code is pretty much the same. My code is never actually getting past the .get line, as the float value is never logged. I am calling it every frame.

I'll try a few things including moving that code into a Java class

@michaeltheory
Copy link
Author

Finally got a chance to try this again, I found the issue. If you're using Kotlin, you must use the full Java syntax of gvrView.getGvrApi().getCurrentProperties() even though Android Studio will warn you to change it to gvrView.gvrApi.currentProperties

@sigmaxipi
Copy link

sigmaxipi commented Dec 12, 2018

Is this issue specific to the GVR classes? GvrAPI does have some multi-classloader dynamic loading magic under the hood and it may be interfering with Kotlin. While GVR doesn't support other languages, this was the first issue of this type that we've heard of.

@michaeltheory
Copy link
Author

That makes sense. This is the first time I've seen that happen, but from my end I'm all good

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

No branches or pull requests

2 participants