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

Obscura not detecting immersive-vr support/poor performance #12

Closed
msub2 opened this issue Feb 2, 2022 · 9 comments
Closed

Obscura not detecting immersive-vr support/poor performance #12

msub2 opened this issue Feb 2, 2022 · 9 comments
Labels
bug Something isn't working priority-medium

Comments

@msub2
Copy link
Contributor

msub2 commented Feb 2, 2022

Configuration

Wolvic version: 0.9
Wolvic build ID: d8f8501 (AC 63.0.0)

Hardware: Oculus Quest 2 v37

Steps to Reproduce

  1. Visit obscura.world from the Wolvic start page
  2. Observe that it does not detect VR support to enter the experience and stays on the 3D model
  3. Manually navigate to https://obscura.world/app to proceed to the experience and click Enter VR
  4. Observe very sub-optimal performance.

Current Behavior

Obscura does not detect immersive-vr capabilities and performs very poorly in the actual app.

Expected Behavior

Site should detect capability and perform at an optimal framerate similar to Meta Browser.

Possible Solution

I've determined that the reason it is not displaying the "Enter Experience" button on the homepage is due to a mobile user agent check by Obscura that appears to exclude all Android/mobile devices besides Oculus/Meta devices. I'll pass this along to the team members at Third Axis. I am unsure what is causing the poor performance. I would need to set up remote debugging and dig into it some more from there.

@juanjosanchez juanjosanchez added bug Something isn't working priority-medium labels Feb 22, 2022
@svillar
Copy link
Member

svillar commented Feb 22, 2022

Thanks for reporting. Tell us about your findings with the Third Axis crew. It'd be awesome if they could adopt a different solution than checking the UA (a bad policy in general). In case of not having a server side fix I guess we could always tune the UA for that site...

@msub2
Copy link
Contributor Author

msub2 commented Feb 22, 2022

This is actually the full check that happens on the page:

window.mobileCheck = function() {
    let check = false;
    (function(a){if(/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i.test(a.substr(0,4))) check = true;})(navigator.userAgent||navigator.vendor||window.opera);
    console.log(check)
    return check;
  };

mobileCheck();

if(mobileCheck()){
  document.getElementById('model').removeAttribute('shadow-intensity')
  document.getElementById('body').style.backgroundSize = "fit"
}else {
  
  document.getElementById('mobile_enter').style.display = ""
  document.getElementById('body').style.backgroundSize = "fit"
  document.addEventListener('wheel', function(e) {
    console.log(e)
    
  });
};


  var str = navigator.userAgent;

  if(str.includes('Oculus')){
    document.getElementById("enter").innerHTML = "Enter VR"
  }

  window.addEventListener('DOMContentLoaded', (event) => {
    var str = navigator.userAgent;
    if(str.includes('Instagram')){
      document.getElementById('ar_text').innerHTML = "Open In Safari"
      document.getElementById('insta_banner').classList.remove('hidden')
      document.getElementById('ar_text').classList.remove('border-white')
      
      document.getElementById('ar_text').classList.add('hidden')
    }
  })

As you can see it actually explicitly checks for Oculus in the user agent before loading the Enter VR button. They are aware of the issue now, just not sure when they'll actually get around to addressing it.

@svillar
Copy link
Member

svillar commented Feb 22, 2022

Yeah I saw the JS too. Actually the issue is not only claiming to be Oculus. In order for the button "Enter VR" to show the "Android" part of the UA needs to be removed too, because otherwise we wouldn't pass the mobileCheck(). With those 2 changes the "Enter VR" button appears.

WRT the performance it's indeed not good enough, we'd have to check that but Gecko is known for a not so good WebGL performance.

@ianpetrarca
Copy link

Hey thanks for going through all of this :) - the user agent issue will be fixed in the newest version of Obscura. As far as the performance issues, is Wolvic using the same version of the WebXR API that the Oculus Browser is using? Please correct me if I'm wrong but the last version of Firefox reality that I tested was using the WebVR api instead of the newer WebXR API. Is that still the case?

@svillar
Copy link
Member

svillar commented Mar 7, 2022

Hey thanks for going through all of this :) - the user agent issue will be fixed in the newest version of Obscura. As far as the performance issues, is Wolvic using the same version of the WebXR API that the Oculus Browser is using? Please correct me if I'm wrong but the last version of Firefox reality that I tested was using the WebVR api instead of the newer WebXR API. Is that still the case?

That's awesome, looking forward to the new version.

Regarding WebXR yes, Wolvic supports WebXR indeed. WRT WebVR we have dropped the support as it's deprecated and it'd be too much work to support both.

@ianpetrarca
Copy link

Awesome to hear. Thank you for clarifying that. Regarding your previous comments:

"WRT the performance it's indeed not good enough, we'd have to check that but Gecko is known for a not so good WebGL performance."

Is this something that I can assume and include in our device detection process? Almost every different platform supports WebGL and WebXR API in a different way. Knowing the limitations of Wolvic would be very helpful so we can build in responsive changes that makes the user experience in Wolvic better.

For example, in the current build of Obscura, there is a dynamic light that produces a shadow on the floating clock in the main-hall on desktop. If you view the scene in VR we remove the dynamic light to improve FPS and overall performance.

If we can pin-point the things to avoid in Wolvic I'd be happy to include it in our device detection process.


"It'd be awesome if they could adopt a different solution than checking the UA (a bad policy in general). "

I'm curious, how would you recommend understanding what device a user is visiting the page on without the user agent string? Open to adopting a better practice but at the moment I've found this to be pretty much the only way to do it.

Understanding the user device is crucial given the fragmented support of the WebXR API.

For example, when Third Axis links to our work in Instagram or Twitter posts and a user views it via the in-app browsers (webkit) inside of instagram and twitter, USDZ content is blocked from loading. We use the user-agent to detect instagram/twitter, and show a banner that says 'please view this in safari" so that users can actually view things in AR.

@svillar
Copy link
Member

svillar commented Mar 8, 2022

Checking the UA string is (and has been) generally a bad idea for a variety of reasons. Among other things it basically breaks the universal accessibility of the web and the web standards. I've worked on browser engines for more than a decade now, and we've had to add specific quirks for many sites tons of times even changing them over time. Our users were suddenly forbidden to access some sites just because there were changes in the server side wrt the UA filtering. In the end, if you think about it, web browsers end up pretending to be some others so the ultimate purpouse of UA filtering does not work.

Not only that but trying to get information from UA is also a very hard problem which usually leads to issues like the ones we have in Wolvic (we claim to run on Android so we're filtered out because the server thinks we're on a mobile phone). Also it's super easy to fake the user agent (can be done in Wolvic with a Firefox extension without building from sources).

Summarizing a lot instead, of using UA filtering is way much better to look for specific features you might need. There are plenty of resources in the web to check that, but the one I've always found more interesting is this one from Mozilla https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent

Hope it helps

@ianpetrarca
Copy link

Thank you for breaking this all down. Will try and remove the user-agent filtering as much as possible in the newest builds of Obscura.

@svillar
Copy link
Member

svillar commented Jun 20, 2022

This should work in the next release. XR experience is not great though. Looks like the 3D models are very expensive to render in some devices (like Huawei glasses)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority-medium
Projects
None yet
Development

No branches or pull requests

4 participants