Forum Discussion
pittsburghjoe
11 years agoProtege
The Foundry just solved live action stereoscopic VR 360
http://www.cgchannel.com/2015/04/the-fo ... f-vr-work/ :!:
Anonymous
11 years agoWe have the single presentation posted now on Vimeo so you don't have to go through the large live stream file.
https://vimeo.com/125572049
This is just a tech preview. We will have a lot more to talk about in the future on this. You don't have to re-solve anything if you don't want to. Nuke is just a DAG with a series of nodes and metadata. Each set of nodes is very modular and re-usable. You could create the entire rig in Nuke manually if you wanted without solving or import an fbx/alembic file with a camera setup from another application. Once you have solved for one part of the pipe you could use it for all shots and not re-solve it each time. Camera rigs for VR(especially gopro ones) are very flexible, not always precise and the geometry is often changing so many times you do want to re-solve for it if you are removing any cameras to change out batteries, etc... It is up to you though.
Previously we created multi camera tracker already built into Nuke for many years now which can solve for stills or a moving camera and can do point clouds, image based modeling, etc....
https://vimeo.com/94369259
https://vimeo.com/album/3087027
We already produce tech for correcting stereo 3d images called "Ocula" which we created originally for Avatar about 7 years ago. It has has 5 iterations since then and used on hundreds of films. It solves geometry of cameras and does color matching, alignment repair, etc....
http://www.thefoundry.co.uk/products/ocula/
https://vimeo.com/album/2985109
Not impossible but problematic so it is easier to fade out the depth at the poles.
Do you have working links for those docs? The pages appear to be down and I can't find an alternate source for the paper on google.
https://vimeo.com/125572049
Also in the Nuke process it seems to solve the cameras from scratch each time whereas a more trustworthy process and one that would be better for creating reusable templates maybe would be to determine the lens/sensor parameters of each camera separately (Gopros vary a lot, for example in the positioning of the sensor behind the lens). You can do this calibration with an accurate indexed panorama head and PTGui or Hugin. It would be nice to be able to input this information into Nuke (or use Nuke to do this individual calibration via panorama head) -- and then go from there to calibrate the positions and orientations and fine tune the individual camera internal parameters of the camera array.
This is just a tech preview. We will have a lot more to talk about in the future on this. You don't have to re-solve anything if you don't want to. Nuke is just a DAG with a series of nodes and metadata. Each set of nodes is very modular and re-usable. You could create the entire rig in Nuke manually if you wanted without solving or import an fbx/alembic file with a camera setup from another application. Once you have solved for one part of the pipe you could use it for all shots and not re-solve it each time. Camera rigs for VR(especially gopro ones) are very flexible, not always precise and the geometry is often changing so many times you do want to re-solve for it if you are removing any cameras to change out batteries, etc... It is up to you though.
Previously we created multi camera tracker already built into Nuke for many years now which can solve for stills or a moving camera and can do point clouds, image based modeling, etc....
https://vimeo.com/94369259
https://vimeo.com/album/3087027
Then he talks about stitching. He shows how each of the stereo panoramas from the L/R pairs have geometric -- ie parallax (and sync presumably with this rig) stitching errors which can be corrected automatically by Nuke's warping capabilities. But the L and R stitching errors (speaking parallax errors only) will likely be in different locations in the L and R panoramas and there is no guarantee (at least he didnt mention that they are handling this) that the blending algorithms will act in stereoscopically identical fashion.
We already produce tech for correcting stereo 3d images called "Ocula" which we created originally for Avatar about 7 years ago. It has has 5 iterations since then and used on hundreds of films. It solves geometry of cameras and does color matching, alignment repair, etc....
http://www.thefoundry.co.uk/products/ocula/
https://vimeo.com/album/2985109
Then he talks about how correct stereo for zenith and nadir is impossible without a textured mesh of scene geometry (or by using depth maps to reduce nadir and zenith depth to zero -- infinity in vr headset contexts). In fact Micoy at least claims correct nadir and zenith stereo viewing is possible (they sell plugins for full dome stereo rendering and have patents for a spherical camera array where images are stitched in spiral patterns).
Not impossible but problematic so it is easier to fade out the depth at the poles.
Do you have working links for those docs? The pages appear to be down and I can't find an alternate source for the paper on google.
Quick Links
- Horizon Developer Support
- Quest User Forums
- Troubleshooting Forum for problems with a game or app
- Quest Support for problems with your device