Game Development Community

dev|Pro Game Development Curriculum

Torque 3D and Oculus Rift (A Tale in Pictures)

by Dave Wyand · 03/25/2013 (1:36 pm) · 33 comments







Torque 3D and Oculus Rift (A Tale in Pictures)

Back on September 20, 2012, we launched the MIT licensed version of Torque 3D on GitHub. Next on December 19, 2012, we launched the first new release under open source, version 2.0. Then on January 10, 2013, the T3D Steering Committee announced the roadmap for version 3.0. Within this roadmap was improved support for various input devices to take advantage of current and future controllers that are entering the PC market.

The first new input device was the Leap Motion with support added to the development branch as announced in my blog on January 24, 2013. the second new input device was the Razer Hydra, whose support was also added to the development branch as announced in my blog on February 22, 2013.

On the heels of these two devices, I am pleased to announce that I have been working on a third device but have not been allowed to talk about it until now. It is the Oculus Rift, a head mounted display and tracking system. Some of you may be aware of the Kickstarter project that allowed the Rift to become a reality, and I know there are community members that were part of that Kickstarter (myself included).

Thanks to the fine folks at Oculus VR I was able to procure a preview version of the Rift and have been modifying Torque 3D to work with it. I'm not yet ready to merge my work into the development branch but I did want to share with you all my progress. So let's get started!


The Story Begins...

Back in February, 2013, this happened:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-RiftAwe.jpg

Trying out the preview version of the Oculus Rift for the first time. It works even better when plugged in. With apologies to notch and crew


And then I tried this:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-FakeStereoRendering.jpg

Fake stereo rendering by starting with the normal screen, taking a vertical slice, and pasting with an offset for each eye. Works remarkably well and will likely remain as a fallback for underperforming systems.


Using the included Oculus VR SDK documentation, I was then able to get this:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-FakeStereoWithDistortion.jpg

The same fake stereo rendering but with the proper barrel distortion applied for the Rift.


After doing some work to make Torque 3D support true stereo rendering and the Rift's projection offset, I ended up with this:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-TrueStereoWithDistortion.jpg

True stereo rendering. Advanced lighting shadows are calculated once, with left and right views being rendered separately.


Torque 3D's graphics pipeline was not originally intended for stereo rendering so I ended up with errors like this:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-ShadowErrors.jpg

Sun shadows did not like the required projection offset.


And errors like this:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-LightErrors.jpg

Spot and point lights were being cleared after the left eye was rendered.


Fortunately, I was able to solve these issues:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-StereoBanking.jpg

Correct shadows and lights. Full head tracking, including support for bank/roll with the standard Player class. I will also be adding full head tracking to the Camera class.


And with the Rift, it looks something like this:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-RiftStack.jpg

Top: View in Rift without the lenses. Middle: The lenses attached. Bottom: The view through the right Rift lens with my testing Torque 3D level.


When I merge my changes into the development branch we will also include a demo to showcase Torque 3D and the Oculus Rift:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-DemoLevel2.jpg

Torque 3D demo level for the Oculus Rift. Completely original art created by our very own Ron Kapaun. Way to go, Ron!


We may also have a surprise or two for those that have been following my previous blogs:

www.gnometech.com/torque/images/blog-2013-03-25/2013-03-25-RiftAndHydra.jpg

A VR world with one gun in each hand? OMGWTFBBQ!


The journey continues...

- Dave

Page «Previous 1 2
#1
03/25/2013 (2:21 pm)
Quote:
Top Photo: 2013-03-25-RiftAwe.jpg

Can't tell if that is the look of awe or a developer sleeping standing up - I hear crunch does that to you. ;)

Cool stuff, Dave. Though after looking at all of those screenshots I now have double vision! :P
#2
03/25/2013 (3:01 pm)
This sounds pretty awesome for training support contracts ;). Can't wait until this stuff becomes standard for consumers!
#3
03/25/2013 (3:03 pm)
OMG! I love you guys! I wasn't able to make the original kickstarter, but hopefully I'm not to far back in line with the pre-order. I was praying that you guys would implement it after hearing how it would be ready to work with unity and unreal already. Great job! Can't wait!
#4
03/25/2013 (3:22 pm)
Shiny! Great work Dave.
#5
03/25/2013 (3:38 pm)
Thanks, guys!

For anyone that is curious about the Oculus Rift, here are two of the most popular forums:

Meant To Be Seen Official Rift Forum
Reddit Oculus Subreddit

Looks like someone has already posted a link to this blog on Reddit.

- Dave
#6
03/25/2013 (6:46 pm)
Dave,

Thanks for the shout out about the demo level!

Just a note to all the T3D artists out there. Designing for the Rift is VERY different then anything we have had to do previously. Once the demo goes live, everyone will have access to the source files I created (all the art assets will be open source and free for anyone to use and I will have a download for the art assets) and I will be doing a 'special video' concerning all the things I have learned by designing for the rift system. Dave, Mike and I have had a constant stream of emails and Skype conversations about this demo, and I have documented it all. As everyone that follows me probably knows, I am going to release all of the modeling 'for Rift' information to our great community for nothing, so that we can make GREAT art for this system.

Designing for Rift truly is an example of when programmers and artists NEED to talk and understand each other. I think Dave, Mike and myself have completed quite a task in making the Rift demo the best it can be. I personally think, the T3D Rift demo is the most 'interesting' demo that I have seen so far. We are creating a world versus a 'scene'.

I also want to point out a number of improvements that most of you will NOT notice on first install and play-through of this demo. (This is because most of us 'end users' don't think about all the thought that goes into things that we 'assume' are correct...and Dave is TOO DAMN shy to brag about!)

Technical data follows: (individual results will vary depending on system and hardware!)

Dave worked his ass off and improved the latency between the time that T3D senses a scene object and displays it. This directly correlates to the time it takes to render a single frame in T3D. (for me, using a nvidia geforce 550ti with 1 gig of ram video card, a quad core (intel i5 3.2 gig processor and 6 gigs of on-board ram) and the latest video drivers, Dave managed to optimize the milliseconds it takes to render a single frame from an average of 20 to 30+ms to between 12 and 16ms. This is DIRECTLY relational to the number of polys in a given view, so it varies from frame to frame. Lag experienced is like more MY fault (as the world modeler) than anything on the programming side!

Keep in mind this is within an early version of the demo, I am still not at version 1.0!) Even so, this result is displaying an average of nearly 1 million polys (average) per frame! This means we can render the demo scene at nearly a continuous 60 fps in BOTH Rift views (left eye and right eye). This will also IMPROVE with time since we will continue to improve the render and art pipeline.

This whole project has helped me understand how important it is to understand what a programmer and artist MUST do and MUST communicate to each other to accomplish such a complex task.

I have heard a number of people state that this is JUST another new input device and it is a trivial/gimmick addition to T3D. I understand why someone might think that but, TRUST ME by working the issues involved and developing these systems (Rift, Leap, and Razor) we have identified CORE Engine faults and issues! Dave, Mike, myself and others have identified and corrected the problems! This work will make T3D even MORE relevant in the future, even if you DON'T use the rift or other input devices.

Keep this in mind, you can look at the Rift and Unity Blogs and Forums and see that people are NOT happy about the choice to make purchasing a Unity 4 Pro license (1,500$ US dollars) a requirement to use the Rift. This may change in the future, but for now, T3D will support Rift under MIT, out of the box, for no charge, and Dave improved the render pipeline!

NOTE: As a side observation, I have a very strong respect now, for ANY console development team (X-Box, PlayStation, etc.) after this little development project. It is an enormous task to meet a set FPS/frames per millisecond requirement! Props go out to everyone that makes the games we play look SO good!

Ron
#7
03/25/2013 (6:54 pm)


The game I'm working on will be making use of the Rift. I knew GG would be adding support for it, so I've been patiently waiting. This will be most exciting when I'm all done. I've not seen any other games using the Rift yet quite like what I'm doing. It will be very, very exciting.
#8
03/25/2013 (9:50 pm)
I am very happy to see this support added and to hear the engine has improved as a result.

Developing our games with Rift in mind is a good marketing tool too. As not many games have that support.

Really great work and I look forward to seeing your documentation Ron.
#9
03/26/2013 (12:38 am)
Do the changes help with rendering to texture for a scene (like a scope) or split screen?
#10
03/26/2013 (3:32 am)
@Ron
Quote:Designing for the Rift is VERY different then anything we have had to do previously

Do you mean in terms of art optimization requirements, or people catering for both Rift and monitor would need to have some kind of fallback art?
#11
03/26/2013 (4:27 am)
Awesome to finally see some indie action for Oculus - woohoo!
#12
03/26/2013 (6:10 am)
Guys this is just awesome :)
and i have to admit i didnt expected to see it happen that fast
keep it up!
#13
03/26/2013 (7:19 am)
This is a good start.
But..
The T3D be more to promote cross-platform. Multi-threaded computing and rendering tools perfect.
We did not find that fewer and fewer people now use this engine. Many people choose other engine. Leave GG ... the T3D engine development up to now. One can make the engine more people to choose products with the game there was not one. GG should do this reflection
#14
03/26/2013 (7:37 am)
That's all very good input, and something that has been said many times. But GG are not the core developers on the engine any longer with a large dedicated team working towards a (hopefully) profitable point release. It's up to all of us (as in the Torque and open source development community) to push the engine forward.
#15
03/26/2013 (7:42 am)
Quote:
This whole project has helped me understand how important it is to understand what a programmer and artist MUST do and MUST communicate to each other to accomplish such a complex task.

Wiser words were never spoken ... at least not about game design. ;)
#16
03/26/2013 (7:54 am)
Quote:
The T3D be more to promote cross-platform.
It's open source. GarageGames isn't the "owner" of the engine anymore - just the name of the engine. If you're really hot on cross-platform development in T3D then get to work on it. This thread shows great progress by a few of the community members in Linux, for example.
#17
03/26/2013 (9:00 am)
@Demolishun:
No, these changes don't specifically address that. For the Rift I've modified GuiTSCtrl to render two viewports, with the camera slightly offset for each viewport. This allows for a number of optimisations (such as only calculating advanced lighting once) as I know that the two viewports are nearly identical.

For render to texture and split screen you are using very different camera locations to render from, and these optimisations may not apply. Split screen also implies controlling a 2nd player, which has a number of other, non-rendering issues.

A camera scope, however, could be a special case as it is usually pointed in the same general direction as the Player, and has a similar location to the Player. I wonder if you could get away with slipping in a separate render target to the GuiTSCtrl rendering chain. It could be used for binoculars, a hand held thermal scanner if you allowed postFx to also be applied to the render target, etc.

In this case, the work I'm doing for the Rift may help out. It makes it much easier to do multiple renderings at once before clearing out the buffers.

- Dave
#18
03/26/2013 (9:45 am)
@Dave,
Thanks for the explanation. This is really good news for VR buffs too.
#19
03/26/2013 (10:25 am)
Hey All:

I'm doing an Ask Me Anything about Oculus Rift C++ development on Reddit right now!

www.reddit.com/tb/1b1smc

- Dave
#20
03/27/2013 (3:59 am)
Awsome news, can't wait to get my Oculus Rift pre-order and can't wait for your Demo Ron.

Oculus Rift may be a game changer!
Page «Previous 1 2