I have already deleted GameOverlayRenderer.dll. I just think that my PC has not the power to run The Ball with the 3D Vision flag (1 FPS in the intro videos, sometimes a short glimpse of the main menu and then it crashes/freezes). But I think AllowNvidiaStereo3d=True is not the way to fix The Ball anyway...?
I have already deleted GameOverlayRenderer.dll. I just think that my PC has not the power to run The Ball with the 3D Vision flag (1 FPS in the intro videos, sometimes a short glimpse of the main menu and then it crashes/freezes). But I think AllowNvidiaStereo3d=True is not the way to fix The Ball anyway...?
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="3d4dd"]I have already deleted GameOverlayRenderer.dll. I just think that my PC has not the power to run The Ball with the 3D Vision flag (1 FPS in the intro videos, sometimes a short glimpse of the main menu and then it crashes/freezes). But I think AllowNvidiaStereo3d=True is not the way to fix The Ball anyway...?[/quote]OK, could be. I know I've had TheBall crash at weird times too.
Yeah, the AllowNVidiaStereo3d flag doesn't work to fix the whole game, but it does fix a few effects. At the expense of terrible frame rates.
I made that suggestion in 0.5 mostly as a reminder to not spend time fixing stuff if you can get it for free with a flag like this. (that reminder was for me too, since I started down the path of fixing without even looking.)
That also inspired the page for a fixing strategy to optimize your time. If people have suggestions, or think a different approach is better, don't hesitate to let me know.
http://wiki.bo3b.net/index.php?title=Game_Fixing_Strategy
3d4dd said:I have already deleted GameOverlayRenderer.dll. I just think that my PC has not the power to run The Ball with the 3D Vision flag (1 FPS in the intro videos, sometimes a short glimpse of the main menu and then it crashes/freezes). But I think AllowNvidiaStereo3d=True is not the way to fix The Ball anyway...?
OK, could be. I know I've had TheBall crash at weird times too.
Yeah, the AllowNVidiaStereo3d flag doesn't work to fix the whole game, but it does fix a few effects. At the expense of terrible frame rates.
I made that suggestion in 0.5 mostly as a reminder to not spend time fixing stuff if you can get it for free with a flag like this. (that reminder was for me too, since I started down the path of fixing without even looking.)
That also inspired the page for a fixing strategy to optimize your time. If people have suggestions, or think a different approach is better, don't hesitate to let me know.
I just wanted to add a couple of tips I've picked up that can help in shader hunting.
Numpad minus will reset the disabled shaders - I find a lot of games tend to crash if you move the mouse while some shaders are disabled, so I am now in the habit of pressing numpad minus before looking around (this key has no configuration option, it is hardcoded in the dll and I discovered it purely by accident).
If you are having difficulty finding a pixel or vertex shader for a given effect, but you are able to find the other type of shader for the effect, you can look at the numbers next to VertexPair and PixelPair to work out possible shaders.
e.g. If you are looking for a pixel shader for an effect, but can only identify the vertex shader, cycle until the vertex shader is disabled and look at the number next to VertexPair. Then cycle pixel shaders to that same number and you will be on the corresponding pixel shaders.
Note that sometimes these numbers change while cycling shaders, so I'd suggest cycling both pixel and vertex shaders to different effects and back to make sure the numbers still match up.
e.g. If you have successfully disabled both vertex and pixel shaders for the same effect, you will have VS = PixelPair and PS = VertexPair, like this
[code]VS 36 CRC32 0xblah PS 28 CRC32 0xblah ... VertexPair 28 PixelPair 36[/code]
Also, keep in mind that that some effects may have multiple layers, so you may need to check several shader pairs (and sometimes these even have the same CRCs for one of the shaders) to find the right one.
I just wanted to add a couple of tips I've picked up that can help in shader hunting.
Numpad minus will reset the disabled shaders - I find a lot of games tend to crash if you move the mouse while some shaders are disabled, so I am now in the habit of pressing numpad minus before looking around (this key has no configuration option, it is hardcoded in the dll and I discovered it purely by accident).
If you are having difficulty finding a pixel or vertex shader for a given effect, but you are able to find the other type of shader for the effect, you can look at the numbers next to VertexPair and PixelPair to work out possible shaders.
e.g. If you are looking for a pixel shader for an effect, but can only identify the vertex shader, cycle until the vertex shader is disabled and look at the number next to VertexPair. Then cycle pixel shaders to that same number and you will be on the corresponding pixel shaders.
Note that sometimes these numbers change while cycling shaders, so I'd suggest cycling both pixel and vertex shaders to different effects and back to make sure the numbers still match up.
e.g. If you have successfully disabled both vertex and pixel shaders for the same effect, you will have VS = PixelPair and PS = VertexPair, like this
Also, keep in mind that that some effects may have multiple layers, so you may need to check several shader pairs (and sometimes these even have the same CRCs for one of the shaders) to find the right one.
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
I have spent/wasted some hours trying to fix the refraction issues in The Sims 4 I have described here https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/160/ (there are also the VS and PS).
Doing this raised some fundamental (and stupid?) questions I want to ask here in our class room:
- As You can see on the screenshot http://photos.3dvisionlive.com/3d4dd/image/54638154d475fef77800018f/ the objects above and under water are not aligned correctly. The shift along the x-axis depends on the distance to the object and the depth/convergence settings used. Isn't this an issue that is very similar to the halo issue we have learned to fix with the prime directive? So that correcting the x position of the parts under water should fix this issue?
- If I want to correct the x position then I have to change the VS not the PS, right?
- Which values in a VS are connected to the x position of an object/texture on screen? I thought that it might be texcoord,texcoord1,...,texcoord7 and that the x value for corresponding output o1, o2,...,o8 is the one that has to be corrected. So I tried to identify which of o1, o2,...,o8 could affect the x shift for the objects under water. I added at the end of the shader
mov o[1,2...,8].x, c5.x (c5.x defined by myself using different values from 0 to 100)
But I couldn't observe any changes regarding the position on screen. Only in some cases the color of the water changed a little bit. Then I did the same with dcl_position o0. This moved the complete water of the swimming pool out of the basin. But as I don't want to change the position of the water surface (which is correct in S3D) but only the position of the objects under water this didn't help.
Regarding the PS I discovered that replacing c25.x (RefractionDistortionScale) with 0 in line 185
mad r0.xy, r2.xzzw, c25.x, v6
removed the distortion of objects under water caused by the waves but it didn't affect the x shift per se.
When I commented out line 187
texldp r0, r0, s0
this disabled the objects under water (water surface became yellow and intransparent). The other lines with texldp only affected other parts of the water (reflections, etc.). But does this give me a hint which part of the VS I have to look at? Or can I change the x shift whtin the PS?
The profile for Aion and Sims 3 seem to include a fix for this issue whith water surfaces but in the case of Sims 4 it also distorts parts of the HUD which is usually 2D at screen depth.
I have spent/wasted some hours trying to fix the refraction issues in The Sims 4 I have described here https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/160/ (there are also the VS and PS).
Doing this raised some fundamental (and stupid?) questions I want to ask here in our class room:
- As You can see on the screenshot http://photos.3dvisionlive.com/3d4dd/image/54638154d475fef77800018f/ the objects above and under water are not aligned correctly. The shift along the x-axis depends on the distance to the object and the depth/convergence settings used. Isn't this an issue that is very similar to the halo issue we have learned to fix with the prime directive? So that correcting the x position of the parts under water should fix this issue?
- If I want to correct the x position then I have to change the VS not the PS, right?
- Which values in a VS are connected to the x position of an object/texture on screen? I thought that it might be texcoord,texcoord1,...,texcoord7 and that the x value for corresponding output o1, o2,...,o8 is the one that has to be corrected. So I tried to identify which of o1, o2,...,o8 could affect the x shift for the objects under water. I added at the end of the shader
mov o[1,2...,8].x, c5.x (c5.x defined by myself using different values from 0 to 100)
But I couldn't observe any changes regarding the position on screen. Only in some cases the color of the water changed a little bit. Then I did the same with dcl_position o0. This moved the complete water of the swimming pool out of the basin. But as I don't want to change the position of the water surface (which is correct in S3D) but only the position of the objects under water this didn't help.
Regarding the PS I discovered that replacing c25.x (RefractionDistortionScale) with 0 in line 185
mad r0.xy, r2.xzzw, c25.x, v6
removed the distortion of objects under water caused by the waves but it didn't affect the x shift per se.
When I commented out line 187
texldp r0, r0, s0
this disabled the objects under water (water surface became yellow and intransparent). The other lines with texldp only affected other parts of the water (reflections, etc.). But does this give me a hint which part of the VS I have to look at? Or can I change the x shift whtin the PS?
The profile for Aion and Sims 3 seem to include a fix for this issue whith water surfaces but in the case of Sims 4 it also distorts parts of the HUD which is usually 2D at screen depth.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
First off, gotta say, great job! You are going about this the right way, by trying experiments and trying to understand what pieces do what. That is the essence of hacking, where we poke the black box and try to understand what it's doing.
The shift along the x axis does in fact cause the change in apparent depth. The stuff under the water surface is not adjusted automatically by the driver, and thus we need to, in order to stereo correct the refraction part. If you look at the refracted part only, it looks OK, just at the wrong depth. If you change your focus to look at just the water, it all works, just at way to much stereo depth.
This is very similar to the problem we saw in The Ball with the water at the last round. Looking right at the edge of the water we could see the water surface was right, but beneath the transparent surface it was off, wrong depth.
You might want to take a look at The Ball as an example, since the shader is available and we can fix it there.
Here in the thread we talk about that water shader. It seems suspiciously similar to what you are seeing in Sims.
[url]https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4317490/#4317490[/url]
Shader hunting that shader was the hardest part, it doesn't show up. 4everawake found it by an offline technique as VS A2E7F5BC. Since this is a known example, it might be worth the legwork to see if you can fix this one first. The reason to do that is because we know for certain this one can be fixed, unlike the Sims one. And it might give you particular insight into how the Sims one is failing. If we get stuck we can always ask 4everawake. :->
[quote="3d4dd"]- If I want to correct the x position then I have to change the VS not the PS, right?[/quote]Not always, but most often. It is sometimes possible to correct the location/depth in the PS as well, as it is often an input parameter to the PS. More of a convention than a hard rule, as VS is generally used for location, PS is generally for color.
As a counter example, for deferred shading effects, they generally do all location/depth calculation in the PS itself, and so those can only be fixed there. So, like most of these things, "it depends."
[quote="3d4dd"]- Which values in a VS are connected to the x position of an object/texture on screen? I thought that it might be texcoord,texcoord1,...,texcoord7 and that the x value for corresponding output o1, o2,...,o8 is the one that has to be corrected. [/quote]There is no correlation. You should think of those textures as random, because they will vary depending upon what the shader is doing. The only thing that is mostly reliable is the dcl_position parameter for a VS where it is the location of the vertex. The textures are any assortment of applied surfaces/textures/pictures that the designer wanted.
[quote="3d4dd"]But I couldn't observe any changes regarding the position on screen. Only in some cases the color of the water changed a little bit. Then I did the same with dcl_position o0. This moved the complete water of the swimming pool out of the basin. But as I don't want to change the position of the water surface (which is correct in S3D) but only the position of the objects under water this didn't help.[/quote]Are you certain the surface is correct? In The Ball case, as I point out in the thread, it only looks like it's at the right location, but the surface is actually off. I suspect you are on the right track with the o0 location, because it moves it out of the pool altogether. That's the sort of effect we are looking for.
Remember that 3D graphics is all an illusion. It might look like we can see into the water, but in fact it's just another picture painted on a flat polygon like Trompe-l'œil. The surface may very well be the thing we need to hit.
[quote="3d4dd"]Regarding the PS I discovered that replacing c25.x (RefractionDistortionScale) with 0 in line 185
mad r0.xy, r2.xzzw, c25.x, v6
removed the distortion of objects under water caused by the waves but it didn't affect the x shift per se.
When I commented out line 187
texldp r0, r0, s0
this disabled the objects under water (water surface became yellow and intransparent). The other lines with texldp only affected other parts of the water (reflections, etc.). But does this give me a hint which part of the VS I have to look at? Or can I change the x shift whtin the PS?[/quote]This also makes me think that it might be very much like The Ball. When you look at the pool by itself, all the pieces line up with each other in the water, it's just not aligned with the world. And we probably don't want to shift the 'under water' images, because then they won't line with other water pieces. I think we need to move the entire thing.
[quote="3d4dd"]The profile for Aion and Sims 3 seem to include a fix for this issue whith water surfaces but in the case of Sims 4 it also distorts parts of the HUD which is usually 2D at screen depth.[/quote]Awesome. Just like Lesson 0.5, this might be the best way to fix it. If the profile fixes a hard one, then we are left having to fix a newly damaged one. But if it's easier to fix, that seems like a win.
First off, gotta say, great job! You are going about this the right way, by trying experiments and trying to understand what pieces do what. That is the essence of hacking, where we poke the black box and try to understand what it's doing.
The shift along the x axis does in fact cause the change in apparent depth. The stuff under the water surface is not adjusted automatically by the driver, and thus we need to, in order to stereo correct the refraction part. If you look at the refracted part only, it looks OK, just at the wrong depth. If you change your focus to look at just the water, it all works, just at way to much stereo depth.
This is very similar to the problem we saw in The Ball with the water at the last round. Looking right at the edge of the water we could see the water surface was right, but beneath the transparent surface it was off, wrong depth.
You might want to take a look at The Ball as an example, since the shader is available and we can fix it there.
Here in the thread we talk about that water shader. It seems suspiciously similar to what you are seeing in Sims.
Shader hunting that shader was the hardest part, it doesn't show up. 4everawake found it by an offline technique as VS A2E7F5BC. Since this is a known example, it might be worth the legwork to see if you can fix this one first. The reason to do that is because we know for certain this one can be fixed, unlike the Sims one. And it might give you particular insight into how the Sims one is failing. If we get stuck we can always ask 4everawake. :->
3d4dd said:- If I want to correct the x position then I have to change the VS not the PS, right?
Not always, but most often. It is sometimes possible to correct the location/depth in the PS as well, as it is often an input parameter to the PS. More of a convention than a hard rule, as VS is generally used for location, PS is generally for color.
As a counter example, for deferred shading effects, they generally do all location/depth calculation in the PS itself, and so those can only be fixed there. So, like most of these things, "it depends."
3d4dd said:- Which values in a VS are connected to the x position of an object/texture on screen? I thought that it might be texcoord,texcoord1,...,texcoord7 and that the x value for corresponding output o1, o2,...,o8 is the one that has to be corrected.
There is no correlation. You should think of those textures as random, because they will vary depending upon what the shader is doing. The only thing that is mostly reliable is the dcl_position parameter for a VS where it is the location of the vertex. The textures are any assortment of applied surfaces/textures/pictures that the designer wanted.
3d4dd said:But I couldn't observe any changes regarding the position on screen. Only in some cases the color of the water changed a little bit. Then I did the same with dcl_position o0. This moved the complete water of the swimming pool out of the basin. But as I don't want to change the position of the water surface (which is correct in S3D) but only the position of the objects under water this didn't help.
Are you certain the surface is correct? In The Ball case, as I point out in the thread, it only looks like it's at the right location, but the surface is actually off. I suspect you are on the right track with the o0 location, because it moves it out of the pool altogether. That's the sort of effect we are looking for.
Remember that 3D graphics is all an illusion. It might look like we can see into the water, but in fact it's just another picture painted on a flat polygon like Trompe-l'œil. The surface may very well be the thing we need to hit.
3d4dd said:Regarding the PS I discovered that replacing c25.x (RefractionDistortionScale) with 0 in line 185
mad r0.xy, r2.xzzw, c25.x, v6
removed the distortion of objects under water caused by the waves but it didn't affect the x shift per se.
When I commented out line 187
texldp r0, r0, s0
this disabled the objects under water (water surface became yellow and intransparent). The other lines with texldp only affected other parts of the water (reflections, etc.). But does this give me a hint which part of the VS I have to look at? Or can I change the x shift whtin the PS?
This also makes me think that it might be very much like The Ball. When you look at the pool by itself, all the pieces line up with each other in the water, it's just not aligned with the world. And we probably don't want to shift the 'under water' images, because then they won't line with other water pieces. I think we need to move the entire thing.
3d4dd said:The profile for Aion and Sims 3 seem to include a fix for this issue whith water surfaces but in the case of Sims 4 it also distorts parts of the HUD which is usually 2D at screen depth.
Awesome. Just like Lesson 0.5, this might be the best way to fix it. If the profile fixes a hard one, then we are left having to fix a newly damaged one. But if it's easier to fix, that seems like a win.
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
Hey bo3b. I'm currently having issues using 3dMigoto with Project CARS. When I try to save a shader, the game crashes. When I try to dump all shaders (export_hlsl = 0), the game runs for 2 seconds & then crashes. This happens with both 32 & 64 bit versions. I attached my log file.
Might be unrelated, but I was having issues with Helixmod as well. The game has distorted textures with just the DLL in the folder.
Hey bo3b. I'm currently having issues using 3dMigoto with Project CARS. When I try to save a shader, the game crashes. When I try to dump all shaders (export_hlsl = 0), the game runs for 2 seconds & then crashes. This happens with both 32 & 64 bit versions. I attached my log file.
Might be unrelated, but I was having issues with Helixmod as well. The game has distorted textures with just the DLL in the folder.
Log doesn't show anything too significant, looks like it's loading and running pretty right.
When marking the shader, it got a bad CRC somehow, of 000000000000001. That's going to be related somehow.
Is this using the 0.99.2 version of 3Dmigoto? If not, try that one for sure. Lots of good fixes. If already using that, try setting the debug=1 and unbuffered=1 flags for a more verbose log version.
Log doesn't show anything too significant, looks like it's loading and running pretty right.
When marking the shader, it got a bad CRC somehow, of 000000000000001. That's going to be related somehow.
Is this using the 0.99.2 version of 3Dmigoto? If not, try that one for sure. Lots of good fixes. If already using that, try setting the debug=1 and unbuffered=1 flags for a more verbose log version.
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
I'm using the newest version now. But it's still crashing when I try to save a shader. Here's the new log file (with debug and unbuffered flags set to 1):
I'm using the newest version now. But it's still crashing when I try to save a shader. Here's the new log file (with debug and unbuffered flags set to 1):
[quote="4everAwake"]I'm using the newest version now. But it's still crashing when I try to save a shader. Here's the new log file (with debug and unbuffered flags set to 1):[/quote]Good, thanks.
Looking at this log, it is also running very well. No errors up to the point of crashing. Everything looks normal.
Try this next step. Set the export_hlsl=3 in the .ini file. That will generate a ShaderCache with every shader in it, and uses a slightly different path to generate the HLSL. I'll be curious if your shader shows up there, if it crashes trying that, and/or if the log shows something different for ac05816c28ae5e28.
4everAwake said:I'm using the newest version now. But it's still crashing when I try to save a shader. Here's the new log file (with debug and unbuffered flags set to 1):
Good, thanks.
Looking at this log, it is also running very well. No errors up to the point of crashing. Everything looks normal.
Try this next step. Set the export_hlsl=3 in the .ini file. That will generate a ShaderCache with every shader in it, and uses a slightly different path to generate the HLSL. I'll be curious if your shader shows up there, if it crashes trying that, and/or if the log shows something different for ac05816c28ae5e28.
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
Hello bo3b!,
Hope you're doing well. Anyway, I finally got around to going through your tutorials this week. That went quite ok for the first 3. Skipped 4 though (I think I can better motivate myself once I can fix a game I actually intend to play ;) ). However, after that, things get a bit fuzzy.
About this prime directive, and more specifically the code. Is the reasoning behind it something like: "here we have an effect that renders wrongly to screen, let's re-calculate stereo using positional data from the game and output that instead"? I ask, because I suppose I was expecting corrections would involve us actually [i]modifying[/i] the formula on a case by case basis.
Hope you're doing well. Anyway, I finally got around to going through your tutorials this week. That went quite ok for the first 3. Skipped 4 though (I think I can better motivate myself once I can fix a game I actually intend to play ;) ). However, after that, things get a bit fuzzy.
About this prime directive, and more specifically the code. Is the reasoning behind it something like: "here we have an effect that renders wrongly to screen, let's re-calculate stereo using positional data from the game and output that instead"? I ask, because I suppose I was expecting corrections would involve us actually modifying the formula on a case by case basis.
Great to have you! No worries on skipping #4, as long as you got the idea of making a ToDo list of shaders, and the main thing there (unstated) was to give you practice at finding and disabling shaders.
Don't hesitate to fix other games or apply the lessons to games you are more interested in. For example, I went through the original Far Cry Lesson 4 style, where I just disabled anything broken to get it playable.
For the prime directive, no the formula doesn't change for other fixes, not in general. The basic strategy is that we are trying to recalculate a .x parameter for a given effect, to put it to the right visual location. And it is almost always a differential value we add, which is why it's a [i]x +=[/i] format, where we want to keep the original projection space location, but offset it slightly to make the stereo correction.
That doesn't have to be by using the directive. For example, if we know for a fact we want it at depth, we may just force it to a specific value. If we want it at screen depth, we set it to zero.
And sometimes we will modify the formula based on other things we might have found out, but it's rare.
The takeaway message is that in order to solve stereo glitches, we are going to modify the .x parameter in order to change the parallax, which directly translates to how we perceive its depth. Wider distance between left and right eyes makes it seem deeper/farther from us. That would correspond to a larger value added to the original .x. The maximum value added to a .x location would be the current user separation value.
Great to have you! No worries on skipping #4, as long as you got the idea of making a ToDo list of shaders, and the main thing there (unstated) was to give you practice at finding and disabling shaders.
Don't hesitate to fix other games or apply the lessons to games you are more interested in. For example, I went through the original Far Cry Lesson 4 style, where I just disabled anything broken to get it playable.
For the prime directive, no the formula doesn't change for other fixes, not in general. The basic strategy is that we are trying to recalculate a .x parameter for a given effect, to put it to the right visual location. And it is almost always a differential value we add, which is why it's a x += format, where we want to keep the original projection space location, but offset it slightly to make the stereo correction.
That doesn't have to be by using the directive. For example, if we know for a fact we want it at depth, we may just force it to a specific value. If we want it at screen depth, we set it to zero.
And sometimes we will modify the formula based on other things we might have found out, but it's rare.
The takeaway message is that in order to solve stereo glitches, we are going to modify the .x parameter in order to change the parallax, which directly translates to how we perceive its depth. Wider distance between left and right eyes makes it seem deeper/farther from us. That would correspond to a larger value added to the original .x. The maximum value added to a .x location would be the current user separation value.
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
[quote="bo3b"]Great to have you! No worries on skipping #4, as long as you got the idea of making a ToDo list of shaders, and the main thing there (unstated) was to give you practice at finding and disabling shaders.
Don't hesitate to fix other games or apply the lessons to games you are more interested in. For example, I went through the original Far Cry Lesson 4 style, where I just disabled anything broken to get it playable.
For the prime directive, no the formula doesn't change for other fixes, not in general. The basic strategy is that we are trying to recalculate a .x parameter for a given effect, to put it to the right visual location. And it is almost always a differential value we add, which is why it's a [i]x +=[/i] format, where we want to keep the original projection space location, but offset it slightly to make the stereo correction.
That doesn't have to be by using the directive. For example, if we know for a fact we want it at depth, we may just force it to a specific value. If we want it at screen depth, we set it to zero.
And sometimes we will modify the formula based on other things we might have found out, but it's rare.
The takeaway message is that in order to solve stereo glitches, we are going to modify the .x parameter in order to change the parallax, which directly translates to how we perceive its depth. Wider distance between left and right eyes makes it seem deeper/farther from us. That would correspond to a larger value added to the original .x. The maximum value added to a .x location would be the current user separation value.[/quote]
Oh, I hadn't actually realised the whole stereo geometry was being modified via the eye separation! Lol. I've worked with stereoscopes in the past and there you always changed the geometry by moving the images farther apart or closer together.
Ok, well crossed the first hurdle. I was going to try to do some repairs on Total War: Rome II. Mike already made a fix for it once, but one of the many patches to the game broke it.
Here's something odd though: I couldn't get the debug version of Helixmod working until I tried a rather old one, from back in 2012. Is that something I need to worry about?
bo3b said:Great to have you! No worries on skipping #4, as long as you got the idea of making a ToDo list of shaders, and the main thing there (unstated) was to give you practice at finding and disabling shaders.
Don't hesitate to fix other games or apply the lessons to games you are more interested in. For example, I went through the original Far Cry Lesson 4 style, where I just disabled anything broken to get it playable.
For the prime directive, no the formula doesn't change for other fixes, not in general. The basic strategy is that we are trying to recalculate a .x parameter for a given effect, to put it to the right visual location. And it is almost always a differential value we add, which is why it's a x += format, where we want to keep the original projection space location, but offset it slightly to make the stereo correction.
That doesn't have to be by using the directive. For example, if we know for a fact we want it at depth, we may just force it to a specific value. If we want it at screen depth, we set it to zero.
And sometimes we will modify the formula based on other things we might have found out, but it's rare.
The takeaway message is that in order to solve stereo glitches, we are going to modify the .x parameter in order to change the parallax, which directly translates to how we perceive its depth. Wider distance between left and right eyes makes it seem deeper/farther from us. That would correspond to a larger value added to the original .x. The maximum value added to a .x location would be the current user separation value.
Oh, I hadn't actually realised the whole stereo geometry was being modified via the eye separation! Lol. I've worked with stereoscopes in the past and there you always changed the geometry by moving the images farther apart or closer together.
Ok, well crossed the first hurdle. I was going to try to do some repairs on Total War: Rome II. Mike already made a fix for it once, but one of the many patches to the game broke it.
Here's something odd though: I couldn't get the debug version of Helixmod working until I tried a rather old one, from back in 2012. Is that something I need to worry about?
[quote="Muizer"]Oh, I hadn't actually realised the whole stereo geometry was being modified via the eye separation! Lol. I've worked with stereoscopes in the past and there you always changed the geometry by moving the images farther apart or closer together.
Ok, well crossed the first hurdle. I was going to try to do some repairs on Total War: Rome II. Mike already made a fix for it once, but one of the many patches to the game broke it.
Here's something odd though: I couldn't get the debug version of Helixmod working until I tried a rather old one, from back in 2012. Is that something I need to worry about?[/quote]
No, that was probably not clear enough. We don't modify the entire stereo geometry.
It's actually very much like the stereoscopes modifying the images at view time.
The 3D models are generated in World Coordinates, and the whole model is consistent with itself as an actual scene. That model is then translated to Projection Coordinates, which is taking a camera/eye view of the scene. That translation is normally a single eye for cyclops viewing/2D. In stereoscopic, there are two translations, one for each eye- and they are done from the proper angle and displacement (IPD) to get the right view for each eye.
Where things mess up is that the game designers are doing some sort of cheat on the original World 3D model. Like shadows are drawn very last in the Projection view, instead of drawing them in the 3D model. They usually do this for performance reasons.
So to fix those, we figure out where the effect is being painted wrong, and modify only those coordinates for the offending effect. We are fixing the effect by forcing it to draw in the proper 3D model.
Hope that's more clear. If not, best bet will be to read through and understand the NVidia white paper referenced in the class.
[url]http://www.nvidia.com/content/GTC-2010/pdfs/2010_GTC2010.pdf[/url]
Great that you are taking a look at Rome II!
Using an older HelixMod is not a concern. There are a lot of variables in the games and wrappers, and it's not all that uncommon to use an older one that is more compatible. The wrappers kinda/sorta match the generation of games that were produced, as every game generation they tend to introduce some new madness we have to work around.
Muizer said:Oh, I hadn't actually realised the whole stereo geometry was being modified via the eye separation! Lol. I've worked with stereoscopes in the past and there you always changed the geometry by moving the images farther apart or closer together.
Ok, well crossed the first hurdle. I was going to try to do some repairs on Total War: Rome II. Mike already made a fix for it once, but one of the many patches to the game broke it.
Here's something odd though: I couldn't get the debug version of Helixmod working until I tried a rather old one, from back in 2012. Is that something I need to worry about?
No, that was probably not clear enough. We don't modify the entire stereo geometry.
It's actually very much like the stereoscopes modifying the images at view time.
The 3D models are generated in World Coordinates, and the whole model is consistent with itself as an actual scene. That model is then translated to Projection Coordinates, which is taking a camera/eye view of the scene. That translation is normally a single eye for cyclops viewing/2D. In stereoscopic, there are two translations, one for each eye- and they are done from the proper angle and displacement (IPD) to get the right view for each eye.
Where things mess up is that the game designers are doing some sort of cheat on the original World 3D model. Like shadows are drawn very last in the Projection view, instead of drawing them in the 3D model. They usually do this for performance reasons.
So to fix those, we figure out where the effect is being painted wrong, and modify only those coordinates for the offending effect. We are fixing the effect by forcing it to draw in the proper 3D model.
Hope that's more clear. If not, best bet will be to read through and understand the NVidia white paper referenced in the class.
Using an older HelixMod is not a concern. There are a lot of variables in the games and wrappers, and it's not all that uncommon to use an older one that is more compatible. The wrappers kinda/sorta match the generation of games that were produced, as every game generation they tend to introduce some new madness we have to work around.
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
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Yeah, the AllowNVidiaStereo3d flag doesn't work to fix the whole game, but it does fix a few effects. At the expense of terrible frame rates.
I made that suggestion in 0.5 mostly as a reminder to not spend time fixing stuff if you can get it for free with a flag like this. (that reminder was for me too, since I started down the path of fixing without even looking.)
That also inspired the page for a fixing strategy to optimize your time. If people have suggestions, or think a different approach is better, don't hesitate to let me know.
http://wiki.bo3b.net/index.php?title=Game_Fixing_Strategy
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
Numpad minus will reset the disabled shaders - I find a lot of games tend to crash if you move the mouse while some shaders are disabled, so I am now in the habit of pressing numpad minus before looking around (this key has no configuration option, it is hardcoded in the dll and I discovered it purely by accident).
If you are having difficulty finding a pixel or vertex shader for a given effect, but you are able to find the other type of shader for the effect, you can look at the numbers next to VertexPair and PixelPair to work out possible shaders.
e.g. If you are looking for a pixel shader for an effect, but can only identify the vertex shader, cycle until the vertex shader is disabled and look at the number next to VertexPair. Then cycle pixel shaders to that same number and you will be on the corresponding pixel shaders.
Note that sometimes these numbers change while cycling shaders, so I'd suggest cycling both pixel and vertex shaders to different effects and back to make sure the numbers still match up.
e.g. If you have successfully disabled both vertex and pixel shaders for the same effect, you will have VS = PixelPair and PS = VertexPair, like this
Also, keep in mind that that some effects may have multiple layers, so you may need to check several shader pairs (and sometimes these even have the same CRCs for one of the shaders) to find the right one.
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
Doing this raised some fundamental (and stupid?) questions I want to ask here in our class room:
- As You can see on the screenshot http://photos.3dvisionlive.com/3d4dd/image/54638154d475fef77800018f/ the objects above and under water are not aligned correctly. The shift along the x-axis depends on the distance to the object and the depth/convergence settings used. Isn't this an issue that is very similar to the halo issue we have learned to fix with the prime directive? So that correcting the x position of the parts under water should fix this issue?
- If I want to correct the x position then I have to change the VS not the PS, right?
- Which values in a VS are connected to the x position of an object/texture on screen? I thought that it might be texcoord,texcoord1,...,texcoord7 and that the x value for corresponding output o1, o2,...,o8 is the one that has to be corrected. So I tried to identify which of o1, o2,...,o8 could affect the x shift for the objects under water. I added at the end of the shader
mov o[1,2...,8].x, c5.x (c5.x defined by myself using different values from 0 to 100)
But I couldn't observe any changes regarding the position on screen. Only in some cases the color of the water changed a little bit. Then I did the same with dcl_position o0. This moved the complete water of the swimming pool out of the basin. But as I don't want to change the position of the water surface (which is correct in S3D) but only the position of the objects under water this didn't help.
Regarding the PS I discovered that replacing c25.x (RefractionDistortionScale) with 0 in line 185
mad r0.xy, r2.xzzw, c25.x, v6
removed the distortion of objects under water caused by the waves but it didn't affect the x shift per se.
When I commented out line 187
texldp r0, r0, s0
this disabled the objects under water (water surface became yellow and intransparent). The other lines with texldp only affected other parts of the water (reflections, etc.). But does this give me a hint which part of the VS I have to look at? Or can I change the x shift whtin the PS?
The profile for Aion and Sims 3 seem to include a fix for this issue whith water surfaces but in the case of Sims 4 it also distorts parts of the HUD which is usually 2D at screen depth.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
The shift along the x axis does in fact cause the change in apparent depth. The stuff under the water surface is not adjusted automatically by the driver, and thus we need to, in order to stereo correct the refraction part. If you look at the refracted part only, it looks OK, just at the wrong depth. If you change your focus to look at just the water, it all works, just at way to much stereo depth.
This is very similar to the problem we saw in The Ball with the water at the last round. Looking right at the edge of the water we could see the water surface was right, but beneath the transparent surface it was off, wrong depth.
You might want to take a look at The Ball as an example, since the shader is available and we can fix it there.
Here in the thread we talk about that water shader. It seems suspiciously similar to what you are seeing in Sims.
https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4317490/#4317490
Shader hunting that shader was the hardest part, it doesn't show up. 4everawake found it by an offline technique as VS A2E7F5BC. Since this is a known example, it might be worth the legwork to see if you can fix this one first. The reason to do that is because we know for certain this one can be fixed, unlike the Sims one. And it might give you particular insight into how the Sims one is failing. If we get stuck we can always ask 4everawake. :->
Not always, but most often. It is sometimes possible to correct the location/depth in the PS as well, as it is often an input parameter to the PS. More of a convention than a hard rule, as VS is generally used for location, PS is generally for color.
As a counter example, for deferred shading effects, they generally do all location/depth calculation in the PS itself, and so those can only be fixed there. So, like most of these things, "it depends."
There is no correlation. You should think of those textures as random, because they will vary depending upon what the shader is doing. The only thing that is mostly reliable is the dcl_position parameter for a VS where it is the location of the vertex. The textures are any assortment of applied surfaces/textures/pictures that the designer wanted.
Are you certain the surface is correct? In The Ball case, as I point out in the thread, it only looks like it's at the right location, but the surface is actually off. I suspect you are on the right track with the o0 location, because it moves it out of the pool altogether. That's the sort of effect we are looking for.
Remember that 3D graphics is all an illusion. It might look like we can see into the water, but in fact it's just another picture painted on a flat polygon like Trompe-l'œil. The surface may very well be the thing we need to hit.
This also makes me think that it might be very much like The Ball. When you look at the pool by itself, all the pieces line up with each other in the water, it's just not aligned with the world. And we probably don't want to shift the 'under water' images, because then they won't line with other water pieces. I think we need to move the entire thing.
Awesome. Just like Lesson 0.5, this might be the best way to fix it. If the profile fixes a hard one, then we are left having to fix a newly damaged one. But if it's easier to fix, that seems like a win.
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
Might be unrelated, but I was having issues with Helixmod as well. The game has distorted textures with just the DLL in the folder.
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
When marking the shader, it got a bad CRC somehow, of 000000000000001. That's going to be related somehow.
Is this using the 0.99.2 version of 3Dmigoto? If not, try that one for sure. Lots of good fixes. If already using that, try setting the debug=1 and unbuffered=1 flags for a more verbose log version.
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
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Looking at this log, it is also running very well. No errors up to the point of crashing. Everything looks normal.
Try this next step. Set the export_hlsl=3 in the .ini file. That will generate a ShaderCache with every shader in it, and uses a slightly different path to generate the HLSL. I'll be curious if your shader shows up there, if it crashes trying that, and/or if the log shows something different for ac05816c28ae5e28.
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
Hope you're doing well. Anyway, I finally got around to going through your tutorials this week. That went quite ok for the first 3. Skipped 4 though (I think I can better motivate myself once I can fix a game I actually intend to play ;) ). However, after that, things get a bit fuzzy.
About this prime directive, and more specifically the code. Is the reasoning behind it something like: "here we have an effect that renders wrongly to screen, let's re-calculate stereo using positional data from the game and output that instead"? I ask, because I suppose I was expecting corrections would involve us actually modifying the formula on a case by case basis.
Don't hesitate to fix other games or apply the lessons to games you are more interested in. For example, I went through the original Far Cry Lesson 4 style, where I just disabled anything broken to get it playable.
For the prime directive, no the formula doesn't change for other fixes, not in general. The basic strategy is that we are trying to recalculate a .x parameter for a given effect, to put it to the right visual location. And it is almost always a differential value we add, which is why it's a x += format, where we want to keep the original projection space location, but offset it slightly to make the stereo correction.
That doesn't have to be by using the directive. For example, if we know for a fact we want it at depth, we may just force it to a specific value. If we want it at screen depth, we set it to zero.
And sometimes we will modify the formula based on other things we might have found out, but it's rare.
The takeaway message is that in order to solve stereo glitches, we are going to modify the .x parameter in order to change the parallax, which directly translates to how we perceive its depth. Wider distance between left and right eyes makes it seem deeper/farther from us. That would correspond to a larger value added to the original .x. The maximum value added to a .x location would be the current user separation value.
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
Oh, I hadn't actually realised the whole stereo geometry was being modified via the eye separation! Lol. I've worked with stereoscopes in the past and there you always changed the geometry by moving the images farther apart or closer together.
Ok, well crossed the first hurdle. I was going to try to do some repairs on Total War: Rome II. Mike already made a fix for it once, but one of the many patches to the game broke it.
Here's something odd though: I couldn't get the debug version of Helixmod working until I tried a rather old one, from back in 2012. Is that something I need to worry about?
No, that was probably not clear enough. We don't modify the entire stereo geometry.
It's actually very much like the stereoscopes modifying the images at view time.
The 3D models are generated in World Coordinates, and the whole model is consistent with itself as an actual scene. That model is then translated to Projection Coordinates, which is taking a camera/eye view of the scene. That translation is normally a single eye for cyclops viewing/2D. In stereoscopic, there are two translations, one for each eye- and they are done from the proper angle and displacement (IPD) to get the right view for each eye.
Where things mess up is that the game designers are doing some sort of cheat on the original World 3D model. Like shadows are drawn very last in the Projection view, instead of drawing them in the 3D model. They usually do this for performance reasons.
So to fix those, we figure out where the effect is being painted wrong, and modify only those coordinates for the offending effect. We are fixing the effect by forcing it to draw in the proper 3D model.
Hope that's more clear. If not, best bet will be to read through and understand the NVidia white paper referenced in the class.
http://www.nvidia.com/content/GTC-2010/pdfs/2010_GTC2010.pdf
Great that you are taking a look at Rome II!
Using an older HelixMod is not a concern. There are a lot of variables in the games and wrappers, and it's not all that uncommon to use an older one that is more compatible. The wrappers kinda/sorta match the generation of games that were produced, as every game generation they tend to introduce some new madness we have to work around.
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