cancel
Showing results for 
Search instead for 
Did you mean: 

Did FB just kill the Oculus Rift S???

Chris_WG
Honored Guest
Anyone watch Oculus Connect 6?

It was basically announced that the Oculus Quest will receive PC VR support, essentially making it a Rift S as well as a standalone headset.  Also, they plan to introduce hand-tracking with the Quest.

Did they just kill the Oculus Rift S in one fell swoop with this announcement?  As a Rift S owner, not sure how I feel about it.  The Quest is now going to be able to do everything the Rift S can do plus a few more things it seems.

Did Mark Zuckerberg just give all Rift S user s a big FU?
96 REPLIES 96

Anonymous
Not applicable

Mradr said:


Spuzzum said:


T_K_T said:

From a technical standpoint, no. I don’t have a quest, but I at least know that it doesn’t run as well as the Rift S. FB is doing this to give Quest users much more content. Sure, the quest can go wireless and wired, but in the end the experience won’t be as polished as the rift s



Until it actually releases to the public, and people get hands-on reviews, then all this is just speculation. The Quest's OLED screens are far better for blacks and colours than the Rift-S's LCD panel, and being able to manually adjust the IPD slider, to a broader range of eyes out there, that alone makes the Quest better than the Rift-S. The Quest also has 2880x1600 resolution, while the Rift-S is still only 2560x1440. The Quest, while tethered, will be reduced to the Rift-S's 2560x1440 though. Personally, I'd rather have the Quest and Link than a Rift-S. Now if we could convince Carmack to get the Quest recertified for 90Hz/fps, then we're laughing. He said the panels can do it, it's just that hardly any games would run at 90 on the Quest's processor power. But 90fps while tethered would be perfect.


Hmmm he also goes on to say - while this might be possible to do at 90Hz - the method at witch they encode/decode wouldn't be fast enough and thus the reason why they drop the resolution from 2880x1600 to 2560x1440. If there are any improves in the compression - it'll go to not having to compress as hard for image quality it self.



nalex66 said:


Spuzzum said:
...Now if we could convince Carmack to get the Quest recertified for 90Hz/fps, then we're laughing. He said the panels can do it, it's just that hardly any games would run at 90 on the Quest's processor power. But 90fps while tethered would be perfect.


It’s not just about recertification though. Due to the decoder bottleneck, you’d be trading off frame rate against resolution or compression. I believe Carmack commented that between getting more frames or higher resolution, he’d rather have the better image quality. 



Crap...I never even thought of that. 😛 150Mb/s @ 72fps definitely looks better than 150Mb/s @ 90fps at the same resolution. The pipeline is limited to 150Mb/s...can they create multiple pipelines, acting in SLI? 😛

Anonymous
Not applicable

Spuzzum said:
Crap...I never even thought of that. 😛 150Mb/s @ 72fps definitely looks better than 150Mb/s @ 90fps at the same resolution. The pipeline is limited to 150Mb/s...can they create multiple pipelines, acting in SLI? 😛


They could - but then you still would have to sync the split image or data thus creating a frame or more of lag thus it wont work well enough. Not to say they can't make it work - if SLI has proven anything - split data can be harder to handle than a single run. For example, what if half the image is harder to encode/takes time - what do you do then? What if the next frame is ready to be drawn? One way around this is to interlace - but this bring ghosting as well.

I'm sure there is a balance that could be made - but it would also add cost and that link cable is already 80$... that be 160$ o.o; More or less you would be better off supporting display-port over USB C than you would be to keep adding USB connections. Something they still will have to add later on as even USB4 or 5 wont have the bandwidth of HDMI or Display-port will have for higher resolution screens.

Anonymous
Not applicable

Mradr said:


Spuzzum said:
Crap...I never even thought of that. 😛 150Mb/s @ 72fps definitely looks better than 150Mb/s @ 90fps at the same resolution. The pipeline is limited to 150Mb/s...can they create multiple pipelines, acting in SLI? 😛


They could - but then you still would have to sync the split image or data thus creating a frame or more of lag thus it wont work well enough. Not to say they can't make it work - if SLI has proven anything - split data can be harder to handle than a single run.



If you watch the video on Oculus' youtube channel about the Link cable, they're rendering 1/3 of a frame at a time, which reduces latency, resulting in an 'almost' 1:1 render to encode time. Yeah, I've read SLI can be difficult...I was just being curious...and an ass. 😛 But I know Carmack said they created the pipelines in the chip, and seeing as they render/encode 1/3 of a frame at a time, I was thinking they could split that over more pipelines.

https://www.youtube.com/watch?v=9gocUADwqo8

Interestingly, I just came across an article from 2009, talking about Carmack playing with 'dTech 5 megatexture content creation pipeline' for the iPhone 3GS.

https://kotaku.com/carmack-just-about-everything-id-makes-coming-to-iphon-5303694


edit: Actually, the 1/3 of a frame at a time is the encoding on the pc, before being sent as a whole frame to the Quest. So that wouldn't work. Regular SLI would be the only hope.

Anonymous
Not applicable
Their method is still slow in that they slice the image into 3 parts - witch will help some - but H.265+ for example takes only the differences and updates the required pixels instead. So while their 3 part slice will help show the image faster - it still takes almost 1/3 more data than just uploading the difference would take instead. You could in theory add both methods to both show a third of that image to the screen - while sampling the next image thus creating a far less bandwidth update - but it still only maybe be around a 35% improvement at best. Still - really neat stuff! All above my head for sure, LOL. This is why I belive Quest will keep improving on Link and continue to get super close to that of the Rift S image. Scary to think for Rift S users in a way 😜 For Quest owners - this is super amazing news our headsets will have a LONG life.

As or SLIing that data - hmm in theory, like I said, its possible to just add more data lines to upload two or more chunks at the time - it just has added cost on the cable, weight, and stiffness along with the encoding/decoding channels to process the data. The video covers that as well. They made their own cable to get around some of the issues. What's fun about fiber optic cable - all you would have to do is get more colors in the cable to get more data thus they could see full on 255Tbps cables while still only being the size of a stander cable while HDMI would be the size of a chair lol.


https://www.extremetech.com/extreme/192929-255tbps-worlds-fastest-network-could-carry-all-the-intern...

Anonymous
Not applicable
So, instead of 90fps, how about the 80 the Rift-S is getting? They're using a fixed foveated render, so could they push the codec/process for another 10%?

Anonymous
Not applicable

Spuzzum said:

So, instead of 90fps, how about the 80 the Rift-S is getting? They're using a fixed foveated render, so could they push the codec/process for another 10%?


All possible - yes. There is only one problem - and that is why I said above - is that if they have to redraw te whole image - I don't care how smart they are - they will have to redraw the whole image and that is where the problem lies in terms of hitting that 80 Hz. The more moving data there is - the more bandwidth you need to keep up with.

Anonymous
Not applicable

Mradr said:


Spuzzum said:

So, instead of 90fps, how about the 80 the Rift-S is getting? They're using a fixed foveated render, so could they push the codec/process for another 10%?


All possible - yes. There is only one problem - and that is why I said above - is that if they have to redraw te whole image - I don't care how smart they are - they will have to redraw the whole image and that is where the problem lies in terms of hitting that 80 Hz. The more moving data there is - the more bandwidth you need to keep up with.



That's why I said to push the codec/process. If it can do it with the same bandwidth, then there's no problem. As long as the quality doesn't suffer. Is the audio signal included in that 150Mb/s(?). If so, then that could be tweaked a bit as well. If the signal is 150Mb/s, then 10% more is only 15Mb/s. That's not a hell of a lot to squeeze out.

Anonymous
Not applicable

Spuzzum said:


Mradr said:


Spuzzum said:

So, instead of 90fps, how about the 80 the Rift-S is getting? They're using a fixed foveated render, so could they push the codec/process for another 10%?


All possible - yes. There is only one problem - and that is why I said above - is that if they have to redraw te whole image - I don't care how smart they are - they will have to redraw the whole image and that is where the problem lies in terms of hitting that 80 Hz. The more moving data there is - the more bandwidth you need to keep up with.



That's why I said to push the codec/process. If it can do it with the same bandwidth, then there's no problem. As long as the quality doesn't suffer. Is the audio signal included in that 150Mb/s(?). If so, then that could be tweaked a bit as well.


It would though - they can't really "overclock" the part of the process or else they would've anyways I would assume. I dont think it's a latency issue - it be more of a bandwidth issue more than anything. 

Anonymous
Not applicable

Mradr said:


Spuzzum said:


Mradr said:


Spuzzum said:

So, instead of 90fps, how about the 80 the Rift-S is getting? They're using a fixed foveated render, so could they push the codec/process for another 10%?


All possible - yes. There is only one problem - and that is why I said above - is that if they have to redraw te whole image - I don't care how smart they are - they will have to redraw the whole image and that is where the problem lies in terms of hitting that 80 Hz. The more moving data there is - the more bandwidth you need to keep up with.



That's why I said to push the codec/process. If it can do it with the same bandwidth, then there's no problem. As long as the quality doesn't suffer. Is the audio signal included in that 150Mb/s(?). If so, then that could be tweaked a bit as well.


It would though - they can't really "overclock" the part of the process or else they would've anyways I would assume. I dont think it's a latency issue - it be more of a bandwidth issue more than anything. 



What would be overclocked? the panels can run more than 80Hz, and the encoding gets done on the pc side. As long as you can squeeze that extra 10% into the same 150Mb/s, then that's all you need. My 'guess' as to why they didn't go that route...is it would definitely had killed the Rift-S.

edit: Carmack also said the panels will do 90Hz, but that they couldn't get games to run at 90fps, rendered on the Quest itself, so they settled for 72Hz instead.

Anonymous
Not applicable
The data needs to be both encoded and decoded. It's no different than how streaming works. Not to sound rude - but I dont think you understand how it fully works:) not to say I do as well - but lets stop here:)