Looking “Into” Dream with the Oculus Rift

With the Dream Rift Prototype release just around the corner, I thought I would write a short section about the process of porting Dream over to the Rift.

As we have said many times, most features in Dream were developed with the Rift in mind; we want to create a truly immersive exploration game, and when the rift was announced it was clearly a no-brainer.

The Wait

I know a lot of you have been waiting an awfully long time to experience Dream in the rift. The main reason on why the release is so late was purely because of the engine we use and its compatibility with the Rift.

Oculus released a version of OUDK (Oculus UDK) just a few months after the launch of their SDK. This version that they released was purely an alpha state. It was very broken and not feasible to release Dream on this version and main features that were needed did not work.

The engine had issues with Scaleform, SpeedTree and Bink. For those of you that don’t know; Scaleform is used for all the menus and the in-game PC in Dream. SpeedTree is used to create some of the foliage in Dream, and with the Garden Side Dream using SpeedTree quite a bit, the experience in the Garden with the Rift would be dramaticly reduced and overall feel less immersive. Bink is used for the loading screens and splash intros; which actually wouldn’t have been that big of an issue. Whilst these were the main issues there were also the following bugs which made developing & releasing the Rift version at the time a bad idea;

-Control about Additive Oculus rotation (to enable cockpit like support) for “pitch and roll”
-No way to disable tracking (for testing purpose)
-No changing camera “scale”
-No attaching the Camera to a socket (possible today via external unrealscript coding)
-Impossible to change fov
-Unable to use rift in Editor (play in editor) instead of “play this game on pc”
-Lighting and Materials would swap LOD’s between Rift and Normal mode
-Unable to have oculus info on overlay in realtime. (rotations,absolute rotation, fov, ipd etc…)
-No chromatic aberration

Then tragic struck over at Oculus, when they lost their Co-Founder/Engineer in an accident.

Andrew Scott Reisse was also developing the OUDK.

Now, with the addition of John Carmack, the OUDK has come along way. It has been built from the ground up and a new version got released not to long ago. Whilst this version fixes many many bugs, it still also contains a few such as;

-Not being able to attach cameras to sockets
-Ability to control the Additive Oculus Rotation.
-Temporarily disabled planar reflection shadows in stereo until they are properly fixed.
-Captured scenes render-to-texture doesn’t render correctly with screenpercentage > 100, plus, HMD warp shader is applied to it, but shouldn’t (this is already fixed, but didn’t make to RC2)
-Dynamic shadows are rendered in one eye only (left) (FoliageMap) (This has issues with things such as mirrors)
-Incorrect viewport size in ‘cinema’ mode in stereo
-Changing resolution in stereo to greater than nominal 1280×800 and with screenpercentage > 100 might cause screen corruption

Overall, its good enough to be released! So onto porting.

Porting Over

Porting Dream over was relatively easy. We played around with the settings that are on the Dream build now, got peoples opinions (laughed at them nearly vomiting at there first ever Rift experience) and found out that removing the DOF and Lens Flare was a great start. It feels more natural on the eyes. The aim is to provide the best immersion experience; so removing these were natural decisions.

The next obvious thing was that the menu’s and inventory system were not greatly visible. After changing the ZDepth of the menu’s it was still clear that they had to be redone slightly. Moving them back just made them harder to see because of the resolution on the Developers Rift and most of the menu was being clipped of the sides of the screen as you can see in the image below. To fix this for the rift version I just moved the menu’s to the right a bit and made sure all the elements were visible. Notice how the Credits button was not even in view.

Rift_MenuView

Next issue to deal with are the camera’s the Dream uses. We have a few different ones set up for different uses, such as in front of the PC to zoom into, Menu’s and the Hallucination Maze. Now as this OUDK engine still doesn’t support Additive movement, there is no way to let the hallucination maze spin around like it does whilst being on your head; so for now this part has been removed. The other camera’s were not an issue really, just had to change a single line of code to unlock the aspect ratio to avoid stretching and clipping.

Great, everything seemed to be looking good, however as a player you feel a little small.
This got fixed by makign the eyehieght of the player taller at the beginning of the level. This is a quick trick that will supplement for now untill Howard makes it into the rift build. However it is causing a little problem making interacting with small items an issue. It simply moves the camera up but the player’s eyes are actually below the camera. This can mess up the look at system slightly. Right now it only happens in one area, but ill be posting a guide on that when the rift is released. I’ll go into this issue in more depth below.

Look at system

Our look-at system is fantastic. Sam built some Kismet Nodes which track what the player is looking at, makes the item glow and enables the user to interact with it. It works perfectly in the non Rift build but there are some small issues with the Rift version. This look at system doesn’t actually track if the player is looking at the mesh, but checks to see if the player is looking at the mesh’s collision. This is beneficial in many ways, one of which being we can set up custom collision in case we want a player to only be looking at a certain part of the mesh.

This is where the issue comes in. Meshes with small collision seem to be throwing up errors in OUDK. I think the reason is because of the way it renders. As it renders 2 images it seems to go for the average where the collision overlays. This in addition to the increased player height means you have to look above the collision slightly too. The image below should explain more. Big items don’t really have an issue as there is a lot of surface area to look at. The image below shows the collision around a small object.
Collision_View
Now if we take the Viewing Area for each eye and overlap them you can see the collision below;

Collision_View_Player

It seems to behave as though only the overlapping parts are collision, reducing the area size. Adding this to the eye height explains the Viewing image (2 images above) saying Interact for the locks whilst looking above them.

This system will be improved once the Engine allows Camera Socket’s for the Rift, letting us add the Howard Mesh and keep the camera on his eyes rather than increasing the height of the camera. As for the collision detection it’s something we will have to look at. Fortunately as I said this only seems to be an issue here and now we know this we can keep the issue in mind.

Overall, it’s ready to go and I cant wait for you to experience and help us shape the game. We’re unsure when the next OUDK will be released but if it fixes and adds support for the Dream Rift Bugs we will be sure to update.

Thanks for reading!

-Ash