Mirrorshades update

It’s been a while since I posted anything about the Mirrorshades project, so here’s a few things I’ve been working on!

rift

I’ve stopped using the Playstation Eye cameras because the drivers were too buggy; I would frequently try to start work on the project only to find that Unity couldn’t find the DLL & there was seemingly no fix other than to repeatedly reinstall & restart for hours until they started working.

I’m now using a pair of Logitech C310 & whilst the resolution is higher than the Playstation Eye cameras (1280×960 vs 640×480), the refresh rate is lower (30hz vs 60hz). To my eyes, the Playstation Eye cameras actually gave a nicer experience, but of course when they weren’t working they were no use!

I’m using the same 3D printed clips (red) with the cameras epoxy’d to thermoplastic (white) so they can be adjusted via the nuts & bolts with rubber washers. Once again, inspiration taken from William Steptoe’s AR Rift project.

I quickly measured the latency introduced by the C310 webcams (& then realised that it would’ve been interesting to have done the same experiment on the PlayStation Eye cameras!). I placed the Rift, with the lenses removed, facing a LCD monitor displaying a timer from flatpanels.dk. I placed a camera behind such that it could see both the monitor & the Rift’s screen, then cranked the sensitivity up on the camera so that it could record 50fps video with a 1/4000th shutter speed.

The monitor & the Rift were both refreshing at 60fps, each frame lasting 16.67ms, whilst a 1/4000 shutter speed on the camera meant that the shutter was open for 0.25ms. The response time of the monitor (quoted by the manufacturer as 8ms GTG) was evidently much higher than that of the Rift, as the tenths & even hundredths digit on the monitor was usually legible in each frame of the video whereas on the Rift the hundredths & thousandths digits were always illegible. So I went through the video frame-by-frame looking for adjacent frames where a transition from one tenth digit to the next was good enough to read on the Rift & the hundredths/thousandths digits were good enough to read on the monitor, such as this pair;

00000.MTS.Still001

00000.MTS.Still002

From these we can infer that the tenths digit on the Rift screen (right eye) changed from 9 to 0 sometime between 181 & 198 on the monitor, meaning a latency of between 181ms & 198ms. Out of 11 pairs of frames like this, 7 pairs showed this 181-198ms latency, whilst 4 pairs showed 198-215ms as in the pair below;

00000.MTS.Still015

00000.MTS.Still016

I was also able to take some still photos with the same 1/4000th shutter speed, which all showed the same 181-215ms latency (3 images following), however as timing shots to get legible digits was entirely down to luck it was easier to video at 50fps to get enough frames to work from.

still1

still2

still3

This latency of 181-215ms is substantially worse than the 60ms latency between head movement & resultant VR changes being displayed that is often quoted as the upper limit for an acceptable VR experience. This increased camera latency compared to the tracker-to-VR latency (quoted as typically being 30-60ms for applications running at 60fps on the Rift DK1, same link) will probably arise in experimental results when users actually try out the platform.

sallies

I’ve mapped St Salvator’s Chapel using IndoorAtlas. We plan to use this site for our case studies as it fits with one of my research group’s interests, cultural heritage, whilst also providing a good example of where mobile cross reality is useful. I wasn’t expecting IndoorAtlas to work well in this building, as it doesn’t have a metal frame, but I was pleasantly surprised. Perhaps the addition of central heating & electricity later in the building’s history helped?

diagram

Other than that, I’ve been focussing on theoretical work & designing experiments – after all, the platform is no good without evaluation!