I think you'd be better off with polygonal characters if you want to be able to freely move around them. You can still use motion capture to capture their movement and facial expressions.

I don't think you're going to be able to store voxel models of FMV at anywhere near the resolution required to make it look good. For example, if your models are stored as 512x512x512 voxel maps (which seems about right to me: HD video is 1080 pixels high, so 512 is about half) at 30 frames per second, to store 1 minute of video footage, you'd need (by my calculation) 675GB of uncompressed data - that's per minute of footage. Obviously, compression can reduce that quite a bit, but even if you reduced it by a factor of one thousand, you still need 0.68GB per minute...

If you don't need full 6 degrees of freedom, you can simply capture the video from multiple angles at the same time. But don't forget, for each additional angle you capture at, you're adding an extra stream of video. DVD-quality video requires about 34MB per minute. If you recorded the video from 75 different angles (meaning you'd be able to move around the "model" and get a different view every 5 degrees of rotation) you'd need 2.5GB of storage...

Quote:Original post by RobTheBloke
It does have flaws, but then again so do commercial 3D scanners. From experiance every 3D scan requires significant (manual) cleanup - a particularly nasty job with very dense meshes. The primary problem with the technique seems to be one of calibration - which is where the flaws in his implementation appear to come from. I had a go at implementing the algorithm, and it actually gave reasonable results when fed images rendered from maya (where the camera & projection setup could be controlled accurately).

The projection stripe method he uses is very simple to implement, but has worse artefacts than most of the other methods. In particular, you need multiple frames to resurrect a 3D model, the projected stripes interact with shadows, causing problems in reconstruction, and the stripes remove the ability to record surface colour at the same time. If your target is human, the stripes also prove very distracting for the subject.

You can get around most of these issues by using an infra-red projection (i.e. move the stripes out of the visible spectrum), but it still requires multiple frames to reconstruct.

MIT's coded aperture approach looks like it could be incredible for homebrew, as it doesn't require any additional equipment (such as a projector), can capture scene depth in a single frame, and seems to yield very decent results - unfortunately, nobody seems to have implemented this for a video stream yet.

The ZCam/Project Natal Time-of-Flight approach looks as if it might be the most robust. They pulse an infra-red laser at regular intervals, record the intensity at which it bounces back, and use the speed of light to calculate the distance. The advantage here is that it works flawlessly in near-darkness (where the MIT approach can't), doesn't interfere visually, and can also capture depth in a single frame.

Quote:Original post by Portugal Stew
But once again that seems to me to just be a bit too simple. Surely there are alternate means of storing voxel information than by just cubing the grid.

The obvious alternative being to store voxel coordinates with the color, making it 9byte instead of 3byte. Efficiency aside that will start to help as soon as less than a third of the grid is filled (which it most likely will be). Then of course a simple octree would also allow to throw away a ton of empty space for (hopefully) much smaller overhead.