Non-issue: links to working PSVR code #13
Description
I said I would make some code available for study once it was published online. Here (below) are those links. Warning, this code isn't packaged for convenient readability, but that can be good, because it distills everything down to brass tacks.
This (http://svn.swordofmoonlight.net/code/SomEx/som.shader.cpp) link has a reduction of all of the PSVRFramework code that deals with the set's geometry near the top, and shaders for barrel and chromatic aberration correction. But I should warn that the shaders are mixed in with all other effects that are applied in a final effects pass. Also the split-screen parameter is very tricky to grasp (written for efficiency) and the variables are sometimes packed into vectors to take advantage of their simultaneous processing in the GPU programs. Look for stereo and STEREO and DCA marks chromatic aberration. Also of interest is color correction code (that I've yet to really dig into) that is tailored to the PSVR's peculiar gamut. It looks better than home-theater mode I think, overall, but it's just cowboy coding. I intend to approach the color reproduction problem more systematically at some point in the future.
PSVR stuff is rewritten under namespace PSVR and is not actually used, since it just reduces down to 4 constants, which I recommend discarding 2 of, so that they are symmetric in terms of horizontal and vertical. If the input image is a normal game image, these should be square/symmetric. If you play with asymmetric projections in your input image then maybe not, but I haven't tried that out. Using a square input image (aspect ratio is proportionate) I find 94 degrees to be ideal vertical FOV setting. A more exact setting might be somewhere between 93.5 and 94.5, however, using an integer, 94 is the correct FOV.
The bottom of this (http://svn.swordofmoonlight.net/code/SomEx/som.mocap.cpp) file has the sensor data processing, applied to the view volume beginning with static struct som_mocap_BMI055Integrator. This software is unconventional owing to it being something like an exoskeleton, since it's designed to extend an application by injection into its process. (Actually this ought to be a familiar concept to anything that tries to apply itself to existing video games. I don't know if TrinusPSVR works this way, but my impression is it does.)
The UDP processing (coming from PSVRToolbox) is in this (http://svn.swordofmoonlight.net/code/SomEx/som.status.cpp) file. See the static struct som_status_PSVRToolbox section. Headers for this are in this (http://svn.swordofmoonlight.net/code/SomEx/som.status.h) file. This is really not interesting. It just gets the raw sensor values, and issues some commands to the set to switch in and out of pass-through mode.
P.S. The Somvector vector code is a little unorthodox. Don't get too hung up on it. The sensor code is adapted from the PSVRFramework's code. It's left in an experimental state.