RaceRoom Racing Oculus DK2 and Simracing

I really can't understand your posts...

This is a post I made to silent hill just then:
"Hi Craig, i did some more testing and there's a problem. Originally I was using a simple test program instead of a computer game, but ran into problems running it with a real game. The issue is that oculus only release the source to their SDK and not their drivers. This means you would have to integrate my changes into every game you wanted to play. This is of course not possible because no game developer will do this for you. You can't even replace a modified game dell file because the oculus sdk is directly integrated into the game exe file.

I read on the oculus forums that Oculus will not be releasing the source for the drivers (this would allow us to support all games without modification). There are some people on the boards rallying Palmer lucky to support motion platforms but this is a very low priority issue for them and they don't seem to be interested.

Sorry to get your hopes up, I gave it my best shot. I ended up selling my dk2 because I was so disappointed.
John"

I'm still using my DK2 - works OK with motion for most sim games - although large changes in surge have me moving toward or away from the virtual steering wheel. From my experiments, vibration is the killer of camera tracking for Oculus and motion sims. Which is why it is better to have the camera mounted off the rig. I've although have had some success with dampening the vibrations for an on Rig camera (not able to implement all required changes to current SIM). Currently building another Sim with these design ideas included.

Oculus is so hackable it's almost a joke. Their are MANY ways to augment the sensor data.

For starters, no positional processing takes place in their drivers. It's all user mode in their service, you can attach and mod at will w/o futzing around with driver signing.

Second, sensor data is sent by HID. You can attach anything that talks HID and lie to it. Arduino Micro comes to mind.

Third, you don't even have to lie. You can attach anything that gets you HID data and write to the same pipe their drivers use had someone actually plugged in the Rift's USB cable.

You don't even need an additional IMU (although it makes it easy, simple matrix math). You can take the data right from your POTs.

Also, the firmware is software updateable and has plenty of free space. The CPU is a STM32F103xx, if you have IDA and understand ARM, you can mod the firmware to do sensor fusion between multiple IMUs w/o any extra stuff. Never done that myself, but it's there. It's not encrypted, only has a simple header before the interrupt vectors.

Anyway, have a look at their service exe. About 80% of it deals with the camera and display, stuff you won't need to mess with. Only a small portion deals with the IMU, and it gets all its data from a pretty central location. You can spoof an event to make it close and re-open the device, which means you can change at will where it's getting it's data with a simple call to writeprocessmemory.

Seriously, it's a million times easier than all the stuff you guys do to get games working on your sims.

Cool so you gonna make some kinda mod so it offsets the movement for us all ???


Sounds easy peezy !

The seat for my sim doesn't arrive until after new years (one of the last things I needed), so I have to do this for myself at some point anyway.

I was originally going to just augment and emulate the Rift's USB HID, but after seeing these messages and giving a look at the actual drivers (and then the service exe), it occurs to me that's a far superior approach.

The goal, of course, is to get at it in a way that doesn't change from one version to the next (seldom do manufactures change internal names of things like named events, pipes, driver interface guids, etc.). It looks to be simple to force the service to rescan and actually find something it wasn't actually looking for and be happy. From there, everything else would operate as normal, just that the data it's processing is a bit different than what the HMD alone is providing.

At a slightly less desirable location, there are routines that calculate the orientation of the eyes and neck, scale, etc., all as C++ functions. These are far more likely to change, but might stick around for many small revisions.

I have some spare IMUs and arduinos, and holiday time off work, I'll give it a go.

@Kirk that would be cool if you try. I would love to be able to but have no idea how these things work.

Good luck

I'm here for any kind of support!

I finally received my racing seat / bolts / harness a couple days ago, the originals were lost by the mailman. Fortunately, Amazon replaced for free (sent by fedex). It's the first time I've ever had the post office screw things up that badly.

I have no progress to report, unfortunately.

That said, there isn't anything proprietary in the rift. The IMU in the rift is directly exposed, as is the camera data. You could wrap it in open sourced code, at the expense of sacrificing compatibility with the plethora of software that is already "rift aware" (although it could probably also be done in a way that you can keep the best of both worlds, and you could also shim a "fake" rift to look like a real one the same way).

It's not like TrackIR where the company went out of their way to ensure you were using the product as intended.

Anyway, I hope to get a chance to look at if further soon.

interesting stuff, never thought the rift would have problems on a motion platform.. I hope this is going to work out, because my triple head setup is aging..

I wonder what effect it presence with Oculus and you can to link it with sim?

Can I use the Oculus with Dirt 3 ?

Very nice . So the PROJECT CARS on mi experince is so bad to much lag..and the game is running on good FPS I don't now whats the problem.