Minimal Hardware for a Portable Rift

[geekmaster]

I have a number of posts in various threads discussing the idea of using a low-power computer to drive an Oculus Rift. I am most interested in any computer that can be used in portable applications, providing a small and lightweight portable standalone Rift-based system.

Most importantly, I want to explore the limits of what kind of VR experiences can be provided using such hardware. One such computer that quickly comes to mind is the Raspberry Pi, because it comes with HDMI video out, and has OpenGL ES support built-in. It can run Linux, and it can run apps based on SDL, Ogre, and OgreKit (gamekit). It can also run Doom (and more).

Here are some quotes from other threads (to gather them into one place):

Regarding my thoughts about using the Raspberry Pi as a portable gaming device to be used with an Oculus Rift, here is an example of a RasPi app that I would like to port to the Rift:

http://store.raspberrypi.com/projects/openarena







This needs to be head-tracked and pre-warped for the Rift. If the RasPi can do this in stereoscopic 3D too, all the better!

Remember that by uncoupling head tracking from rendering, we can still have (a portion of) the view track our head rotation quickly, keeping us immersively anchored in the VR reference frame, even while the game world around us updates at a slower pace. That requires rendering a larger FoV than our HMD can see, so we have some margin to look into when we move our heads a little in and out of the visible margins.

But hey, this game for the RasPi shows that we can do more with it as a Rift gaming device than just simple "90's era" VR games.


And because most 7-inch tablet PCs are MUCH more powerful than a RasPi, something like this should be a "piece of cake" for a Fov2Go-style HMD add-on for a tablet PC.

And here is Pi3D, a 3D Python graphics & resources app for the Rasberry Pi:
http://store.raspberrypi.com/projects/skillmanmedia

Pi3D source code:
https://github.com/tipam/pi3d







With the source code, we can add Rift (and Rift-like clone) support to Pi3D.

EDIT: I found a configuration script for the RasPi that makes it display the desktop in SBS-Half format, which might work okay with the Rift, or with a tablet based HMD (after pre-warp is added).

I will pull more quotes over here from other threads as I find them.

For now, you may find more "RasPi" related content in the "PTZ Tweening" thread.

[geekmaster]

Feel free to add discussions about low-power portable computers (and applications for them) to this thread.

I hope we can provide a fairly rich and interesting VR experience even with low-powered computing hardware.

Some of these apps may also work on older consumer desktop PCs...

[cybereality]

There's always the option of having a gaming laptop in a back-pack (backtop).

[geekmaster]

There's always the option of having a gaming laptop in a back-pack (backtop).

There are already threads for that. "Backtops" are certainly an option, but such gaming laptops are not low power (compared to a RasPi), nor are they "minimal" (the topic of this thread). They can be quite affordable though, especially if you buy one with a broken screen off eBay. And they can run much richer apps than a Raspberry Pi.

But the main goal of this thread is to gather resources for an inexpensive experience using the Rift, that does not require purchasing expensive new computer hardware. However, even a RasPi can get expensive when you start adding on the various options available for it.

The main thing I plan to explore in this thread is just how rich an experience we CAN provide with a Rift, a Rasberry Pi, and perhaps a Razer Hydra (if we can get ARM linux drivers for it). I may add an Arduino or other embedded processor to the mix to provide more add-ons such as IMU/GPS/FPV accessories, and whatever else looks like fun...

I am much more of a "maker/developer" than a "player/gamer", which will cast a development-oriented flavor into my posts. But feel free to discuss more gaming-oriented issues too, if that is what interests you...

[sth]

In theory, any linux-powered device that supports at least OpenGL ES 2.0 (because of the warp shader) should be able to support the Rift.
In practice, there might be some software limitations at first (mainly availability of the Oculus SDK on the platform and hardware architecture).

The Raspberry Pi seems to have a very decent GPU from what I've read, but the CPU is an ancient (by mobile tech standards) single ARM11 core. That will probably be much more limiting than the GPU side of things (current mobile GPUs are very capable).


[edit]: There seem to be quite a few unknowns to RaspPi graphics performance. There are bold claims about it's theoretical performance ("faster than Tegra 2", "faster than PowerVR SGX543MP2") but most of the videos show pretty lackluster performance in Quake 3 – sometimes even running at resolutions as low as 640x480. Hopefully it's just a driver thing, but maybe it's CPU-limited (which would pretty much rule out using the Rift with it in any usable way).
On the other hand, even the original iPad was able to sustain playable framerates in Quake 3 at 1024x768, and that device really had a crappy GPU (PowerVR SGX535) by todays standards and compared to what the RaspPi is supposed to be capable of on the graphics side.

[geekmaster]

Based on previous experience with 8 and 16-bit computers decades ago, we may be able to do warping in software with some careful code optimizations, but that would burn CPU power that could be used to drive the game (especially things like game AI), so better to use a GPU when available. I want to explore both GPU and non-GPU options for pre-warp and other filters. I also want to play with procedural textures, on the theory that modern multi-layer cached processors are fast enough that computation can be faster than table lookups. I am not sure how that applies to the RasPi though, because I do not yet have a RasPi.

I also plan to explore using my Nexus 7 for portable HMD use, but it does not have HDMI out, so it will be more suited for a "Fov2Go" type of HMD. Because this thread is for portable Rift accessories, I plan to explore Nexus 7 VR in a different (perhaps dedicated) thread (but that thread should probably go in the "VR/AR Research & Development" forum rather than this Rift-specific forum).

[geekmaster]

While looking to see if the Raspberry Pi has any Razer Hydra support, I just discovered that this dude called "grandmaster" has similar ideas to what I said about this topic:
http://www.grandmaster.nu/blog/?p=598

The toys – an Oculus Rift, Razer Hydra and Raspberry Pi. I’m still thinking about a mobile power solution, but the Raspberry actually works on a couple of AA batteries. The Hydra actually generates a magnetic field around 2m in size, and I have no clue how much power the Rift requires, but I’m hoping to make a fully mobile immersive VR solution.

It appears that "geekmaster" and "grandmaster" think alike regarding the Rift, the Rasberry Pi, and the Razer Hydra. Cool!

EDIT: In fact, we even have similar "blog" names (but I never got around to adding useful content to mine).
Geekmaster's Playground (January 16, 2012):
http://wiki.mobileread.com/wiki/Geekmaster's_Playground
GrandMaster's Playground (January 16, 2010):
http://www.grandmaster.nu/blog/

But today is the first day I was aware of grandmaster. "Great" minds think alike?

I see that grandmaster has been working on his own "game engine". That could be useful here:
Part 1: http://www.grandmaster.nu/blog/?page_id=118
Part 2: http://www.grandmaster.nu/blog/?page_id=158
Part 3: http://www.grandmaster.nu/blog/?page_id=191
Part 4: http://www.grandmaster.nu/blog/?page_id=261
Part 5: http://www.grandmaster.nu/blog/?page_id=434
Part 6: http://www.grandmaster.nu/blog/?page_id=570
Part 7: http://www.grandmaster.nu/blog/?page_id=609

[Drewbdoo]

Geek, just wanted to let you know that I'm facinated with this idea. When I first started hearing about the rift and my mind started blowing up with ideas, one of them was some type of incorporated computing in/on the rift. I thought, hmm, what else could we squeeze in that control box, for example. How about a the guts of a full android phone, for one implimentation, where the rift operates as it does now when connected to a pc but can also break off and play its own, lighter games. The raspberry pi idea is even cooler and smaller, though lighter on the horsepower. Where you're on the maker side, I'm definitely more on the end-user gamer side, but I'm trying to learn more code and delve in on the software side of things.

Though, back to the hardware side of things - Is your end goal something like what I'm kinda thinking about above - i.e. Pi+Rift+battery = disconnected from everything?

[geekmaster]

Though, back to the hardware side of things - Is your end goal something like what I'm kinda thinking about above - i.e. Pi+Rift+battery = disconnected from everything?

I already answered that, and the answer was "Yes!"...

I want a standalone portable experience using a Rift and a low-power computer. One option I plan to explore when more processing power is needed (mentioned in another thread and not yet quoted in the first post), is to use the RasPi as a head-tracking and pre-warp processor, and to use a smartphone or tablet PC (such as my Nexus 7 with Tegra 3 processor) to do more of the game rendering, asset management, and AI support.

Essentially, the video processing pipeline would be Smartphone/Tablet ==> Raspberry Pi ==> Oculus Rift.

We could use the built-in batteries in the devices that have them, continuously charged from a battery packs that are belt-mount and/or vest mount. The portable battery packs would also power devices that do not have their own batteries, such as the Oculus Rift controller.

[cybereality]

@geekmaster: Thanks for posting that grandmaster dude's blog. Some interesting stuff related to creating a game engine.

Also, not to be a downer but how do you expect to stay mobile while wearing the Rift? I mean, it blocks out all your vision.

[geekmaster]

@geekmaster: Thanks for posting that grandmaster dude's blog. Some interesting stuff related to creating a game engine.

Also, not to be a downer but how do you expect to stay mobile while wearing the Rift? I mean, it blocks out all your vision.

Planes, Trains & Automobiles:



Or just sitting in the park...

[GeraldT]

Or just sitting in the park...

Rift_outdoors.png

I should not even think of doing that myself ... red, white, brown would make me look really weird ^^

[geekmaster]

Subject: Minimal Hardware for a Portable Rift

Or just sitting in the park...

Rift_outdoors.png

I should not even think of doing that myself ... red, white, brown would make me look really weird ^^

Nice "Farmer's Tan" going on there, Palmer!

[Dycus]

People are gonna be getting "Rift tans" soon enough if you start using it outside...

[geekmaster]

After reading a bit more of the "GrandMaster's Playground" blog, I see that he decided to go with the more powerful "Hackberry" clone:
https://www.miniand.com/products/Hackbe ... er%20Board



Besides a faster processor and more RAM, it has other space-saving built-in peripherals that are costly add-ons for the Raspberry Pi (and take up more space when plugged into the Pi). The Hackberry costs not that much more than than the Pi ($65USD, a great deal for what you get), but then they slap you with another $20 for shipping. When shipping from Australia, they must not get government subsidized shipping like all the cheap crap you can get from China with free shipping included. Oh well... Gotta have it anyway...

I may just get a "Real" RasPi too, so I have baseline hardware on which to test my code.

[crespo80]

You can even consider to use the board from an OUYA, its tegra3 SoC is much more supported for gaming applications, and the overall dimensions are comparable (without the external case).

[geekmaster]

You can even consider to use the board from an OUYA, its tegra3 SoC is much more supported for gaming applications, and the overall dimensions are comparable (without the external case).

The Ouya costs a bit more, but looks quite portable if you take it out of that rather non-portable case. And the extra cost can be justified for all the games it is supposed to support. But how many of those games will support the Oculus Rift?

Like the Pi and Hackberry, the Ouya will certainly make a fine platform for the Rift-compatible games and other VR apps that WE make for it! Some of us are "makers", after all!

[Pingles]

The first time someone went to a Trade show with a Rift and Ouya combination I think we'd see quite a few programmers start to support it.

[geekmaster]

The first time someone went to a Trade show with a Rift and Ouya combination I think we'd see quite a few programmers start to support it.

Are you telling me I need to order a Ouya now too?


I would need to find a good battery pack for it, but that should not be too difficult.

[GeraldT]

crespo has a very good point there - and if it has enough power, then I can see a lot of Rift titles coming for it (at least if Unity is efficient enough). For me it would be just adding an Android option to my Unity (okay ... that just is 1500$ ... but still, in theory it should be simple).

EDIT ... hmmm, now that this is out in the open... if that works, I can totally see myself gaming with the Rift on the balcony in summer and getting one of those Rift tans

[STRZ]

The Intel NUC boards with HD4000 GPU and ULV CPU are interesting for Linux, due to the open source GPU drivers, openGL ES 3.0 Linux support for the GPU and the prospect of Intel attacking the mobile space bigtime in the coming years with their CPU/GPU SoC's. Should be a nice "devkit".

http://www.intel.com/content/www/us/en/ ... 17iye.html

[Sadhu]

I was thinking about going with BeagleBone board.

[MSat]

I think this is a really cool idea. I had overlooked this thread until geekmaster brought it to my attention when I started babbling about the same idea in another one. I'm going to repeat some of what I said elsewhere since this is the more appropriate thread for the discussion.

First off, I'd like to mention that there are some other single board computers besides the RasPi or Ouya that may be good candidates. Just do a google search for "Android stick" and you'll find a ton of Android devices from $30 and up using ARM SoCs ranging from single core Cortext-A5 to multi-core A9s with Mali GPUs. Another thing that shouldn't be overlooked are phones.

What I would really like to see is a gun (rifle) controller that contains the computer, batteries, buttons/joysticks and 3DoF motion tracking, so all you have is the controller and the Rift. A capable phone with HDMI-out has the benefit of having motion sensors built in, USB OTG for connecting to the Rift's head tracker, bluetooth for interfacing to the controller inputs, and WIFI for possible networking (to allow for deathmatching ). Quake3 (and obviously 1 and 2) should be possible on any device with a Cortex-A5 and up.

If the headtracker is still HID compliant (and even better if they also provide the algorithms in libraries instead of DLLs) like it was before nrp joined Oculus, then the community would be able to help port it to other OSes fairly easily.

[mattyeatsmatts]

By the rate those mini android pcs are coming along and advancing I would think this could be possible in the very near future. also would like to see some sort of emulator support so i can relive my childhood and get fully immersed in my games like i did when i was young and had a strong imagination

[STRZ]

What I would really like to see is a gun (rifle) controller that contains the computer, batteries, buttons/joysticks and 3DoF motion tracking, so all you have is the controller and the Rift. A capable phone with HDMI-out has the benefit of having motion sensors built in, USB OTG for connecting to the Rift's head tracker, bluetooth for interfacing to the controller inputs, and WIFI for possible networking (to allow for deathmatching ). Quake3 (and obviously 1 and 2) should be possible on any device with a Cortex-A5 and up.

You'd need a display cable from the gun controller including the phone/computer to the Rift controller box. But it's still a good idea if the cable is long enough and has enough play.

[MSat]

What I would really like to see is a gun (rifle) controller that contains the computer, batteries, buttons/joysticks and 3DoF motion tracking, so all you have is the controller and the Rift. A capable phone with HDMI-out has the benefit of having motion sensors built in, USB OTG for connecting to the Rift's head tracker, bluetooth for interfacing to the controller inputs, and WIFI for possible networking (to allow for deathmatching ). Quake3 (and obviously 1 and 2) should be possible on any device with a Cortex-A5 and up.

You'd need a display cable from the gun controller including the phone/computer to the Rift controller box. But it's still a good idea if the cable is long enough and has enough play.

I figured just velcro the interface box to the gun. The cable that goes from the box to the Rift is more than long enough - even too long perhaps, so it would need to be coiled up.

[STRZ]

What I would really like to see is a gun (rifle) controller that contains the computer, batteries, buttons/joysticks and 3DoF motion tracking, so all you have is the controller and the Rift. A capable phone with HDMI-out has the benefit of having motion sensors built in, USB OTG for connecting to the Rift's head tracker, bluetooth for interfacing to the controller inputs, and WIFI for possible networking (to allow for deathmatching ). Quake3 (and obviously 1 and 2) should be possible on any device with a Cortex-A5 and up.

You'd need a display cable from the gun controller including the phone/computer to the Rift controller box. But it's still a good idea if the cable is long enough and has enough play.

I figured just velcro the interface box to the gun. The cable that goes from the box to the Rift is more than long enough - even too long perhaps, so it would need to be coiled up.

This could work for a gun. Whoa, the idea with the phone inside a controller just made my day, solved a lot of headaches for the prototype of my "game" project

[grandmaster789]

Seems as though you found my blog, hope you guys like it ^_^

The game engine project has been going on for a while, updates are very irregular but I'm still working on it. I'm trying to use openGL ES as a target so that it'll work on mobile hardware. The graphics quality will probably end up nowhere near well-known engines such as Unity/Unreal/Crysis and such, but that's to be expected from a one-man effort. I'm treating it as an educational experience

Some more thoughts I've had on the mobile Rift setup - it's pretty much essential to achieve 60hz graphics updates to prevent simulator sickness (similar to car/sea sickness) and I'm not really confident that my little raspberry can provide that kind of performance. Also, due to the absence of sensors on the users' legs the most convincing usage scenario's should match the users' expectation - don't walk, but fly instead.

[geekmaster]

Seems as though you found my blog, hope you guys like it ^_^

The game engine project has been going on for a while, updates are very irregular but I'm still working on it. I'm trying to use openGL ES as a target so that it'll work on mobile hardware. The graphics quality will probably end up nowhere near well-known engines such as Unity/Unreal/Crysis and such, but that's to be expected from a one-man effort. I'm treating it as an educational experience

Some more thoughts I've had on the mobile Rift setup - it's pretty much essential to achieve 60hz graphics updates to prevent simulator sickness (similar to car/sea sickness) and I'm not really confident that my little raspberry can provide that kind of performance. Also, due to the absence of sensors on the users' legs the most convincing usage scenario's should match the users' expectation - don't walk, but fly instead.

I noticed at your blog that you went with a Hackberry. I have one in my shopping cart, but I did not "pull the trigger" on that purchase just yet.

The Hackberry does look like a nice step up from the basic RPi. Does the Hackberry have enough power for your needs?

I still like pushing small hardware beyond what many believe to be possible, by "programming on the bare metal" (or as close as possible) where you have absolute and total control. A good step in the right direction for low level graphics is to use the SDL library for portability, or framebuffer and event device interfaces if it is linux based. But for even smaller embedded devices, talking directly to the device I/O registers may even be required.

So for me, probably Hackberry AND RPi...

[MSat]

The only bummer about coding to the metal is that you're limited to the CPU as the GPU instruction set is not available, which is a total shame. I had though ARM might release it for their Mali GPUs, but I guess that was expecting too much.

We'll probably have better luck on that front once intel starts using their own graphics GPUs on their SoCs, as they have made it available for their CPUs with integrated HD graphics.

It'll probably be a little while before mobile VR takes off. In the mean time, I'd be happy with a couple of ports from older games.

[Sadhu]

There is an open source reverse engineered driver for Mali GPU called Lima and it is starting to look usable. There were some talks by developers during this years FOSSDEM:
https://fosdem.org/2013/schedule/event/ ... n_arm_gpu/
https://fosdem.org/2013/schedule/event/maliisa/

[geekmaster]

The only bummer about coding to the metal is that you're limited to the CPU as the GPU instruction set is not available, which is a total shame. I had though ARM might release it for their Mali GPUs, but I guess that was expecting too much.

We'll probably have better luck on that front once intel starts using their own graphics GPUs on their SoCs, as they have made it available for their CPUs with integrated HD graphics.

It'll probably be a little while before mobile VR takes off. In the mean time, I'd be happy with a couple of ports from older games.

I "program to the bare metal" only when I need the extra speed, and capabilities supported by the chipset that the device driver writers never got around to supporting...

I use higher level libraries when I trust them to provide sufficient speed and reliability, but I prefer them to be MINIMAL, so they do not hold me back. In the case of the SDL library, it gives me portable cross-platform graphics framebuffer support even on devices that may have a user-accessible framebuffer device. Although I often process raw data directly from linux input event devices, I plan to use FreePIE for my Rift apps, because I do not wish to waste my time digging into the low-level details of such a large variety of 3D input devices, when a perfectly adequate software tool is at hand and up to the task I need. However, for head tracking fusion with other input devices, I may want to "roll my own" using the raw data that the Oculus IMU will reportedly provide. This way, I can experiment with different fusion algorithms, and perhaps "fuse" the best of several of them.

I absolutely LOVE finding the ORIGINAL research papers BEHIND the great libraries and algorithms inside them, and then to implement my own from scratch using nothing but the "calculus laden" research papers. Not only is this educational, but I can explore the nooks and crannies in the original research that the authors may not have thought worth their attention. Sometimes great unexpected surprises may be hiding right around the corner behind the research, lurking there undiscovered for many decades. I have a huge collection of research papers and technical Phd thesis papers, and I reference them in my source code when I use information obtained from them. What is great about this, is that this basic research is often free and open, while later refinements are locked down by patent trolls.

Software is capable of much more graphics performance than many people realize, if you just go back to the software tricks of the past, when most 8-bit computers did not even have multiply or divide instructions. To get REAL speed though, you need to stay aware of multi-level CPU cache, and try to program "cache-oblivious algorithms" so your code can take advantage of vintage/modern/future hardware without skipping a beat. But I plan to add GPU support too, when it is an important part of the device (such as in a Raspberry Pi). If it is there, it is begging to be explored, especially if it can add to the "Wow!" factor.

I am looking forward to Quake and Doom in fully immersive VR. The Descent series would be nice too, or at least a simulacrum of them. And of course, somebody needs to port MAME to a virtual arcade simulation for the Rift.

[geekmaster]

There is an open source reverse engineered driver for Mali GPU called Lima and it is starting to look usable. There were some talks by developers during this years FOSSDEM:
https://fosdem.org/2013/schedule/event/ ... n_arm_gpu/
https://fosdem.org/2013/schedule/event/maliisa/

That looks interesting. What affordable and readily available hardware contains these Mali GPU devices?

[Moriarty]

I've read somewhere in an interview with the Ouya CEO that they are planning a very agressive annual update cycle of the hardware, which seems a bit strange and risky for a console. But if that's the case and they keep up with the pace of the smarthphone industry then that little console could quickly become interesting for all kinds of other applications.Ouya2 with the same Tegra 4 as Project Shield would already be a big improvement :

[MSat]

I was aware of the Mali reverse-engineering efforts, so I guess we'll see where it leads - if anywhere. Far too often do projects get abandoned before completion. Another problem may arise if ARM redesigns future Mali GPUs to the point where they have to be reverse-engineered all over again. Ideally, the information would be provided in an official capacity by ARM themselves.


@Geekmaster

Quite a few manufacturers are using Mali GPUs. I believe Rockchip and Allwinner - the brands used in most of the cheap Android sticks do. I'm guessing these chips are essentially ARM reference designs that require minimal design effort on their part.

For the most part though, I think the Linux kernel and the GPU drivers that come with these modern devices should be sufficient for most uses.

[geekmaster]

For the most part though, I think the Linux kernel and the GPU drivers that come with these modern devices should be sufficient for most uses.

"Sufficient" is always a good place to start. Enhancements can be added later, by optimizing at a lower level only when required (provided that the higher levels do not add too much complexity or inefficiency).

When it comes to computer hardware though, some of us like to go down deep into that rabbit hole, just to see where it leads, and how close we can get to the "bare metal". I am one of those people. A healthy team requires people at both ends of the spectrum, high level artists and "bare metal blacksmiths".

[Pingles]

I've read somewhere in an interview with the Ouya CEO that they are planning a very agressive annual update cycle of the hardware, which seems a bit strange and risky for a console. But if that's the case and they keep up with the pace of the smarthphone industry then that little console could quickly become interesting for all kinds of other applications.Ouya2 with the same Tegra 4 as Project Shield would already be a big improvement :

This schedule would also allow them to update hardware to be compatible with different accessories...like perhaps the Oculus Rift.

If they teamed a $99 console with the Rift I think they could have a pretty sweet revolution on their hands.

It would likely negatively impact the PC crowd but it could bring it to a pretty humongous market.

[MSat]

@DrZimmerman

There should be minimal risk in terms of older games running on newer versions of the Ouya. The biggest problem may be when game developers specifically target a new device to the point where it either runs like crap or not at all on older units. I think Ouya will be pushing consumers as much as possible to follow along with their yearly updates, which isn't too unreasonable since the console is quite cheap.

Actually, I wouldn't be surprised to see MS and Sony also go down the path of more frequent refresh cycles given that they're utilizing standard-ish CPUs/GPUs that can be updated far more often without breaking compatibility. Games could take advantage of a newer console's graphical capabilities which could be disabled on an older device. In fact, MS and Sony might actually need to do this or else a future $100 Ouya with a Tegra5 or 6 might end up being more powerful than then next gen PS and XBox.

[rick2718]

A minimal VR hardware platform for the Rift (and other VR headsets on the way) is what we have been working on
for a while now. We're using an arm7 and Broadcom videocore 4 in our smallest device, which is very
similar to the pi. We've got a 700,000 facet scene (a setting from a recent action movie) displayed
in stereo, with head tracking, body position tracking, and a hand-held joystick running at 60fps.

it is pretty impressive how powerful "low end" hardware is these days.
You can plug in a USB containing a 3D world in various formats, and walk through it
for almost 4 hours with the battery we're using... and the whole thing is on a belt.



rick
rick@LucidityVR.com

[phlebas]

hi,

this might not be exactly in the "minimal" category, but seems interesting based on power-consumption/price/horsepower specs :
http://www.nvidia.com/object/jetson-tk1 ... v-kit.html

much more then Raspberry Pi, but also higher specs, and very reasonable power consumption compared to calculating power (at least on paper)

(planning to get one in near future to try out, mainly for visual odometry, but probably will test some 3d stuff too