DOOM 3 BFG VR fork on github

Post by **tmek** » Sat Mar 16, 2013 9:48 pm

I've forked the official Id Doom 3 BFG source code on git to https://github.com/tmek/DOOM-3-BFG-VR

I'll get it up to date with the modifications I used for my own DIY Rift using the custom sensor fusion and hopefully we can get it to a point such that it won't take much effort to get it working with the Rift SDK when it's released.

Anyone familiar with c++/doom3 code interested in helping out let me know!

Post by **adoral84** » Sat Mar 16, 2013 10:00 pm

I'd be down to help, I still have work to do on my mods but I'd like to see the community step up on this one, it shouldn't be too hard from everything I've seen so far. Eventually I'd like to work in the independent weapon stuff too, which may not be hard at all ( depends on the engine ).

Post by **densohax** » Sat Mar 16, 2013 10:05 pm

Well I have q3 to finish, if I find some time, I'll let you know..

Post by **IGameArt** » Sat Mar 16, 2013 10:09 pm

I actually have the source myself, and after compiling it and making a new exe, i've noticed a few drops int he frame rate and the game looks considerably fuzzier, like its set to render the game at a lower resolution and blow it up to fit my screen. It's incredibly distracting considering that i was able to run the game at a full 60fps with side by side steroscopy beforehand. anybody else have this issue with the source?

Post by **scubaSPI** » Sat Mar 16, 2013 10:33 pm

This is what makes awesome developers such as John Carmack really shine. Releasing the game commercially, then releasing the source so the community can keep the work alive.

Post by **Namielus** » Sat Mar 16, 2013 10:37 pm

Good luck guys! I am looking forward to doom 3 BFG

Post by **2EyeGuy** » Sat Mar 16, 2013 11:58 pm

I submitted some pull requests.

Post by **tmek** » Sun Mar 17, 2013 1:50 am

If someone has Doom 3 BFG purchased on Steam and you would like to help, see if you can follow the instructions below and get it building on your machine.

Everything linked below is free (except you do need to have a purchased copy of Doom 3 BFG on Steam)

Currently there is no extra functionality except that it should compile and run under VC++ Express on Windows 7 and 8. I'm able to get it to build and run on my machine but it will be good to ensure that others can build and run it.

- Install DirectX Software Development Kit
http://www.microsoft.com/en-us/download ... en&id=6812

- Install Micorsoft Visual C++ 2010 Express
http://www.microsoft.com/visualstudio/e ... 10-express

- Install Doom 3 BFG Edition from Steam
http://store.steampowered.com/app/208200/

- Download DOOM-3-BFG-VR source code and Open in VC++ Express
https://github.com/tmek/DOOM-3-BFG-VR/a ... master.zip
unzip the file to some where (c:\DOOM-3-BFG-VR is fine)
using Visual C++ Express open the file c:\DOOM-3-BFG-VR\neo\doom3.sln

- Set Doom3BFG as the StartUp Project
Right click the project and choose "Set as Startup Project"

- Set Debugging Command Arguments
Right click the Doom3BFG project, choose "Properties" -> Configuration Properties -> Debugging -> Command Arguments
copy and paste in the following line:
+set fs_basepath "C:\Program Files (x86)\Steam\steamapps\common\DOOM 3 BFG Edition"

- Press F5 in visual studio to build and run Doom 3 BFG in debug mode.
Visual C++ will mention the project build files are out of date, click "Yes" to build them and run.

troubleshooting
---------------
- Known Issue: DirectX SDK (June 2010) Setup and the S1023 error
http://blogs.msdn.com/b/chuckw/archive/ ... error.aspx

Post by **2EyeGuy** » Sun Mar 17, 2013 2:10 am

Edit: sorry, didn't see the PM. Doing it now.

Post by **tmek** » Sun Mar 17, 2013 2:28 am

IGameArt wrote:I actually have the source myself, and after compiling it and making a new exe, i've noticed a few drops int he frame rate and the game looks considerably fuzzier, like its set to render the game at a lower resolution and blow it up to fit my screen. It's incredibly distracting considering that i was able to run the game at a full 60fps with side by side steroscopy beforehand. anybody else have this issue with the source?

Try disabling the Motion Blur setting and see if that fixes it for you. I had a similar experience once i went into stereoscopic rendering in D3BFG. Specifically that when both 3D and motion blur are enabled together it seems to do some rendering to a texture and then upscaling just as you mention. If you just have one or the other on by themselves it seems fine.

Post by **IGameArt** » Sun Mar 17, 2013 2:44 am

Oh sweet, that actually fixed the problem. The game looks super smooth now and runs at 120fps on my machine in stereoscopic 3d. Also have you had issues with it cutting off the top and bottom portions of the screen when you enable the warp?

Post by **2EyeGuy** » Sun Mar 17, 2013 3:19 am

Yes, I mentioned that right when it came out. Apparently John Carmack thought a square aspect ratio was better in VR, or that you couldn't see the top and bottom of the panel in the old prototype so there was no point in rendering it. But nobody else does that for the Rift, so I think we should fix that to use the whole screen.

Post by **IGameArt** » Sun Mar 17, 2013 3:24 am

Definitely, it's actually somewhat of a hindrance as there are certain entries in the pda that can't be read because its not only being cut off at the top and bottom, but also snipped along the sides as well.

Post by **2EyeGuy** » Sun Mar 17, 2013 4:38 am

OK, I pushed my changes.
It should now have the Carmack Reverse, Doom 1 and 2 have most of the censorship removed, and Doom 2's extra secret level, MAP33: Betray, is now working.

I also fixed this problem:

tmek wrote:- Set Doom3BFG as the StartUp Project
Right click the project and choose "Set as Startup Project"

Now you can remove that step from your instructions.

The things we still need to do are:

Add Bink video playback from the open-source FFmpeg or libavcodec (hard), possibly using the original Doom 3 video playback code as a reference.
Remove the censorship on the Wolfenstein SS in the Doom 2 secret levels.
Replace doomclassic with one of the OpenGL source-ports, so it can be in true VR. The only one I can get to compile is glboom+.
Fix the warping so that it's not letterboxed.
Get headtracking working (with head and neck model or 6DOF tracking).
Get rendering working for the 7" Rift dev kit.
Add support for DIY rifts and prototype rifts.
Make it user-friendly to put it in Rift mode with all the right settings.
Get independent weapon control working.
Let you see your own body when you look down.

Post by **tmek** » Sun Mar 17, 2013 4:34 pm

I added head tracking with Mahony sensor fusion using Hillcrest tracker as a placeholder motion sensor until we get the SDK for the Oculus Rift.
- Added MahonyARHS fusion algorithm to solution
- Added code to init and read raw data [roll, pitch, yaw, x, y, z] from motion sensor and run it through fusion.
- Modified win_input.cpp to merge viewangles from motion sensor data with other input sources.
- Set delta angles to zero each frame (not doing this causes weird drift, but this causes an issue with rotating platforms and trains. Will have to fix that.)
- Added relevant dependencies to \dependences folder (temporary)

2EyeGuy wrote: The things we still need to do are:
Add Bink video playback from the open-source FFmpeg or libavcodec (hard), possibly using the original Doom 3 video playback code as a reference.
Remove the censorship on the Wolfenstein SS in the Doom 2 secret levels.
Replace doomclassic with one of the OpenGL source-ports, so it can be in true VR. The only one I can get to compile is glboom+.
Fix the warping so that it's not letterboxed.
Get headtracking working (with head and neck model or 6DOF tracking).
Get rendering working for the 7" Rift dev kit.
Add support for DIY rifts and prototype rifts.
Make it user-friendly to put it in Rift mode with all the right settings.
Get independent weapon control working.
Let you see your own body when you look down.

I think we should keep in mind that it is still very possible that ZeniMax/Id will release a Rift compatible version in the very near feature. So it probably wouldn't make much sense to try to go to far too soon. I think what most people (myself included) are right now interested in being able to have the Doom 3 BFG Rift demo "experience" on day-one of having their Rifts (or as close as we can come to that).

With that in mind I think the minimal functionality would be..

#1 Updating StereoWarp.vertex and StereoWarp.pixel to match the 7" Rift optics (again the Rift SDK should provide the information we need to make the appropriate changes)
#2 Rift Head Tracking (the Rift SDK will probably already include things like head/neck model and fusion)
#3 Raising and Lowering your gun with right analog stick/mouse
#4 Making PDA readable (fixing the clipping off the edge of the screen in stereo rendering)
#5 Adding a menu item to setup an optimal Rift experience.

Getting a way to play the Bink videos would be nice as that would round out the gameplay. Is that not something we can pull from someone else's fork? If someone else hasn't already done it, it's probably going to be hard to do.

Post by **geekmaster** » Sun Mar 17, 2013 7:53 pm

tmek wrote:I added head tracking with Mahony sensor fusion using Hillcrest tracker as a placeholder motion sensor until we get the SDK for the Oculus Rift.

While waiting for the Oculus Rift SDK, you can have DAY-0 Rift head tracker support NOW if you use the "UNOFFICIAL RIFT TO VRPN SERVER":
http://projects.ict.usc.edu/mxr/diy/vrpn/

And you add VRPN client code to your app:
http://www.cs.unc.edu/Research/vrpn/app ... _view.html

Post by **2EyeGuy** » Sun Mar 17, 2013 11:03 pm

Interesting. The Rift uses a static C++ library, or C++ source code, for their tracking. Internally they are just using the Windows HID interface (and registering for device notifications).

Post by **tmek** » Mon Mar 18, 2013 12:22 am

2EyeGuy wrote:Interesting. The Rift uses a static C++ library, or C++ source code, for their tracking. Internally they are just using the Windows HID interface (and registering for device notifications).

Did you use IDA or something to disassemble the Rift VRPN server?

I was tinkering around some of the VRPN code per geekmaster's suggestion and I was wondering myself if the Rift would register as an HID device like the Hydra and Freespace do (see screenshot).

I assume you'd still have to know the structure of the data being read (or is there some kind of standard for motion trackers?) but that greatly simplifies scanning for available devices, connecting and disconnecting from devices.

Regarding VRPN I was wondering about latency.. wouldn't going across process boundaries using network packets introduce some latency, even if client and server are on the local machine?

Post by **2EyeGuy** » Mon Mar 18, 2013 1:31 am

tmek wrote:
2EyeGuy wrote:Interesting. The Rift uses a static C++ library, or C++ source code, for their tracking. Internally they are just using the Windows HID interface (and registering for device notifications).
Did you use IDA or something to disassemble the Rift VRPN server?

Um... No comment.

But if one were to do that, one might find the code harder to follow than normal, since it's object oriented.

tmek wrote:I was tinkering around some of the VRPN code per geekmaster's suggestion and I was wondering myself if the Rift would register as an HID device like the Hydra and Freespace do (see screenshot).

I assume you'd still have to know the structure of the data being read (or is there some kind of standard for motion trackers?) but that greatly simplifies scanning for available devices, connecting and disconnecting from devices.

I doubt it would use any standard. But since we know it's sending yaw, pitch, and roll, it's not hard to output the data while turning the Rift and seeing which is which. I did that with the VR920.

tmek wrote:Regarding VRPN I was wondering about latency.. wouldn't going across process boundaries using network packets introduce some latency, even if client and server are on the local machine?

Yes. It's not a long-term solution, just a quick fix for getting it working on the Rift without any SDK.

Post by **2EyeGuy** » Thu Mar 21, 2013 1:05 pm

I'm having trouble getting VRPN working. I've added VRPN to the project, and it builds OK. But I can't get any sensible data from it. I'm using the Razer Hydra as a VRPN server. I have no idea why it's not working. The camera keeps pointing in the same direction.

Post by **tmek** » Thu Mar 21, 2013 2:13 pm

2EyeGuy wrote:I'm having trouble getting VRPN working. I've added VRPN to the project, and it builds OK. But I can't get any sensible data from it. I'm using the Razer Hydra as a VRPN server. I have no idea why it's not working. The camera keeps pointing in the same direction.

I'm pulling it down now, I have a hydra and the freespace tracker I'll try with both. What did you use for the Server.exe? Did you build your own or download a binary from somewhere? I had trouble getting the server to build, I think it was probably just due to incorrect header/lib paths.

Post by **CyberVillain** » Thu Mar 21, 2013 4:24 pm

Next version of FreePIE will have a generic plugin that any software can use, we will make a C lib that you can use. Right now you can use it by hooking into the shared memory.

https://github.com/AndersMalmgren/FreeP ... cPlugin.cs

How about adding support for it so that any tracker can be used with BFG?

Post by **2EyeGuy** » Fri Mar 22, 2013 12:23 am

tmek wrote:
2EyeGuy wrote:I'm having trouble getting VRPN working. I've added VRPN to the project, and it builds OK. But I can't get any sensible data from it. I'm using the Razer Hydra as a VRPN server. I have no idea why it's not working. The camera keeps pointing in the same direction.

I didn't upload my actual implementation of the tracking, since I couldn't get it to work at all. I can upload it if you want though.

tmek wrote:I'm pulling it down now, I have a hydra and the freespace tracker I'll try with both. What did you use for the Server.exe? Did you build your own or download a binary from somewhere? I had trouble getting the server to build, I think it was probably just due to incorrect header/lib paths.

Firstly, make sure you checked out the git with the recursive option, if you are using the version in the dependencies\vrpn folder.
Just open the vrpn.sln file and build it a couple of times. There are some missing files and bits that won't build, but the server will build eventually.
The .cfg file is in the server_src folder, you need to uncomment one of the trackers, and it needs to be called Tracker0 (since that's what the Oculus Rift vrpn server uses).
The exe file is in the pc_win32\server_src\vrpn_server\Debug folder. Copy the .cfg file into there, and run it.

Of course, in the version on github, I haven't added the vrpn tracking to the code yet, so it won't do anything.

Post by **2EyeGuy** » Fri Mar 29, 2013 1:46 pm

Sorry, the Oculus Rift SDK license doesn't seem to be compatible with Open Source software.

So there won't be any Oculus Rift support in Doom 3 BFG.

I appologise for that. It was my intention to add Oculus Rift support today, but that will have to wait until I can make my own SDK for working with the Oculus Rift, or until I can get VRPN support working, or until Oculus provide an open-source compatible API.

Post by **IGameArt** » Fri Mar 29, 2013 5:06 pm

well from what i'm able to gather is that the game will be playable on the rift, but without motion tracking, which is kind of sad, but that wont stop me from trying to surround myself with mars. Hopefully we can get that warping to be correct for the new display, and get the vrpn server working.

Post by **2EyeGuy** » Sat Mar 30, 2013 9:16 am

I think it probably is actually compatible with open source licenses if we say it's a system library and don't include the source code to ovrlib.
So, I'm going to go ahead and give it a go.

Does anyone know how to edit the shaders that come with Doom 3 BFG?

Post by **2EyeGuy** » Sun Mar 31, 2013 3:27 pm

Can someone with a Rift (and Doom 3 BFG) test this to see if Rift headtracking is working?

These go in your Doom 3 BFG's exe directory.
https://dl.dropbox.com/u/101772879/Doom3BFGTracking.zip

Some of the tracking may be inverted, or it might not work at all. I don't know.

http://www.youtube.com/user/spankeey77 · Post by **drgroove101** » Sun Mar 31, 2013 11:16 pm

Very excited for this project guys! You're all doing a great job! I think I'm even more excited to play the favourite game of my youth DOOM2 more than Doom3 ! If you guys make this happen, you will truly be my hero. Keep up the great work and I look forward to a playable release!

Post by **nvman90** » Mon Apr 01, 2013 1:51 pm

I quickly tried it out, the head tracking was working great!

I'll have to figure out how to enable the pre-warping and try it out for longer once I get a chance.

Post by **2EyeGuy** » Mon Apr 01, 2013 2:38 pm

drgroove101 wrote:Very excited for this project guys! You're all doing a great job! I think I'm even more excited to play the favourite game of my youth DOOM2 more than Doom3 ! If you guys make this happen, you will truly be my hero. Keep up the great work and I look forward to a playable release!

I fixed the red crosses and the secret levels in the DOOM2 part of Doom 3 BFG (except I haven't done the blue SS enemies yet), but I haven't added head-tracking yet, because the version in Doom 3 BFG is just the vanilla 256-colour software renderer but with a higher resolution. I need to replace most of the doomclassic in Doom 3 BFG with the code from another port, probably prboom+, since that's the only one I could get to compile easily, and I already did some work on porting it to the Rift. BTW, Doom 3 BFG has an extra secret level in Doom 2, called MAP33: Betray, from the Xbox version. It's broken in the original Doom 3 BFG, but I fixed it in this version.

Post by **nvman90** » Mon Apr 01, 2013 2:54 pm

stereorender_warp 1 isn't working, any ideas?

Post by **IGameArt** » Mon Apr 01, 2013 3:03 pm

Hmm that's strange because the warp is working fine for me.

@2eyeguy, have you considered using gzdoom? It has a more robust rendering engine that allows for lots of tweaking of both the graphics, and gameplay.

http://www.youtube.com/user/spankeey77 · Post by **drgroove101** » Mon Apr 01, 2013 10:05 pm

2EyeGuy wrote:I fixed the red crosses and the secret levels in the DOOM2 part of Doom 3 BFG (except I haven't done the blue SS enemies yet), but I haven't added head-tracking yet, because the version in Doom 3 BFG is just the vanilla 256-colour software renderer but with a higher resolution. I need to replace most of the doomclassic in Doom 3 BFG with the code from another port, probably prboom+, since that's the only one I could get to compile easily, and I already did some work on porting it to the Rift. BTW, Doom 3 BFG has an extra secret level in Doom 2, called MAP33: Betray, from the Xbox version. It's broken in the original Doom 3 BFG, but I fixed it in this version.

Man even with the old school graphics I think Doom2 would still be pretty cool with full head tracking in the Rift. I'd probably go through the whole game in one sitting! Never tried prboom+, gzdoom is the engine I use, but if you can upgrade the graphics in addition to adding Rift support... TAKE MY MONEY! *starts throwing money at monitor*

Post by **2EyeGuy** » Tue Apr 02, 2013 3:39 pm

nvman90 wrote:stereorender_warp 1 isn't working, any ideas?

It only works in full side by side 3D mode.

drgroove101 wrote:Man even with the old school graphics I think Doom2 would still be pretty cool with full head tracking in the Rift. I'd probably go through the whole game in one sitting! Never tried prboom+, gzdoom is the engine I use, but if you can upgrade the graphics in addition to adding Rift support... TAKE MY MONEY! *starts throwing money at monitor*

It's harder than it seems at first to integrate OpenGL Doom 2 rendering, because Doom 3 BFG is designed around a separate front-end renderer and back-end renderer (running in a different thread), and the front-end can't use OpenGL directly. So I had to move the Doom Classic rendering code into the back-end renderer, and keep the rest of the Doom Classic code in the front-end.
So far I got it rendering an OpenGL scene from a NeHe tutorial, with the console on top, while I can hear the Doom 2 running invisibly. Now I have to actually merge the PrBoom+ OpenGL source in.

IGameArt wrote:@2eyeguy, have you considered using gzdoom? It has a more robust rendering engine that allows for lots of tweaking of both the graphics, and gameplay.

Right now I don't want it to add lots of tweaking to the graphics and gameplay. I just want it to have the existing functionality but rendering in OpenGL in 3D and able to look around freely, without having to change too many things to get it to work. Once I've worked out how to do that, maybe I'll see about other source ports.

Post by **jack612** » Tue Apr 02, 2013 6:56 pm

Ah, I was using side by side instead of full side by side and wondering why it wasn't working. It's so close now but there's no way to get the image quite right with the slider.

Post by **jack612** » Tue Apr 02, 2013 8:26 pm

Oh wow, I tried:

stereoRender_warp 1
stereoRender_interOccularCentimeters -4
g_fov 110

and it almost fixed the rendering. It's still too zoomed in a little too much and flat, 2D stuff in the foreground still looks cross-eyed, but it's almost there. Also, now that the graphics are kind of working I noticed that the head tilting headtracking seems reversed. Like if I tilt my head left, the screen tilts right. And I'm getting an idea of the kind of performance hit stereo rendering causes. I've got a 2GB 7870 that has no problems running this with a steady 60fps maxed out at 1080p but I noticed some drops in stereo mode at 1280x800.

Post by **IGameArt** » Tue Apr 02, 2013 10:22 pm

Which axis are reversed, is it all three rotations?

Post by **2EyeGuy** » Tue Apr 02, 2013 11:59 pm

IGameArt wrote:Which axis are reversed, is it all three rotations?

That would be roll. That was one of the things I wanted people to test, because I didn't know which direction the axes were supposed to be. I'll fix it now.

Post by **2EyeGuy** » Wed Apr 03, 2013 1:20 am

OK, I updated it to a new version. This should fix the roll:

https://dl.dropbox.com/u/101772879/Doom3BFGTracking.zip

Post by **jack612** » Wed Apr 03, 2013 6:25 am

That fixed it. Head tracking seems to be fully functional now. Awesome!