Actually, I was thinking it would be the other way around. We don't add complexity and more weirdness to the already weird reloading/loading code, the end-user would just use shortcuts as their way of managing the details. So, a sub-folder named Shadows has shortcuts to all the shaders being set up as Shadow fixes, and double clicks would open them directly in the editor.
We could also use hard-links, but all of this is pretty small wins compared to other stuff we can spend time upon. If there is a decent offline/non-tool workaround I still think we are better served to use those.
I'm sure you've all heard of "technical-debt". I'm working as a consultant, and I typically come into organizations that are actually frozen in place because of their technical-debt. Technical-debt generally is the same thing as complexity. It's easy to put in one more 'if' statement, and hack workaround, and small tweak, and tiny feature request, and emergency change, until after awhile you have the classic spaghetti code that no one can add anything to, or fix bugs in without breaking something else. That's technical-debt, and it's why I'm such a pain-in-the-ass about discouraging complexity.
By the far the biggest challenge I see in my consulting jobs is that creeping complexity.
Actually, I was thinking it would be the other way around. We don't add complexity and more weirdness to the already weird reloading/loading code, the end-user would just use shortcuts as their way of managing the details. So, a sub-folder named Shadows has shortcuts to all the shaders being set up as Shadow fixes, and double clicks would open them directly in the editor.
We could also use hard-links, but all of this is pretty small wins compared to other stuff we can spend time upon. If there is a decent offline/non-tool workaround I still think we are better served to use those.
I'm sure you've all heard of "technical-debt". I'm working as a consultant, and I typically come into organizations that are actually frozen in place because of their technical-debt. Technical-debt generally is the same thing as complexity. It's easy to put in one more 'if' statement, and hack workaround, and small tweak, and tiny feature request, and emergency change, until after awhile you have the classic spaghetti code that no one can add anything to, or fix bugs in without breaking something else. That's technical-debt, and it's why I'm such a pain-in-the-ass about discouraging complexity.
By the far the biggest challenge I see in my consulting jobs is that creeping complexity.
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 totally understand your concerns about the overhead the folder crawling may cause, but that folder structure is only needed during the modding process. My game is on the SSD so I do not feel any delay when pressing F10. This folder/renamed shaders implementation could be used only with hunting flag set to > 0 for example and work in optimized way for the end user. You are the masters here, so it's your call, I'm not trying to enforce any of my ideas, just trying to help to make the modding process less time consuming.
I'm gonna try the shortcuts/symlinks method today.
Thank you for fixing the missing variable modifiers.
I totally understand your concerns about the overhead the folder crawling may cause, but that folder structure is only needed during the modding process. My game is on the SSD so I do not feel any delay when pressing F10. This folder/renamed shaders implementation could be used only with hunting flag set to > 0 for example and work in optimized way for the end user. You are the masters here, so it's your call, I'm not trying to enforce any of my ideas, just trying to help to make the modding process less time consuming.
I'm gonna try the shortcuts/symlinks method today.
Thank you for fixing the missing variable modifiers.
[quote="bo3b"]Actually, I was thinking it would be the other way around. We don't add complexity and more weirdness to the already weird reloading/loading code, the end-user would just use shortcuts as their way of managing the details. So, a sub-folder named Shadows has shortcuts to all the shaders being set up as Shadow fixes, and double clicks would open them directly in the editor.
We could also use hard-links, but all of this is pretty small wins compared to other stuff we can spend time upon. If there is a decent offline/non-tool workaround I still think we are better served to use those.
I'm sure you've all heard of "technical-debt". I'm working as a consultant, and I typically come into organizations that are actually frozen in place because of their technical-debt. Technical-debt generally is the same thing as complexity. It's easy to put in one more 'if' statement, and hack workaround, and small tweak, and tiny feature request, and emergency change, until after awhile you have the classic spaghetti code that no one can add anything to, or fix bugs in without breaking something else. That's technical-debt, and it's why I'm such a pain-in-the-ass about discouraging complexity.
By the far the biggest challenge I see in my consulting jobs is that creeping complexity.[/quote]
Ok, now I have a full picture. You are a rare specimen, you know that :) ?
bo3b said:Actually, I was thinking it would be the other way around. We don't add complexity and more weirdness to the already weird reloading/loading code, the end-user would just use shortcuts as their way of managing the details. So, a sub-folder named Shadows has shortcuts to all the shaders being set up as Shadow fixes, and double clicks would open them directly in the editor.
We could also use hard-links, but all of this is pretty small wins compared to other stuff we can spend time upon. If there is a decent offline/non-tool workaround I still think we are better served to use those.
I'm sure you've all heard of "technical-debt". I'm working as a consultant, and I typically come into organizations that are actually frozen in place because of their technical-debt. Technical-debt generally is the same thing as complexity. It's easy to put in one more 'if' statement, and hack workaround, and small tweak, and tiny feature request, and emergency change, until after awhile you have the classic spaghetti code that no one can add anything to, or fix bugs in without breaking something else. That's technical-debt, and it's why I'm such a pain-in-the-ass about discouraging complexity.
By the far the biggest challenge I see in my consulting jobs is that creeping complexity.
Ok, now I have a full picture. You are a rare specimen, you know that :) ?
[quote="bo3b"]Actually, I was thinking it would be the other way around. We don't add complexity and more weirdness to the already weird reloading/loading code, the end-user would just use shortcuts as their way of managing the details. So, a sub-folder named Shadows has shortcuts to all the shaders being set up as Shadow fixes, and double clicks would open them directly in the editor.[/quote]Zero effort for us - sounds good :)
bo3b said:Actually, I was thinking it would be the other way around. We don't add complexity and more weirdness to the already weird reloading/loading code, the end-user would just use shortcuts as their way of managing the details. So, a sub-folder named Shadows has shortcuts to all the shaders being set up as Shadow fixes, and double clicks would open them directly in the editor.
Zero effort for us - sounds good :)
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
Allow me go back to that unfortunate water shader with a broken mask. Adding the centriod modifiers or exporting the shader with the latest 3DM didn't change much. I found one thing though. When I comment the line 134 which you can see below it works as intended.
This line looks a bit suspicious to me, or maybe it's just my lack of knowledge of the asm code.
Would you confirm please if the asm line below really should be looking like the above HLSL code?
Yep, I think you are looking at the right general area - booleans and integers are problem areas for the decompiler due to fundamental differences between typeless GPU registers and fully typed HLSL variables.
I think you actually need to change it from this:
[code]
r1.w = 0 < r1.y;
r1.y = r1.y < 0;
r1.y = ((int)r1.y ? -1 : 0) + ((int)r1.w ? 1 : 0);
[/code]
To this:
[code]
r1.w = (0 < r1.y ? -1 : 0);
r1.y = (r1.y < 0 ? -1 : 0);
r1.y = (int)r1.w - (int)r1.y;
[/code]
The problem here is that in HLSL the result of a boolean test is 0 or 1, but in shader assembly it's 0 or 0xffffffff (-1 as a signed integer). 3DMigoto is taking a different approach and trying to keep track of which components of which variables are booleans (which is why the iadd looked funny), but I don't think it gets it right in every situation.
Yep, I think you are looking at the right general area - booleans and integers are problem areas for the decompiler due to fundamental differences between typeless GPU registers and fully typed HLSL variables.
The problem here is that in HLSL the result of a boolean test is 0 or 1, but in shader assembly it's 0 or 0xffffffff (-1 as a signed integer). 3DMigoto is taking a different approach and trying to keep track of which components of which variables are booleans (which is why the iadd looked funny), but I don't think it gets it right in every situation.
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
Dang, that diff I posted only has 5 lines that don't line up, and those are three. :->
When I paste in DarkStarSword's code into the shader, I get the same iadd instruction desired, so this is very likely the fix.
I actually have prototyped a generalized fix for this -1 vs. 1 problem, but haven't yet tested it enough to have confidence in it. I'll use your shader here as another example.
Dang, that diff I posted only has 5 lines that don't line up, and those are three. :->
When I paste in DarkStarSword's code into the shader, I get the same iadd instruction desired, so this is very likely the fix.
I actually have prototyped a generalized fix for this -1 vs. 1 problem, but haven't yet tested it enough to have confidence in it. I'll use your shader here as another example.
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
Is it yet possible to share the variables beteen shaders from main() for example v1? I searched the wiki page but I coudn't find anything in that matter.
Is it yet possible to share the variables beteen shaders from main() for example v1? I searched the wiki page but I coudn't find anything in that matter.
What type of shader are you trying to copy them from?
For vertex shaders these variables come from the vertex buffers, and starting with 3DMigoto 1.2.11 it is possible to copy a vertex buffer into a texture slot and 3DMigoto will convert it into a structured buffer making it possible to index to look up the inputs to any of the vertices in the draw call. Alternatively, you can copy it into a constant buffer slot, but doing so will make it a lot harder to look up individual entries as you cannot simply index them like you can with a structured buffer (I have got this to work, but there's a whole bunch of gotchas involved).
Please note that there might be an issue with this feature if the game is passing a vertex offset of a per-draw call basis (3DMigoto takes care of the offset the game sets when binding the vertex buffer, but not the individual draw calls - I need to find a game that does that to test it).
I'm using this in FC4 to look up the position of other vertices (I'm not copying it between shaders, but that should work).
[code]
[ShaderOverrideCrosshairMapAndIcons]
Hash = 50344260ea3c9a9c
vs-t100 = vb0
[/code]
[code]
// Structure of the vertex buffer - this essentially matches the input
// signature of the shader, but the formats won't be interpreted the same since
// that relies on the input assembler layout. In this case that means we can't
// use a float4 for the color0 entry, as that would mean 4x4 byte values, but
// in the vertex buffer it's only 4x1 byte values. Since we don't actually care
// about it, just use a float so that the size matches.
struct vb_entry
{
float2 vb_position;
float2 vb_texcoord;
// Don't be fooled by the float4 in the input signature - in
// the vertex buffer this is just a single 4 byte value:
float color0;
};
StructuredBuffer<struct vb_entry> vb_struct : register(t100);
float2 find_quad_center(uint id)
{
// Round down to the first vertex in this icon. Each icon is made up of
// two triangles for six vertices each:
id = id / 6 * 6;
// Look up two diagonally oposite vertices so that the average is at
// the center. In this game I can get away with vertex 0 and 2 - other
// games may need different vertices. If all else fails, we could
// always average all six to find the center
float2 pos1 = vb_struct[id].vb_position;
float2 pos2 = vb_struct[id + 2].vb_position;
return (pos1 + pos2) / 2;
}
[/code]
For reference, the input signature of that shader is (I added the SV_VertexID, which is what I pass to find_quad_center):
[code]
void main(
float2 v0 : position0,
float2 v1 : texcoord0,
float4 v2 : color0,
out float4 o0 : SV_Position0,
out float4 o1 : TEXCOORD0,
out float4 o2 : TEXCOORD1,
uint id : SV_VertexID
)
[/code]
The real trick here is going to be creating a structure definition that matches the layout in the vertex buffer since there is currently no way to dump out the Input Assembler Layout which would tell you the binary encoding of each field. You might be able to guess - in the above example there wasn't anything too surprising, as the position and texcoord were declared as float2s in the signature and were in fact 2 x 32bit floats in the vertex buffer, but the color was declared as a float4, but was actually only a single 4 byte value.
You can use frame analysis to dump out the vertex buffer as text (analyse_options=dump_vb_txt), which will tell you the structure size ("stride") will try to decode everything in the buffer as 32bit floats (at some point I want to make it use the Input Assembler layout to use the correct format to decode them properly, but DX is missing the APIs to make that easy). dump_cb_txt will dump from the offset to the end of the buffer, which will probably include a whole bunch of unrelated data - so don't pay too much attention to it beyond the first couple of entries, especially if the pattern seems to change.
For other shader types, the variables are passed from earlier shaders and cannot be copied directly. It would be tricky to copy these, but you coule potentially copy the inputs from the previous shader instead and recalculate them in the destination shader, or perhaps add an extra render target output to the pixel shader and write them there.
What type of shader are you trying to copy them from?
For vertex shaders these variables come from the vertex buffers, and starting with 3DMigoto 1.2.11 it is possible to copy a vertex buffer into a texture slot and 3DMigoto will convert it into a structured buffer making it possible to index to look up the inputs to any of the vertices in the draw call. Alternatively, you can copy it into a constant buffer slot, but doing so will make it a lot harder to look up individual entries as you cannot simply index them like you can with a structured buffer (I have got this to work, but there's a whole bunch of gotchas involved).
Please note that there might be an issue with this feature if the game is passing a vertex offset of a per-draw call basis (3DMigoto takes care of the offset the game sets when binding the vertex buffer, but not the individual draw calls - I need to find a game that does that to test it).
I'm using this in FC4 to look up the position of other vertices (I'm not copying it between shaders, but that should work).
// Structure of the vertex buffer - this essentially matches the input
// signature of the shader, but the formats won't be interpreted the same since
// that relies on the input assembler layout. In this case that means we can't
// use a float4 for the color0 entry, as that would mean 4x4 byte values, but
// in the vertex buffer it's only 4x1 byte values. Since we don't actually care
// about it, just use a float so that the size matches.
struct vb_entry
{
float2 vb_position;
float2 vb_texcoord;
// Don't be fooled by the float4 in the input signature - in
// the vertex buffer this is just a single 4 byte value:
float color0;
};
float2 find_quad_center(uint id)
{
// Round down to the first vertex in this icon. Each icon is made up of
// two triangles for six vertices each:
id = id / 6 * 6;
// Look up two diagonally oposite vertices so that the average is at
// the center. In this game I can get away with vertex 0 and 2 - other
// games may need different vertices. If all else fails, we could
// always average all six to find the center
float2 pos1 = vb_struct[id].vb_position;
float2 pos2 = vb_struct[id + 2].vb_position;
return (pos1 + pos2) / 2;
}
For reference, the input signature of that shader is (I added the SV_VertexID, which is what I pass to find_quad_center):
void main(
float2 v0 : position0,
float2 v1 : texcoord0,
float4 v2 : color0,
out float4 o0 : SV_Position0,
out float4 o1 : TEXCOORD0,
out float4 o2 : TEXCOORD1,
uint id : SV_VertexID
)
The real trick here is going to be creating a structure definition that matches the layout in the vertex buffer since there is currently no way to dump out the Input Assembler Layout which would tell you the binary encoding of each field. You might be able to guess - in the above example there wasn't anything too surprising, as the position and texcoord were declared as float2s in the signature and were in fact 2 x 32bit floats in the vertex buffer, but the color was declared as a float4, but was actually only a single 4 byte value.
You can use frame analysis to dump out the vertex buffer as text (analyse_options=dump_vb_txt), which will tell you the structure size ("stride") will try to decode everything in the buffer as 32bit floats (at some point I want to make it use the Input Assembler layout to use the correct format to decode them properly, but DX is missing the APIs to make that easy). dump_cb_txt will dump from the offset to the end of the buffer, which will probably include a whole bunch of unrelated data - so don't pay too much attention to it beyond the first couple of entries, especially if the pattern seems to change.
For other shader types, the variables are passed from earlier shaders and cannot be copied directly. It would be tricky to copy these, but you coule potentially copy the inputs from the previous shader instead and recalculate them in the destination shader, or perhaps add an extra render target output to the pixel shader and write them there.
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
oh ok, so you are trying to copy it from a pixel shader.
Can you post the corresponding vertex shader (and domain and geometry shaders if they are used by this effect) so I can see where that texcoord would have come from? Also, that texcoord can potentially vary over the surface of the object, so can you tell me a little about what you are trying to achieve so I can try to offer the best advice?
The way I see it there are three possibilities:
- Assign a new render target that you can copy it to and sample that in another shader (suitable if you need the values copied on a per-pixel basis)
- Determine how that texcoord is derived in the vertex/domain/geometry shader and copy that procedure and all necessary inputs to the destination shader where you will derive it from scratch.
- (Needs a new 3DMigoto feature) Assign a buffer to the stream output stage of the pipeline to capture the texcoord output from the vertex/geometry shader directly (suitable if you need the values copied on a per-vertex basis). This will need non-trivial support added to 3DMigoto to work first, since the shaders need to have been created using a special call to indicate which outputs will be written to the buffer. At the moment you can assign a buffer to the stream output stage, but without this extra support it probably won't do anything useful (plus it's untested and we would probably first want the feature to create a new buffer from scratch to use in it).
oh ok, so you are trying to copy it from a pixel shader.
Can you post the corresponding vertex shader (and domain and geometry shaders if they are used by this effect) so I can see where that texcoord would have come from? Also, that texcoord can potentially vary over the surface of the object, so can you tell me a little about what you are trying to achieve so I can try to offer the best advice?
The way I see it there are three possibilities:
- Assign a new render target that you can copy it to and sample that in another shader (suitable if you need the values copied on a per-pixel basis)
- Determine how that texcoord is derived in the vertex/domain/geometry shader and copy that procedure and all necessary inputs to the destination shader where you will derive it from scratch.
- (Needs a new 3DMigoto feature) Assign a buffer to the stream output stage of the pipeline to capture the texcoord output from the vertex/geometry shader directly (suitable if you need the values copied on a per-vertex basis). This will need non-trivial support added to 3DMigoto to work first, since the shaders need to have been created using a special call to indicate which outputs will be written to the buffer. At the moment you can assign a buffer to the stream output stage, but without this extra support it probably won't do anything useful (plus it's untested and we would probably first want the feature to create a new buffer from scratch to use in it).
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 was trying to copy the blending ratio of a shore ground texture and use it as an alpha channel for the foam texture on the shore of a lake, but as you said, this value may be not always consistent.
Currently I'm using a scaled depth buffer of a lake to add the foam effect, but this has it's drawbacks.
It's better to show it on video. First recording is showing the effect I'm trying to achieve and the problem: when I move the camera the thickness of a foam changes, which is expectable for obvious reasons. Second movie is showing the scaled(value not size) depth buffer of a lake where you can see the problem more clearly.
I was trying to compensate that using the viewport coordinates but with not 100% satisfying results.
I've been struggling with that for the last 3 days, but options are limited. What I need is a shape of the surface of a lake with blurred edges maintaining perspective.
I could show you the shader code but in the current state (experiment over another and another) it would be a pain to read it (needs a proper clean-up when I'm done with experimenting)
If you have even the craziest ideas I'm all ears.
https://www.youtube.com/watch?v=90WmNINRdp8
https://www.youtube.com/watch?v=o_lYlun0Tug
I was trying to copy the blending ratio of a shore ground texture and use it as an alpha channel for the foam texture on the shore of a lake, but as you said, this value may be not always consistent.
Currently I'm using a scaled depth buffer of a lake to add the foam effect, but this has it's drawbacks.
It's better to show it on video. First recording is showing the effect I'm trying to achieve and the problem: when I move the camera the thickness of a foam changes, which is expectable for obvious reasons. Second movie is showing the scaled(value not size) depth buffer of a lake where you can see the problem more clearly.
I was trying to compensate that using the viewport coordinates but with not 100% satisfying results.
I've been struggling with that for the last 3 days, but options are limited. What I need is a shape of the surface of a lake with blurred edges maintaining perspective.
I could show you the shader code but in the current state (experiment over another and another) it would be a pain to read it (needs a proper clean-up when I'm done with experimenting)
how can i enable shader hunting in farcry4 fix ? change hunting=1 in d3d9.ini,and it's still disable
[Hunting]
; Release mode is with shader hunting disabled, optimized for speed.
hunting=0 (change to hunting=1)
; Highlight mode of currently selected shader / rendertarget.
; "skip" = skip shader. don't render anything using the currently selected shader.
; "original" = fall back to original shader if the currently selected shader was patched.
; "mono" = disable stereo for the selected shader / rendertarget.
; "zero" = shader output is all zero. NOTE: this has a big performance impact.
marking_mode=skip
how can i enable shader hunting in farcry4 fix ? change hunting=1 in d3d9.ini,and it's still disable
[Hunting]
; Release mode is with shader hunting disabled, optimized for speed.
hunting=0 (change to hunting=1)
; Highlight mode of currently selected shader / rendertarget.
; "skip" = skip shader. don't render anything using the currently selected shader.
; "original" = fall back to original shader if the currently selected shader was patched.
; "mono" = disable stereo for the selected shader / rendertarget.
; "zero" = shader output is all zero. NOTE: this has a big performance impact.
marking_mode=skip
We could also use hard-links, but all of this is pretty small wins compared to other stuff we can spend time upon. If there is a decent offline/non-tool workaround I still think we are better served to use those.
I'm sure you've all heard of "technical-debt". I'm working as a consultant, and I typically come into organizations that are actually frozen in place because of their technical-debt. Technical-debt generally is the same thing as complexity. It's easy to put in one more 'if' statement, and hack workaround, and small tweak, and tiny feature request, and emergency change, until after awhile you have the classic spaghetti code that no one can add anything to, or fix bugs in without breaking something else. That's technical-debt, and it's why I'm such a pain-in-the-ass about discouraging complexity.
By the far the biggest challenge I see in my consulting jobs is that creeping complexity.
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 gonna try the shortcuts/symlinks method today.
Thank you for fixing the missing variable modifiers.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Ok, now I have a full picture. You are a rare specimen, you know that :) ?
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
This line looks a bit suspicious to me, or maybe it's just my lack of knowledge of the asm code.
Would you confirm please if the asm line below really should be looking like the above HLSL code?
Here is again the full shader code for reference:
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
I think you actually need to change it from this:
To this:
The problem here is that in HLSL the result of a boolean test is 0 or 1, but in shader assembly it's 0 or 0xffffffff (-1 as a signed integer). 3DMigoto is taking a different approach and trying to keep track of which components of which variables are booleans (which is why the iadd looked funny), but I don't think it gets it right in every situation.
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
When I paste in DarkStarSword's code into the shader, I get the same iadd instruction desired, so this is very likely the fix.
I actually have prototyped a generalized fix for this -1 vs. 1 problem, but haven't yet tested it enough to have confidence in it. I'll use your shader here as another example.
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
For vertex shaders these variables come from the vertex buffers, and starting with 3DMigoto 1.2.11 it is possible to copy a vertex buffer into a texture slot and 3DMigoto will convert it into a structured buffer making it possible to index to look up the inputs to any of the vertices in the draw call. Alternatively, you can copy it into a constant buffer slot, but doing so will make it a lot harder to look up individual entries as you cannot simply index them like you can with a structured buffer (I have got this to work, but there's a whole bunch of gotchas involved).
Please note that there might be an issue with this feature if the game is passing a vertex offset of a per-draw call basis (3DMigoto takes care of the offset the game sets when binding the vertex buffer, but not the individual draw calls - I need to find a game that does that to test it).
I'm using this in FC4 to look up the position of other vertices (I'm not copying it between shaders, but that should work).
For reference, the input signature of that shader is (I added the SV_VertexID, which is what I pass to find_quad_center):
The real trick here is going to be creating a structure definition that matches the layout in the vertex buffer since there is currently no way to dump out the Input Assembler Layout which would tell you the binary encoding of each field. You might be able to guess - in the above example there wasn't anything too surprising, as the position and texcoord were declared as float2s in the signature and were in fact 2 x 32bit floats in the vertex buffer, but the color was declared as a float4, but was actually only a single 4 byte value.
You can use frame analysis to dump out the vertex buffer as text (analyse_options=dump_vb_txt), which will tell you the structure size ("stride") will try to decode everything in the buffer as 32bit floats (at some point I want to make it use the Input Assembler layout to use the correct format to decode them properly, but DX is missing the APIs to make that easy). dump_cb_txt will dump from the offset to the end of the buffer, which will probably include a whole bunch of unrelated data - so don't pay too much attention to it beyond the first couple of entries, especially if the pattern seems to change.
For other shader types, the variables are passed from earlier shaders and cannot be copied directly. It would be tricky to copy these, but you coule potentially copy the inputs from the previous shader instead and recalculate them in the destination shader, or perhaps add an extra render target output to the pixel shader and write them there.
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Can you post the corresponding vertex shader (and domain and geometry shaders if they are used by this effect) so I can see where that texcoord would have come from? Also, that texcoord can potentially vary over the surface of the object, so can you tell me a little about what you are trying to achieve so I can try to offer the best advice?
The way I see it there are three possibilities:
- Assign a new render target that you can copy it to and sample that in another shader (suitable if you need the values copied on a per-pixel basis)
- Determine how that texcoord is derived in the vertex/domain/geometry shader and copy that procedure and all necessary inputs to the destination shader where you will derive it from scratch.
- (Needs a new 3DMigoto feature) Assign a buffer to the stream output stage of the pipeline to capture the texcoord output from the vertex/geometry shader directly (suitable if you need the values copied on a per-vertex basis). This will need non-trivial support added to 3DMigoto to work first, since the shaders need to have been created using a special call to indicate which outputs will be written to the buffer. At the moment you can assign a buffer to the stream output stage, but without this extra support it probably won't do anything useful (plus it's untested and we would probably first want the feature to create a new buffer from scratch to use in it).
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
Currently I'm using a scaled depth buffer of a lake to add the foam effect, but this has it's drawbacks.
It's better to show it on video. First recording is showing the effect I'm trying to achieve and the problem: when I move the camera the thickness of a foam changes, which is expectable for obvious reasons. Second movie is showing the scaled(value not size) depth buffer of a lake where you can see the problem more clearly.
I was trying to compensate that using the viewport coordinates but with not 100% satisfying results.
I've been struggling with that for the last 3 days, but options are limited. What I need is a shape of the surface of a lake with blurred edges maintaining perspective.
I could show you the shader code but in the current state (experiment over another and another) it would be a pain to read it (needs a proper clean-up when I'm done with experimenting)
If you have even the craziest ideas I'm all ears.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
[Hunting]
; Release mode is with shader hunting disabled, optimized for speed.
hunting=0 (change to hunting=1)
; Highlight mode of currently selected shader / rendertarget.
; "skip" = skip shader. don't render anything using the currently selected shader.
; "original" = fall back to original shader if the currently selected shader was patched.
; "mono" = disable stereo for the selected shader / rendertarget.
; "zero" = shader output is all zero. NOTE: this has a big performance impact.
marking_mode=skip