Jump to content

DiRT Rally 2.0 - Version 1.8 VR Feedback

Recommended Posts

On 9/7/2019 at 2:35 AM, SteaveG said:

The game runs great.  Love it. 

However, after the 1.8 update, I get squished/distorted overlay text (Turn Hints, Time, Progress, "Hold Handbrake, etc.)

The only other thing that I think would matter is that I have also run the game in desktop mode with "-novr" but I run the game normally through Oculus home.

Deleting hardware_config_settings.ini fixes the UI elements but I can no longer connect to RaceNet.  However, chagning this line:

        <resolution width="1920" height="1080" aspect="auto" 

to this: 

        <resolution width="1366" height="768" aspect=".56"

fixed the problem.

But I imagine I will have the same problem if I run the game in Desktop mode again.

Edited by SteaveG
Additional information

Share this post


Link to post
Share on other sites

Please. please, please disable, or have an option to disable, the chaperone in the Steam version.

I have roomscale VR setup, but my racing cockpit setup is obviously outside of where I can move around freely without bumping into things. The net result of this is that when I start driving in Dirt Rally 2, I see a big box outlining the floor where my play space is in front of me that is distracting as hell.

I've set the chaperone to the Developer setting and reduced the Alpha channel as much as I can, but I still see a white 2 x 3 meter box just off to my left (see attached image).

I raised it as a support ticket with Steam who said there are no 'official' ways of disabling the chaperone beyond what I've already done, but the game developer can choose how and if the chaperone is called into play and they suggested raising it directly with you.

Right now my only option is to run the room setup each time I want to use a different type of VR experience, but even then when setting up as standing only, I still have a white circle beneath me in Dirt Rally 2.

 

 

VR Setup.jpg

left_eye.jpg

Edited by highwaymaned
Added VR View
  • Agree 4

Share this post


Link to post
Share on other sites

@PJTierney

Ive been doing some more testing in VR, and I have come across something interesting. It seams running the old tracks from Dirt Rally 1 in VR within DR2.0; yeilds a highly playable experience (for me at least). Very smooth, with just what appears to be a small bit of headset tracking lag when moving my head left/right. With my testing I have been running Wales at night in the rain, giving everything what should be a worst case scenario (night and rain are usually more demanding than daylight and dry conditions to render). As you can see from my linked recording, with fairly high graphical settings as well. It was perfectly fine, any minor stuttering in the video is because gameplay is 90fps and recording is 60fps, and wasnt present in said gameplay.
 

Ive run this test on the other stages that have been ported over from Dirt Rally 1, and its the same experience for me; smooth and highly playable. Baring again, headset tracking lag when looking left/right. I even bought the second season pass to test this on Greece, and its the same highly playable VR experence with exactly the same settings as in the above Wales video.

When running stages that shipped with DR2.0 however, its a different story entily. I get constant framerate drops, bad frame times; and vomit inducing stuttering. I found, thus far, Argentina and New Zealand to be the best stages from DR2.0 in VR. I get a "managable" VR experiance on those stages. Poland appears to be ok, but only run the stage that is getting used in the qualifier. The worst by far, on my system at least, is Spain. Especially if there are buildings present, which amplifies the mentioned issues exponentially. This is regardless of graphical settings. Even with everything set to the lowest possible settings, its still the same. This is in daylight and dry condidtions.

This, from my perspective anyway, may point to a potential issue with enviroment level optimization. It might be worth someone looking at the stages as they currently stand, and seeing if there are any eronious polys or duplications of meshes hiding anywhere in the DR2.0 enviroments included in the base game. It just seems odd I can run Wales in VR with such high settings at night and in the rain, yet I cant run Spain (or other stages from DR2.0's base game) the same.

Anyway, I hope my findings help pinpoint potential issues.

  • Agree 1

Share this post


Link to post
Share on other sites
On 9/3/2019 at 9:56 PM, ChampionHawker said:

I find that the world view is very laggy in VR.

It´s the same here. Good framerates, bit when I move the head to left or right, up or down there is small lag remarkable. Very annoying.....!!!!!!!!!!!!!!

 

PC 8700k, 32GB, 2080ti, SSD only, Valve index @80Hz (no change with 90hz or more - only more stuttering)

  • Agree 3

Share this post


Link to post
Share on other sites
Quote

 

Right so i have found the issue with SteamVR on Oculus. Running your GPU below roughly 75% utlization will result in head stutter when moving your viewpoint. Now increase the settings to 80-90% GPU utlization and the head stutter will be gone.

So now CM has the cause now it's just up to them to fix it 🙂

Share this post


Link to post
Share on other sites

I have the 2 second stutter issue in the original Dirt Rally, which I've tracked down to it polling for new input devices.  I suspect it could be the same in Dirt Rally 2.0, which I don't yet own, but I've been keeping a close eye on for VR.  I'm using Windows 10 x64 v1903 with a Valve Index HMD and the current SteamVR beta.

I captured a CPU snapshot of the spikes seen in the SteamVR Frame Timing window. That showed the activity was a call to DINPUT8!EnumDevices, which came from drt.exe via the Steam overlay hooks in GameOverlayRenderer.dll.  Back in drt.exe it was sleeping for 2000ms and then looping back round to enumerate input devices, presumably to check if any new controllers had been plugged in.  Editing the 2 second sleep to 10 second changed the frequency of the CPU spikes in the timing window, confirming it to be the source.  Why it stalls everything so badly isn't currently known, but is probably a shared lock somewhere.

Could someone in the development team check if it's the same issue with DR2?  Ideally, could that thread only be polling in the menus and when the game is paused?  If I get a chance I might knock up a utility to disable the device enumeration a minute after startup.

Edit: For a quick test on the original Dirt Rally I've just hex-edited drt.exe and changed the sequence FF 68 D0 07 00 00 FF to FF 68 D0 07 00 01 FF.  That causes it to enumerate devices only once and then sleep for a loooong time.  As long as my wheel/pedals/shifter are plugged in when the game is started it's fine, and the game no longer glitches. It may be a different instruction pattern in DR2, and any module changes could trigger anti-cheat protection, so experiment at your own risk!

Edited by obo
test patch for DR1
  • Agree 3

Share this post


Link to post
Share on other sites
5 hours ago, obo said:

I have the 2 second stutter issue in the original Dirt Rally, which I've tracked down to it polling for new input devices.  I suspect it could be the same in Dirt Rally 2.0, which I don't yet own, but I've been keeping a close eye on for VR.  I'm using Windows 10 x64 v1903 with a Valve Index HMD and the current SteamVR beta.

I captured a CPU snapshot of the spikes seen in the SteamVR Frame Timing window. That showed the activity was a call to DINPUT8!EnumDevices, which came from drt.exe via the Steam overlay hooks in GameOverlayRenderer.dll.  Back in drt.exe it was sleeping for 2000ms and then looping back round to enumerate input devices, presumably to check if any new controllers had been plugged in.  Editing the 2 second sleep to 10 second changed the frequency of the CPU spikes in the timing window, confirming it to be the source.  Why it stalls everything so badly isn't currently known, but is probably a shared lock somewhere.

Could someone in the development team check if it's the same issue with DR2?  Ideally, could that thread only be polling in the menus and when the game is paused?  If I get a chance I might knock up a utility to disable the device enumeration a minute after startup.

Edit: For a quick test on the original Dirt Rally I've just hex-edited drt.exe and changed the sequence FF 68 D0 07 00 00 FF to FF 68 D0 07 00 01 FF.  That causes it to enumerate devices only once and then sleep for a loooong time.  As long as my wheel/pedals/shifter are plugged in when the game is started it's fine, and the game no longer glitches. It may be a different instruction pattern in DR2, and any module changes could trigger anti-cheat protection, so experiment at your own risk!

Curious as to if that's also related to USB input devices I mentioned in the last post here:

 

Does your issue also clear if you go through the USB input devices and disable them?

Share this post


Link to post
Share on other sites
4 hours ago, nbates66 said:

Curious as to if that's also related to USB input devices I mentioned in the last post here:

...

Does your issue also clear if you go through the USB input devices and disable them?

Yes, switching off my wheel clears the performance spikes. If I switch it back on I see a flurry of activity at the time I hear the device arrival notification, and the spikes return.  I get the same behaviour switching my USB HOTAS on and off too.  That's to be expected as the IDirectInput8::EnumDevices call the game makes passes DI8DEVCLASS_GAMECTRL, which is asking only for game controller devices.

The DR2 performance graph posted in the previous thread looks suspiciously similar to what I'm seeing in DR1, so I suspect it's the same problem. I might have to pick up the new game early to check it here.

In the meantime I'm going to keep looking into why/how the background input thread processing is hurting game performance.

  • Like 1
  • Agree 1

Share this post


Link to post
Share on other sites

@PJTierney Could we please have a slider or option to select something between "Enable locked orientation" in the VR comfort settings?  Locked to vehicle is probably my preference but over really bumpy roads it would be nice to have a little "head physics" but not all the way to the floaty locked to horizon. Hope that makes sense. Basically something in between on and off would be ideal.

  • Agree 4

Share this post


Link to post
Share on other sites

i7 6700K / 8GB / SSD 2x256GB / 1080 / HTC VIVE

 

The issue I describe in other posts. Not related to perfs or tracking.

Might be related though to the default incorrect position of the head (few centimeters behind the pilot) when starting a race.

Me correcting my position right away, but pivot of my head remaining behind might be the problem.

I don't have the strength to try again, I'm still sick from yesterday's tests.

 

Description of problem:

When I'm moving my head, the world around me (and mostly the cockpit which is closer) is moving with it, as if the pivot point of the world is different from the pivot point of my head. It feels the pivot point of the world is slightly outside my head, so when my head is moving, the world is kind of wobbly.

A little bit like this, but the other way round:
https://youtu.be/cppAegdR18c?t=41

Edited by beeblo

Share this post


Link to post
Share on other sites
On 9/12/2019 at 4:06 PM, Ialyrn said:

@PJTierney

Ive been doing some more testing in VR, and I have come across something interesting. It seams running the old tracks from Dirt Rally 1 in VR within DR2.0; yeilds a highly playable experience (for me at least). Very smooth, with just what appears to be a small bit of headset tracking lag when moving my head left/right. With my testing I have been running Wales at night in the rain, giving everything what should be a worst case scenario (night and rain are usually more demanding than daylight and dry conditions to render). As you can see from my linked recording, with fairly high graphical settings as well. It was perfectly fine, any minor stuttering in the video is because gameplay is 90fps and recording is 60fps, and wasnt present in said gameplay.
 

Ive run this test on the other stages that have been ported over from Dirt Rally 1, and its the same experience for me; smooth and highly playable. Baring again, headset tracking lag when looking left/right. I even bought the second season pass to test this on Greece, and its the same highly playable VR experence with exactly the same settings as in the above Wales video.

When running stages that shipped with DR2.0 however, its a different story entily. I get constant framerate drops, bad frame times; and vomit inducing stuttering. I found, thus far, Argentina and New Zealand to be the best stages from DR2.0 in VR. I get a "managable" VR experiance on those stages. Poland appears to be ok, but only run the stage that is getting used in the qualifier. The worst by far, on my system at least, is Spain. Especially if there are buildings present, which amplifies the mentioned issues exponentially. This is regardless of graphical settings. Even with everything set to the lowest possible settings, its still the same. This is in daylight and dry condidtions.

This, from my perspective anyway, may point to a potential issue with enviroment level optimization. It might be worth someone looking at the stages as they currently stand, and seeing if there are any eronious polys or duplications of meshes hiding anywhere in the DR2.0 enviroments included in the base game. It just seems odd I can run Wales in VR with such high settings at night and in the rain, yet I cant run Spain (or other stages from DR2.0's base game) the same.

Anyway, I hope my findings help pinpoint potential issues.

@PJTierney Been doing even more testing on and off today, I was running with the Oculus performance monitor open within my HDM. If I have either of my two TH8A shifters plugged in, I get a spike every 2 seconds that tanks the performance of the system. Unplugging both the TH8A shifters solves that problem. Only issue is, I like to actually use them for the purpose of shifting (one is in H pattern mode), and the other for use as a handbrake.

Even with that taken into account, I still get insane amounts of stutter on Spain, especially if there are buildings present in view. Regardless of graphical settings. Every other stage appears playable if I disconnect both TH8A shifters. And even the HMD tracking stutter was completely gone while looking left/right. Just from removing my 2 TH8A shifters. This USB polling issue and the VR stuff really needs fixing.

P.S I was running with everything on "high" with screen space reflections set to "replay", Crowd turned off, and the advanced camera/lighting effects set to "replay". Pretty much the same settings as in the video in my last post. My FPS was a rock solid 90 all the way through my testing, even on the stuttering mess that is spain. I looked at the GPU and CPU useage after running a couple of sprint stages, and my CPU usage on a 6700k was at 30 to 40%, my GPU (gtx 1080) usage was between 50 and 70%. For what ever reason, the ultilisation by DR2.0 is low.
 

Edited by Ialyrn
  • Agree 3

Share this post


Link to post
Share on other sites

I'm also experiencing USB-polling issue in couple of seconds intervals. It is not only related to VR, as I read about it soon after DR2.0 was released and somebody mentioned that it was enough for him to open the Device Manager in Windows for the polling state to clear up. Lo and behold that actually worked for me too. It does not even have to be left open; opening up and closing it once fixes the issue for me until the next reboot.

SteamVR developer FPS graph shows the spikes very well when you are driving a stage and they clear up immediately the device manager has been opened. (Disable fullscreen for this as otherwise it loads all assets and drops into low resolution mode.)

In the menus it cannot be seen so clearly as the motion smoothing and reprojection jumps in all the time for some reason but it is there too...

My system specs with all plugged in USB devices are:

Quote

i9-9900K (8 core), 32 GB mem
ASUS Z390-H motherboard
nVidia RTX-2080ti
Valve Index HMD
Thrustmaster TS-PC Racer wheel
Thrustmaster TH8A shifter
VKBsim Gladiator Mk.II joystick
DasKeyboard Ultimate keyboard
SteelSeries Rival 100 mouse

My previous HW combination that had the same issue with DR2.0:

Quote

i7-6900K (8 core), 32 GB mem
ASUS X-99a USB3.1 motherboard
nVidia RTX-2080ti
Oculus Rift CV1 HMD
Thrustmaster TS-PC Racer wheel
SST Lightning shifter (very old, has not been in sale for 10 years)
VKBsim Gladiator Mk.II joystick
DasKeyboard Ultimate keyboard
SteelSeries Rival 100 mouse

So as can be seen here, in my case at least following components didn't seem to have effect on it: CPU, motherboard, virtual HMD, shifter.

What is left from the old combo are: display adapter, wheel, joystick, keyboard and mouse. And of course my Windows 10 installation; there was not need to reinstall it after changing the components.

Notable is that while opening up and closing the Device Manager cures the issue, should I later unplug and replug the wheel again, the issue is triggered again too. The game does not need to be running for this to happen, so basically it should be unaware of the unplugging of the wheel. From this one could deduce that the issue itself might be in Windows (or more specifically a bug in some API it offers for this), but it is just more visible in DR2.0 because it polls for the USB-devices so frequently. I assume the polling triggers an IRQ (interrupt request) that halts everything for a brief time.

Also it may be of note that high end nVidia display adapter models have had USB-C hub in them for some time now, and it could be that the full polling cycle for devices could cause hiccups all the way to display adapter too, should the IRQ not touch it otherwise already.
(I just had issues with bad driver installation of RTX-2080ti's builtin audio adapter and it seemed to cause similar symptoms for the framerate in 3d modes. So display adapters doing stuff they didn't use to do can cause new tricky situations.)

Edit: More testing...
After starting my computer DasKeyboard, TH8A shifter and VKBsim Gladiator all unplugged I did not have the issue ongoing. After replugging them one by one in that order and starting the game in between the every change, the issue did not trigger. It also did not trigger after full power cycle with all devices plugged in anymore. The power cycle was done from the mains for couple of minutes because ASUS mobos have a builtin USB aware OS running in them and I wanted to rule that out too.
It is possible that enumeration and initialization order of USB devices matter for this issue to triggerer in Windows. (Now I really think it is a problem in Windows or some device drivers, and that DR2.0 just happens to use a method for USB device polling that makes it more visible.)

Final edit:
I was able to rule out keyboard, shifter and joystick. Only wheel, mouse and the empty USB hubs of Valve Index and display adapter were left and the issue persisted until I unplugged the wheel. Why the issue cleared itself up in previous test I don't know. Maybe plugging in different USB devices in particular order may occasionally trigger something in Windows that cleans up the conflict.

The absolutely very last edit:
There is a fix for USB-enumeration based stuttering bug for all DIRT games, and it fixed my issue too. See:
https://github.com/simonowen/dirtfix

 

Edited by ButWhyMrDuck
Added more details, more testing, and the fix
  • Like 1

Share this post


Link to post
Share on other sites

I hat switched off the (unused) USB-C-Port of my 2080ti and no change remakable. It is still a laggy world

Share this post


Link to post
Share on other sites

@PJTierney I caved and purchased the Oculus Store version of the game in order to do some more testing in VR. Its so much better.

Testing the performance difference between the Oculus Store and Steam versions of this game in VR. I tested on Spain, as I found it to be the worst Rally from an FPS performance stand point within the steam version of the game when using VR. I also turned off ASW using "Oculus Tray Tool" in order to read the FPS properly, and to make sure temps where not a factor at all; I have been running aircon to cool my studio room to 18° before playing, and turned the CPU and GPU fans up to a fixed speed setting of 90%. The in game graphical settings are the same between both versions of the game (the same settings as in my last video I posted in this thread), but I have reduced the resolution in SteamVR on the steam version by a considurable amount. Its the ONLY way I can get anywhere near a playable and somewhat stable FPS on the steam version of the game in VR. I used Oculus Mirror and OBS in order to record the Oculus performance overlay with the gameplay. All this was to make sure it is an apples to apples comparison, with the only difference been between SteamVR and the Oculus version of the game.

Its a night and day difference in terms of performace, the Oculus store version performed miles better on all stages. The headset tracking stutter in the steam version was not present in the Oculus Store version, so made for a vastly smoother experience. I did still get a frame rate drop around the buildings near the start of the stage in the video, but no way near as bad as the SteamVR version performed in the same area. It remained highly playable on the Oculus store version. Either way, there is something not right at Spain. At least with this new video of mine, the Devs can see the areas that are causingthe drops, and can potentially find what is causing the FPS to tank in both versions of the game in those areas. From the Rallys stages I have loaded up, Spain is the only one that exhibits this specific frame drop; in either the Steam or Oculus store versions. The Oculus store version though, even with ASW turned off for framerate reading purposes, remained totally playable for me.

Its really annoying though, because now I have to choose between playing a version in VR that is actually playable in VR but without DLC, or playing a version that is terrible in VR but has all the DLC.

I did have to run the Oculus Store version through steam in order to get any game audio however, that needs correcting. If I launch through the Oculus app or via Oculus home while wearing the headset, I get no audio at all.
 

 

  • Thanks 1

Share this post


Link to post
Share on other sites
6 hours ago, PJTierney said:

 

 

1.8.1 is not available at Oculus Home, and 1.9 patch notes don't say anything about the no sound problem that is affecting some Oculus users (but I'm glad there are fixes for the audio cutting mid-stage). I guess they didn't manage to replicate it.

Share this post


Link to post
Share on other sites
8 hours ago, PJTierney said:

 

Is a bug which makes VR player to stuck after attempt of editing setup name fixed? Is it a part of "General stability improvements and minor bug fixes throughout title"
Is dev team aware about this issue? Actually it could be considered as major issue, cause once it happens, there is no other way than close the game (ie ALT+F4).

Edited by MaXyMsrpl

Share this post


Link to post
Share on other sites
On 9/25/2019 at 9:51 PM, JuanEtxeb said:

 

1.8.1 is not available at Oculus Home, and 1.9 patch notes don't say anything about the no sound problem that is affecting some Oculus users (but I'm glad there are fixes for the audio cutting mid-stage). I guess they didn't manage to replicate it.

I have the no audio issue on the Oculus home version as well, I had to add it into my steam library and called it "DR2.0 Oculus Store". Then I start "oculus home" and then run the game from the steam library instead. This gives me sound in the Oculus Store version every single time. If I run the game direct from the Oculus app or while in the HMD itself, I got zero sound 100% of the time.

@PJTierney The no sound issue on the Oculus Store version is actually really bad. Not everyone will know there is a work around in order to get audio to work on the Oculus store version. Could you let us know if the devs are looking into it???

Share this post


Link to post
Share on other sites
5 hours ago, Ialyrn said:

I have the no audio issue on the Oculus home version as well, I had to add it into my steam library and called it "DR2.0 Oculus Store". Then I start "oculus home" and then run the game from the steam library instead. This gives me sound in the Oculus Store version every single time. If I run the game direct from the Oculus app or while in the HMD itself, I got zero sound 100% of the time.

 

Yes, that works for me too... I can't believe it only affects a very small fraction of Oculus users, but it's there, there are lots of reports. And not a single word from Codemasters about it.

Share this post


Link to post
Share on other sites

Even after the 1.9 update, I still see my Chaperone, is there a setting somewhere that needs to be changed, I can't find one within the game...

Share this post


Link to post
Share on other sites
4 hours ago, highwaymaned said:

Even after the 1.9 update, I still see my Chaperone, is there a setting somewhere that needs to be changed, I can't find one within the game...

You haven't updated yet.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×