Oculus Connect Keynote: John Carmack

What people said

lhl · 2015-06 · Strong recommendation

While this may be true for high fidelity gaming, for moving some textured triangles around, mobile GPUs are fine. Also, they can (and do) perform much better clock-for-clock vs a PC (and especially a Mac) thanks to the ability to optimize drivers. For a fascinating discussion of the optimizations possible, Carmack's 2014 Oculus Connect keynote is well worth watching: [VIDEO] This talk was a slightly long but very informative discussion of the various challenges in reducing latency and dealing w/ PC rendering: [LINK]

Read the original HN comment ↗

nickjj · 2021-06 · Recommendation

> What was Carmack's development focus during Oculus? I'm not sure exactly but there's a bunch of keynotes from Carmack around Oculus Connect on YouTube. Here's one from 2014: [VIDEO] , and another one from a year later where he's live coding in a VR environment [LINK] . You'll find a bunch more if you search too. I remember skimming through them years ago not because I'm into VR development but I've been a life long fan of Carmack's work and like listening to him talk about things.

Read the original HN comment ↗

pfranz · 2016-11 · Reference

Found where Carmack talked about it[1]. For VR, the consensus I've seen seem to push for multi-sample AA > full-screen AA > temporal AA (I feel like I've even seen no AA is better than temporal AA). I'm not quite sure if it's performance, architecture (they really prefer forward renderers instead of deferred renderers for low latency), or aesthetics. In the little bit I've done, when just playing with knobs temporal AA looks better to me. Without AA specular highlights are way too distracting and pop too much. This reference[2] talks about the extra velocity buffer needed for temporal AA and the fact it tends to over-blur which can fuzz out fine details (low resolution is a touchy subject in VR). There's a lot of moving pieces when making decisions. In talking about interlacing, he was ideally talking about not having to create a whole image buffer before sending data to the hardware--just rendering parts (well, scanline) of the image that moved. [1] [VIDEO] [2] [LINK]

Read the original HN comment ↗