I don’t see Zuck as a gamer. I doubt he is fun at all
Meta isn’t looking to VR as a gaming device but a social network device you can also game on so the lower the cost the more can enter.
So it’s not about can’t but need to.
It’s like Ford v Ferrari. Ford can beat Ferrari but their market demand isn’t for that Ford model.
What I heard, during the minutes for which I listened, from the the timestamp you linked, was pretty clearly stated: Brute-forcing FOV out of the same type of construction almost all VR has been since the Rift DK1, through “simply” increasing the sizes of the lenses and screens (plus some canting), which is pretty much exactly what my own observation has been all along.
I don’t know about: “can not” – obviously each company chooses their own priorities and tradeoff balances.
I regard people’s playing down how nice it would be to have better FOV, as being mostly a bit of a sour grapes situation.
…of course we got the usual wild misconceptions about FOV measurements overall: 130-140° for the Index, huh? -I would have hoped everybody had learned better, by now.
Somebody noted the increasing benefits of foveated rendering the wider one’s FOV is – pretty much what we have all been thinking here as well, I think…?
We really need some changes and standardisations in software frameworks, to take wide FOV, and foveated rendering, and other things, out of its niche-within-a-niche-within-a-niche status – too much legacy practices, and too much hardcoding to proprietary hardware devices and APIs, has been breaking and braking VR back for too long (…often under the excuse that “too early” standardisation would purportedly stifle innovation). -Don’t know whether OpenXR does anything to deal with this yet, or if it is just repackaging the old so far…
If somebody can truly not appreciate that Pimax, and a few others, are at least trying to cater to the demand for wider FOV; Well – that is that person’s problem. :7
Wide FoV headsets don’t sell which is why Pimax just had their 3rd round of funding. That’s all well and good while there’s cash in the bank keeping the lights turned on but what for long term sustainability?
Say StarVR Two came out with 2880x2880 panels, where would that leave Pimax? It’s a good job for Pimax no other company chooses the niche wide FoV root.
That is written in such a way if sounds like a suggestion wide FOV in itself would be cause for bad sales - not an assessment I see myself buying. -I think Pimax is quite capable of tanking themselves on the market, without there being some sort of wide-FOV curse.
How about curved displays? Much of whats wasted in VR resolution is lost in the periphery…canted displays try to optimise this by putting the sweet spot in the center of the view from each eye…perhaps curved microleds are the answer, at least horizontally, such that the lens would have less distortion, and therfore be lighter, then finally you also dont have to render as much? Just a far future thought probably, but curved displays do exist, so maybe a possibility.
Yes, there was speculation about curved panels and lenses from Samsung, years ago.
Unfortunately, the typical HMD manufacturers have to choose from the existing portfolio of panels, and curved also means mechanical stress, i.e. mura. But it might work that way in the future
OpenXR isn’t a graphics API so its not going to solve the foveated rendering problem on it’s own. As a quick reminder, DX11 doesn’t support VRS (the key technology behind foveated rendering) without vendor-specific extensions (that only Nvidia provides). When I see the majority of VR games still released with only DX11, that’s already not a promising step forward.
Now let’s assume that graphics API isn’t an issue, there is unfortunately no standard support for foveated rendering in OpenXR. But that’s not really an issue. There are vendor-specific extensions for it, but they only do something like providing the VRS mask, which isn’t that complex if you have raw eye tracking data. When I first released FFR rendering in OpenXR Toolkit, it was out of question to not let users customize all the parameters (because I know people would’ve complained without this level of customization). So these OpenXR extensions, even if made standard across vendors, wouldn’t make the community happy anyway since they don’t allow that customization. Anyway they are only supported for standalone mode and not for PCVR.
Where OpenXR could have solved a problem was about getting eye tracking data in a generic way. Microsoft implemented that (for HoloLens so y’all probably don’t care) and then Varjo followed. Would’ve been great to continue on that train, but unfortunately neither Quest Pro nor Pico 4 Pro implement that. So we’re back to almost square one with developers needing to support per-device interfaces. Worse, a device like Pico 4 Pro doesn’t even offer a PC SDK to go and use the eye tracker device at all.
So yeah, I now have 4 different implementations of getting eye tracker data in OpenXR Toolkit: HP, Droolon, Quest Pro and of course the generic OpenXR one that only Varjo implemented.
Now to be honest, these different implementations are pretty simple, because and eye tracker has a pretty simple interface in the end, but where it hurts is about the need to acquire a device of each type to develop it. I didn’t do that for all, I dont have a Droolon for example, and I had to do back and forth with a tester to get it right.
For Crystal I plan on providing eye tracker support in PimaxXR through the generic OpenXR extension, but it’s still TBD if it’s going to work (and I don’t have a Crystal to develop).