Will there be any plans for Tegra support? I wouldn’t be surprised if someone creates some cool DIY project with NVIDIA’s K1 tablet due to it’s 192 shader core GPU at 852 MHz.
Reason: I can get very good frame rates on the tablet, and there is controller support natively put in by NVIDIA.
Galaxy S6? It’s got an 8-core CPU with 3GB ram and a 1440p screen, it seems godly for this!
Wouldn’t something like OnePlus 2 do better in terms of graphics? The Samsung S6 only has an Adreno 320 (16 shader cores at 400 MHz) while the OnePlus 2 has an Adreno 430 (192 shader cores at 650 MHz).
I think generally when you say “mobile VR” you have to imply “phone”. You’re putting it against your face. It’s important for the device to be small and light.
Otherwise I hear NVidia chips are pretty good. Would probably work well.
Galaxy phones are also a good choice - we’ll be focusing on all Gear VR compatible phones just as a hardware baseline in the beginning. I think ROBLOX may not work right now on Galaxy S6 specifically but all other phones should be good.
tfw I just got a galaxy s6
Wait does that mean it’s out of the question forever?
What is?
I think he’s referring to tablet (non-phone) VR
I mean, it’s not really up to us. We’ll probably run Cardboard-style VR on a tablet without issues.
You’d have to:
- Build a headset for your tablet
- Specify a Cardboard-compatible optical configuration for headset/etc. - see developers.devsite.corp.google.com - Google Single Sign On: Sign into corp
- Suffer a large tablet strapped to your head and that’s in addition to other issues
On the bright side, heavy tablet on your face restrains the motion which puts less pressure on gyro latency…
I was asking about Galaxy S6 Roblox VR Support
I’m sure it’ll happen.
Meanwhile, time for a new round of updates!
API
We have implemented new API for Camera to push further on making more games work better out of the box in VR:
bool Camera.HeadLocked
CFrame Camera:GetRenderCFrame()
By default all cameras are head-locked which means that we automatically combine camera CFrame with user head CFrame to get camera rendering CFrame (which you can get using the function above).
In addition to that, rendering CFrame also includes Roll from the camera in case anybody still uses it. Effectively, like with parts, GetRenderCFrame returns you the true complete CFrame that will be used for rendering. You can use this even if VR is not enabled, of course.
There are some cases in which the automatic adjustment is inconvenient - e.g. you want to implement custom camera control logic that uses complicated transformations that somehow restrict or augment head CFrame data. In this case you can disable HeadLocked and proceed using the custom logic. However, please do NOT set HeadLocked to false mindlessly! What happens if you set HeadLocked to false and fail to apply user head CFrame is the user gets sick. Don’t make the user sick.
Specifically do NOT set HeadLocked to false without testing your game in VR.
Even if your game is using VR, by default do NOT set HeadLocked to false. HeadLocked=true lets us do some latency optimizations so it’s the ideal choice. In other words, HeadLocked=false is for power users - people who author VR-optimized content and have done a lot of experiments. We trust you to not misuse the power.
We’re also working on UserHeadCFrame API to incorporate hand tracking in addition to head tracking - more news on that in a couple of weeks.
Controls
We’ve significantly improved default character/camera controls in VR. They feel more natural and improve comfort. A few examples of things we had to do (thanks to @0xBAADF00D for working on this!):
- In VR you can only turn the camera up/down by rotating your head, gamepad/mouse controls do not work
- In third person the character now moves where you look with the head, so navigation is easier since you don’t have to turn the character as frequently
- In first person the direction of movement is the same as the look direction. This is somewhat controversial - not all people prefer that although this seems to be the more comfortable option out of the two.
Very Soon™
Updates shipping next week:
- Humanoid name/health rendering (currently they are not rendered in VR)
- BillboardGui rendering improvements (it will be rendered in world-space in VR so that it feels like a 3D object in the world and not a weird resizing panel)
- Fix moon turning when you roll your head (oops)
- Head tracking/rendering support for HTC Vive. Just install Steam & SteamVR and ROBLOX will work with Vive.
Updates we’re working on:
- Hand tracking support for HTC Vive
- Input support for HTC Vive (still designing the API)
- Rework base core GUIs (backpack, top bar, etc.) for VR
I just wondered…
did anyone make a game yet that’s meant to make people sick?
A bit like a ride at a fair, but virtual, less intensive and 100% meant for being sick.
Does this actually work with cardboard at the moment?
If so, does anyone have a setup guide?
No. As said before, Cardboard support is a few months away.
Gotcha.
I’m saving up for an HTC Vive right now, hoping to have it in a month or so.
We already used some software to actually make ROBLOX think we are using an occulusus. But we where using an cardboard
Why is the Oculus Rift so expensive? It just looks like something you slide your phone into.
Because it’s not something you slide your phone in. It has it’s own screen which is optimized for VR and has a far higher framerate and resolution than your phone.