Author Topic: Hi all! Excited to tear into this code (introduction)  (Read 2557 times)

0 Members and 1 Guest are viewing this topic.

Hi all! Excited to tear into this code (introduction)
Hi! I'm glad to see such a strong community based around Freespace!

I've played Decent: Freespace and FS2 off and on since they came out, nothing has really rivaled these games as far as space combat and storytelling. I picked the series up again fairly recently and just discovered this community. I was brought here by the Diaspora mod. I'm a huge BSG fan, and those guys have done a GREAT job with their mod.

I've done a small amount of game development. Years back I played with the torque engine and did some low poly modeling with blender. Since then I've been doing mostly hardware and firmware with work, every now and then I break out C# to do an interface to my gadgets.

I recently bought an Oculus DK2 (should be here Wednesday! :D ) mainly for cockpit games such as freespace. As I understand it there's no software off the shelf that will enable Oculus support, so I thought I'd give it a go. I have to admit that I've never really dealt with a project of this size, and my Cpp-fu is pretty weak, but I'm excited to see what I can add to this project. I've downloaded the FS2 open source code and the DK2 SDK, I'll be tinkering with them in the coming weeks. I have a great deal of searching and reading in front of me, but I would greatly appreciate any advice you guys may have for me as far as where to get started.

 

Offline Goober5000

  • HLP Loremaster
  • Moderator
  • 214
    • Goober5000 Productions
Re: Hi all! Excited to tear into this code (introduction)
:welcome:

This sounds pretty cool. :)  My workplace will also be getting an Oculus DK2 in the near future, so I will be very interested to follow anything you do with this.

 

Offline m!m

  • 211
Re: Hi all! Excited to tear into this code (introduction)
I guess that adding the headtracking support would be the easiest thing to do as there is already some support for it in FSO.

The headtracking code in the current version of FSO is very TrackIR specific but I already implemented a generic interface some time ago. If you want you can use that to save you some time: https://github.com/asarium/fs2open.github.com/tree/feature/freetrack/code/headtracking

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Hi all! Excited to tear into this code (introduction)
Oculus Rift support is planned (I have an Oculus Rift devkit boxed and sitting next to me) but there are a couple obstacles to getting it working.

The Freespace2 engine code isn't exactly the most well-written codebase out there. When coding stereoscopic rendering, you basically need to render the same scene twice, albeit using two different perspectives. The frame rendering function (game_render_frame()) assumes it's only going to be called once per frame with only one eyepoint. A lot of redundant work that doesn't need to be done will be done if you call this function twice. So there needs to be a bit of restructuring done to make sure the code that needs to actually render stuff is called twice while the code that sets it all up is only called once. A bit easier said than done.

Second is the OpenGL draw call overhead. The way our OpenGL calls are structured aren't very efficient so even if you get stereoscopic rendering in the game, I doubt it'll be able to run at an acceptable framerate. A lot of my upcoming rewrites and code restructuring should improve framerates but I don't know if it'll be enough. I've been thinking of a way to use draw call instancing so when rendering a model, we render it twice in the same draw call but send the duplicated rasterized triangles to both right and left stereoscopic framebuffers using a geometry shader. There still may be a performance hit but at least the hit will be on the actual GPU (where we're barely even scratching at the moment)

Third is the upcoming deferred rendering and soft shadows builds that I'm hopefully going to get into the engine soon. That adds a bit more work to the equation and raises some additional questions about how we're going to handle doing deferred lighting for two stereoscopic framebuffers. Do I do the instanced rendering trick again using geometry shaders? Do I just do the lighting pass twice and just take the performance hit?

So... yeah. That's a lot to swallow and I don't mean to discourage you. But coding support for VR in this engine requires a significant amount of knowledge in computer graphics and OpenGL. This isn't a feature I'd recommend for coders new to this engine.

I hope you stick around though! It's always great to get new coders. I hope you find something else you can start with and then maybe you'll be able to tackle something as... daunting as this feature. :P
« Last Edit: September 09, 2014, 02:14:47 am by Swifty »

 
Re: Hi all! Excited to tear into this code (introduction)
I'm glad smarter and more experienced people than me are working on this. I very much like the process of squeaking out more performance through optimization, I just usually do it on 8 bit processors in assembly or basic. A single frame contains more information than I can store in RAM and flash on most of the micros I work with  :lol: I had a feeling this would be a pretty huge task, at the very least I can offer help testing and will wade into the code at a slower pace.

In any case I'm definitely sticking around. I'm digesting some of the code right now, just hearing you talk about the render process has cleared up quite a bit.

 

Offline Parias

  • 27
Re: Hi all! Excited to tear into this code (introduction)
Oculus Rift support is planned (I have an Oculus Rift devkit boxed and sitting next to me) but there are a couple obstacles to getting it working.

Thanks for this post - I've got a DK2 sitting right next to me as well and was extremely curious about what challenges would be involved in getting Freespace 2 OR-friendly.

 

Offline niffiwan

  • 211
  • Eluder Class
Re: Hi all! Excited to tear into this code (introduction)
I've found Michael Abrash's blog@Valve to have some interesting posts on the challenges inherent in VR gaming.
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Hi all! Excited to tear into this code (introduction)
Yes, they're very useful indeed. I've been to Michael Abrash's talk at GDC 2013 about VR and it was very elucidating.

 

Offline Echelon9

  • 210
Re: Hi all! Excited to tear into this code (introduction)
Swifty, you might be interested to hear Intel Sandy Bridge (incl Macbook Airs from c.2011) now supports OpenGL 3.3 on Linux Mesa-dev drivers since last week.

http://www.phoronix.com/scan.php?page=news_item&px=MTc5MTg

Quote
Kenneth and Jordan realized that for this to work we also need GL_AMD_vertex_shader_layered (which requires OpenGL 3.2, so it could not be
enabled before this patch), so we agreed to enable this together with OpenGL 3.2 in this patch.

In the comments you'll see that OpenGL 3.3 support was trivial as well. Sadly no clear path for that feature equivalence in the Intel Windows driver for the same hardware (we've had Intel GPU issues with driver feature levels).

Apple's OSX drivers for Sandy Bridge have supported OpenGL 3.3 for a while.
« Last Edit: September 23, 2014, 01:14:57 am by Echelon9 »