News Oculus special live stream

Last edited:

PlayfulPhoenix

Founder of SFF.N
SFFLAB
Chimera Industries
Gold Supporter
Feb 22, 2015
1,052
1,990
No kidding.

(But of course, I have class during the announcement. Ah well)
 

PlayfulPhoenix

Founder of SFF.N
SFFLAB
Chimera Industries
Gold Supporter
Feb 22, 2015
1,052
1,990
No pricing = begin to worry that it's no longer a $349 purchase :oops:

The hand controllers are interesting, if not a little goofy. But they literally announced everything except specs, pricing, and availability.

(You know, the things we want to know about :p)
 

jeshikat

Jessica. Wayward SFF.n Founder
Original poster
Silver Supporter
Feb 22, 2015
4,969
4,781
Other than the new input it was pretty light on details, hopefully we'll hear more at E3. I'm not too worried on price, Facebook has a fat bank account so they don't have to make hefty margins on the product.
 

Phuncz

Lord of the Boards
SFFn Staff
May 9, 2015
5,837
4,906
Nice, but I'm also very interested in the HTC Vive when it materializes and how these compare. Because I doubt they are mutually compatible and it will be the most popular platform that will proceed into the future. Here's hoping Nvidia's doesn't succeed, I'm not keen on being GPU-vendor-locked-in.
 

jeshikat

Jessica. Wayward SFF.n Founder
Original poster
Silver Supporter
Feb 22, 2015
4,969
4,781
Yup, for something like VR content is king. No point having the technological superior product if there's nothing to play on it.

Cross-platform compatibility will probably be a mess for the first few years.
 

Phuncz

Lord of the Boards
SFFn Staff
May 9, 2015
5,837
4,906
About content, I remember some motion controller being all the hype not so long ago. Can't even remember the name. A clear sign of a product without a properly supported use-case.
 

EdZ

Virtual Realist
May 11, 2015
1,578
2,107
Because I doubt they are mutually compatible
One of the primary purposes of the SteamVR API is for it to be device-agnostic. Unless someone throws a hissy-fit, games targeted at SteamVR should work on both the Vive and the Rift (and any other HMD that can talk to SteamVR). Control is a bit of wrinkle though. Vive has tracked controllers for launch, Oculus will have them post-launch (controller devkit available after CV1 release), and the STEM is still coming at some point too.
 

Phuncz

Lord of the Boards
SFFn Staff
May 9, 2015
5,837
4,906
The Leap controller.
Yes that's the one :) Ahh the fail that was.

One of the primary purposes of the SteamVR API is for it to be device-agnostic.
That's a step in the right direction ofcourse but my worries are more towards G-sync and Free-Sync, seperate dual screens vs 1 spanned screen, how will SLI/Crossfire handle this, etc.

Because input lag, high minimum fps and frame times are very important for VR, I'm still very interested in reading the first critical reviews.
 

EdZ

Virtual Realist
May 11, 2015
1,578
2,107
G-Sync/Freesync is fundamentally incompatible with low-persistence updating when latency is a priority. If you do not know weh nthe next frame will arrive, you cannot correctly modulate the illumination level of the current frame to maintain a constant perceptual brightness (buffering frames solves this, but the latency is unacceptable for VR).
Multi-card rendering appears to be being handled identically by both Nvidia and AMD, but under different brandings. The concepts that AMD and Nvidia presented were essentially identical to those proposed by Valve and Oculus as "we would love to be able to do this" features (e.g. the ability to know exactly when a VSYNC will occur without late-latching hackery) so it is pretty clear that for now at least, the HMD companies are driving what features the GPU companies implement.
Multi-screen addressing should not be a problem (if any company implements a HMD that uses it, rather than aggregating multiple screens as one addressable area). Both companies know how to implement proper genlocking (and have done so on their professional ranges). Re-enabling it for chips on consumer cards - in certain circumstances if not in general - would not be too tricky.


The Leap Motion was a nice idea, with some great but poorly used hardware (cheap very high refresh rate IR cameras without any need to interface hack or debayer are REALLY useful to have), hobbled by switching focus from desktop to VR use (and having the camera spacing subsequently be suboptimal) and an initially very poor spindle-tracking algorithm.
Though even perfect optical hand-tracking might not be all that useful for VR. Your hands are fundamentally Haptic manipulators. Relying 100% on your visual system for any sort of feedback as to what your hands are doing is going to surprise people who have not tried it with how unintuitive it is for almost every task. Pointing and social communicative gestures work fantastically, any sort of object interaction is at best an exercise in frustration.
 

Phuncz

Lord of the Boards
SFFn Staff
May 9, 2015
5,837
4,906
Wow, thanks for your insights and info. I was expecting G-Sync and FreeSync to be of special importance due to the (almost complete) elimination of tearing without having to restort to severe FPS drops when the slightest frame below the treshold could not be displayed. But I guess V-Sync will be more important here.
 

EdZ

Virtual Realist
May 11, 2015
1,578
2,107
While the goal of rendering for VR is to never experience drops below VSYNC (and ideally never experience spikes above it, both through careful timing of rendering), the method for dealing with it in VR is a technique originally called 'asynchronous timewarp' by Carmack and Abrash when the concept was first described for VR (Carmack had experimented with it for Quake, but it was unnecessary and didn't work too well then) with some companies naming it something else (Sony calls it 'asynchronous reprojection' for example).
Basically, a few milliseconds before every VSYNC call, whatever was the latest rendered frame is taken from the buffer, warped based on the latest possible measurement of the user's head orientation and location (almost perfect warping for orientation, with some minor but acceptable artefacts when changing position) and this then gets handed over to the display. Ideally, you would perform this warping as the buffer is being read out ('racing the beam') to minimise latency. If you always have a new frame ready for each refresh, this is regular old 'synchronous timewarp'. If you are synthesising new frames because a new one isn't ready yet, it's 'asynchronous timewarp'.

Other methods of render time management are to change the resolution you are rendering the frame at dynamically frame-to-frame, so 'harder' scenes have a slightly lower resolution. Because EVERY frame gets warped before display, and thus there is no such thing as 1:1 pixel display for VR headsets, the image quality hit is pretty small compared to the rendering performance gain.
 
  • Like
Reactions: WiSK

jeshikat

Jessica. Wayward SFF.n Founder
Original poster
Silver Supporter
Feb 22, 2015
4,969
4,781
I knew about the other tricks but hadn't heard of changing the resolution on the fly. That's clever and better than changing stuff like the detail level which would be much more noticeable.
 

Phuncz

Lord of the Boards
SFFn Staff
May 9, 2015
5,837
4,906
I haven't heard about either of these, thanks for the info, very interesting.
 

EdZ

Virtual Realist
May 11, 2015
1,578
2,107
A new technique coming to Oculus and Valve's HMD interface SDKs is using the SDK as a compositor. This lets you composite buffers of multiple different resolutions into one output buffer (eye buffer). This makes it easy to dynamically drop the resolution for the in-game visuals, where the quality drop is much less noticeable, while rendering text and UI elements at many times supersampled (SSAA is VERY effective for VR, and MSAA is effectively a minimum requirement). You coudl even render 'hero' game elements at a higher resolution and 'background' elements at a lower resolution. Sort of like how '3D Skyboxes' work for Source, or the use of multiple viewports to get around scale issues for space sims (one viewport for the cockpit, another for everything outside, both with different scaling factors).
 
  • Like
Reactions: jeshikat