open-ecosystem-development / OpenXR-SDK

Apache License 2.0
2 stars 3 forks source link

Play area blue wireframe not shown with backface culling enabled #30

Open svillar opened 2 years ago

svillar commented 2 years ago

This comes from this report in Wolvic. A blue line was shown when moving out of the security zone (play area) instead of the blue wireframe cylinder.

I found that the issue is that enabling backface culling glEnable(GL_CULL_FACE) makes the wireframe vanish. So it should be either a problem in the OpenGL stack or in the way the faces of the wireframe are defined.

It's easy to see that this problem is not a Wolvic one and can be reproduced with any OpenXR sample. Just add a glEnable(GL_CULL_FACE) after eglMakeCurrent() and the blue line will be shown instead of the wireframe cylinder.

Lixming commented 2 years ago

This bug will be fixed on the next version.

svillar commented 2 years ago

Any news about this? It isn't fixed in .77

svillar commented 1 year ago

I can still reproduce it in the latest .79. It can be reproduced in your XrDemo, you just have to do this

bool XrDemo::initEGLSurface(){
    const EGLint attribs[] = { EGL_NONE };
    EGLSurface windowSurface = eglCreateWindowSurface(mDisplay, mConfig, mNativeWindow, attribs);

    if (eglMakeCurrent(mDisplay, windowSurface,  windowSurface, mContext) == EGL_FALSE)
    {
        LOGI("eglMakeCurrent failed: %s", getEglErrorChars());
        return false;
    }
    glEnable(GL_CULL_FACE);
    return true;
}

I'm just adding the glEnable()

Lixming commented 1 year ago

Just confirm the problem phenomenon firstly. A blue line with wireframe cylinder was shown when the controller was moved out of the security zone (play area) , which starting height displayed on the screen is at the head position?This is what we see in our demo.

matlu commented 1 year ago

Th

Just confirm the problem phenomenon firstly. A blue line with wireframe cylinder was shown when the controller was moved out of the security zone (play area) , which starting height displayed on the screen is at the head position?This is what we see in our demo.

This is NOT at all working from within Wolvic and there has been no progress on this issue for 6 months.

It is very easy to compare experience by doing this:

  1. Setup up 6DoF environment with safety zone and confirm (you will see the blue safety net grid)
  2. When in VR Launcher (VR Home) slowly walk towards the safety zone. Well before you will hit the zone will be clearly shown as overlay within VR Home and you get a chance to react and change you position..
  3. Now do go back into your play area and launch Wolvic.
  4. Directly from within the Wolvic launch page, slowly walk towards the safety zone. You will notice the blue safety zone will not be show as early warning. Instead it will be briefly shown at time it is too late (when you passed it) and now Wolvic is force quit by the system.

This has to be fixed!

matlu commented 1 year ago

2nd part of this issue is that even if we have the correct blue safety grid shown and the user pass it, the app should not be force closed. Instead it should work like it does on Quest 2 devices. E.g. what should stop is the Immersive experience (why the user is getting lost and walk outside the safety zone).

So when the user continues to walk outside the safety zone the system should send the command to stop the Immersive experience (what is mapped to he left hamburger button key within Wolvic),

With this setup the user can go back into the safety zone and continue the WebXR experience from where it was left by JUST clicking on the VR button again.

With current implementation (Wolvic is Force Quit), the user has to do:

  1. Relaunch Wolvic from VR Home
  2. Go to the experience (typically Wolvic will show latest page opened as default)
  3. Start the experience and enter VR mode (WebXR)
  4. Navigate through the experience to the place where you were thrown out.

This is VERY VERY FRUSTRATING for a user and if you are playing a game, all of your game play has been lost.

@svillar can you advice on what is the command the system should send to Wolvic to break the immersive experience? I believe this issue should be tracked in a separate issue as it is separate from not showing blue wireframe but it should be addressed at the same time.

Lixming commented 1 year ago

NOW, it seems that the app will not be forced to exit due to leaving the safe zone. So the critical point is that we cannot see the only A blue line when leaving the safe zone. Can you share the screenshot or take a photo for us to help confirm the phenomenon?

svillar commented 1 year ago

2nd part of this issue is that even if we have the correct blue safety grid shown and the user pass it, the app should not be force closed. Instead it should work like it does on Quest 2 devices. E.g. what should stop is the Immersive experience (why the user is getting lost and walk outside the safety zone).

So when the user continues to walk outside the safety zone the system should send the command to stop the Immersive experience (what is mapped to he left hamburger button key within Wolvic),

With this setup the user can go back into the safety zone and continue the WebXR experience from where it was left by JUST clicking on the VR button again.

With current implementation (Wolvic is Force Quit), the user has to do:

  1. Relaunch Wolvic from VR Home
  2. Go to the experience (typically Wolvic will show latest page opened as default)
  3. Start the experience and enter VR mode (WebXR)
  4. Navigate through the experience to the place where you were thrown out.

This is VERY VERY FRUSTRATING for a user and if you are playing a game, all of your game play has been lost.

@svillar can you advice on what is the command the system should send to Wolvic to break the immersive experience? I believe this issue should be tracked in a separate issue as it is separate from not showing blue wireframe but it should be addressed at the same time.

The system properly notifies Wolvic about the graphics resources being destroyed. We do detect that properly. The current Wolvic code exits the session when that happens. We have a local patch that makes Wolvic not exit the session and instead wait for the user to get into the sec zone again.

However we haven't still fixed the problem when we reenter the security zone. Sometimes the application crashes in the Android rendering code and we are not sure why. We're working on that as I agree is very frustrating.

Anyway that's a different issue that is tracked in Wolvic, I think we should focus here on the issue of the security zone not being shown.