HackPerception

- If you really want to deep dive, this podcast is extremely influential in the VR development community: The Voices of VR Podcast.

- you might like the following two videos

, The simple answer is that licensing for high-profile IP like Pokemon is extremely complicated, corporate, and expensive. The ecosystem will likely need to mature, add userbase, and see wider access to hardware before you see top brands like Pokemon release official content in the vein that you've described. Everything is in place from a hardware and software development ecosystem standpoint to make something like this happen; it's more of question of how and when the transition to VR will occur for different IPs. That transition speed will be directly affected by who owns the IP, how that IP fits into their catalog, and the IP holder's XR specific strategy and partnerships. Pokemon IP moves alot of hardware units for Nintendo which makes it one of the trickier edge cases within VR, especially as Nintendo has some level of ownership in TPC.

, two other important factors are pupil swim and stereo overlap. Pupil swim is one of the primary things you're trying to eliminate by switching over to a hybrid fresnel - it makes a huge impact on human UX. Vive has greater stereo overlap than most HMD's currently available which is critical in some use cases such as simulation training.

- this is the tool our techs would have recommend you use. In the future, you can just email customersupport@viveport.com for assistance with anything Viveport; the last thing we want you to do is spend hours trying to debug the client, we have technical specialists who can assist you.

, Thank you for reporting this! I just spent some time trying to reproduce this and while I was able to reproduce the bug, I was also able to download the SDK in some of the test-cases so there seems to be a something tricky happening here. I've sent a high priority internal email to all stakeholders - we'll work to get this fixed asap!

, Thank you for reporting this! I just spent some time trying to reproduce this and while I was able to reproduce the bug, I was also able to download the SDK in some of the test-cases so there seems to be a something tricky happening here. I've sent a high priority internal email to all stakeholders - we'll work to get this fixed asap! - If you ever catch something like this, don't hesitate to alert us. As soon as one of us sees something like this, it sparks an immediate QA pass :)

, We haven't created a F->F adapter as the length of the stock tether is pushing right up against the limits of what DP1.2 can handle. If we released a F->F adapter, customers would attempt to daisy chain tethers together and it wouldn't work at all resulting in frustrating UX and a customer service logistical problem. When I swap between wired and wireless for debugging/testing, I just leave the wireless adapter in place and simply unplug the teather from the adapter to the HMD and then plug in the standard tether (via the linkbox). If you remove the wireless adapter each time; that's going to add extra steps and it may not really make a difference in your UX since you'll primarily be seated. The extra bulk on top of the HMD won't affect you in the same way it would if you were playing a movement heavy game like holopoint so removing it is less important.

, Go to SteamVR -> Settings -> Developer -> Reset -> Remove All SteamVR USB Devices for the GUI flow which may or may not meet your needs. To manually remove drivers, use USBDeview.

, Two 2.0 stations can cover an area around 6m x 6m depending on the environment and the coverage of the stations. The stations themself have a 6m range (but SteamVR wants you to mount them no more than 5.5m apart for optimal tracking). The diagonal is longer than 6m; the tether to the HMD however is not and in many cases, it's the teather that actually dictates the range of the HMD. You can have a massive playspace but little range on your HMD - the playspace is simply referring to the roomsetup configuration that is stored by SteamVR and composited into the the output of the game engine. Not everybody using Pro is tethered, and not everybody using Pro is using 2 stations, there's quite a bit of I don't see anywhere in the image where it's referring to a "6m range" diagonally on that image? Did something get cut off at the bottom? I'm not sure where you're getting that value from.

, I have a couple of notes on on this: The Vive Pro is a Displayport 1.2+ device. Your GPU must have a port capable of outputting DP1.2+ signaling. This requirement is listed as a system requirement on all marketing pages and store pages.Most current gen HMDs have the same requirement such as Valve Index, Oculus S, Pimax 5/8K, ect... If your laptop ends up not being compatible with Pro, it will by default be incompatible with these other HMDs. HDMI is not capable of delivering the bandwidth required to drive the Pro - you cannot drive a Pro via an HDMI port using any combination of adapter, cable, ect... USB-C is extra tricky because OEMs can integrate them a number of different ways. You first need to first look up the spec sheet for your specific model of laptop and confirm if the USB-C port is capable of supporting DP1.2 signaling and if the USB-C jack is wired to the dedicated GPU. In many cases, especially with budget laptops, that USB-C port will only be wired to the integrated graphics or will not If your laptop's USB-C port will output DP1.2+, here is an adapter that's known to work with Pro. It will only work if your laptop is compatible. If you can't confirm, reach out to your laptop's OEM to have them confirm if the port is wired to support DP1.2+ via the dGPU. Laptops need extra umphf because they're not as powerful as their PC equivalent. In most cases, you need a GTX1070 to run a Vive Pro on a laptop due to thermal throttling, a 1060 usually dosen't cut it (but it depends). Your laptop should have a MiniDP port if it's a modern gaming laptop with a dGPU.

- When dealing with a flashing grey screen - it's typically indicative of tracking issues first and foremost. When troubleshooting traking issues, you'll want to generate a SteamVR system report and search the output for reflections or other basestation specific lines. The way to confirm a reflective issue would be to create a SteamVR system report, save the file, then open the file in a text editor and use Ctrl+F to search the document for the following term: back-facing. If you see a high number of back-facing hits, it's almost certainly a reflective issue. Here's an example output that shows a clear-cut case of reflection-based interference: Sun Jun 26 2016 23:02:09.676 - lighthouse: LHR-4R8EF209 H: Dropped 32312 back-facing hits, 2069 non-clustered hits during the previous tracking session

, Realistically - desktop VR is significantly easier than standalone devices to develop a shippable product right now if you're new to VR. Standalone headsets like the Focus Plus have tons of benefits from being inherently standalone but they're mobile products and the current generation of standalones are using Snapdragon 835's. Porting or developing for standalone requires an specific skill-set. is a video that highlights some helpful tips. You can definitely start for Focus but you'll be able to get going faster with desktop. Desktop VR on the other hand doesn't have the same headroom limitations - you have a dedicated GPU to handle geometry and shading. You can get away with alot and most asset store assets are geared towards desktop. The desktop development ecosystem has been around longer and there's a more robust set of tools, forum posts, and learning resources, ect.... The install base of desktop HMDs are also higher than standalone currently (but there are more developers targeting that market). If you're developing VR you'll need a gaming PC with a powerful GPU which is the primary barrier that prevents people from getting a desktop VR - you're more than halfway there already. Each platform has limitations and use-case. It's possible to develop your project in a way that will work with both standalone and desktop using intelligent just know that optimization for standalone is no joke and is resource intensive whereas desktop doesn't require the same focus on optimization and you'll be able to iterate much quicker and have many more tools and computer resources at your disposal. Here are my current top recommended resources for beginners: https://voicesofvr.com/ https://www.substance3d.com/pbr-guide Game Maker's Toolkit https://80.lv/ How To Create VR

I'm sending an email to the address associated with your account In short, there are no known conflicts (Vive Wireless is RF based, Optitrack is IR based) and we state the range of the adapter to be 6m (but you can mount it in some creative ways to cover large areas).

- Thanks for taking the time to share your devlog on our community! I really like the concept for this experience! As someone who lives in San Francisco, the smash and grab city, I find this more hilarious that I probably ought to and will defintely be following this project.

- That's more or less the level of end-user support there is currently on MacOS. It's not just that MacOS needs to support the hardware (which in some cases it will natively on Mojave based machines), but also the software ecosystem to drive the hardware needs to be in place. We consider the overall experince to be in a developer/pre-developer state on Apple Hardware and MacOS. Valve and Apple maintain a developer program independent of Vive to drive support for Vive and SteamVR overall within the Apple ecosystem. As an end user - there simply aren't apps compiled to run on MacOS. The main issue here is that developers can't turnkey deploy their projects to MacOS. Most projects are using the core Windows based rendering technologies like DirectX. Apple has variations on all of these core technologies (ex: DirectX -> Metal 2) and so a developer would have to go through and rework their entire project to work with Apple's rendering and shading technologies. You're more or less able to boot the HMD via the branch I posted above - from there there isn't much to do unless you're a developer. The overall support of SteamVR on Mac is a Valve/Apple conversation for the most part.

, you're not likely to damage anything by testing that cable. The results will be pretty binary - it will either work or it will fail to initialize the HMD.

, Vive is considered pre-developer on MacOS - there is not end-user support. If you're a consumer trying to use MacOS to drive your Vive, be fully aware that hardware support is only one part of the puzzle piece and that only a handful (>10) of experiences have binaries that will run on MacOS. The eGPU support is super weird - Apple primarily is supporting the eSonnate eGPU in their developer program. In any case, Apple + Valve manage their developer program, not Vive. Desktop VR is almost entirely centered around Windows based PCs. You can access the MacOS enabled binaries of SteamVR via SteamVR's beta's tab.

, Vive is considered pre-developer on MacOS - there is not yet any end-user support. If you're a consumer trying to use MacOS to drive your Vive, be fully aware that hardware support is only one part of the puzzle piece and that only a handful (less than 10) of experiences have binaries that will run on MacOS and are publicly available. The eGPU support is super weird - Apple primarily is supporting the eSonnate eGPU in their developer program. In any case, Apple + Valve manage their developer program, not Vive. Desktop VR is almost entirely centered around Windows based PCs. You can access the MacOS enabled binaries of SteamVR via SteamVR's beta's tab.

, Also please let us know how you're mounting the station in question. The only thing I can think of that would produce this behavior is if the station was power cycling or if the station was detecting movement and thus exiting broadcast mode and then re-entering it when the rotors spin back up to the proper speed.

, You cannot use any sort of adapter, convert, cable, ect... to drive a Vive Pro via HDMI. The Pro must be driven by a port that specifically supports MiniDisplayport 1.2+ signaling. If looking for a MiniDisplayport -> Minidisplayport cable, you'll want to hit the following specs: Under 2 meters in length Capable of supporting 4K at a minimum of 20gbps. The cable we've recommended most often is this one: Cable Matters Mini DisplayPort Cable (Mini DP Cable) in Black 3 Feet - 4K Resolution Ready This cable is known to be compatible with Pro and we use this cable for all of our team's VR laptops. Other cables may be compatible if they meet the reqs I posted above; this cable for sure works and is under $10 USD.

This is an ancient thread - since this was posted, Youtube has released a SteamVR native YoutubeVR desktop client.