Sony Announces Virtual Reality Headset For PS4 112
An anonymous reader writes "Sony has announced 'Project Morpheus,' their project to develop a virtual reality headset for use with the PlayStation 4. 'Using a combination of Sony's own hardware, combining personal video viewers with PlayStation Move controllers, PlayStation engineers experimented with multiple prototypes.' They've been working on it for over three years — here's a picture of the current incarnation. The headset will use 3D audio tech that changes as players move their heads. One of their big goals is to make it extremely simple to use. They intend the display to be 1080p with a 90-degree field of view."
Re:Watch It Succeed (Score:4, Interesting)
I am not sure what more processing capability would be required, though.
Presumably (and this might be nonsense since I have never used the system), they already determine what sound goes into each channel based on the location and orientation of the view of the player (this is old-hat OpenAL stuff). Determining the orientation is done via the analog input of the controller so really they just need to convert the gyroscope data of the headset into the orientation language used by their input system. Other than that, it should just be a matter of running the video and audio to the headset, as opposed to the TV.
The hard part with this is typically just in building the hardware light enough that it doesn't cause neck strain in the user.
If they are trying to build stereoscopic 1080p, then you have the difficulty of rendering the scene twice (well, 2x over the normal number of render passes) and then reading out from 2 framebuffers. That is mostly a question of memory bandwidth in the GPU, though, and how their display controllers arbitrate the bus.
Re:Watch It Succeed (Score:3, Interesting)
On one level, it depends on their memory topology (how many components are fighting over that particular memory bus - this _should_ be pretty good in a game console).
In general, rendering a large scene takes immense memory bandwidth as the data required to describe the scene (GL commands, texture data, other data for shaders, etc) and the representation of the output (framebuffer, other pixel buffers, etc) are very large.
Then again, my main background in this area is working with compositors (where bandwidth was the limiting factor - in both texture upload and frame composite), so this data profile might push all the limits into direct computation.
In any case, if you are limited purely by computation, it is just a numbers game to see what (if any) trade-off would be required to get the second framebuffer for a given game.