Project Cars 3D Vision
  8 / 30    
[quote="quarra933"]Absolutely amazing work you are doing, Mike! I've already tested lots of tracks and cars in various weather conditions found some bugs: - with rain and heavy rain, you need to adjust the A.I's back lighting reflected incorrectly on the wet ground. It happens when they brake. - always with rain or heavy rain, when you see A.I. cars in front of you running on the wet ground, you can notice another car shader rendered inside those white rain particles (or lets call it dense cloud of water particles) [/quote] Great, thanks for this feedback. The first effect you mention is the "lights" one I was talking about i.e. the tricky one. This is exactly how I noticed it initially. The second effect sounds the same as the dust haloing, so if bo3b's suggestion for fixing the decompiler issue works, I will be able to fix that as well. One thing I have not seen much of is "water" like rivers or lakes, fountains etc. The game might not have them of course, but water rendering is usually wrong in most games.
quarra933 said:Absolutely amazing work you are doing, Mike!
I've already tested lots of tracks and cars in various weather conditions
found some bugs:

- with rain and heavy rain, you need to adjust the A.I's back lighting reflected incorrectly on the wet ground.
It happens when they brake.
- always with rain or heavy rain, when you see A.I. cars in front of you running on the wet ground, you can notice another car shader rendered inside those white rain particles (or lets call it dense cloud of water particles)

Great, thanks for this feedback. The first effect you mention is the "lights" one I was talking about i.e. the tricky one. This is exactly how I noticed it initially. The second effect sounds the same as the dust haloing, so if bo3b's suggestion for fixing the decompiler issue works, I will be able to fix that as well.
One thing I have not seen much of is "water" like rivers or lakes, fountains etc. The game might not have them of course, but water rendering is usually wrong in most games.

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 05/11/2015 09:20 PM   
Nothing to add. I just wanted to add my thanks and show my appreciation for all your hard work getting this to work properly in 3D. You are massively improving the experience for the lucky folks that have this amazing kit. I switch between 3D Vision & Oculus DK2. There's no comparison to the 2D version of the sim. It's difficult to go back after having experienced both of these technologies. Thanks again Chris
Nothing to add. I just wanted to add my thanks and show my appreciation for all your hard work getting this to work properly in 3D. You are massively improving the experience for the lucky folks that have this amazing kit. I switch between 3D Vision & Oculus DK2. There's no comparison to the 2D version of the sim. It's difficult to go back after having experienced both of these technologies.

Thanks again
Chris

Posted 05/11/2015 10:07 PM   
Thank you again Mike! that big shadow ''of Mordor'' would be the next step to go, I hope... ;-) p.s. Inside the Mclaren P1 there's a strange shadow on the steering wheel, please check it as soon as you can!
Thank you again Mike!

that big shadow ''of Mordor'' would be the next step to go, I hope... ;-)

p.s. Inside the Mclaren P1 there's a strange shadow on the steering wheel, please check it as soon as you can!

Posted 05/11/2015 10:14 PM   
[quote="mike_ar69"]@ronrebell This solution is the only way to make it work. The game engine is making some internal call to stop rendering the OSD HUD, which is nothing to do with shaders, so inaccessible otherwise. This is the same trick for unlocking convergence in some games. I am not entirely sure why I need to have the shader fix that I do have, but without it I don't see the HUD for some reason. The only other solution is for the developer to sort this out.[/quote] I just did some experiments to see if I could force the game to think it doesn't have NvAPI, and it worked: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/64356/[/img] Needs some work to make this a real thing, but the proof of concept is that we won't need to edit the exe, and will be able to make the HUD on/off selectable via an iniParam. For alpha use- keep using the edit exe+shader fix. I won't be able to get to this until the weekend.
mike_ar69 said:@ronrebell This solution is the only way to make it work. The game engine is making some internal call to stop rendering the OSD HUD, which is nothing to do with shaders, so inaccessible otherwise. This is the same trick for unlocking convergence in some games. I am not entirely sure why I need to have the shader fix that I do have, but without it I don't see the HUD for some reason. The only other solution is for the developer to sort this out.

I just did some experiments to see if I could force the game to think it doesn't have NvAPI, and it worked:

Image

Needs some work to make this a real thing, but the proof of concept is that we won't need to edit the exe, and will be able to make the HUD on/off selectable via an iniParam.

For alpha use- keep using the edit exe+shader fix. I won't be able to get to this until the weekend.
Attachments

pCARS6403_85.jps

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 05/11/2015 11:09 PM   
[quote="bo3b"][quote="mike_ar69"]@ronrebell This solution is the only way to make it work. The game engine is making some internal call to stop rendering the OSD HUD, which is nothing to do with shaders, so inaccessible otherwise. This is the same trick for unlocking convergence in some games. I am not entirely sure why I need to have the shader fix that I do have, but without it I don't see the HUD for some reason. The only other solution is for the developer to sort this out.[/quote] I just did some experiments to see if I could force the game to think it doesn't have NvAPI, and it worked: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/64356/[/img] Needs some work to make this a real thing, but the proof of concept is that we won't need to edit the exe, and will be able to make the HUD on/off selectable via an iniParam. For alpha use- keep using the edit exe+shader fix. I won't be able to get to this until the weekend.[/quote] Ah, nice work mate! Definitely interested to now how you did that ;-) I tried the various params in the d3dx.ini file but they did not work. Are you overriding the nvapi_Query call to force a return of false or something?
bo3b said:
mike_ar69 said:@ronrebell This solution is the only way to make it work. The game engine is making some internal call to stop rendering the OSD HUD, which is nothing to do with shaders, so inaccessible otherwise. This is the same trick for unlocking convergence in some games. I am not entirely sure why I need to have the shader fix that I do have, but without it I don't see the HUD for some reason. The only other solution is for the developer to sort this out.

I just did some experiments to see if I could force the game to think it doesn't have NvAPI, and it worked:

Image

Needs some work to make this a real thing, but the proof of concept is that we won't need to edit the exe, and will be able to make the HUD on/off selectable via an iniParam.

For alpha use- keep using the edit exe+shader fix. I won't be able to get to this until the weekend.

Ah, nice work mate! Definitely interested to now how you did that ;-) I tried the various params in the d3dx.ini file but they did not work. Are you overriding the nvapi_Query call to force a return of false or something?

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 05/12/2015 02:03 AM   
[quote="mike_ar69"]Ah, nice work mate! Definitely interested to now how you did that ;-) I tried the various params in the d3dx.ini file but they did not work. Are you overriding the nvapi_Query call to force a return of false or something?[/quote] Yep, exactly, just a custom build to see what the game was looking for API wise, and where we might be able to lie to it successfully. That spot isn't quite right because the HUD is broken into two different eyes for some reason, rather than doubling the HUD like we'd want. In the worst case, I know we already hook NvAPI_Initialize, and I can always return false there which should be roughly comparable to hammering the nvapi in the exe. Will be a nice added option for other games in any case. BTW, that shot shows a missing shader in the car, where one hand is in light and the other in darkness. Edit: Also of note on that shot- the center console speedometer LCD display is at a different depth from the steering wheel. That shot is bad, the convergence is waaay too high. That's why the HUD showed in one eye only, off the screen. Returning just the NvAPI_IsStereoEnabled as false works, and shows the HUD, so we've got an easy way to get around this problem. This also means that they are using 3D Vision Automatic for the Oculus display, so someone with a DK2 should take Mike's alpha fix and give it a try. I think that it will fix all the broken shaders for Rift too.
mike_ar69 said:Ah, nice work mate! Definitely interested to now how you did that ;-) I tried the various params in the d3dx.ini file but they did not work. Are you overriding the nvapi_Query call to force a return of false or something?

Yep, exactly, just a custom build to see what the game was looking for API wise, and where we might be able to lie to it successfully.

That spot isn't quite right because the HUD is broken into two different eyes for some reason, rather than doubling the HUD like we'd want. In the worst case, I know we already hook NvAPI_Initialize, and I can always return false there which should be roughly comparable to hammering the nvapi in the exe.

Will be a nice added option for other games in any case.


BTW, that shot shows a missing shader in the car, where one hand is in light and the other in darkness.


Edit: Also of note on that shot- the center console speedometer LCD display is at a different depth from the steering wheel.

That shot is bad, the convergence is waaay too high. That's why the HUD showed in one eye only, off the screen. Returning just the NvAPI_IsStereoEnabled as false works, and shows the HUD, so we've got an easy way to get around this problem.

This also means that they are using 3D Vision Automatic for the Oculus display, so someone with a DK2 should take Mike's alpha fix and give it a try. I think that it will fix all the broken shaders for Rift too.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 05/12/2015 04:21 AM   
[quote="mike_ar69"]The main thing that will be very tricky is the lights at night time, as I described in an earlier post. The same shader to remove the black haloing moves the correctly rendered light reflections to screen depth, and then unfortunately the exact same Pixel shader that renders the effects that were haloing also renders the lights. So it's not like there is one VS and many PS, which makes separation of the fix easy. I need to find something unique about each case that I can separate by. I had this issue in RE6 and never solved it...[/quote] It's probably a bit of a long shot, but I did add two methods that could be used to filter fixes for FC4 that might help here (though from your description I'm not that hopeful): - You can add depth_filter=depth_inactive or depth_filter=depth_active to a [ShaderOverride] section to only use the replacement shader when the depth buffer is either active or inactive (In FC4 I used this to filter HUD adjustments that messed up other things). - You can add a partner=<hash> to a [ShaderOverride] section to only use the replacement shader when it is used in conjunction with a given partner shader. I used this in an early attempt to fix the regular god rays in FC4, but didn't use it in the final fix as I found a better place to fix them that didn't need this. Both of these are pretty basic at the moment, selecting either the original or replaced shader (we can improve that when we need something more advanced). Another trick I used in FC4 was to filter based on the dimensions of the active render target to determine when the shaders were drawing a reflection or not. There I was able to use a variable passed from the game to check this, but I always wanted to add the ability for 3Dmigoto to pass this in as an iniParam as well (there is one shader in FC4 where this would help - the glow around the sun/moon doesn't have access to the necessary variable from the game). If you can think of any other way you might be able to distinguish them let Bo3b or me know - we still need to add support for texture separation and other methods could turn out to be useful as well.
mike_ar69 said:The main thing that will be very tricky is the lights at night time, as I described in an earlier post. The same shader to remove the black haloing moves the correctly rendered light reflections to screen depth, and then unfortunately the exact same Pixel shader that renders the effects that were haloing also renders the lights. So it's not like there is one VS and many PS, which makes separation of the fix easy. I need to find something unique about each case that I can separate by. I had this issue in RE6 and never solved it...

It's probably a bit of a long shot, but I did add two methods that could be used to filter fixes for FC4 that might help here (though from your description I'm not that hopeful):

- You can add depth_filter=depth_inactive or depth_filter=depth_active to a [ShaderOverride] section to only use the replacement shader when the depth buffer is either active or inactive (In FC4 I used this to filter HUD adjustments that messed up other things).

- You can add a partner=<hash> to a [ShaderOverride] section to only use the replacement shader when it is used in conjunction with a given partner shader. I used this in an early attempt to fix the regular god rays in FC4, but didn't use it in the final fix as I found a better place to fix them that didn't need this.

Both of these are pretty basic at the moment, selecting either the original or replaced shader (we can improve that when we need something more advanced).

Another trick I used in FC4 was to filter based on the dimensions of the active render target to determine when the shaders were drawing a reflection or not. There I was able to use a variable passed from the game to check this, but I always wanted to add the ability for 3Dmigoto to pass this in as an iniParam as well (there is one shader in FC4 where this would help - the glow around the sun/moon doesn't have access to the necessary variable from the game).

If you can think of any other way you might be able to distinguish them let Bo3b or me know - we still need to add support for texture separation and other methods could turn out to be useful as well.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 05/12/2015 05:39 AM   
Really nice work Mike bo3b and all involved... just tried it out and it works brilliantly, massive improvement on the current state it was in, so thanks hugely for that. One minor bug I noticed with the Lotus78 open cockpit formula car is that a whole panel at the front of the cockpit is entirely missing such that you can see through to the road. It is behind the dash/steering wheel and as I drive this car alot I noticed it right away. So one of the shader changes must have dissolved the metal eh !? LOL nice work anyway, cheers :)
Really nice work Mike bo3b and all involved... just tried it out and it works brilliantly, massive improvement on the current state it was in, so thanks hugely for that.

One minor bug I noticed with the Lotus78 open cockpit formula car is that a whole panel at the front of the cockpit is entirely missing such that you can see through to the road. It is behind the dash/steering wheel and as I drive this car alot I noticed it right away.

So one of the shader changes must have dissolved the metal eh !? LOL nice work anyway, cheers :)

Posted 05/12/2015 12:18 PM   
[quote="blanes"]Really nice work Mike bo3b and all involved... just tried it out and it works brilliantly, massive improvement on the current state it was in, so thanks hugely for that. One minor bug I noticed with the Lotus78 open cockpit formula car is that a whole panel at the front of the cockpit is entirely missing such that you can see through to the road. It is behind the dash/steering wheel and as I drive this car alot I noticed it right away. So one of the shader changes must have dissolved the metal eh !? LOL nice work anyway, cheers :)[/quote] Thanks for the feedback, I think I know what that issue is. There is a decompiler bug that I need to manually correct, so I must have missed that one. I'll check it out.
blanes said:Really nice work Mike bo3b and all involved... just tried it out and it works brilliantly, massive improvement on the current state it was in, so thanks hugely for that.

One minor bug I noticed with the Lotus78 open cockpit formula car is that a whole panel at the front of the cockpit is entirely missing such that you can see through to the road. It is behind the dash/steering wheel and as I drive this car alot I noticed it right away.

So one of the shader changes must have dissolved the metal eh !? LOL nice work anyway, cheers :)

Thanks for the feedback, I think I know what that issue is. There is a decompiler bug that I need to manually correct, so I must have missed that one. I'll check it out.

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 05/12/2015 01:41 PM   
[quote="DarkStarSword"][quote="mike_ar69"]The main thing that will be very tricky is the lights at night time, as I described in an earlier post. The same shader to remove the black haloing moves the correctly rendered light reflections to screen depth, and then unfortunately the exact same Pixel shader that renders the effects that were haloing also renders the lights. So it's not like there is one VS and many PS, which makes separation of the fix easy. I need to find something unique about each case that I can separate by. I had this issue in RE6 and never solved it...[/quote] It's probably a bit of a long shot, but I did add two methods that could be used to filter fixes for FC4 that might help here (though from your description I'm not that hopeful): - You can add depth_filter=depth_inactive or depth_filter=depth_active to a [ShaderOverride] section to only use the replacement shader when the depth buffer is either active or inactive (In FC4 I used this to filter HUD adjustments that messed up other things). - You can add a partner=<hash> to a [ShaderOverride] section to only use the replacement shader when it is used in conjunction with a given partner shader. I used this in an early attempt to fix the regular god rays in FC4, but didn't use it in the final fix as I found a better place to fix them that didn't need this. Both of these are pretty basic at the moment, selecting either the original or replaced shader (we can improve that when we need something more advanced). Another trick I used in FC4 was to filter based on the dimensions of the active render target to determine when the shaders were drawing a reflection or not. There I was able to use a variable passed from the game to check this, but I always wanted to add the ability for 3Dmigoto to pass this in as an iniParam as well (there is one shader in FC4 where this would help - the glow around the sun/moon doesn't have access to the necessary variable from the game). If you can think of any other way you might be able to distinguish them let Bo3b or me know - we still need to add support for texture separation and other methods could turn out to be useful as well.[/quote] Thanks for this, I'll have a look at the new features.
DarkStarSword said:
mike_ar69 said:The main thing that will be very tricky is the lights at night time, as I described in an earlier post. The same shader to remove the black haloing moves the correctly rendered light reflections to screen depth, and then unfortunately the exact same Pixel shader that renders the effects that were haloing also renders the lights. So it's not like there is one VS and many PS, which makes separation of the fix easy. I need to find something unique about each case that I can separate by. I had this issue in RE6 and never solved it...

It's probably a bit of a long shot, but I did add two methods that could be used to filter fixes for FC4 that might help here (though from your description I'm not that hopeful):

- You can add depth_filter=depth_inactive or depth_filter=depth_active to a [ShaderOverride] section to only use the replacement shader when the depth buffer is either active or inactive (In FC4 I used this to filter HUD adjustments that messed up other things).

- You can add a partner=<hash> to a [ShaderOverride] section to only use the replacement shader when it is used in conjunction with a given partner shader. I used this in an early attempt to fix the regular god rays in FC4, but didn't use it in the final fix as I found a better place to fix them that didn't need this.

Both of these are pretty basic at the moment, selecting either the original or replaced shader (we can improve that when we need something more advanced).

Another trick I used in FC4 was to filter based on the dimensions of the active render target to determine when the shaders were drawing a reflection or not. There I was able to use a variable passed from the game to check this, but I always wanted to add the ability for 3Dmigoto to pass this in as an iniParam as well (there is one shader in FC4 where this would help - the glow around the sun/moon doesn't have access to the necessary variable from the game).

If you can think of any other way you might be able to distinguish them let Bo3b or me know - we still need to add support for texture separation and other methods could turn out to be useful as well.

Thanks for this, I'll have a look at the new features.

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 05/12/2015 01:44 PM   
[quote="bo3b"][quote="mike_ar69"]Ah, nice work mate! Definitely interested to now how you did that ;-) I tried the various params in the d3dx.ini file but they did not work. Are you overriding the nvapi_Query call to force a return of false or something?[/quote] Yep, exactly, just a custom build to see what the game was looking for API wise, and where we might be able to lie to it successfully. That spot isn't quite right because the HUD is broken into two different eyes for some reason, rather than doubling the HUD like we'd want. In the worst case, I know we already hook NvAPI_Initialize, and I can always return false there which should be roughly comparable to hammering the nvapi in the exe. Will be a nice added option for other games in any case. BTW, that shot shows a missing shader in the car, where one hand is in light and the other in darkness. Edit: Also of note on that shot- the center console speedometer LCD display is at a different depth from the steering wheel. That shot is bad, the convergence is waaay too high. That's why the HUD showed in one eye only, off the screen. Returning just the NvAPI_IsStereoEnabled as false works, and shows the HUD, so we've got an easy way to get around this problem. This also means that they are using 3D Vision Automatic for the Oculus display, so someone with a DK2 should take Mike's alpha fix and give it a try. I think that it will fix all the broken shaders for Rift too.[/quote] Thanks bo3b. There are a few things going on in that cockpit, what car was it? I think the shadows are due to that acb shader we discussed offline, so let me try it out.
bo3b said:
mike_ar69 said:Ah, nice work mate! Definitely interested to now how you did that ;-) I tried the various params in the d3dx.ini file but they did not work. Are you overriding the nvapi_Query call to force a return of false or something?

Yep, exactly, just a custom build to see what the game was looking for API wise, and where we might be able to lie to it successfully.

That spot isn't quite right because the HUD is broken into two different eyes for some reason, rather than doubling the HUD like we'd want. In the worst case, I know we already hook NvAPI_Initialize, and I can always return false there which should be roughly comparable to hammering the nvapi in the exe.

Will be a nice added option for other games in any case.


BTW, that shot shows a missing shader in the car, where one hand is in light and the other in darkness.


Edit: Also of note on that shot- the center console speedometer LCD display is at a different depth from the steering wheel.

That shot is bad, the convergence is waaay too high. That's why the HUD showed in one eye only, off the screen. Returning just the NvAPI_IsStereoEnabled as false works, and shows the HUD, so we've got an easy way to get around this problem.

This also means that they are using 3D Vision Automatic for the Oculus display, so someone with a DK2 should take Mike's alpha fix and give it a try. I think that it will fix all the broken shaders for Rift too.

Thanks bo3b. There are a few things going on in that cockpit, what car was it? I think the shadows are due to that acb shader we discussed offline, so let me try it out.

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 05/12/2015 01:46 PM   
Hi, I extracted the files from the pCars_3Dmigoto_Alpha0.02.rar in the folder where the game exe is, but when I start the game the picture through my left eye (glass) is very, very dark, the picture through my right eye is normal. Perhaps it doesn't work in 3D surround with your fix or am I doing something wrong? EDIT: after some restarts (without changing anything!) suddenly it worked. Thank you!!
Hi, I extracted the files from the pCars_3Dmigoto_Alpha0.02.rar in the folder where the game exe is, but when I start the game the picture through my left eye (glass) is very, very dark, the picture through my right eye is normal.
Perhaps it doesn't work in 3D surround with your fix or am I doing something wrong?

EDIT: after some restarts (without changing anything!) suddenly it worked. Thank you!!

Win 8.1 pro 64 bit, Gigabyte Z87X-D3H - i7-4770K@3.5 - 32 GB, 2x Geforce TITAN SLI (EVGA), 3x ASUS 3D-Vision-Monitors

Posted 05/12/2015 04:31 PM   
Hi Mike, when are you going to release the next version? are there any chances for better lights in future? p.s. Mike, look at Dubai Autodrome National, there you will find more shaders rendered at wrong depth!
Hi Mike, when are you going to release the next version? are there any chances for better lights in future?


p.s. Mike, look at Dubai Autodrome National, there you will find more shaders rendered at wrong depth!

Posted 05/12/2015 05:38 PM   
Very impressive job particularly in such a short amount of time guys. Thank you so much. I now choose my games depending on your fixes :) All this to say I am very grateful, however in my case, PCars performances get an unusual drop for 3dvision. Maybe this is due to Vram as mentioned earlier but it looks strange to me since Vram issue usually provide irregular framerate, here it is regularly low (Maxed out except AA I would say 20fps average). Even with lower settings in training mode (so one car, no rain, daytime), with all options set to high or medium (except cars and track quality at ultra and medium SMAA) I get kind of poor framerate with few drops under 30 fps I got an AMD FX 8 core at 4.6Ghz and two OC 970GTX in sli, win7 64, last drivers. I will investigate about GPU usage VRAM usage and exact framerate but such perfs look strange to me, didn't someone said at the beginning of the thread a 970GTX was enough to run the game through Tridef Maxed out at 60fps? Anyway, thanks again.
Very impressive job particularly in such a short amount of time guys. Thank you so much.
I now choose my games depending on your fixes :)

All this to say I am very grateful,
however in my case, PCars performances get an unusual drop for 3dvision.

Maybe this is due to Vram as mentioned earlier but it looks strange to me since Vram issue usually provide irregular framerate, here it is regularly low (Maxed out except AA I would say 20fps average).
Even with lower settings in training mode (so one car, no rain, daytime), with all options set to high or medium (except cars and track quality at ultra and medium SMAA) I get kind of poor framerate with few drops under 30 fps
I got an AMD FX 8 core at 4.6Ghz and two OC 970GTX in sli, win7 64, last drivers.
I will investigate about GPU usage VRAM usage and exact framerate but such perfs look strange to me, didn't someone said at the beginning of the thread a 970GTX was enough to run the game through Tridef Maxed out at 60fps?

Anyway, thanks again.

-PSU:Enermax 850W Revolution 87+.
-MB:ASRock 990FX Extreme 9.
-CPU:AMD FX 9590.
-Cooler: Fractal Design Kelvin S36.
-RAM:16GB DDR3 1866 Kingston Hyper X.
-GPU:GTX1080 @1808/1947, Memory 11000.
-PhysXGPU: GTX570
-HDD:2*256 GB Samsung SSD.
-Screen1:ASUS VG278H 3DVision2.
-Screen2:SAMSUNG 60F6400 LED 3DTVPlay.
-Screen3:HTC Vive.
-OS:Win10 Pro 64.

Posted 05/12/2015 07:56 PM   
Haven't touched a racing game since F1 2012 because there was no good sim in 3D. With this fix, insta-buy. Thanks!!!!!!!!!!!!
Haven't touched a racing game since F1 2012 because there was no good sim in 3D. With this fix, insta-buy. Thanks!!!!!!!!!!!!

i7-6700k @ 4.5GHz, 2x 970 GTX SLI, 16GB DDR4 @ 3000mhz, MSI Gaming M7, Samsung 950 Pro m.2 SSD 512GB, 2x 1TB RAID 1, 850w EVGA, Corsair RGB 90 keyboard

Posted 05/12/2015 08:16 PM   
  8 / 30    
Scroll To Top