[quote=""]Hi Folks,
I encountered a strange 3dvision problem with Il2 Battle of Stalingrad : planes are hidden by cloud when in 3d vision mode but not when in normal mode !
In fact clouds are not drawn at the right depth. This problem can be seen when in external view. I managed to make plane appears by pushing cloud a bit forward, but this fix has a too much of drawbacks.
So I wonder, why going to 3dvision mode is making plane to be drawn after cloud ? As clouds are “cloudy” this should not be a problem to have plane drawn in front of clouds that are not at the right depth, but how to make that?
Is there a magic option that should help to fix this problem? Or something obvious to do in the shader ?
Here is a picture of the problem: in 2D mode plane is here [url]http://www.mediafire.com/view/78yj94c5d54jjyg/2015_6_13__11_45_31.jpg[/url] but not in 3d mode : [url]http://photos.3dvisionlive.com/lefuneste/image/557f3631e7e5642f7500006d/[/url]
And the shader I modified to push the cloud are this one : [url]http://www.mediafire.com/view/vquvy7i65bxf3mn/VertexShader_73_CRC32_40729A4C.txt[/url] (This is the original one, which is making the plane disapearing behind cloud). The shader seem used to draw clouds, when disabled there is no more clouds...
[/quote]
What's happening there is the cloud shader is sampling the depth buffer from the wrong location, and it is making the cloud too opaque where the plane is and too transparent off to either side (you can also see an outline of the cockpit poking a hole in the cloud - same cause.
This is a very common problem and is usually pretty straight forward to fix. Once you have finished bo3b's school up to lesson #6 you should have the skills you need to fix this.
If you get stuck, post the vertex & pixel shaders for the cloud and we can help you out.
said:Hi Folks,
I encountered a strange 3dvision problem with Il2 Battle of Stalingrad : planes are hidden by cloud when in 3d vision mode but not when in normal mode !
In fact clouds are not drawn at the right depth. This problem can be seen when in external view. I managed to make plane appears by pushing cloud a bit forward, but this fix has a too much of drawbacks.
So I wonder, why going to 3dvision mode is making plane to be drawn after cloud ? As clouds are “cloudy” this should not be a problem to have plane drawn in front of clouds that are not at the right depth, but how to make that?
Is there a magic option that should help to fix this problem? Or something obvious to do in the shader ?
What's happening there is the cloud shader is sampling the depth buffer from the wrong location, and it is making the cloud too opaque where the plane is and too transparent off to either side (you can also see an outline of the cockpit poking a hole in the cloud - same cause.
This is a very common problem and is usually pretty straight forward to fix. Once you have finished bo3b's school up to lesson #6 you should have the skills you need to fix this.
If you get stuck, post the vertex & pixel shaders for the cloud and we can help you out.
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
Thanks for the answer, I will go back to school.
I surely spent not enough time in it because I did not remeber to have seen things regarding the depth buffer location in the lessons...
Thanks for the answer, I will go back to school.
I surely spent not enough time in it because I did not remeber to have seen things regarding the depth buffer location in the lessons...
I'm not sure if the lessons explained that as the cause - but it was the issue with the lava and water in lesson #6, so I believe similar fix of adding the prime directive to one of the texcoords will very likely work here as well.
I'm not sure if the lessons explained that as the cause - but it was the issue with the lava and water in lesson #6, so I believe similar fix of adding the prime directive to one of the texcoords will very likely work here as well.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
So I saw again the lesson 6. Then try to use the canonical stereo code for my case. I have to say that I successfully use it previously to fix 2D items (HUD) and a smoke issue for IL2 BoS, but in vertex shaders.
But in this case I can not find the vertex shader related to my problem. The VertexPair/PixelPair numbers aret not working: the faulty pixel shader is the 7 number and it seems that there is no vertex shader pairing with this pixel shader !
Moreover, I found 3 vertex shaders related to clouds, with 8 to 9 outputs, the pixel shader has only 3 inputs. I was not able to correlate output disabling of any vertex shader with the outline issue. But maybe it's a "global" VS (disabling all the game picture) that is calling this pixel shader...
Anyway I tried to fix the pixel shader as in lesson 6, but I miserably failed to make something working...
My idea was to apply the canonical stereo code to the input of the PS instead of the output of the VS, but I did not manage to change anything...
Here is a link to the pixel shader : [url]http://www.mediafire.com/view/9rr5kenft6tc3av/PixelShader_5_CRC32_ABC76CF3.txt[/url]
I am sure that it makes the clouds transparents for the planes because when it is disabled the plane is also hidden by cloud in 2D mode. I prevously disabled it to avoid the cockpit frame outline, but wa s not aware of this side effect...
So I saw again the lesson 6. Then try to use the canonical stereo code for my case. I have to say that I successfully use it previously to fix 2D items (HUD) and a smoke issue for IL2 BoS, but in vertex shaders.
But in this case I can not find the vertex shader related to my problem. The VertexPair/PixelPair numbers aret not working: the faulty pixel shader is the 7 number and it seems that there is no vertex shader pairing with this pixel shader !
Moreover, I found 3 vertex shaders related to clouds, with 8 to 9 outputs, the pixel shader has only 3 inputs. I was not able to correlate output disabling of any vertex shader with the outline issue. But maybe it's a "global" VS (disabling all the game picture) that is calling this pixel shader...
Anyway I tried to fix the pixel shader as in lesson 6, but I miserably failed to make something working...
My idea was to apply the canonical stereo code to the input of the PS instead of the output of the VS, but I did not manage to change anything...
Here is a link to the pixel shader : http://www.mediafire.com/view/9rr5kenft6tc3av/PixelShader_5_CRC32_ABC76CF3.txt
I am sure that it makes the clouds transparents for the planes because when it is disabled the plane is also hidden by cloud in 2D mode. I prevously disabled it to avoid the cockpit frame outline, but wa s not aware of this side effect...
That pixel shader does not look very promising - it has three samplers, but none of them are the depth buffer I would have expected, and the only texcoord that is used to sample a texture (v0) only has X & Y coordinates -- no depth information to use with the prime directive.
As a side note, if you see a "preshader" like that one has you will need to remove it or comment it out before placing it in the ShaderOverride folder. The first non-comment line should be the ps_3_0 or vs_3_0 line.
Generally I look at the vertex shader for these types of issues first - it usually stems from there and as you learn to recognise the patterns that's the place to spot it (the pattern being that the output position is used for further calculations or copied to texture coordinate output). My shadertool.py script can often recognise this pattern and may be able to automatically fix it for you if you can find the right shader to run it on (shadertool.py -i --auto-fix-vertex-halo Dumps/SingleShaders/VertexShader/xxxxxxxxx.txt)
Sometimes it does turn out to be necessary to fix these issues in the pixel shader, but that's usually only the case for things like water and generally not clouds (the reason being that water has opacity, reflections and refractions and adjusting it in the vertex shader may fix one but break another).
That pixel shader does not look very promising - it has three samplers, but none of them are the depth buffer I would have expected, and the only texcoord that is used to sample a texture (v0) only has X & Y coordinates -- no depth information to use with the prime directive.
As a side note, if you see a "preshader" like that one has you will need to remove it or comment it out before placing it in the ShaderOverride folder. The first non-comment line should be the ps_3_0 or vs_3_0 line.
Generally I look at the vertex shader for these types of issues first - it usually stems from there and as you learn to recognise the patterns that's the place to spot it (the pattern being that the output position is used for further calculations or copied to texture coordinate output). My shadertool.py script can often recognise this pattern and may be able to automatically fix it for you if you can find the right shader to run it on (shadertool.py -i --auto-fix-vertex-halo Dumps/SingleShaders/VertexShader/xxxxxxxxx.txt)
Sometimes it does turn out to be necessary to fix these issues in the pixel shader, but that's usually only the case for things like water and generally not clouds (the reason being that water has opacity, reflections and refractions and adjusting it in the vertex shader may fix one but break another).
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
ok, I will hunt the VS related to this pixelshader.
I have a noob question regarding the input of the PS:
[code] dcl_texcoord v0.xy
dcl_texcoord1 v1.z
dcl_texcoord5 v2.xyz
dcl_texcoord7 v3[/code]
Does this mean that the VS should have output named textcoord1, 5, 7 ?
Does textcoord1 output only have z component or is it possible that the VS defines textcoord1 x&y components for other PS for example ?
Does this mean that the VS should have output named textcoord1, 5, 7 ?
Does textcoord1 output only have z component or is it possible that the VS defines textcoord1 x&y components for other PS for example ?
Yeah, the vertex shader will define outputs (o* registers) for texcoord0 (the 0 is usually omitted to texcoord), texcoord1, texcoord5, texcoord7 and possibly others - it should be a superset of the inputs found in the pixel shader.
It is possible that the vertex shader will define other components on a texcoord output as well (you are correct that other pixel shaders may use them). If you need these outputs in the pixel shader you can adjust the input mask to match, or remove the input mask altogether.
Yeah, the vertex shader will define outputs (o* registers) for texcoord0 (the 0 is usually omitted to texcoord), texcoord1, texcoord5, texcoord7 and possibly others - it should be a superset of the inputs found in the pixel shader.
It is possible that the vertex shader will define other components on a texcoord output as well (you are correct that other pixel shaders may use them). If you need these outputs in the pixel shader you can adjust the input mask to match, or remove the input mask altogether.
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 seems that I have found the shader: it is the [url=http://www.mediafire.com/view/6hjg2l9q9xio300/VertexShader_50_CRC32_37D9218A.txt]37D9218A[/url]. I managed to reduce the outline of the cockpit and also make plane visible by using a [url=http://www.mediafire.com/view/2khbed6cdzvtcns/37D9218A_const.txt]constant depth fix[/url]. Of course the fix is only working for the case used to define the depth. I tried to use the [url=http://www.mediafire.com/view/a936s91jdqupqil/37D9218A_canonical.txt]prime directive[/url], but it does not fix the problem...
What do you think about it ?
I did not try your script, because I want to understand the problem...
Here are picture for [url=https://shar.es/1qtPzk]default shader[/url], for [url=https://shar.es/1qtPBp]canonical modified shader[/url] and constant depth fix [url=https://shar.es/1qtPLw]view 1[/url] and [url=https://shar.es/1qtMmN]view 2[/url]
I seems that I have found the shader: it is the 37D9218A. I managed to reduce the outline of the cockpit and also make plane visible by using a constant depth fix. Of course the fix is only working for the case used to define the depth. I tried to use the prime directive, but it does not fix the problem...
What do you think about it ?
I did not try your script, because I want to understand the problem...
Here are picture for default shader, for canonical modified shader and constant depth fix view 1 and view 2
Sure, let's take a look at the shader and I'll point out what I look for in this pattern:
[code]...
preshader
rcp c0.x, c2.x
neg r0.x, c2.z
...[/code] Remove or comment out this preshader section to make sure it will work with Helix Mod.
[code]
vs_3_0
...
dcl_position v0
dcl_position o0
[/code] Note which output register is the position, in this case o0. Let's look for where it's used...
[code]
...
dp4 r1.x, r2, c11
dp4 r1.y, r2, c12
dp4 r1.z, r2, c13
dp4 r1.w, r2, c14
mov o0, r1
[/code]Here we see that the output position is set from a temporary register r1. The output position will be adjusted automatically by the driver, but if anything else in this shader uses r1 it will likely need to be adjusted. This would be a good spot to insert the prime directive on r1 so any more uses below this point get the adjusted version as well.
[code]
...
mov r3.zw, r1
[/code] Here we see r1 is used again, but as this only uses the Z and W components it won't matter since we only adjust X. Let's keep looking...
[code]
...
dp3 r1.z, r2, v0
[/code]This line replaced r1.z with something else. Still not interesting, let's keep looking...
[code]
...
mul r4, r1.xwwy, c26.yyzw
[/code]Ah ha! This line is using the X component of r1, so it needs to be adjusted before this point.
Here we see that the output position is set from a temporary register r1. The output position will be adjusted automatically by the driver, but if anything else in this shader uses r1 it will likely need to be adjusted. This would be a good spot to insert the prime directive on r1 so any more uses below this point get the adjusted version as well.
...
mov r3.zw, r1
Here we see r1 is used again, but as this only uses the Z and W components it won't matter since we only adjust X. Let's keep looking...
...
dp3 r1.z, r2, v0
This line replaced r1.z with something else. Still not interesting, let's keep looking...
...
mul r4, r1.xwwy, c26.yyzw
Ah ha! This line is using the X component of r1, so it needs to be adjusted before this point.
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
You are a great man !
It works for the plane ! I have to double check for cockpit outline, because there is heavy ghosting whith white clouds but it should also be OK.
Do you have an idea for the left bar on the screen ? It is still there.
There are now some compatibity issues with some other fixes I made before (output disabled or Pixel shaders disabed) so I have now to identify which shaders are faulty and try to fix them instead of disabling them...
You are a great man !
It works for the plane ! I have to double check for cockpit outline, because there is heavy ghosting whith white clouds but it should also be OK.
Do you have an idea for the left bar on the screen ? It is still there.
There are now some compatibity issues with some other fixes I made before (output disabled or Pixel shaders disabed) so I have now to identify which shaders are faulty and try to fix them instead of disabling them...
I was able to fix some shader instead of disabling them, but I am stuck with [url=http://www.mediafire.com/view/4egzboah9nw4y10/VertexShader_19_CRC32_D0834DE6.txt]this one[/url].
I made different try but did not achieve to fix it...o0 as a constant depth, but this is not the case of o1 impact on image...
Disabling o1 solve the problem (still outline for cockpit and parts of plane in external view) but this also introduce flashing on ground texture.
I was able to fix some shader instead of disabling them, but I am stuck with this one.
I made different try but did not achieve to fix it...o0 as a constant depth, but this is not the case of o1 impact on image...
Disabling o1 solve the problem (still outline for cockpit and parts of plane in external view) but this also introduce flashing on ground texture.
That particular shader is not performing any transformations (input position v0.xy is directly copied to output position o0.xy), so chances are any fixes will have to take place in the pixel shader. What effect is that one responsible for?
As for the bar on the side of the screen - there might not be anything you can do, but first try setting max pre-prenderd frames to 1 in the nvidia control panel in case that helps. If not, focus on any other issues first since sometimes a problem like that is a side effect of another issue. There's only a few times when I've gone out of my way to remove an issue at the side of the screen, and they were difficult (in Far Cry 4 Mike and I moved the position of the reflected objects and the reflection sampler to counter it, and in Miasmata I had to do all sorts of tricks to hide a really nasty issue in the fog/light shaft layer).
That particular shader is not performing any transformations (input position v0.xy is directly copied to output position o0.xy), so chances are any fixes will have to take place in the pixel shader. What effect is that one responsible for?
As for the bar on the side of the screen - there might not be anything you can do, but first try setting max pre-prenderd frames to 1 in the nvidia control panel in case that helps. If not, focus on any other issues first since sometimes a problem like that is a side effect of another issue. There's only a few times when I've gone out of my way to remove an issue at the side of the screen, and they were difficult (in Far Cry 4 Mike and I moved the position of the reflected objects and the reflection sampler to counter it, and in Miasmata I had to do all sorts of tricks to hide a really nasty issue in the fog/light shaft layer).
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
It's hard to explain, some fine light effects. But when I disable the o1 output it makes outlines disapear.
Should it be possible that VS are chained and so, when I disable an output in a "middle" VS I disrupt the flow and consequently disable the effect ?
It's hard to explain, some fine light effects. But when I disable the o1 output it makes outlines disapear.
Should it be possible that VS are chained and so, when I disable an output in a "middle" VS I disrupt the flow and consequently disable the effect ?
It might be easier to provide a screenshot of that effect so I can see what you mean.
It is possible that an effect may be built up using several passes, so breaking the VS in a middle pass could well disrupt it and may or may not disable the effect. This won't be two vertex shaders chained together - rather a pair of vertex and pixel shaders would be used to render an intermediate step to a temporary off-screen buffer, which will then be passed in as an input to another pair of vertex and pixel shaders (in some cases both passes may use the same vertex and/or pixel shader, in other cases they will all be unique).
This type of thing is fairly common with shadows for example, where the depth information of scene is rendered from the perspective of a light source in a bunch of passes, then a final pass will actually render the shadow on to the back buffer. I've also seen similar multi-pass rendering on certain types of light shafts and ambient occlusion effects, as well as ripples for water, etc.
It might be easier to provide a screenshot of that effect so I can see what you mean.
It is possible that an effect may be built up using several passes, so breaking the VS in a middle pass could well disrupt it and may or may not disable the effect. This won't be two vertex shaders chained together - rather a pair of vertex and pixel shaders would be used to render an intermediate step to a temporary off-screen buffer, which will then be passed in as an input to another pair of vertex and pixel shaders (in some cases both passes may use the same vertex and/or pixel shader, in other cases they will all be unique).
This type of thing is fairly common with shadows for example, where the depth information of scene is rendered from the perspective of a light source in a bunch of passes, then a final pass will actually render the shadow on to the back buffer. I've also seen similar multi-pass rendering on certain types of light shafts and ambient occlusion effects, as well as ripples for water, etc.
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
unfortunately, I will not be able to access to my PC for 2 or 3 weeks...
It seems that the bugs may be related to SSAO processing. Fortunately the next patch for IL2 BOS will allow to disable SSAO effects. So I do not know if I will keep on fixing it...
It will depend of the difficutly to identify which output of which shader is still bothering me, as now I know that they should be linked and I have to work on the "father" to fix the problem...
unfortunately, I will not be able to access to my PC for 2 or 3 weeks...
It seems that the bugs may be related to SSAO processing. Fortunately the next patch for IL2 BOS will allow to disable SSAO effects. So I do not know if I will keep on fixing it...
It will depend of the difficutly to identify which output of which shader is still bothering me, as now I know that they should be linked and I have to work on the "father" to fix the problem...
What's happening there is the cloud shader is sampling the depth buffer from the wrong location, and it is making the cloud too opaque where the plane is and too transparent off to either side (you can also see an outline of the cockpit poking a hole in the cloud - same cause.
This is a very common problem and is usually pretty straight forward to fix. Once you have finished bo3b's school up to lesson #6 you should have the skills you need to fix this.
If you get stuck, post the vertex & pixel shaders for the cloud and we can help you out.
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
I surely spent not enough time in it because I did not remeber to have seen things regarding the depth buffer location in the lessons...
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
But in this case I can not find the vertex shader related to my problem. The VertexPair/PixelPair numbers aret not working: the faulty pixel shader is the 7 number and it seems that there is no vertex shader pairing with this pixel shader !
Moreover, I found 3 vertex shaders related to clouds, with 8 to 9 outputs, the pixel shader has only 3 inputs. I was not able to correlate output disabling of any vertex shader with the outline issue. But maybe it's a "global" VS (disabling all the game picture) that is calling this pixel shader...
Anyway I tried to fix the pixel shader as in lesson 6, but I miserably failed to make something working...
My idea was to apply the canonical stereo code to the input of the PS instead of the output of the VS, but I did not manage to change anything...
Here is a link to the pixel shader : http://www.mediafire.com/view/9rr5kenft6tc3av/PixelShader_5_CRC32_ABC76CF3.txt
I am sure that it makes the clouds transparents for the planes because when it is disabled the plane is also hidden by cloud in 2D mode. I prevously disabled it to avoid the cockpit frame outline, but wa s not aware of this side effect...
As a side note, if you see a "preshader" like that one has you will need to remove it or comment it out before placing it in the ShaderOverride folder. The first non-comment line should be the ps_3_0 or vs_3_0 line.
Generally I look at the vertex shader for these types of issues first - it usually stems from there and as you learn to recognise the patterns that's the place to spot it (the pattern being that the output position is used for further calculations or copied to texture coordinate output). My shadertool.py script can often recognise this pattern and may be able to automatically fix it for you if you can find the right shader to run it on (shadertool.py -i --auto-fix-vertex-halo Dumps/SingleShaders/VertexShader/xxxxxxxxx.txt)
Sometimes it does turn out to be necessary to fix these issues in the pixel shader, but that's usually only the case for things like water and generally not clouds (the reason being that water has opacity, reflections and refractions and adjusting it in the vertex shader may fix one but break another).
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
I have a noob question regarding the input of the PS:
Does this mean that the VS should have output named textcoord1, 5, 7 ?
Does textcoord1 output only have z component or is it possible that the VS defines textcoord1 x&y components for other PS for example ?
It is possible that the vertex shader will define other components on a texcoord output as well (you are correct that other pixel shaders may use them). If you need these outputs in the pixel shader you can adjust the input mask to match, or remove the input mask altogether.
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
What do you think about it ?
I did not try your script, because I want to understand the problem...
Here are picture for default shader, for canonical modified shader and constant depth fix view 1 and view 2
Remove or comment out this preshader section to make sure it will work with Helix Mod.
Note which output register is the position, in this case o0. Let's look for where it's used...
Here we see that the output position is set from a temporary register r1. The output position will be adjusted automatically by the driver, but if anything else in this shader uses r1 it will likely need to be adjusted. This would be a good spot to insert the prime directive on r1 so any more uses below this point get the adjusted version as well.
Here we see r1 is used again, but as this only uses the Z and W components it won't matter since we only adjust X. Let's keep looking...
This line replaced r1.z with something else. Still not interesting, let's keep looking...
Ah ha! This line is using the X component of r1, so it needs to be adjusted before this point.
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
It works for the plane ! I have to double check for cockpit outline, because there is heavy ghosting whith white clouds but it should also be OK.
Do you have an idea for the left bar on the screen ? It is still there.
There are now some compatibity issues with some other fixes I made before (output disabled or Pixel shaders disabed) so I have now to identify which shaders are faulty and try to fix them instead of disabling them...
I made different try but did not achieve to fix it...o0 as a constant depth, but this is not the case of o1 impact on image...
Disabling o1 solve the problem (still outline for cockpit and parts of plane in external view) but this also introduce flashing on ground texture.
As for the bar on the side of the screen - there might not be anything you can do, but first try setting max pre-prenderd frames to 1 in the nvidia control panel in case that helps. If not, focus on any other issues first since sometimes a problem like that is a side effect of another issue. There's only a few times when I've gone out of my way to remove an issue at the side of the screen, and they were difficult (in Far Cry 4 Mike and I moved the position of the reflected objects and the reflection sampler to counter it, and in Miasmata I had to do all sorts of tricks to hide a really nasty issue in the fog/light shaft layer).
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
Should it be possible that VS are chained and so, when I disable an output in a "middle" VS I disrupt the flow and consequently disable the effect ?
It is possible that an effect may be built up using several passes, so breaking the VS in a middle pass could well disrupt it and may or may not disable the effect. This won't be two vertex shaders chained together - rather a pair of vertex and pixel shaders would be used to render an intermediate step to a temporary off-screen buffer, which will then be passed in as an input to another pair of vertex and pixel shaders (in some cases both passes may use the same vertex and/or pixel shader, in other cases they will all be unique).
This type of thing is fairly common with shadows for example, where the depth information of scene is rendered from the perspective of a light source in a bunch of passes, then a final pass will actually render the shadow on to the back buffer. I've also seen similar multi-pass rendering on certain types of light shafts and ambient occlusion effects, as well as ripples for water, etc.
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
It seems that the bugs may be related to SSAO processing. Fortunately the next patch for IL2 BOS will allow to disable SSAO effects. So I do not know if I will keep on fixing it...
It will depend of the difficutly to identify which output of which shader is still bothering me, as now I know that they should be linked and I have to work on the "father" to fix the problem...