cancel
Showing results for 
Search instead for 
Did you mean: 

DOOM 3 BFG - VR ( V0.021 Updated 3-12-2017)

Samson
Heroic Explorer

Latest Release And Downloads:

Latest Version: V0.021

https://github.com/KozGit/DOOM-3-BFG-VR/releases

Updates from v0.20:

Edit: Many many thanks to 2EyeGuy for all his hard work on the .020 release, and for handling bugfixes and compiling this release while I was on vacation

Additions:

QuakeCon style teleport. ( jkchng )

Fixes from v 0.020

Fix issue #107: use other hand for movement.
Fix issue #97: Fix talking waking monsters.
Fix issues 100 & 106: Change language detection to use sound files. Issue #100 and Issue #106            
Fix issues #113 and #27: Fix timing issues.    
Improve issue #27:Disable ASW and make it a menu.
Improve issue #103:    Fix loading old savegames with different scripts.
Fix crash loading 020 save games, and allow old versions.
Loading RBDoom savegames works now.
"Fix" loading script objects of different sizes.   
Fix save and load menus.    
Adjust installer, Readme, and other docs for v 0.21 Alpha.
Work Around Movement Popping.

**EDIT:**
Known issue: After saving a game it might appear greyed out in the load game list and be unable to find it. To fix this issue, either use this console command before opening the load game menu, or exit the program and restart it:
testSavegameEnumerate
This issue is fixed in the next version.


Previous Release:

Doom 3 BFG VR: Fully Possessed V0.020 Alpha


This is sizeable update with many new features and improvements.


New features include:


Teleportation is now supported, including a parabolic aiming beam.


Voice commands are supported - say a weapon name to select it!


Flicksync mode based on Ready Player One.


Many aids to prevent motion sickness, including a new Third Person movement mode.


Many other improvements have been made, please see the readme.txt for a full feature list and documentation.

https://github.com/KozGit/DOOM-3-BFG-VR/blob/master/README.txt


Default Configuration

No single controller configuration or comfort setting is going to accommodate all users equally,

so Doom 3 BFGVR: Fully Possessed defaults to a comfort oriented mode.
In the default mode, comfort ( or snap ) turning is enabled by default,
and artificial movement uses the Third Person mode. These settings
should provide a comfortable experience for almost all users. These
settings may be easily changed or disabed in game if they do not suit
your needs. From the System Menu ( say 'System', or press ≡ (menu) on
the left Touch or Right Vive ), then select 'VR Options' then 'Comfort +
Safety Protocols'. From this menu, use the 'Turning' options to change
the turning mode (' smooth 'is standard analog turning - caution -
smooth turning causes motion sickness in most people ). Use the 'Motion
Sickness Aid' options to change the comfort settings. 'None' disables
all motion aids, but this will induce motion sickness in the vast
majority of people.


Default Controller Layout

The default controller layout can also easily be changed in game. Any
controller button or Stick/Pad axis can be mapped to any in game action,
to easily create a controller layout tailored to your liking. From the
System Menu ( say 'System', or press ≡ (menu) on the left Touch or
Right Vive ), Select 'Controls' then 'Key Bindings', Scroll through
the list and highlight the action you would like to change the control
for. Press the trigger to enter 'bind' mode, then simply press the
controller button or stick/pad axis you would like to assign to that
action. If the button or stick is already assigned to a different
control, you will be asked if you are sure you want to re map, otherwise
you are done! A button or joystick/pad axis can be unbound from an
action the exact same way.


Installing Doom 3 BFG: Fully Possessed.


There are two options for installing the mod: A self-extracting installer, or a .zip file.

Due to the inclusion of new player AAS files needed to support teleportation, the size of the mod has

increased a fair amount. You will need about 1GB of free hard drive space to install the mod.


Installing with the self-extracting installer

Download the file 'Doom3BFGVR_Fully_Possessed_Alpha020_Installer.exe' from the release page at the top of this post and execute.


By default, the installer will look to install the mod in the default
app directory in your Steam library on drive C. If your Steam library is
in a different location, or you have installed doom 3 someplace else,
browse to the location of your Doom 3 BFG installation. IMPORTANT
If you browse to select a directory to install the mod, the installer
will append 'Doom 3 BFG edition' to the install path. REMOVE THIS from
the install path, so that only the full name of your Doom 3 BFG
directory is displayed. Failure to do this will result in the mod files
being installed in the wrong directory. Once installed, you should see
a folder named 'Fully Possessed' inside your main Doom 3 directory
along with some support files and the Doom3BFGVR.exe. Launch this .exe
to play.


Installing with the .zip file

Download the 'Doom3BFGVR_Fully_Possessed_Alpha020.zip' file from the release page at the top of this post, and
extract into your main Doom 3 BFG directory. You should see a folder
named 'Fully Possessed' inside your main Doom 3 directory along with
some support files and the Doom3BFGVR.exe. Launch this .exe to play.


Compatibility with existing Mods or Native Doom 3 BFG

Doom 3 BFG: Fully Possessed stores all changed assets and save games in
their own directories. Installing the mod will not interfere with
existing mods or the native game.


Compatibility with the Hi-Def texture pack

Doom 3 BFG:Fully Possessed is compatible with the hi-def texture pack.
Please be aware that the 'generated' folder included in the hi-def
texture pack is corrupt, and will crash the game if not deleted. This
is not an issue with this mod, but with the texture pack itself. After
installing the texture pack, delete the 'generated' folder inside the
'Base' directory.

NOTES


  1. The texture pack also installs German language files. If you do not
    want the game menus to be in German, delete the 'german.lang' file in
    the 'Base/Strings' directory.
  2. It does not matter if you install the mod first or the texture pack
    first, but be aware that games saved without the texture pack installed
    will not work once the pack is installed, and vice versa.

Reporting Bugs

Many bugs have been addressed in this relase, but if you do find one,
please open an issue on our tracker. We can't fix it if we don't know
its broken!

https://github.com/KozGit/DOOM-3-BFG-VR/issues


Enjoy!




OLD UPDATES:

--------------------


Update 12-10-2016

Fixed bug related to save game crashes. Archives updated


Additional Update 12-9:

I've updated the OpenVR version of the mod to address  issues some people were having, and added a few new features.

There are now versions of the mod that support OpenVR and the Rift/Touch natively via the Oculus SDK.

See  below for a link and additional info. 


Update 12-9


I've updated the mod and posted a test verison with native Oculus/Touch support.

This includes full motion controls and the ability to interact with in game guis and the PDA by using them as touch screens.

Release:

https://github.com/KozGit/DOOM3-BFG-RIFT/releases/tag/v0.11-alpha

Please
make a clean copy of your doom 3 directory before installing, right now
this mod will not co-exist with other mods as too many of the
assets have been changed.

Take a look at the description on the release page, and the two readme files
included in the archive.  I've also included a .pdf that lists
most of the common cvars you can use to configure the mod.  Please
remember all the controls ( all joystick axes and buttons) can be
unbound or remapped to any other control. In the system menus go to 
(Settings->Controls->Key Bindings)

There's still a little oddness during loading screens.  Let me know if you find any issues. This is the first test of this, so there may be issues I'm unaware of, please let me know if you find anything.



------------------------------------------------------------------------------------------------------------

Previous update:


I've been working on a mod for Doom 3 BFG edition for a while, and it might be ready for an alpha test. I'm looking for people to test and let me know what issues ( and I'm sure there will be some ) you have. ( Please note this is an entirely new mod, not a variant of an existing one.)


Anyway, here we go:

https://github.com/KozGit/DOOM3-BFG-RIFT/releases

New features:



Full motion control support for weapons, with support for right or left handed control.

Reload mechanics and motion controlled melee attacks are NOT finished yet, but in progress.

For now press the attack button to punch and reload to well, reload. Grenades are now

thrown via motion controls.



Flashlight modes

The flashlight can be held in the off hand, mounted to the weapon, mounted to the player helmet, or

mounted to the player body. If 'mount to weapon' mode is enabled, and a weapon without a barrel is

selected (e.g. grenade, fists, chainsaw) the flashlight is temporarily moved to the head.



Player body view modes:

You can chose to view the entire player body with ( very very basic ) IK for the arms, view the weapon and

hands, or view the weapons only.



Weapon sight modes:

Chose from a laser sight, laser dot, circle dot, or crosshair.



Optional heading indicator.

With independent head/body movement it's easy to forget which way the body ( and forward

movement) is pointing. The heading beam points in the direction the body is moving. Beam can be

solid, have arrows, or scrolling arrow. Temporary artwork.



Movement options:

The player body is locked to user position, so moving in the real world moves the player body.

Optional comfort turning, with user defined delta and repeat delay.

Walk speed adjustment from game default consistent over level changes

Option for forward movement to be in direction off hand controller is pointed

Headkick and knockback are disabled by default but can be toggled.

For non motion controls, you can lock the view and aim together, or use independent aiming with user

defined deadzones



Hud options:

Hud is translucent and projected into world.

Hud can be locked to the view or the body.

Hud position and size are configurable.

Hud can be toggled on or off, or faded in when user looks down past defined angle

If hidden, can be configured to reveal when health below defined level

Individual Hud elements can be turned on or off if desired



Stat Watch ( for the love of god someone come up with a better name )


Ammo stats are provided on a wrist worn armament inventory device if player has weapon equipped.

Soon to provide health stats as well.



Gui interaction modes.

Player can choose one of three ways to interact with in game guis

1) Look direction controls gui cursor

2) Weapon aim controls guis, in the event weapon has no barrel (grenade, fists, etc) default to look

direction

3) If motion controls are enabled, guis can be touch activated. When close enough to touch, look at gui

to activate then touch gui to control.



PDA is rendered as model in game.

PDA can be held in hand, or fixed in a position in front of the player body. If gui touch mode is enabled, the

PDA works as a touch screen device. Pressing escape during the game brings up the system menus in

game on the PDA.

PDA fixed position can be adjusted.



Cinematics

Cinematics are now from a fixed camera position. This is still being worked on, but is much better than the

free camera IMO. Some camera files still need to be tweaked for some of the cinematics. Pressing the PDA

button will exit the current cinematic



Pixel density can be adjusted.



ALL controller buttons and axes can be re-mapped to any control or action.



Weapon models have been fully fleshed out.

All of the options are currently controlled via cvars that start with vr_.  I'll add the options to the menus at some point.

The code has not been tested on any machines other than mine, so hopefully it will at least run for some of you 🙂

There are some issues I do know about. The loading and saving transitions are pretty glitchy, which is annoying.  I'll either smooth them out or just black them out.  I changed how the player hand animations work, so occasionally the hands don't play the correct firing animation.  I know how to address just need to implement.  The weapons also jump/blink for a frame when you change weapons, I know how to address I just need to get to it. Also, the source code is a mess, it's not actually on github at the moment, I'm working to clean it up and get it posted soon.

Anyway, let me know how it works for you!





908 REPLIES 908

Syndroid
Heroic Explorer

Baz_uK said:

So when my Touch arrives I should be able download a small use this MOD as is.....or should I wait a tad longer for fixes / improvements. Not sure how good a state it's in right now? 



There are two versions. The one from user Samson and the other one from Leyland.
I tried both with a gamepad only, but they both deliver one of the best vr experiences currently available.
They both run through Steamvr, but performance wise it's great.  Oculus SDK support would be better maybe, but I don't know if they are even considering it.

Samson
Heroic Explorer
My touch arrives tomorrow.  The original test I released ( without motion controls ) used the oculus SDK, so all the rendering work should be taken care of.  I haven't looked at how they are handling input for the touch controllers yet, but it should be abstracted enough in the code that it doesn't really matter.   I haven't added any real support for gestures, but I don't know that for this game gestures add value other than cosmetic. ( I can look at what it would take to add some basic gestures, but there are some other things I would like to work on first)  I already implemented support for touch screens ( without using specific gesture code), when you focus on a touch screen when using motion controls, it automatically hides the weapon and brings up your pointer finger, which you can use to interact with the in game guis or the PDA.  So anyway, I do plan on implementing native oculus support in the near future 🙂 

Leyland
Expert Protege

Samson said:

My Shell rendering is actually a pretty big mess -  I've updated it since the last release to address scaling issues at different resolutions, but I should really go back and re-work most of it.  I did a lot of experimenting with changing the  SWF rendering scale for when the PDA or game shell is copied to a texture for the in game PDA model, and I havent gone back to clean any of it up.  I really need to take some time and  re-work everything related to pausing the game for rendering the shell on the PDA as well.  Thanks for the tip on the stencil mask, I'll think about that when i get around to re-working SWF handling.

I haven't looked at the scissor issue in a while, but I can tell you why at the time I leaned towards it being a driver bug, at least when I originally found a work around for the issue. 

1) It only happens when MSAA is enabled.  I did a test where I still performed the blit, just to a non-msaa framebuffer, and everything worked fine.

2)  I originally thought the same thing as you, that I had somehow corrupted the scissor settings, or an inappropriate scissor was left active, so I logged all  calls that set the scissor, and didn't find any irregularities.   Additionally, I tried manually setting the scissor to a known good value immediately prior to the blit, and the issue still occurred. Again, this was a while ago, but at the time it appeared to be all in the driver.  (Did you find a call that set the scissor too small -  If so, I must have missed it, that's really puzzling! )

I'm working on one more thing before I release an update - I want the player to be able to lean a little bit when the player model has collided with a surface and normal movement fails.  If that tests ok, i post an update and start cleaning up the code to release.




Yeah, I'm not a fan of SWF, I did weird scaling stuff for the HUD and messed up the objective text, and I have been itching to replace the whole thing with Webkit or CEF and redo the UI in HTML, but looking at CEF it looks like it uses software rendering and doesn't integrate with OpenGL, but I do know some older versions of Webkit that do use OpenGL and are pretty fast (I helped port one to a puny 300Mhz TV set top box a couple of years ago). It would be interesting also to have a Javascript console to hack the game and experiment with things in real time instead of having to take the headset on and off all the time when changing code or data.

1) It could be just that they never properly implemented glBlitFramebuffer with scissors in the driver, and maybe in a driver update they added scissor support for MSAA buffers only but not non-MSAA buffers.

2) Logging is how I found it, but I had the logging in reverse, I was logging after the MSAA resolve, but I also found another variable backEnd.currentScissor, and looking at that it had a value that wasn't full screen, and it gets set by surfaces when they draw to the screen. I didn't quite understand why surfaces have scissors, if it is some kind of overdraw reduction optimization but it is used when r_useScissor is set to 1, and setting it to 0 also solved the issue for me.

I have something similar for player physics that I have been sitting on for some time, but it doesn't work so much as a lean (it won't let you lean over desks or railing) but more as letting your head get closer to walls than your body does. I had to duplicate the main loop of the slidemove, and have the first part apply velocity from controller input, and the other half tries to move the body to the head location, I couldn't figure out how to have them in the same loop without effecting the end velocity, basically the controls would get sluggish if you got to close to the walls because the body had a velocity trying to reach the head.

Samson
Heroic Explorer

Leyland said:



I have something similar for player physics that I have been sitting on for some time, but it doesn't work so much as a lean (it won't let you lean over desks or railing) but more as letting your head get closer to walls than your body does. I had to duplicate the main loop of the slidemove, and have the first part apply velocity from controller input, and the other half tries to move the body to the head location, I couldn't figure out how to have them in the same loop without effecting the end velocity, basically the controls would get sluggish if you got to close to the walls because the body had a velocity trying to reach the head.



This is kind of what I'm  trying to implement, I just called it lean for lack of a better term.

 I copied slidemove to a new physicsObj func called motionmove, which is passed the velocity of the current physical motion delta for each frame. Motionmove was updated to remove all references of current.velocity and instead only uses the value passed to it.  After performing its calculations and translating the player, Motion move returns the new player origin, allowing for moving up/down steps or sliding along walls, but without modifying the actual velocity of the player.  I use the result from motion move to determine if the player was blocked or not and if so, start the 'leaning'

  I'm  testing some now, and so far the only downsides are when you physically move and the player goes up or down a step, the translation is instant instead of smoothed because it's called outside of normal walk physics. Also, the player body instantly snaps to a new location when exiting 'lean'. ( although the view doesn't change so it's not really noticeable) . Its still awkward when you hit the clamp for the lean offset, but at least it allows some additional headway. ( ha. headway. ) I literally just finished the first iteration of this, so need to check it's actually working as intended.

2) Logging is how I found it, but I had the logging in reverse, I was
logging after the MSAA resolve, but I also found another variable
backEnd.currentScissor, and looking at that it had a value that wasn't
full screen, and it gets set by surfaces when they draw to the screen. I
didn't quite understand why surfaces have scissors, if it is some kind
of overdraw reduction optimization but it is used when r_useScissor is
set to 1, and setting it to 0 also solved the issue for me.

Yep, setting r_useScissor to 0 clears the issue, but wasn't a viable solution due to performance impact.  I still don't understand why it persisted when I manually set the scissor to fullscreen immediately before blitting without it being a bug, or why if it was just a scissor issue it had such a negative impact on perfomance.  If I actually had more free time I'd be interested to go back and take another look at this, but hey, its working.


Leyland
Expert Protege
So to my implementation I decided to expand the radius beyond the body bounds, and I added a bound trace for the head to make sure it doesn't clip anything. The trace goes from the center of the body out to the location of the head, and if it collides it pops the head to the first collision. This is really the only important part, it occurs after attempting to move the body to the head but the head is going outside the bounds of the body:
idBounds bounds(idVec3(-5,-5,-5), idVec3(5,5,5));
gameLocal.clip.TraceBounds( trace, start, end, bounds, clipMask, self );

headOrigin = trace.endpos - current.origin;
headOrigin.z = 0;

With 'start' being the center of the body with a z height same as the heads destination, and the 'end' being the heads destination. It works, but obviously your head will pop in many cases, like you can lean over a rail but if you lean over to much the rail you will be pushed back from the rail. In same cases clipping still occurs, like I pushed my head against a door and the door was slightly clipped at the edge of the screen.

You can take a peak at the rest of my changes here:
https://github.com/Codes4Fun/RBDOOM-3-BFG/commit/65b789509f5c8219a4e8d6d79c8fa131c0a7d419

I have not released a binary of it yet, still working on some things.

Samson
Heroic Explorer
Well, I received my touch today, and took some time tonight to implement native oculus/touch support via the oculus SDK.  At first blush it appears to be working pretty well, although there are still some issues during loading screens.

 I also finished adding health and armor to the gui on the statwatch ( which still needs a better name) -   vertical bars on the left for health and right for armor. So now if you don't want to use the hud you can get most of the important info on your wrist.

Not a bad idea with the clip for the head.  I should probably do something similar instead of just clamiping the distance you can move the head from the body. 

Tomorrow when I'm not so tired Ill run another quick test , and post both binaries, (steamvr & oculus native) for some testing.  I just need to make sure to package a standard controller layout for the touch so I don't get crucified again.


Baz_uK
Expert Protege
Sounds good, cant wait to play Doom 3 BFG with Touch.

JohnnyDioxin
Expert Trustee
Yes - thanks for your efforts.

i5 9600k @4.5GHz; 16GB DDR4 3200; 6xSSD; RTX2080ti; Gigabyte Z390D Mobo
Rift CV1; Index; Quest; Quest 2

Samson
Heroic Explorer
Ok, I posted a test verison with native Oculus/Touch support.

https://github.com/KozGit/DOOM3-BFG-RIFT/releases/tag/v0.11-alpha

Please make a clean copy of your doom 3 directory before installing, right now this mod will not co-exist with the other one, as too many of the assets have been changed.

Take a look at the readme files included in the archive(two of them).  I also included a .pdf that lists most of the common cvars you can use to configure the mod.  Please remember all the controls ( all josystick axes and buttons) can be unbound or remapped to any other control in the system menus. (Settings->controlls->KeyBindings)

Theres still a little oddness during loading screens.  Let me know if you find any issues.

Leyland
Expert Protege
@Samson are you detecting controllers or plan to in the future? I was planning on doing that, but I don't have a Touch yet (not even a shipping email) so I don't know the best way to detect it is.

In OpenVR I was going to use either vr::Prop_ModelNumber_String or vr::Prop_Axis0Type_Int32. I do know that the axis type doesn't work with the Hydra (always returns vr::k_eControllerAxis_TrackPad instead of vr::k_eControllerAxis_Joystick), while the model number returns "Hydra" and "Vive Controller MV" (not really numbers but still different). I was hoping to special case Hydra through the model number and then use axis type for all other controllers assuming that axis type is accurate for the Touch. So I am curious if you have plans and/or if you have looked at these?


			char modelNumberString[ vr::k_unTrackingStringSize ];
int axisType;
const char * axisTypeString;

hmd->GetStringTrackedDeviceProperty(
g_openVRLeftController, vr::Prop_ModelNumber_String,
modelNumberString, vr::k_unTrackingStringSize );
axisType = hmd->GetInt32TrackedDeviceProperty( g_openVRLeftController, vr::Prop_Axis0Type_Int32 );
axisTypeString = hmd->GetControllerAxisTypeNameFromEnum( (vr::EVRControllerAxisType)axisType );
common->Printf("openvr: left model number \"%s\" axis type %s\n", modelNumberString, axisTypeString );