Bo3b's School For Shaderhackers
  13 / 87    
[quote="bo3b"]Time once again for a new Lesson! It's up! This one is Lesson 5 - experimentation. The basic idea is to demonstrate the role of experimenting (<cough> hacking) on shaders to figure out what pieces of the code affect which part of the image, and how you might disable just a sub-piece instead of the whole image. Since this ran long, I broke it into two parts that are independent. The first part is a short tour of 3D graphics themselves, and a demo of how shaders work so you can connect what you see on screen to what you see in shader code. I think you should all find this lesson particularly interesting.[/quote] I just watched the Lesson 5 videos. Very very nice!!! I really loved the way you started with the intro about the graphics pipeline so everyone have a clear idea of what's going on! I really loved the nvidia Demo you found (which I wasn't aware of) and which is very good for teaching. I really love the way you make the videos :) Very nicely structured. Now I can't wait to get to the more advanced stuff! Just a couple of ideas (probably you already have them written down already): - How to correct the position in a vertex shader, if the position is wrong. - How to fix 2D Shadows & reflections. - How to fix 3D Shadows that are rendering at a bad depth (or are eye inversed) - What operations are required for the above and what matrixes are to be used (like why use the ProjectionInverse matrix) The above plague most of the games that's why I am personally looking forward to these things:) Anywho keep up the awesome work! I've followed all of your lessons till now and still discover new things about the wrapper and ASM shaders:D Will defo look for the next lesson:D
bo3b said:Time once again for a new Lesson! It's up!

This one is Lesson 5 - experimentation.

The basic idea is to demonstrate the role of experimenting (<cough> hacking) on shaders to figure out what pieces of the code affect which part of the image, and how you might disable just a sub-piece instead of the whole image.

Since this ran long, I broke it into two parts that are independent. The first part is a short tour of 3D graphics themselves, and a demo of how shaders work so you can connect what you see on screen to what you see in shader code.

I think you should all find this lesson particularly interesting.


I just watched the Lesson 5 videos. Very very nice!!! I really loved the way you started with the intro about the graphics pipeline so everyone have a clear idea of what's going on! I really loved the nvidia Demo you found (which I wasn't aware of) and which is very good for teaching.
I really love the way you make the videos :) Very nicely structured.

Now I can't wait to get to the more advanced stuff! Just a couple of ideas (probably you already have them written down already):
- How to correct the position in a vertex shader, if the position is wrong.
- How to fix 2D Shadows & reflections.
- How to fix 3D Shadows that are rendering at a bad depth (or are eye inversed)
- What operations are required for the above and what matrixes are to be used (like why use the ProjectionInverse matrix)

The above plague most of the games that's why I am personally looking forward to these things:)
Anywho keep up the awesome work! I've followed all of your lessons till now and still discover new things about the wrapper and ASM shaders:D Will defo look for the next lesson:D

1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc


My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com

(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)

Posted 09/14/2014 11:01 AM   
Thanks for that feedback, it's good to know that it's still been worth the time to create, and worth your time to view. (Lesson 4 is the weakest of the set, I had a good idea there, but couldn't make it work well.) I think Lesson 5 finishes my idea of what constitutes good basics and decent background so that the more complicated stuff does not become overwhelming. Current plan is that Lesson 6 will discuss the Prime Directive, and then we'll move into applying the Prime Directive for fixes. I plan to hit the normal fixes in order of complexity, so that we build on prior knowledge. I expect to get to shadows and reflections, but those will be nearly last, because they are much, much harder than anything else, and often do not conform to normal patterns that we see for other problems. This is one reason I've started off by emphasizing disabled effects. A lot of times we'll try to fix stuff that is freakin' hard when it's nearly as good to simply disable them. Like The Ball- do we need shadows? Definitely nice to have, but how much time are they worth? But Lava, yes, clearly we need lava here. If you want to try to work through a shadow problem before we get that far, post in the main HelixMod thread, and we can give it a try. My experience trying to fix shadows has been mostly frustration, hence my recommendation to try other stuff.
Thanks for that feedback, it's good to know that it's still been worth the time to create, and worth your time to view.

(Lesson 4 is the weakest of the set, I had a good idea there, but couldn't make it work well.)


I think Lesson 5 finishes my idea of what constitutes good basics and decent background so that the more complicated stuff does not become overwhelming.

Current plan is that Lesson 6 will discuss the Prime Directive, and then we'll move into applying the Prime Directive for fixes.

I plan to hit the normal fixes in order of complexity, so that we build on prior knowledge. I expect to get to shadows and reflections, but those will be nearly last, because they are much, much harder than anything else, and often do not conform to normal patterns that we see for other problems.

This is one reason I've started off by emphasizing disabled effects. A lot of times we'll try to fix stuff that is freakin' hard when it's nearly as good to simply disable them. Like The Ball- do we need shadows? Definitely nice to have, but how much time are they worth? But Lava, yes, clearly we need lava here.


If you want to try to work through a shadow problem before we get that far, post in the main HelixMod thread, and we can give it a try. My experience trying to fix shadows has been mostly frustration, hence my recommendation to try other stuff.

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 09/15/2014 07:00 AM   
[quote="bo3b"]Thanks for that feedback, it's good to know that it's still been worth the time to create, and worth your time to view. ...... Current plan is that Lesson 6 will discuss the Prime Directive, and then we'll move into applying the Prime Directive for fixes. I plan to hit the normal fixes in order of complexity, so that we build on prior knowledge. I expect to get to shadows and reflections, but those will be nearly last, because they are much, much harder than anything else, and often do not conform to normal patterns that we see for other problems. This is one reason I've started off by emphasizing disabled effects. A lot of times we'll try to fix stuff that is freakin' hard when it's nearly as good to simply disable them. Like The Ball- do we need shadows? Definitely nice to have, but how much time are they worth? But Lava, yes, clearly we need lava here. ..... My experience trying to fix shadows has been mostly frustration, hence my recommendation to try other stuff.[/quote] My experience with shadows is exactly the same;)) Although in my OpenGL wrapper I was able to fix a couple of them (thanks to help from Mike). But there I have access to the source code and everything makes "more" sense to me;)) The biggest problem that I am having is actually understanding WHY those operations are required in that order;)) I know, these are probably the most advanced fixes (due to the way shadows actually work and the projection from the light point of view and so on) but also are some of the most beautiful ones to master;)) I really intend to go with the Lessons all the way to the end and I didn't mention them above to put pressure or anything;)) I just wanted to show my enthusiasm basically at the awesome tutorials you are making;)) Every lesson I learn something new;)) and that is awesome;)) Can't wait for Lesson 6 and to see how those Prime Directives are working in ASM shaders;)) (I expect them to be the same as in GLSL only the code is different and thus the confusion). Keep up the awesome work!!! and thank you for taking the time to do this!!!
bo3b said:Thanks for that feedback, it's good to know that it's still been worth the time to create, and worth your time to view.

......

Current plan is that Lesson 6 will discuss the Prime Directive, and then we'll move into applying the Prime Directive for fixes.

I plan to hit the normal fixes in order of complexity, so that we build on prior knowledge. I expect to get to shadows and reflections, but those will be nearly last, because they are much, much harder than anything else, and often do not conform to normal patterns that we see for other problems.

This is one reason I've started off by emphasizing disabled effects. A lot of times we'll try to fix stuff that is freakin' hard when it's nearly as good to simply disable them. Like The Ball- do we need shadows? Definitely nice to have, but how much time are they worth? But Lava, yes, clearly we need lava here.

.....

My experience trying to fix shadows has been mostly frustration, hence my recommendation to try other stuff.



My experience with shadows is exactly the same;)) Although in my OpenGL wrapper I was able to fix a couple of them (thanks to help from Mike). But there I have access to the source code and everything makes "more" sense to me;)) The biggest problem that I am having is actually understanding WHY those operations are required in that order;))

I know, these are probably the most advanced fixes (due to the way shadows actually work and the projection from the light point of view and so on) but also are some of the most beautiful ones to master;))
I really intend to go with the Lessons all the way to the end and I didn't mention them above to put pressure or anything;)) I just wanted to show my enthusiasm basically at the awesome tutorials you are making;))
Every lesson I learn something new;)) and that is awesome;))

Can't wait for Lesson 6 and to see how those Prime Directives are working in ASM shaders;)) (I expect them to be the same as in GLSL only the code is different and thus the confusion).

Keep up the awesome work!!! and thank you for taking the time to do this!!!

1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc


My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com

(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)

Posted 09/15/2014 09:31 AM   
Is helixmod a spyware?! ;) bo3b, in Your lesson You once again picked up an issue I just had to deal with when I tried to fix a game. In this case disabling a part of a shader instead of the complete shader. Thank You so much for Your explanations and inspiration! I hope You don't mind that I tried to transfer Your lesson to another game instead of doing the quiz before... I had a look at "The Sims 4" (of course for my niece, not for myself ;)) and found a strange issue that at least in parts could be fixed by experimentation...
Is helixmod a spyware?! ;) bo3b, in Your lesson You once again picked up an issue I just had to deal with when I tried to fix a game. In this case disabling a part of a shader instead of the complete shader. Thank You so much for Your explanations and inspiration! I hope You don't mind that I tried to transfer Your lesson to another game instead of doing the quiz before... I had a look at "The Sims 4" (of course for my niece, not for myself ;)) and found a strange issue that at least in parts could be fixed by experimentation...

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 09/18/2014 01:27 PM   
If you've managed to fix a game, congratulations! Maybe you can get the fix put up on the Helix blog.
If you've managed to fix a game, congratulations! Maybe you can get the fix put up on the Helix blog.

Posted 09/18/2014 05:16 PM   
[quote="3d4dd"]Is helixmod a spyware?! ;) bo3b, in Your lesson You once again picked up an issue I just had to deal with when I tried to fix a game. In this case disabling a part of a shader instead of the complete shader. Thank You so much for Your explanations and inspiration! I hope You don't mind that I tried to transfer Your lesson to another game instead of doing the quiz before... I had a look at "The Sims 4" (of course for my niece, not for myself ;)) and found a strange issue that at least in parts could be fixed by experimentation...[/quote]No problem at all if people want to do other tests of their knowledge instead of the quiz. I make the quiz as something for people to use to practice their new knowledge. Without practice, you don't actually have the skill, as just reading about it is not the same as doing it. So, by all means, if there is something you find more interesting, do not hesitate to work on those. Please be sure to share your progress. Sharing is more fun. :->
3d4dd said:Is helixmod a spyware?! ;) bo3b, in Your lesson You once again picked up an issue I just had to deal with when I tried to fix a game. In this case disabling a part of a shader instead of the complete shader. Thank You so much for Your explanations and inspiration! I hope You don't mind that I tried to transfer Your lesson to another game instead of doing the quiz before... I had a look at "The Sims 4" (of course for my niece, not for myself ;)) and found a strange issue that at least in parts could be fixed by experimentation...
No problem at all if people want to do other tests of their knowledge instead of the quiz. I make the quiz as something for people to use to practice their new knowledge. Without practice, you don't actually have the skill, as just reading about it is not the same as doing it.

So, by all means, if there is something you find more interesting, do not hesitate to work on those. Please be sure to share your progress. Sharing is more fun. :->

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 09/19/2014 06:48 AM   
It's more a workaround than a real fix as I had to remove a gameplay element (painted ground textures like soil, cobblestone, etc.) to get rid of the issues. You can still use floor plates but I fear that this is not enough for a hard-core Sims fan. So I hope the issue really can be fixed (I will post about the issue in the How to... topic later). At least I would like to offer the possibility to toggle the fix. But it doesn't seem to work. Could it be that a game completely restricts the use of constants? I know that c256 is the maximum and that the constant definded in DX9Settings should not be used by other shaders in the dumpall folder. As c0-c249 already are used by other shaders I tried c250. But it didn't work. So I checked which constants I could use at least WITHIN the shader and used the following code in a test PS: [code]def c200, 0, 1, 0.0625, 0 ... mov r30.x, c200.w if_eq r30.x, c200.x mov oC0.xyzw, c200.wwww endif [/code] I know that the code doesn't make sense as it always should disable the shader output. But it was just for testing if the value of the constant is recognized correctly by if_eq. I discovered that it worked with c200 and I could change the shader and reload it with F10. Then I tried this code with c250, c251, c252, c253, c554, c255, c256: the shader output was NOT disabled and the shader obviously completely broken as I couldn't reload it with F10. I also tried other values (c230, c240) that are used in other shaders (like c200) and had the same problem. c230 and c240 could be global as they were not definded within the shaders. But c250-c256 are not used in other shaders (at least as far as dumpall works) and nevertheless do not work with DX9Settings or even within the shader. Any idea which constant I could use to toggle the shader?
It's more a workaround than a real fix as I had to remove a gameplay element (painted ground textures like soil, cobblestone, etc.) to get rid of the issues. You can still use floor plates but I fear that this is not enough for a hard-core Sims fan. So I hope the issue really can be fixed (I will post about the issue in the How to... topic later).

At least I would like to offer the possibility to toggle the fix. But it doesn't seem to work. Could it be that a game completely restricts the use of constants? I know that c256 is the maximum and that the constant definded in DX9Settings should not be used by other shaders in the dumpall folder. As c0-c249 already are used by other shaders I tried c250. But it didn't work. So I checked which constants I could use at least WITHIN the shader and used the following code in a test PS:
def c200, 0, 1, 0.0625, 0
...
mov r30.x, c200.w
if_eq r30.x, c200.x
mov oC0.xyzw, c200.wwww
endif

I know that the code doesn't make sense as it always should disable the shader output. But it was just for testing if the value of the constant is recognized correctly by if_eq. I discovered that it worked with c200 and I could change the shader and reload it with F10. Then I tried this code with c250, c251, c252, c253, c554, c255, c256: the shader output was NOT disabled and the shader obviously completely broken as I couldn't reload it with F10. I also tried other values (c230, c240) that are used in other shaders (like c200) and had the same problem. c230 and c240 could be global as they were not definded within the shaders. But c250-c256 are not used in other shaders (at least as far as dumpall works) and nevertheless do not work with DX9Settings or even within the shader. Any idea which constant I could use to toggle the shader?

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 09/19/2014 07:53 AM   
@Bo3b I have stumbled upon some problem(s) with disabling the effect on the layer causing the "doubling effect" on the water section where you fight the giant worm at the end. First off, I couldn't find any vertex shader associated with the water as a whole, or parts of it, but the one pixel shader I traced down, turned the entire surface of the water into texture. Until now, the effects on the earlier parts of the game, has either been invisible, colorized or distorted in some way (blurred, pixelated etc) as being the correct shader. This pixel shader makes the entire water surface texturized (seems like it's the texture from the walls that is being applied to the water surface. I recall this was "PixelShader_89_CRC32_B8341752". I've commented out each texldl function, and refreshed to see the changes in-game, what I noticed was the some of the texldl instructions/lines, was related to the movement of the stream in the water, some others were responsible for the waves and ripples on the water (by accentuating them). I wasn't sure where to continue from there, as you continued in your lesson to the inputs and outputs, and their importance. I noticed two dcl_texcoord instructions with three dimensions (v1, v2)(possibly related to the movement/position of the water stream). dcl_texcoord5 v1.xyw dcl_texcoord6 v2.xyz Since xyw, and xyz could be related to some moving layer/texture causing the doubling on the water, I decided to search by the v1 (as in the lava shader/layer). Replacing v1.xxx (preserving the different parameters used), with temp register r30. Then above adding the mov r30.xyzw, c200.wwww (c200 being the def c200 local register I created), and refreshing the game, odd occurences happended. The closest I got was to get rid of the haloing around the "weapon" pointing towards the water, but this made the entire water surface blue. The transparency of the water was gone. Only solid blue color with some bubbles and lights/shadows. In addition to that the entire screen was subdivided by four big squares. top-left, top-right, bottom-left, bottom-right, all had some strange artifacts with flickering of light and color fluctuations. So in other words not any ideal solution. I can't for the life of me think that this would be an adequate workaround. I just don't know where to look, or what to try next. Perhaps it isn't the correct shader, or I'm looking at this all wrong. Excuse me for perhaps referring to the wrong instructions, I need to check my shaderfiles if you need more details. Perhaps you could give me some input? I've also removed some subtle glow horizontal glow from the fire on some of the walls, as well as the mist on the bottom of the mountains in the intro cutscene. I figured you could hit the escape button, and you only got a little menu hud up on the screen, but the rest was there, so I had the time to localize the shader responsbile for the mist underneath the mountaints. I also removed some other problematic details. :) I'm really hoping to carry on with the lessons, as I find this extremely fascinating and educating. ;) And the experimenting lesson 5 tutorial, I did understand, and followed to a tee. Codewise, and in terms of how to think. So everything good, just really frustrates me that I'm a little stuck at this point. PS. I did find some relating VertexShaders by the way. Quite a few of them. But they were related to the reflections from the statues and walls from the environment onto the water surface. I don't know if this would be the shaders to focus on.
@Bo3b

I have stumbled upon some problem(s) with disabling the effect on the layer causing the "doubling effect" on the water section where you fight the giant worm at the end.

First off, I couldn't find any vertex shader associated with the water as a whole, or parts of it, but the one pixel shader I traced down, turned the entire surface of the water into texture. Until now, the effects on the earlier parts of the game, has either been invisible, colorized or distorted in some way (blurred, pixelated etc) as being the correct shader. This pixel shader makes the entire water surface texturized (seems like it's the texture from the walls that is being applied to the water surface. I recall this was "PixelShader_89_CRC32_B8341752".

I've commented out each texldl function, and refreshed to see the changes in-game, what I noticed was the some of the texldl instructions/lines, was related to the movement of the stream in the water, some others were responsible for the waves and ripples on the water (by accentuating them).
I wasn't sure where to continue from there, as you continued in your lesson to the inputs and outputs, and their importance. I noticed two dcl_texcoord instructions with three dimensions (v1, v2)(possibly related to the movement/position of the water stream).
dcl_texcoord5 v1.xyw
dcl_texcoord6 v2.xyz

Since xyw, and xyz could be related to some moving layer/texture causing the doubling on the water, I decided to search by the v1 (as in the lava shader/layer). Replacing v1.xxx (preserving the different parameters used), with temp register r30. Then above adding the mov r30.xyzw, c200.wwww (c200 being the def c200 local register I created), and refreshing the game, odd occurences happended. The closest I got was to get rid of the haloing around the "weapon" pointing towards the water, but this made the entire water surface blue. The transparency of the water was gone. Only solid blue color with some bubbles and lights/shadows. In addition to that the entire screen was subdivided by four big squares. top-left, top-right, bottom-left, bottom-right, all had some strange artifacts with flickering of light and color fluctuations. So in other words not any ideal solution. I can't for the life of me think that this would be an adequate workaround. I just don't know where to look, or what to try next. Perhaps it isn't the correct shader, or I'm looking at this all wrong. Excuse me for perhaps referring to the wrong instructions, I need to check my shaderfiles if you need more details.

Perhaps you could give me some input?

I've also removed some subtle glow horizontal glow from the fire on some of the walls, as well as the mist on the bottom of the mountains in the intro cutscene. I figured you could hit the escape button, and you only got a little menu hud up on the screen, but the rest was there, so I had the time to localize the shader responsbile for the mist underneath the mountaints. I also removed some other problematic details. :)

I'm really hoping to carry on with the lessons, as I find this extremely fascinating and educating. ;) And the experimenting lesson 5 tutorial, I did understand, and followed to a tee. Codewise, and in terms of how to think. So everything good, just really frustrates me that I'm a little stuck at this point.

PS. I did find some relating VertexShaders by the way. Quite a few of them. But they were related to the reflections from the statues and walls from the environment onto the water surface. I don't know if this would be the shaders to focus on.

CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2

Posted 09/19/2014 11:59 PM   
@InsameInGame: You have definitely already mastered that part of doing partial disabling. It's not always going to be possible to do things this way. The key aspect is experimenting on it to see if you can work out anything that is viable. Now, I have a confession to make. I don't actually know if the quiz for Lesson 5 is doable. I had meant to go back and look myself, but needed to help with WatchDogs fixes and did not get back to it. So it's entirely possible that you have done all that can be done. Sorry for wasting your time a bit there, but that experience is [i]exactly [/i]how working on the games will be. Very much frustration, not clear if it's possible. Very much a crazy, multi-faceted puzzle. While writing up the next lesson in fact, I just had the exact same experience, spending two hours on something that I know for a fact must work. It's always a challenge. For the water shader here, I would say the best place to look would be in the VertexShaders. It's suspicious that you have not found a VS, as there must be one. The v1.xyz you have there as texcoord5 is also very likely to be the input from the VS, and have a similar problem to the lava. Also, taking a quick look at that shader, see if you can replicate my change where I futz with v1 as some sort of stereo related input. The structure is very similar to the lava, look for uses of v1. Edit: I took a quick look at this one, and it might be too complicated for us at our present stage. Not sure, but the experimenting will make it more clear. The top surface of the water is controlled by that shader you reference above. It looks like it gets the alpha channel set to 0 as one of the last instructions (the .w assignment, same as .a assignment). I also see the same thing you get with a solid texture surface instead. With the right color choice, I think that would be a viable fix, and better than straight black. That alpha=0 suggests that the problem for the view might not be this shader. If a layer below that were doing some sort of bad refraction, that would also explain the look. And disabling that layer/shader might fix the bad look. The reflections in the water surface from the wall items is likely to be the VertexShader associated. As long as it's not the source of that light, but the reflection off the surface. i.e. the items on the wall don't disappear, only the reflection does. The halo around the gun being fixed is definitely a good clue that you've got the right texture. The fundamental problem is that the texture for that layer is offset, and thus at the wrong depth, which causes those halos.
@InsameInGame: You have definitely already mastered that part of doing partial disabling. It's not always going to be possible to do things this way. The key aspect is experimenting on it to see if you can work out anything that is viable.

Now, I have a confession to make. I don't actually know if the quiz for Lesson 5 is doable. I had meant to go back and look myself, but needed to help with WatchDogs fixes and did not get back to it. So it's entirely possible that you have done all that can be done. Sorry for wasting your time a bit there, but that experience is exactly how working on the games will be. Very much frustration, not clear if it's possible. Very much a crazy, multi-faceted puzzle.

While writing up the next lesson in fact, I just had the exact same experience, spending two hours on something that I know for a fact must work. It's always a challenge.


For the water shader here, I would say the best place to look would be in the VertexShaders. It's suspicious that you have not found a VS, as there must be one. The v1.xyz you have there as texcoord5 is also very likely to be the input from the VS, and have a similar problem to the lava.

Also, taking a quick look at that shader, see if you can replicate my change where I futz with v1 as some sort of stereo related input. The structure is very similar to the lava, look for uses of v1.


Edit: I took a quick look at this one, and it might be too complicated for us at our present stage. Not sure, but the experimenting will make it more clear.

The top surface of the water is controlled by that shader you reference above. It looks like it gets the alpha channel set to 0 as one of the last instructions (the .w assignment, same as .a assignment). I also see the same thing you get with a solid texture surface instead. With the right color choice, I think that would be a viable fix, and better than straight black.

That alpha=0 suggests that the problem for the view might not be this shader. If a layer below that were doing some sort of bad refraction, that would also explain the look. And disabling that layer/shader might fix the bad look.

The reflections in the water surface from the wall items is likely to be the VertexShader associated. As long as it's not the source of that light, but the reflection off the surface. i.e. the items on the wall don't disappear, only the reflection does.

The halo around the gun being fixed is definitely a good clue that you've got the right texture. The fundamental problem is that the texture for that layer is offset, and thus at the wrong depth, which causes those halos.

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 09/20/2014 03:27 AM   
Thank you so much for the valuable input. Yes, I rekon there will be quite som experimentation, trial and error, until one builds up enough experience to recognize common patterns, and even then there will be cases where you're groping in the dark so to speak. Like you said in one of your earlier lessons, that one have to experiment until it's more clear what is going on, then applying the respective fix. I'm new and learning, but I feel strong and passionate about progressing and experimenting, so this is right up my alley. hehe. ;) Yes, I thought so as well regarding the v1.xyz value in the pixel shader, that it should originate from the vertex shader output. There must be a shader that I've somehow missed. The key press sensitivity when navigating through the shaders is extremely high, so I might have spotted something, then stepped back too much (skipped a shader), and thought I didn't see anything the first time around. So I'll give it another shot. Thanks again. Have a great weekend. :)
Thank you so much for the valuable input. Yes, I rekon there will be quite som experimentation, trial and error, until one builds up enough experience to recognize common patterns, and even then there will be cases where you're groping in the dark so to speak. Like you said in one of your earlier lessons, that one have to experiment until it's more clear what is going on, then applying the respective fix. I'm new and learning, but I feel strong and passionate about progressing and experimenting, so this is right up my alley. hehe. ;)

Yes, I thought so as well regarding the v1.xyz value in the pixel shader, that it should originate from the vertex shader output. There must be a shader that I've somehow missed. The key press sensitivity when navigating through the shaders is extremely high, so I might have spotted something, then stepped back too much (skipped a shader), and thought I didn't see anything the first time around. So I'll give it another shot.

Thanks again. Have a great weekend. :)

CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2

Posted 09/20/2014 05:04 AM   
Yeah, this quiz is harder than the previous ones. :-> I took another longer look, and it's got a lot going on. Another way to find that VS is to look through the full dumps folder for texcoord5. There will be some smallish subset (hopefully) that have that as an output, and you narrow them down by setting that output to null in every instance you see, then do a binary search on those shaders to find the right one. So, for example, you have 25 shaders with texcoord5 output set to null, and you take half and re-enable them and reload with F10. If you see the effect change, you know it was in that half, if not, it's in the other half. Keep commenting and uncommenting half of the remaining, and you can narrow it down quickly. Log2(25)=5 tries in this case. For trying to find the exact shader using keys, you might have bring out your gaming reflexes to hit the key fast enough. Watch the number in the top left to see if you are getting too many hits. Also as part of the experimentation, you will get a feel for what parts affect what, and where the trouble might lie. After some experiments, it seems clear that in this shader, the glitch happens because of some refraction that is not correct in 3D. So trying to find the refraction and killing it would be one approach. Another approach would be to try to find how the top layer or layers are made, and make them less transparent, so that the refraction is not as annoying. Good luck with it.
Yeah, this quiz is harder than the previous ones. :-> I took another longer look, and it's got a lot going on.

Another way to find that VS is to look through the full dumps folder for texcoord5. There will be some smallish subset (hopefully) that have that as an output, and you narrow them down by setting that output to null in every instance you see, then do a binary search on those shaders to find the right one. So, for example, you have 25 shaders with texcoord5 output set to null, and you take half and re-enable them and reload with F10. If you see the effect change, you know it was in that half, if not, it's in the other half. Keep commenting and uncommenting half of the remaining, and you can narrow it down quickly. Log2(25)=5 tries in this case.

For trying to find the exact shader using keys, you might have bring out your gaming reflexes to hit the key fast enough. Watch the number in the top left to see if you are getting too many hits.


Also as part of the experimentation, you will get a feel for what parts affect what, and where the trouble might lie. After some experiments, it seems clear that in this shader, the glitch happens because of some refraction that is not correct in 3D. So trying to find the refraction and killing it would be one approach.

Another approach would be to try to find how the top layer or layers are made, and make them less transparent, so that the refraction is not as annoying. Good luck with it.

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 09/20/2014 05:39 AM   
[quote="3d4dd"]At least I would like to offer the possibility to toggle the fix. But it doesn't seem to work. Could it be that a game completely restricts the use of constants? I know that c256 is the maximum and that the constant definded in DX9Settings should not be used by other shaders in the dumpall folder. As c0-c249 already are used by other shaders I tried c250. But it didn't work. So I checked which constants I could use at least WITHIN the shader and used the following code in a test PS: [code]def c200, 0, 1, 0.0625, 0 ... mov r30.x, c200.w if_eq r30.x, c200.x mov oC0.xyzw, c200.wwww endif [/code] I know that the code doesn't make sense as it always should disable the shader output. But it was just for testing if the value of the constant is recognized correctly by if_eq. I discovered that it worked with c200 and I could change the shader and reload it with F10. Then I tried this code with c250, c251, c252, c253, c554, c255, c256: the shader output was NOT disabled and the shader obviously completely broken as I couldn't reload it with F10. I also tried other values (c230, c240) that are used in other shaders (like c200) and had the same problem. c230 and c240 could be global as they were not definded within the shaders. But c250-c256 are not used in other shaders (at least as far as dumpall works) and nevertheless do not work with DX9Settings or even within the shader. Any idea which constant I could use to toggle the shader?[/quote]It's often not clear to me what works and what doesn't, or why. Sometimes it can be that I make mistakes, like maybe setting the below code to use c255, but not changing the upper constant, so it's undefined. Without any notification on compile errors it's hard to tell when stuff like that happens. To get around, that I'll often put the mov oC0,c200.wwww at the bottom and comment and uncomment it, to make sure that it still works. If you can do both off and on, then that tells you that it's compiling at least, and thus the problem would be something else. You are on the right track with making your code a more sure experiment to try to clarify where the problem lies. The other thing to do in these sort of cases is to check the LOG.txt to see if there are any errors. No way to know what will work except by trial and error as far as I know. If c200 is working, why not use it?
3d4dd said:At least I would like to offer the possibility to toggle the fix. But it doesn't seem to work. Could it be that a game completely restricts the use of constants? I know that c256 is the maximum and that the constant definded in DX9Settings should not be used by other shaders in the dumpall folder. As c0-c249 already are used by other shaders I tried c250. But it didn't work. So I checked which constants I could use at least WITHIN the shader and used the following code in a test PS:
def c200, 0, 1, 0.0625, 0
...
mov r30.x, c200.w
if_eq r30.x, c200.x
mov oC0.xyzw, c200.wwww
endif

I know that the code doesn't make sense as it always should disable the shader output. But it was just for testing if the value of the constant is recognized correctly by if_eq. I discovered that it worked with c200 and I could change the shader and reload it with F10. Then I tried this code with c250, c251, c252, c253, c554, c255, c256: the shader output was NOT disabled and the shader obviously completely broken as I couldn't reload it with F10. I also tried other values (c230, c240) that are used in other shaders (like c200) and had the same problem. c230 and c240 could be global as they were not definded within the shaders. But c250-c256 are not used in other shaders (at least as far as dumpall works) and nevertheless do not work with DX9Settings or even within the shader. Any idea which constant I could use to toggle the shader?
It's often not clear to me what works and what doesn't, or why. Sometimes it can be that I make mistakes, like maybe setting the below code to use c255, but not changing the upper constant, so it's undefined. Without any notification on compile errors it's hard to tell when stuff like that happens.

To get around, that I'll often put the mov oC0,c200.wwww at the bottom and comment and uncomment it, to make sure that it still works. If you can do both off and on, then that tells you that it's compiling at least, and thus the problem would be something else. You are on the right track with making your code a more sure experiment to try to clarify where the problem lies.

The other thing to do in these sort of cases is to check the LOG.txt to see if there are any errors.

No way to know what will work except by trial and error as far as I know. If c200 is working, why not use it?

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 09/20/2014 05:45 AM   
I only had tested c200 within the shader and not as global DX9Settings.ini constant. As there are many hits for "c200" if I search the dumpall folder I thought that this could cause conflicts (like c250 did in The Ball). So I wanted to use a constant without hits (like c250, etc.). But now I have tried c200 in DX9Settings.ini and toggle worked. As far I could see there were no side effects with other shaders :) When I have used c250, c251, etc. commenting/uncommenting mov oC0,c200.wwww had no effect so using these contants seems to brake the shader.
I only had tested c200 within the shader and not as global DX9Settings.ini constant. As there are many hits for "c200" if I search the dumpall folder I thought that this could cause conflicts (like c250 did in The Ball). So I wanted to use a constant without hits (like c250, etc.). But now I have tried c200 in DX9Settings.ini and toggle worked. As far I could see there were no side effects with other shaders :) When I have used c250, c251, etc. commenting/uncommenting mov oC0,c200.wwww had no effect so using these contants seems to brake the shader.

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 09/20/2014 01:05 PM   
Ah, right, my confusion on Const1 use versus our c200 const. Looking for the use of the constants in the dumps folder is not a sure bet, just a guideline for likely candidates. There can be a lot of them used there that are not active in the scene that you are hacking upon, and thus would not conflict with use in your shader. I don't have a good answer for why they sometimes just don't work, and are otherwise unreferenced that you can see. It's almost certainly a conflict of some form, but we don't have any insight into how HelixMod is structured.
Ah, right, my confusion on Const1 use versus our c200 const.

Looking for the use of the constants in the dumps folder is not a sure bet, just a guideline for likely candidates. There can be a lot of them used there that are not active in the scene that you are hacking upon, and thus would not conflict with use in your shader.

I don't have a good answer for why they sometimes just don't work, and are otherwise unreferenced that you can see. It's almost certainly a conflict of some form, but we don't have any insight into how HelixMod is structured.

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 09/20/2014 01:21 PM   
I've not followed all this thread, but on constants you need to be aware that whereas the upper constant limit is 256, a given game can limit that (I don't know how, I just read about it). I regularly hit the problem where I can't use a constant past, say 225. This is usually reported in the LOG.txt file as an invalid constant. Also when looking for constants that might be in use, don't forget to make sure that you look at the full range of constants used in any given declaration. e.g. float4x4 thing c0 actually uses c0-c3. One scenario that has got me in the past is something called "bonematrices", which are to do with character rendering. These things are often declared using c0, but could easily be of size 200. A consequence of interfering with one of these constants is the effect where you get long lines sticking out of a persons body, or fingers etc.
I've not followed all this thread, but on constants you need to be aware that whereas the upper constant limit is 256, a given game can limit that (I don't know how, I just read about it). I regularly hit the problem where I can't use a constant past, say 225. This is usually reported in the LOG.txt file as an invalid constant. Also when looking for constants that might be in use, don't forget to make sure that you look at the full range of constants used in any given declaration. e.g. float4x4 thing c0 actually uses c0-c3. One scenario that has got me in the past is something called "bonematrices", which are to do with character rendering. These things are often declared using c0, but could easily be of size 200. A consequence of interfering with one of these constants is the effect where you get long lines sticking out of a persons body, or fingers etc.

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

Posted 09/20/2014 02:01 PM   
  13 / 87    
Scroll To Top