1) Decal on ground- fixed with another PS below.
2) Blue light from sniper+bloom on tail lights of car. Same shader, but it's notable that it varies with convergence. I can dial it up to match at 3.0 convergence. e9849e745227d124-vs_replace.txt
3) Lights on desert. Can't find it, might have been a night-time water thing.
Fixed another decal shader, 40ee678464eb9621-ps_replace.txt:
// Multiplying by depth for view space coords?
// Need to adjust before subtracting InstanceConsts[4]
// r0.xyz = v2.xyz * r0.xxx + -InstanceConsts[4].xyz;
r0.xyz = v2.xyz * r0.xxx;
[quote="bo3b"]Fixed another decal shader, 40ee678464eb9621-ps_replace.txt:[/quote]
That one didn't compile for me, I think there's a copy + paste issue, this makes it compile again:
https://github.com/DarkStarSword/3d-fixes/commit/38f85226fcf86bd63201de8bd24a10cd739866ee
I will add that decal shader.
For the Blue Light from sniper, i fix that shader (works dynamics depending of the distance of the sniper)...i'm using 3.2 of convergence and is looking ok. I will double check. the fixing code is this, so this will works for any convergence value (maybe a SLI or driver issue?)
[code]o0.x += stereo.x * (o0.w - stereo.y) / 2;[/code]
The bloom in the same shader is render in one eye, and is not affected by the fixing code... i try a couple of things and the bloom is still render in one eye. i left that way :(
The car light on desert i think i fix it in the last update (i add 4 lights shaders and one was some light in front of a car at night)
Thanks!!
For the Blue Light from sniper, i fix that shader (works dynamics depending of the distance of the sniper)...i'm using 3.2 of convergence and is looking ok. I will double check. the fixing code is this, so this will works for any convergence value (maybe a SLI or driver issue?)
o0.x += stereo.x * (o0.w - stereo.y) / 2;
The bloom in the same shader is render in one eye, and is not affected by the fixing code... i try a couple of things and the bloom is still render in one eye. i left that way :(
The car light on desert i think i fix it in the last update (i add 4 lights shaders and one was some light in front of a car at night)
I found the last point light I fixed broke several others... easily fixed again:
https://github.com/DarkStarSword/3d-fixes/commit/a744bd45716309b054d812c5793c28fe73315371
I'm going to have a quick look at the bloom and see if I can make it work in both eyes.
I used frame analysis to identify the problem with the bloom and fixed it via a TextureOverride:
[code]
[TextureOverrideBloom]
; Force downsampled bloom render target to stereo to fix mono bloom:
; <RenderTarget hash=b190ee3c type=Texture2D Width=90 Height=90 MipLevels=1 ArraySize=1 RawFormat=26 Format="R11G11B10_FLOAT" SampleDesc.Count=1 SampleDesc.Quality=0 Usage=0 BindFlags=40 CPUAccessFlags=0 MiscFlags=0></RenderTarget>
Hash=b190ee3c
StereoMode=1
[/code]
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/66362/[/img]
[quote="bo3b"]2) Blue light from sniper+bloom on tail lights of car. Same shader, but it's notable that it varies with convergence. I can dial it up to match at 3.0 convergence. e9849e745227d124-vs_replace.txt[/quote]
I've had a bit of a look at this, and I can't find any naive way to fix it for all circumstances and have confirmed using frame analysis that it simply does not have access to the depth of the light source, nor the matrix of the light source to do the right thing.
So, all we can do for now is kill it or move it to a fixed depth that looks good enough.
As this is a common problem in a lot games I have been thinking about ways to solve it, and I've currently got a few ideas:
1. Inject the depth buffer into the shader, and use a variation of the experimental code I was playing with for the auto UI depth in the Witcher 3 to try to move it to roughly the correct position. This would probably work pretty well, but might cause the light to move to the wrong depth when another object is nearby on the depth buffer. This is potentially doable today, but I never resolved the reported memory leak in 3DMigoto using this feature, and have plans to scrap that code once I get the arbitrary resource copying working (which can do the same thing, but better).
2. Once I get the arbitrary resource copying working, copy the constant buffer containing the matrix of the light source to the light bloom shader and use that to determine the depth. This won't work reliably when there are multiple lights in the scene as you would get the matrix for whichever was drawn last, but might turn out to be ok.
3. ok, I have a really wacky idea I've been thinking about that has the potential to solve this 100% (maybe)... Similar to 2 in that we are copying the matrix from the shaders responsible for the light source, but collect all of them that are drawn in a frame, then in the bloom shader go through each of them and compare the X + Y coordinates to find the closest one to the bloom, then use the depth from that. I don't want to move too much of the logic to do this into 3DMigoto itself because the specifics will vary for each game, so I've been thinking about using an AppendStructuredBuffer to get the shaders to store the matrices - only problem is I'd need to do that once per instance, which would be easy from a vertex shader - but I can only use an append structured buffer from a SM5 pixel shader :( I could maybe inject a compute shader to do it though... hmmm....
For now this is just food for thought - the first one we could potentially try today (maybe, I haven't checked if the depth buffer is enabled when the bloom is drawn in this game), but was reported to have some memory leaks, so I wouldn't recommend it yet. The second will require me to finish the code I've been working on, and the third will require code I haven't started to write and am still not entirely sure how it would work.
bo3b said:2) Blue light from sniper+bloom on tail lights of car. Same shader, but it's notable that it varies with convergence. I can dial it up to match at 3.0 convergence. e9849e745227d124-vs_replace.txt
I've had a bit of a look at this, and I can't find any naive way to fix it for all circumstances and have confirmed using frame analysis that it simply does not have access to the depth of the light source, nor the matrix of the light source to do the right thing.
So, all we can do for now is kill it or move it to a fixed depth that looks good enough.
As this is a common problem in a lot games I have been thinking about ways to solve it, and I've currently got a few ideas:
1. Inject the depth buffer into the shader, and use a variation of the experimental code I was playing with for the auto UI depth in the Witcher 3 to try to move it to roughly the correct position. This would probably work pretty well, but might cause the light to move to the wrong depth when another object is nearby on the depth buffer. This is potentially doable today, but I never resolved the reported memory leak in 3DMigoto using this feature, and have plans to scrap that code once I get the arbitrary resource copying working (which can do the same thing, but better).
2. Once I get the arbitrary resource copying working, copy the constant buffer containing the matrix of the light source to the light bloom shader and use that to determine the depth. This won't work reliably when there are multiple lights in the scene as you would get the matrix for whichever was drawn last, but might turn out to be ok.
3. ok, I have a really wacky idea I've been thinking about that has the potential to solve this 100% (maybe)... Similar to 2 in that we are copying the matrix from the shaders responsible for the light source, but collect all of them that are drawn in a frame, then in the bloom shader go through each of them and compare the X + Y coordinates to find the closest one to the bloom, then use the depth from that. I don't want to move too much of the logic to do this into 3DMigoto itself because the specifics will vary for each game, so I've been thinking about using an AppendStructuredBuffer to get the shaders to store the matrices - only problem is I'd need to do that once per instance, which would be easy from a vertex shader - but I can only use an append structured buffer from a SM5 pixel shader :( I could maybe inject a compute shader to do it though... hmmm....
For now this is just food for thought - the first one we could potentially try today (maybe, I haven't checked if the depth buffer is enabled when the bloom is drawn in this game), but was reported to have some memory leaks, so I wouldn't recommend it yet. The second will require me to finish the code I've been working on, and the third will require code I haven't started to write and am still not entirely sure how it would work.
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
There's something weird going on with this bloom shader in general - the effect is *far* more pronounced than it is in 2D, which becomes apparent when separation is more than a few percent. It also gets clipped out in one eye depending on the camera angle... I suspect it's using the depth buffer to determine opacity and is being thrown out based on the fact the depth buffer has moved. I'm not entirely sure what is responsible for that yet.
[quote="DarkStarSword"]1. Inject the depth buffer into the shader, and use a variation of the experimental code I was playing with for the auto UI depth in the Witcher 3 to try to move it to roughly the correct position. This would probably work pretty well, but might cause the light to move to the wrong depth when another object is nearby on the depth buffer. This is potentially doable today, but I never resolved the reported memory leak in 3DMigoto using this feature, and have plans to scrap that code once I get the arbitrary resource copying working (which can do the same thing, but better).[/quote]
If you wanted to see what this looks like, my first impression is that the result is alright... but not perfect:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/66365/[/img]
As you can see, most of the bloom is now at the correct depth, but one of the blobs is too far forward thanks to Max' head being in the way on the depth buffer. This could potentially be improved if the arbitrary resource copying is going to do what I hope and allow access to the vertex buffer as a constant buffer so that the coordinates of other vertices can be looked up allowing us to find the center of the effect from any vertex, but it still wouldn't help entirely in cases like the above.
It also affects the lens flare:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/66366/[/img]
If you wanted to try it out I've pushed the code to an experimental branch. It's the same code I was playing with in The Witcher 3 with only the near and far clipping planes adjusted (knew those would come in handy ;-):
https://github.com/DarkStarSword/3d-fixes/commit/2e92c268147dcdef8808d7738f8e5e7a095dc857
There's something weird going on with this bloom shader in general - the effect is *far* more pronounced than it is in 2D, which becomes apparent when separation is more than a few percent. It also gets clipped out in one eye depending on the camera angle... I suspect it's using the depth buffer to determine opacity and is being thrown out based on the fact the depth buffer has moved. I'm not entirely sure what is responsible for that yet.
DarkStarSword said:1. Inject the depth buffer into the shader, and use a variation of the experimental code I was playing with for the auto UI depth in the Witcher 3 to try to move it to roughly the correct position. This would probably work pretty well, but might cause the light to move to the wrong depth when another object is nearby on the depth buffer. This is potentially doable today, but I never resolved the reported memory leak in 3DMigoto using this feature, and have plans to scrap that code once I get the arbitrary resource copying working (which can do the same thing, but better).
If you wanted to see what this looks like, my first impression is that the result is alright... but not perfect:
As you can see, most of the bloom is now at the correct depth, but one of the blobs is too far forward thanks to Max' head being in the way on the depth buffer. This could potentially be improved if the arbitrary resource copying is going to do what I hope and allow access to the vertex buffer as a constant buffer so that the coordinates of other vertices can be looked up allowing us to find the center of the effect from any vertex, but it still wouldn't help entirely in cases like the above.
ok, the depth IS available... but it's in the pixel shader and it needs to be scaled. I should be able to fix the bloom disappearing incorrectly at least.
ok, the depth IS available... but it's in the pixel shader and it needs to be scaled. I should be able to fix the bloom disappearing incorrectly at least.
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
ok, this fixes the opacity of the bloom & lens flare, and stops them from being overly exaggerated or only showing in one eye:
https://github.com/DarkStarSword/3d-fixes/commit/a0f71fccfda105ab6a4a1d9b71534c5d68ae977c
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/66370/[/img]
Their position still needs to be corrected, either using the code I posted above, or a static adjustment. This discovery does show that it will be possible to fix these accurately once I finish that whole resource copy feature in 3DMigoto I keep talking about... I'll try to find some time to work on it this weekend, but I can't guarantee when it will be ready so for now I'd suggest getting the fix out without that and we can update it later.
@bo3b there's a weird decompiler bug I hit on those shaders you might like to take a look at.
Their position still needs to be corrected, either using the code I posted above, or a static adjustment. This discovery does show that it will be possible to fix these accurately once I finish that whole resource copy feature in 3DMigoto I keep talking about... I'll try to find some time to work on it this weekend, but I can't guarantee when it will be ready so for now I'd suggest getting the fix out without that and we can update it later.
@bo3b there's a weird decompiler bug I hit on those shaders you might like to take a look at.
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
[quote="chtiblue"]Anybody has the crosshair with sniper doubled?[/quote]
yop. Same here. Use to be alright but suddenly crosshair became 2D or something.
[quote="SKAUT"][quote="chtiblue"]Anybody has the crosshair with sniper doubled?[/quote]
yop. Same here. Use to be alright but suddenly crosshair became 2D or something.[/quote]
Can you upload a screenshot?
Here are the screenshots of Sniper and Thunderpoon crosshair - but now I know why they are 2D. They must be the same shader group as UI. When I was using "P" to adjust target marks then I`ve been changing this to some zero point and that was like 2D.
All I have to do is to adjust the Crosshair each time I`m using one of the weapons.
Here are the screenshots of Sniper and Thunderpoon crosshair - but now I know why they are 2D. They must be the same shader group as UI. When I was using "P" to adjust target marks then I`ve been changing this to some zero point and that was like 2D.
All I have to do is to adjust the Crosshair each time I`m using one of the weapons.
SKAUT...is 2D because you have Target icons in 2D, if you press "P" you will noticed that Target icons and crosshair cycle through different depth.
You can see it in this picture:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/66373/[/img]
I can separate the target icons from crosshair in 2 different presets.... i will take a look tonight.
1) Decal on ground- fixed with another PS below.
2) Blue light from sniper+bloom on tail lights of car. Same shader, but it's notable that it varies with convergence. I can dial it up to match at 3.0 convergence. e9849e745227d124-vs_replace.txt
3) Lights on desert. Can't find it, might have been a night-time water thing.
Fixed another decal shader, 40ee678464eb9621-ps_replace.txt:
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
That one didn't compile for me, I think there's a copy + paste issue, this makes it compile again:
https://github.com/DarkStarSword/3d-fixes/commit/38f85226fcf86bd63201de8bd24a10cd739866ee
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
For the Blue Light from sniper, i fix that shader (works dynamics depending of the distance of the sniper)...i'm using 3.2 of convergence and is looking ok. I will double check. the fixing code is this, so this will works for any convergence value (maybe a SLI or driver issue?)
The bloom in the same shader is render in one eye, and is not affected by the fixing code... i try a couple of things and the bloom is still render in one eye. i left that way :(
The car light on desert i think i fix it in the last update (i add 4 lights shaders and one was some light in front of a car at night)
Thanks!!
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
https://github.com/DarkStarSword/3d-fixes/commit/a744bd45716309b054d812c5793c28fe73315371
I'm going to have a quick look at the bloom and see if I can make it work in both eyes.
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
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
http://photos.3dvisionlive.com/chtiblue/album/530b52d4cb85770d6e000049/3Dvision with 49" Philips 49PUS7100 interlieved 3D (3840x2160) overide mode, GTX 1080 GFA2 EXOC, core i5 @4.3GHz, 16Gb@2130, windows 7&10 64bit, Dolby Atmos 5.1.4 Marantz 6010 AVR
I've had a bit of a look at this, and I can't find any naive way to fix it for all circumstances and have confirmed using frame analysis that it simply does not have access to the depth of the light source, nor the matrix of the light source to do the right thing.
So, all we can do for now is kill it or move it to a fixed depth that looks good enough.
As this is a common problem in a lot games I have been thinking about ways to solve it, and I've currently got a few ideas:
1. Inject the depth buffer into the shader, and use a variation of the experimental code I was playing with for the auto UI depth in the Witcher 3 to try to move it to roughly the correct position. This would probably work pretty well, but might cause the light to move to the wrong depth when another object is nearby on the depth buffer. This is potentially doable today, but I never resolved the reported memory leak in 3DMigoto using this feature, and have plans to scrap that code once I get the arbitrary resource copying working (which can do the same thing, but better).
2. Once I get the arbitrary resource copying working, copy the constant buffer containing the matrix of the light source to the light bloom shader and use that to determine the depth. This won't work reliably when there are multiple lights in the scene as you would get the matrix for whichever was drawn last, but might turn out to be ok.
3. ok, I have a really wacky idea I've been thinking about that has the potential to solve this 100% (maybe)... Similar to 2 in that we are copying the matrix from the shaders responsible for the light source, but collect all of them that are drawn in a frame, then in the bloom shader go through each of them and compare the X + Y coordinates to find the closest one to the bloom, then use the depth from that. I don't want to move too much of the logic to do this into 3DMigoto itself because the specifics will vary for each game, so I've been thinking about using an AppendStructuredBuffer to get the shaders to store the matrices - only problem is I'd need to do that once per instance, which would be easy from a vertex shader - but I can only use an append structured buffer from a SM5 pixel shader :( I could maybe inject a compute shader to do it though... hmmm....
For now this is just food for thought - the first one we could potentially try today (maybe, I haven't checked if the depth buffer is enabled when the bloom is drawn in this game), but was reported to have some memory leaks, so I wouldn't recommend it yet. The second will require me to finish the code I've been working on, and the third will require code I haven't started to write and am still not entirely sure how it would work.
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
If you wanted to see what this looks like, my first impression is that the result is alright... but not perfect:
As you can see, most of the bloom is now at the correct depth, but one of the blobs is too far forward thanks to Max' head being in the way on the depth buffer. This could potentially be improved if the arbitrary resource copying is going to do what I hope and allow access to the vertex buffer as a constant buffer so that the coordinates of other vertices can be looked up allowing us to find the center of the effect from any vertex, but it still wouldn't help entirely in cases like the above.
It also affects the lens flare:
If you wanted to try it out I've pushed the code to an experimental branch. It's the same code I was playing with in The Witcher 3 with only the near and far clipping planes adjusted (knew those would come in handy ;-):
https://github.com/DarkStarSword/3d-fixes/commit/2e92c268147dcdef8808d7738f8e5e7a095dc857
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
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
https://github.com/DarkStarSword/3d-fixes/commit/a0f71fccfda105ab6a4a1d9b71534c5d68ae977c
Their position still needs to be corrected, either using the code I posted above, or a static adjustment. This discovery does show that it will be possible to fix these accurately once I finish that whole resource copy feature in 3DMigoto I keep talking about... I'll try to find some time to work on it this weekend, but I can't guarantee when it will be ready so for now I'd suggest getting the fix out without that and we can update it later.
@bo3b there's a weird decompiler bug I hit on those shaders you might like to take a look at.
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
yop. Same here. Use to be alright but suddenly crosshair became 2D or something.
https://steamcommunity.com/profiles/76561198014296177/
Can you upload a screenshot?
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
All I have to do is to adjust the Crosshair each time I`m using one of the weapons.
https://steamcommunity.com/profiles/76561198014296177/
https://steamcommunity.com/profiles/76561198014296177/
You can see it in this picture:
I can separate the target icons from crosshair in 2 different presets.... i will take a look tonight.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com