Didn't respond earlier because I didn't see the questions in the edits.
[quote="Oomek"][quote="DarkStarSword"]I haven't asked, but I assume you are just targetting this at 2D (3D would of course change the coordinates)?[/quote]
It's a postprocess screenspace effect, but assuming that those shaders are lauched for each eye it should in theory look fine in stereo, if that's what you were asking about.[/quote]If you are doing the search for the brightest pixel on the GPU and the driver has run that search for both eyes and uses a stereo resource to pass it to the destination shader then yeah it probably would.
My experience with light shafts is that 80% of them work in roughly the same way and they usually have the wrong sun position as that is a 2D coordinate passed from the CPU, but that is fairly easy to fix.
The other 20% can get much more complex (offhand, the hardest by far was those used in Miasmata. Far Cry 4's regular light shafts were pretty difficult, The Forest was only possible after inventing the Unity reflection fix for various reasons, Dreamfall Chapters & The Long Dark are impossible (or at least extremely difficult) despite having the source code (perhaps if we patch the C# code in the game files it might be doable)).
Anyway, I recognise that this is not your goal so this is just food for thought.
[quote][quote]If they are separate draw calls you will have to bind another render target or UAV and use it to pass them, and as you already know this support is still quite alpha. I'm working through a bug at the moment in Batman where passing a UAV from a custom compute shader (support added in the upcoming version) to the game is not working as I expect, so you might want to wait until the next version.[/quote]I'm waiting patiently for it.[/quote]The issue passing a UAV (specifically a structured buffer) to another shader in Batman was resolved in 1.2.22 (that was the next version I was referring to), but there is of course more work still to go (offhand - still need to be able to create new buffers & textures, passing a regular buffer may not work, no support for raw buffers yet, append/consume buffers might work by reference but are not tested, binding a UAV to a pixel shader as opposed to a compute shader still needs to be tested).
[quote]Edit: if RWTexture will come eventually how will I be able to write at the specified coordinate to avoid interpolation? Shall I just check the SV_Position if it's (0,0) (0,1) or (0,2) or is there another way?
Nevermind, stupid question, i just specify the index as an argument.[/quote]You answered your own question, but an extra point - I've been thinking about your headlight problem and I'm wondering if binding a RWTexture2D to a UAV slot might allow you to overcome this as you can read the texture in the shader, do your own blending and write it back out - AFAIK the OM blend state won't affect UAVs.
The code to do this has existed for some time (a RWTexture2D is just a Texture2D bound to a UAV slot, so just use ps-u1= instead of o1 and declare it as a RWTexture2D<float4> : register(u1); in the headers instead of an SV_Target1), but binding UAVs to pixel shaders is still untested so it might not work (documentation on the call was not clear, so I'm not sure I've used it right).
Binding them to compute shaders is tested and definitely works, but unlike pixel shaders a compute shader needs to be told how many times to run (Dispatch = X, Y, Z for number of thread groups and a declaration in the shader for how many threads to run for each group), so you would need to know in advance how large the resource is (there is currently no way to specify this dynamically in the d3dx.ini... some day I might end up adding a full expression parser to it out of necessity, but I'm trying to avoid that for now as it adds a lot more complexity - I could probably add support for DispatchIndirect as an alternative to allow a previous shader to write the dimensions in a buffer). Compute shaders also carry a higher risk of harming performance as they allow you to (easily) do things that the GPU pipeline is not optimised for.
[quote]Edit2: is this new feature functional enough to inject a shader and use it to premultiply two referenced textures and then reference the output as a texture in the following shader? If so I would appreciate some example code.[/quote]Perhaps. You're still somewhat at the mercy of the input assembler, rasterizer, output merger and (if you care) sampler states that the game has left for you, but you could probably do so with something like (untested!):
[code]
; Custom resource declarations:
[ResourcePremultipliedInput1]
[ResourcePremultipliedInput2]
[ResourcePremultipliedResult]
[ResourceBackup_o0]
[ResourceBackup_oD]
[CustomShaderPremultiply]
vs = ShaderFixes/premultiply_vs.hlsl
ps = ShaderFixes/premultiply_ps.hlsl
; Back up state from the game we are going to change. If there are other render
; targets bound you should also back them up and unbind them. I will probably
; add a command to do this for you at some point, but it's a low priority since
; you can do so manually with existing support. Specifying the copy be done by
; reference is necessary as 3DMigoto would default to a full copy here (since
; the destination is a custom resource):
ResourceBackup_o0 = ref o0
ResourceBackup_oD = ref oD
oD = null
; Same old hack to get the right dimensions until we have support to make our
; own resources (if the inputs are different sizes you probably want to copy
; the larger of the two, but that's up to you):
ResourcePremultipliedResult = copy ResourcePremultipliedInput1
; Bind input and output resources (by reference is the default here):
o0 = ResourcePremultipliedResult
ps-t100 = ResourcePremultipliedInput1
ps-t101 = ResourcePremultipliedInput2
; Draw two triangles. We aren't using vertex buffers yet so don't care what
; vertex to start at:
Draw = 6, 0
; Restore original state before leaving (by reference is the default here):
post o0 = ResourceBackup_o0
post oD = ResourceBackup_oD
post ps-t100 = null
post ps-t101 = null
[ShaderOverride1]
Hash = ...
; I'm not sure where your inputs are coming from so I'll leave figuring out how
; to set ResourcePremultipliedInput1 & 2 to you.
; Either run the cusom shader before this one:
run = CustomShaderPremultiply
; or after it:
post run = CustomShaderPremultiply
[/code]
ShaderFixes/premultiply_vs.hlsl
[code]
void main(
out float4 pos : SV_Position0,
out float2 texcoord : TEXCOORD0,
uint vertex : SV_VertexID)
{
// Not using vertex buffers so manufacture our own coordinates.
// You may have to adjust this depending on whether the game is using
// clockwise or counterclockwise for front-facing surfaces:
switch(vertex) {
case 0:
pos.xy = float2(-1, -1);
break;
case 1:
pos.xy = float2(1, -1);
break;
case 2:
pos.xy = float2(-1, 1);
break;
case 3:
pos.xy = float2(-1, 1);
break;
case 4:
pos.xy = float2(1, -1);
break;
case 5:
pos.xy = float2(1, 1);
break;
default:
pos.xy = 0;
break;
};
pos.zw = float2(0, 1);
// Note to all our 3D shaderhackers - this is where halos come from:
texcoord = pos.xy / 2 + 0.5;
}
[/code]
ShaderFixes/premultiply_ps.hlsl
[code]
// If these aren't UNORMs, SNORMs or FLOATs adjust the types:
Texture2D<float4> Input1: register(t100);
Texture2D<float4> Input2: register(t101);
void main(
float4 pixel_pos : SV_Position0,
float2 texcoord : TEXCOORD0,
out float4 result : SV_Target0)
{
float4 in1, in2;
// Load input data without samplers (assuming these are all the same
// size - if not you will have to account for that. You could
// potentially use a sampler that the game has left bound if they have
// a suitable state with texcoord for the position instead of pixel_pos):
in1 = Input1.Load(int3(pixel_pos.xy, 0));
in2 = Input2.Load(int3(pixel_pos.xy, 0));
// Assuming this isn't going to go above 1.0, or if it does that our
// render target is not a UNORM or SNORM and hoping the OM blend state
// is not set to saturate:
result = in1 * in2;
}
[/code]
Or alternatively you could use a compute shader if the resource size is fixed.
Didn't respond earlier because I didn't see the questions in the edits.
Oomek said:
DarkStarSword said:I haven't asked, but I assume you are just targetting this at 2D (3D would of course change the coordinates)?
It's a postprocess screenspace effect, but assuming that those shaders are lauched for each eye it should in theory look fine in stereo, if that's what you were asking about.
If you are doing the search for the brightest pixel on the GPU and the driver has run that search for both eyes and uses a stereo resource to pass it to the destination shader then yeah it probably would.
My experience with light shafts is that 80% of them work in roughly the same way and they usually have the wrong sun position as that is a 2D coordinate passed from the CPU, but that is fairly easy to fix.
The other 20% can get much more complex (offhand, the hardest by far was those used in Miasmata. Far Cry 4's regular light shafts were pretty difficult, The Forest was only possible after inventing the Unity reflection fix for various reasons, Dreamfall Chapters & The Long Dark are impossible (or at least extremely difficult) despite having the source code (perhaps if we patch the C# code in the game files it might be doable)).
Anyway, I recognise that this is not your goal so this is just food for thought.
If they are separate draw calls you will have to bind another render target or UAV and use it to pass them, and as you already know this support is still quite alpha. I'm working through a bug at the moment in Batman where passing a UAV from a custom compute shader (support added in the upcoming version) to the game is not working as I expect, so you might want to wait until the next version.
I'm waiting patiently for it.
The issue passing a UAV (specifically a structured buffer) to another shader in Batman was resolved in 1.2.22 (that was the next version I was referring to), but there is of course more work still to go (offhand - still need to be able to create new buffers & textures, passing a regular buffer may not work, no support for raw buffers yet, append/consume buffers might work by reference but are not tested, binding a UAV to a pixel shader as opposed to a compute shader still needs to be tested).
Edit: if RWTexture will come eventually how will I be able to write at the specified coordinate to avoid interpolation? Shall I just check the SV_Position if it's (0,0) (0,1) or (0,2) or is there another way?
Nevermind, stupid question, i just specify the index as an argument.
You answered your own question, but an extra point - I've been thinking about your headlight problem and I'm wondering if binding a RWTexture2D to a UAV slot might allow you to overcome this as you can read the texture in the shader, do your own blending and write it back out - AFAIK the OM blend state won't affect UAVs.
The code to do this has existed for some time (a RWTexture2D is just a Texture2D bound to a UAV slot, so just use ps-u1= instead of o1 and declare it as a RWTexture2D<float4> : register(u1); in the headers instead of an SV_Target1), but binding UAVs to pixel shaders is still untested so it might not work (documentation on the call was not clear, so I'm not sure I've used it right).
Binding them to compute shaders is tested and definitely works, but unlike pixel shaders a compute shader needs to be told how many times to run (Dispatch = X, Y, Z for number of thread groups and a declaration in the shader for how many threads to run for each group), so you would need to know in advance how large the resource is (there is currently no way to specify this dynamically in the d3dx.ini... some day I might end up adding a full expression parser to it out of necessity, but I'm trying to avoid that for now as it adds a lot more complexity - I could probably add support for DispatchIndirect as an alternative to allow a previous shader to write the dimensions in a buffer). Compute shaders also carry a higher risk of harming performance as they allow you to (easily) do things that the GPU pipeline is not optimised for.
Edit2: is this new feature functional enough to inject a shader and use it to premultiply two referenced textures and then reference the output as a texture in the following shader? If so I would appreciate some example code.
Perhaps. You're still somewhat at the mercy of the input assembler, rasterizer, output merger and (if you care) sampler states that the game has left for you, but you could probably do so with something like (untested!):
[CustomShaderPremultiply]
vs = ShaderFixes/premultiply_vs.hlsl
ps = ShaderFixes/premultiply_ps.hlsl
; Back up state from the game we are going to change. If there are other render
; targets bound you should also back them up and unbind them. I will probably
; add a command to do this for you at some point, but it's a low priority since
; you can do so manually with existing support. Specifying the copy be done by
; reference is necessary as 3DMigoto would default to a full copy here (since
; the destination is a custom resource):
ResourceBackup_o0 = ref o0
ResourceBackup_oD = ref oD
oD = null
; Same old hack to get the right dimensions until we have support to make our
; own resources (if the inputs are different sizes you probably want to copy
; the larger of the two, but that's up to you):
ResourcePremultipliedResult = copy ResourcePremultipliedInput1
; Bind input and output resources (by reference is the default here):
o0 = ResourcePremultipliedResult
ps-t100 = ResourcePremultipliedInput1
ps-t101 = ResourcePremultipliedInput2
; Draw two triangles. We aren't using vertex buffers yet so don't care what
; vertex to start at:
Draw = 6, 0
; Restore original state before leaving (by reference is the default here):
post o0 = ResourceBackup_o0
post oD = ResourceBackup_oD
post ps-t100 = null
post ps-t101 = null
[ShaderOverride1]
Hash = ...
; I'm not sure where your inputs are coming from so I'll leave figuring out how
; to set ResourcePremultipliedInput1 & 2 to you.
; Either run the cusom shader before this one:
run = CustomShaderPremultiply
; or after it:
post run = CustomShaderPremultiply
ShaderFixes/premultiply_vs.hlsl
void main(
out float4 pos : SV_Position0,
out float2 texcoord : TEXCOORD0,
uint vertex : SV_VertexID)
{
// Not using vertex buffers so manufacture our own coordinates.
// You may have to adjust this depending on whether the game is using
// clockwise or counterclockwise for front-facing surfaces:
switch(vertex) {
case 0:
pos.xy = float2(-1, -1);
break;
case 1:
pos.xy = float2(1, -1);
break;
case 2:
pos.xy = float2(-1, 1);
break;
case 3:
pos.xy = float2(-1, 1);
break;
case 4:
pos.xy = float2(1, -1);
break;
case 5:
pos.xy = float2(1, 1);
break;
default:
pos.xy = 0;
break;
};
pos.zw = float2(0, 1);
// Note to all our 3D shaderhackers - this is where halos come from:
texcoord = pos.xy / 2 + 0.5;
}
ShaderFixes/premultiply_ps.hlsl
// If these aren't UNORMs, SNORMs or FLOATs adjust the types:
Texture2D<float4> Input1: register(t100);
Texture2D<float4> Input2: register(t101);
void main(
float4 pixel_pos : SV_Position0,
float2 texcoord : TEXCOORD0,
out float4 result : SV_Target0)
{
float4 in1, in2;
// Load input data without samplers (assuming these are all the same
// size - if not you will have to account for that. You could
// potentially use a sampler that the game has left bound if they have
// a suitable state with texcoord for the position instead of pixel_pos):
in1 = Input1.Load(int3(pixel_pos.xy, 0));
in2 = Input2.Load(int3(pixel_pos.xy, 0));
// Assuming this isn't going to go above 1.0, or if it does that our
// render target is not a UNORM or SNORM and hoping the OM blend state
// is not set to saturate:
result = in1 * in2;
}
Or alternatively you could use a compute shader if the resource size is fixed.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="Oomek"]The problem with that discrepancy is that I have a variable in constantbuffer called sunDirectionAndTime which I'm using. But the sun itself is beeing drawn from the float3 v0 : POSITION0, feeded to the vertex shader in a form of 3 gradients in .xyz, not as the coordinates and I have no way to peek how it's beeing calculated.[/quote]
What do you know about it? sunDirectionAndTime sounds like it's going to be a 3D vector in xyz either pointing towards or away from the sun.
Your unknowns:
- Is this a unit vector?
- What coordinate system is the vector in (view-space? world-space?)
- Is it something completely different? (e.g. polar coordinates?)
I'm assuming (based on what I would do) that it is likely to be a unit vector in either view-space or world-space.
To answer these you can do a couple of experiments by changing the shader to output something obvious (solid colour, etc) when various components in the shader are below/above a certain threshold.
You should do an experiment to test that none of the components are above 1.0 or below -1.0 regardless of camera rotation to give you some assurance that it is a unit vector (if it is not you should try to confirm that it is at least centered around the origin).
To answer what coordinate system it is in use a test on x > 0, then in game rotate the camera and observe what happens. I *think* the results will be that if the shader changes as the sun passes on the center of the screen and again at 180 degrees backwards you are very likely in view-space coordiantes. If it does not change while rotating the camera you are likely in world-space coordinates. A test on y may help confirm that it is in view-space (as opposed so something unusual), and a test on z should be 90 degrees out from your results testing x. (Again - I think this will be the observations, I haven't tried this experiment).
If it is in world-space coordinates, you will want to convert it to view-space first, typically by using a view matrix that is related to the 3D camera. Since this is a vector you don't want the camera position to affect this transformation (only rotation) you can set the homogeneous W coordinate to 0 before multiplying by the view matrix (or multiply a second coordinate at 0,0,0,1 and take the difference of the two).
Once in view-space you will want to project the vector to a coordinate at infinity (or close enough) by multiplying it by a large number - the value of the far clipping plane would be ideal if you have it. If the vector is not normalised you may want to do this first, or it is possible that it might already be the right magnitude if the game had already scaled it appropriately. If the vector was pointing away from the sun you should negate it.
Then multiply by the projection matrix to get it into clip-space (be sure to set the homogeneous W coordinate back to 1 before this multiply), divide by W to get the screen-space coordiantes, then divide by 2 and add 0.5 to get to texture-space.
Finding appropriate matrices may be easy or difficult. You might already have them in the shader, but I would caution you that if the shader is for a 2D effect the matrices are not guaranteed to be usable for this (they might be transforming from pixels to screen-space, or may be an identity matrix) and you may have to look elsewhere, but then again they might be fine, or perhaps there are two sets of matrices (possibly in separate constant buffers) and one set may be usable. If the matrices aren't available in this shader and you can't copy them from another shader you may have to get creative with the maths and whatever you do have.
Oomek said:The problem with that discrepancy is that I have a variable in constantbuffer called sunDirectionAndTime which I'm using. But the sun itself is beeing drawn from the float3 v0 : POSITION0, feeded to the vertex shader in a form of 3 gradients in .xyz, not as the coordinates and I have no way to peek how it's beeing calculated.
What do you know about it? sunDirectionAndTime sounds like it's going to be a 3D vector in xyz either pointing towards or away from the sun.
Your unknowns:
- Is this a unit vector?
- What coordinate system is the vector in (view-space? world-space?)
- Is it something completely different? (e.g. polar coordinates?)
I'm assuming (based on what I would do) that it is likely to be a unit vector in either view-space or world-space.
To answer these you can do a couple of experiments by changing the shader to output something obvious (solid colour, etc) when various components in the shader are below/above a certain threshold.
You should do an experiment to test that none of the components are above 1.0 or below -1.0 regardless of camera rotation to give you some assurance that it is a unit vector (if it is not you should try to confirm that it is at least centered around the origin).
To answer what coordinate system it is in use a test on x > 0, then in game rotate the camera and observe what happens. I *think* the results will be that if the shader changes as the sun passes on the center of the screen and again at 180 degrees backwards you are very likely in view-space coordiantes. If it does not change while rotating the camera you are likely in world-space coordinates. A test on y may help confirm that it is in view-space (as opposed so something unusual), and a test on z should be 90 degrees out from your results testing x. (Again - I think this will be the observations, I haven't tried this experiment).
If it is in world-space coordinates, you will want to convert it to view-space first, typically by using a view matrix that is related to the 3D camera. Since this is a vector you don't want the camera position to affect this transformation (only rotation) you can set the homogeneous W coordinate to 0 before multiplying by the view matrix (or multiply a second coordinate at 0,0,0,1 and take the difference of the two).
Once in view-space you will want to project the vector to a coordinate at infinity (or close enough) by multiplying it by a large number - the value of the far clipping plane would be ideal if you have it. If the vector is not normalised you may want to do this first, or it is possible that it might already be the right magnitude if the game had already scaled it appropriately. If the vector was pointing away from the sun you should negate it.
Then multiply by the projection matrix to get it into clip-space (be sure to set the homogeneous W coordinate back to 1 before this multiply), divide by W to get the screen-space coordiantes, then divide by 2 and add 0.5 to get to texture-space.
Finding appropriate matrices may be easy or difficult. You might already have them in the shader, but I would caution you that if the shader is for a 2D effect the matrices are not guaranteed to be usable for this (they might be transforming from pixels to screen-space, or may be an identity matrix) and you may have to look elsewhere, but then again they might be fine, or perhaps there are two sets of matrices (possibly in separate constant buffers) and one set may be usable. If the matrices aren't available in this shader and you can't copy them from another shader you may have to get creative with the maths and whatever you do have.
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 did it :) It's perfect now.
[img]http://i.imgur.com/U438cv5.jpg[/img]
I started experimenting again after reading your elaborate and I accidentally discovered a proper sun direction vector hidden in skyParameters3.xyz The previous one did not apparently contain the values from the xml about the custom sky rotation and the sun angle. All I had to do was to multipliy that unit vector by a large number and mul that by the already premultiplied matrix viewProjection referenced from the vertex shader. It was that simple :) The rest of calculations as usual as you described except the y coordinate which had to be
r3.y = 1.0f - (0.5f + r3.y / 2.0f);
Now, I'm trying the method of premultiplying you gave me an example of. I hope to finish that light shafts today so I could try how it looks in stereo.
Big thanks mate.
I started experimenting again after reading your elaborate and I accidentally discovered a proper sun direction vector hidden in skyParameters3.xyz The previous one did not apparently contain the values from the xml about the custom sky rotation and the sun angle. All I had to do was to multipliy that unit vector by a large number and mul that by the already premultiplied matrix viewProjection referenced from the vertex shader. It was that simple :) The rest of calculations as usual as you described except the y coordinate which had to be
r3.y = 1.0f - (0.5f + r3.y / 2.0f);
Now, I'm trying the method of premultiplying you gave me an example of. I hope to finish that light shafts today so I could try how it looks in stereo.
Well, Light shafts suffer from the same as the headlights, the rays go pink when I accelerate, so I tried the RWTexture instead of a rendertarget.
Would you take a quick look and tell me if I'm doing it right? All I have is a black screen when I try to sample a texture referenced from a resource bound to u1.
[ResourceScene]
[ResourceSun]
[ResourceSkyPSGlobals]
[ResourceSkyVSCameraParamsConstantBuffer]
[ShaderOverride-SkyPS]
Hash = 5fb7805badf885b7
ResourceScene = o0
ResourceSun = ps-u1
;//tried all of that as well
;//ResourceSun = copy o0
;//ps-u1 = ResourceSun
;//post ps-u1 = null
ResourceSkyPSGlobals = ps-cb0
As you can see on the picture below I was using the OM problem to my advantage because for some strange reason the sky isn't drawn when I reference o0 and o1 but instead from the Sky PS I get the sun's halo and the ground objects. I needed your premultiplying example just for that operation from the picture to not to sample twice in the rays loop (it's actually a subtraction) but first I need to get rid of that bug when I accelerate.
Ps. To be clear. The first plan was to use the depth buffer as a mask, but it doesn't contain the lod3(bitmap) trees, so I cannot use it.
Can someone tell me what I have done wrong here? It is a fog shader which is haloing. It seems to be following the pattern but halos remain. The disable disables the fog.
Any ideas?
//Fog in asteroid
cbuffer cb0 : register(b0)
{
float4 cb0[11] : packoffset(c0);
}
// Apply a stereo correction to the temporary register that holds a copy of the
// output position:
float4 stereo = StereoParams.Load(0);
r1.x += stereo.x * (r1.w - stereo.y);
@Oomek
I see no mention of 3D in the "small" article on your upcoming mod, so is all this just for 2D. Or are you also working on a 3D compatibility patch for Dirt 3?
http://www.dsogaming.com/news/dirt-3-complete-edition-will-get-a-new-mod-that-aims-to-offer-realistic-lighting/
I see no mention of 3D in the "small" article on your upcoming mod, so is all this just for 2D. Or are you also working on a 3D compatibility patch for Dirt 3?
[quote="D-Man11"]@Oomek
I see no mention of 3D in the "small" article on your upcoming mod, so is all this just for 2D. Or are you also working on a 3D compatibility patch for Dirt 3?
http://www.dsogaming.com/news/dirt-3-complete-edition-will-get-a-new-mod-that-aims-to-offer-realistic-lighting/[/quote]
Dirt 3 is rated "excellent" by 3DVision, so my only job is to not to screw something up :)
I see no mention of 3D in the "small" article on your upcoming mod, so is all this just for 2D. Or are you also working on a 3D compatibility patch for Dirt 3?
Awesome :)
I have Dirt 3 on my Steam Wish list and have been following your posts. But after seeing that brief article, I wanted to be sure that I am not to get my hopes up, thinking that I'll be using your mod.
It's really shaping up nice. Ty
I have Dirt 3 on my Steam Wish list and have been following your posts. But after seeing that brief article, I wanted to be sure that I am not to get my hopes up, thinking that I'll be using your mod.
It's really shaping up nice. Ty
[quote="andysonofbob"]Can someone tell me what I have done wrong here? It is a fog shader which is haloing. It seems to be following the pattern but halos remain. The disable disables the fog.[/quote]That looks right, so it might be a little more complex than the usual halo pattern. The next step is to try to get more information about what parts of the shader are relevant to the halo or not - I usually try a few experiments by disabling each of the texcoords to get an idea of which contribute to what, then I adjust the position of any that looked suspect or that I was unsure about to see if I can move the broken part of the effect.
andysonofbob said:Can someone tell me what I have done wrong here? It is a fog shader which is haloing. It seems to be following the pattern but halos remain. The disable disables the fog.
That looks right, so it might be a little more complex than the usual halo pattern. The next step is to try to get more information about what parts of the shader are relevant to the halo or not - I usually try a few experiments by disabling each of the texcoords to get an idea of which contribute to what, then I adjust the position of any that looked suspect or that I was unsure about to see if I can move the broken part of the effect.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="Oomek"]Well, Light shafts suffer from the same as the headlights, the rays go pink when I accelerate, so I tried the RWTexture instead of a rendertarget.
Would you take a quick look and tell me if I'm doing it right? All I have is a black screen when I try to sample a texture referenced from a resource bound to u1.
[code]
[ResourceScene]
[ResourceSun]
[ResourceSkyPSGlobals]
[ResourceSkyVSCameraParamsConstantBuffer]
[ShaderOverride-SkyPS]
Hash = 5fb7805badf885b7
ResourceScene = o0
ResourceSun = ps-u1
;//tried all of that as well
;//ResourceSun = copy o0
;//ps-u1 = ResourceSun
;//post ps-u1 = null
ResourceSkyPSGlobals = ps-cb0
[/code][/quote]The code you have commented out is the right way to do it here (with the caveat that ps-u1= is untested and may or may not work).
[quote]
[code]
[ShaderOverride-Mixdown1]
Hash = dfcdc4e8b0ac57d3
ps-t118 = ResourceScene
ps-t119 = ResourceSun
ps-cb3 = ResourceSkyPSGlobals
ps-cb4 = ResourceSkyVSCameraParamsConstantBuffer
[ShaderOverride-Mixdown3]
Hash = 87a1c7a31aaab7ac
ps-t118 = ResourceScene
ps-t119 = ResourceSun
ps-cb3 = ResourceSkyPSGlobals
ps-cb4 = ResourceSkyVSCameraParamsConstantBuffer
[/code]
[/quote]
You will also need to add
[code]
post ps-t119 = null
[/code]to both of these because according to MSDN "the runtime does not allow you to have both a UAV mapping for a resource and SRV mapping for the same resource active at the same time".
[quote]Sky PS ( I commented in capitals the lines with the old method)[/quote]Looks right to me, with the caveat that I haven't tried a RWTexture2D myself (only RWStructuredBuffers), so I might be missing something.
Oomek said:Well, Light shafts suffer from the same as the headlights, the rays go pink when I accelerate, so I tried the RWTexture instead of a rendertarget.
Would you take a quick look and tell me if I'm doing it right? All I have is a black screen when I try to sample a texture referenced from a resource bound to u1.
[ResourceScene]
[ResourceSun]
[ResourceSkyPSGlobals]
[ResourceSkyVSCameraParamsConstantBuffer]
[ShaderOverride-SkyPS]
Hash = 5fb7805badf885b7
ResourceScene = o0
ResourceSun = ps-u1
;//tried all of that as well
;//ResourceSun = copy o0
;//ps-u1 = ResourceSun
;//post ps-u1 = null
ResourceSkyPSGlobals = ps-cb0
The code you have commented out is the right way to do it here (with the caveat that ps-u1= is untested and may or may not work).
to both of these because according to MSDN "the runtime does not allow you to have both a UAV mapping for a resource and SRV mapping for the same resource active at the same time".
Sky PS ( I commented in capitals the lines with the old method)
Looks right to me, with the caveat that I haven't tried a RWTexture2D myself (only RWStructuredBuffers), so I might be missing something.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="Oomek"]I'm not getting anywhere recently. Tried also your shader injecting example but getting a lot of errors:[/quote]Not surprising - as I mentioned I hadn't tested any of that code (I wasn't even at home when I wrote that so I couldn't even run fxc to check for typos) and it was just an example to get you started. I've corrected the errors in the above post to make it compile, but haven't tried running them.
Oomek said:I'm not getting anywhere recently. Tried also your shader injecting example but getting a lot of errors:
Not surprising - as I mentioned I hadn't tested any of that code (I wasn't even at home when I wrote that so I couldn't even run fxc to check for typos) and it was just an example to get you started. I've corrected the errors in the above post to make it compile, but haven't tried running them.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
I have problems when dumping shaders in Dolphin lately. Something must have changed in Dolphin, because old 3Dmigoto builds in new Dolphin builds have the same problem:
The HLSL part of some shaders is incomplete (while the ASM code seems OK), so after dumping a shader, it becomes invisible instantly in the game. Example of background 2D objects in Baten Kaitos (3ce041838d16e198-vs_replace.txt with the 4.0-8717 build):
// ---- Created with 3Dmigoto v1.2.22 on Sun Jan 17 11:57:04 2016
Trying to load original_d3d11.dll
Hooked_LoadLibraryExW switching to original dll: original_d3d11.dll to C:\Windows\system32\d3d11.dll.
Hooked_CreateDXGIFactory called with riid: IDXGIFactory
calling original CreateDXGIFactory API
CreateDXGIFactory returned factory = 0000000001E3FC30, result = 0
HackerDXGIFactory::EnumAdapters(class HackerDXGIFactory@000000000EF12600) adapter 0 requested
created HackerDXGIAdapter wrapper = 000000000EF12660 of 0000000001E3FD50
returns result = 0
HackerDXGIAdapter::GetDesc(class HackerDXGIAdapter@000000000EF12660) called
returns adapter: NVIDIA GeForce GTX 760, sysmem=0, vidmem=2087387136
HackerDXGIFactory::MakeWindowAssociation(class HackerDXGIFactory@000000000BC70500) called with WindowHandle = 0000000000190548, Flags = 1
Flags = DXGI_MWA_NO_WINDOW_CHANGES(no monitoring)
returns result = 0
HackerUnknown::Release(class HackerDXGIFactory@000000000BC70500), counter=3, this=000000000BC70500
HackerUnknown::Release(class HackerDXGIAdapter@000000000BE089D0), counter=5, this=000000000BE089D0
HackerDevice::CreatePixelShader called with BytecodeLength = 848, handle = 0000000001EB1190, ClassLinkage = 0000000000000000
bytecode hash = 4dab6625ae76d67b
shader registered for possible reloading: 4dab6625ae76d67b_ps as bin -
returns result = 0, handle = 0000000001EB10A8
HackerDevice::CreateVertexShader called with BytecodeLength = 1104, handle = 0000000001EB3C90, ClassLinkage = 0000000000000000
bytecode hash = b2293ce2e61dfc49
shader registered for possible reloading: b2293ce2e61dfc49_vs as bin -
returns result = 0, handle = 0000000001F27FA8
HackerDevice::CreatePixelShader called with BytecodeLength = 2340, handle = 0000000001F29BC0, ClassLinkage = 0000000000000000
bytecode hash = a4918560526792e4
shader registered for possible reloading: a4918560526792e4_ps as bin -
returns result = 0, handle = 0000000001F2A528
HackerDevice::CreatePixelShader called with BytecodeLength = 1224, handle = 0000000001F29BB0, ClassLinkage = 0000000000000000
bytecode hash = c7b4ecbf2cc3686f
shader registered for possible reloading: c7b4ecbf2cc3686f_ps as bin -
returns result = 0, handle = 0000000001EB3AE8
HackerDevice::CreatePixelShader called with BytecodeLength = 1460, handle = 0000000001F29E10, ClassLinkage = 0000000000000000
bytecode hash = 45d3fefdb845bfdf
shader registered for possible reloading: 45d3fefdb845bfdf_ps as bin -
returns result = 0, handle = 0000000001F2A428
HackerDevice::CreatePixelShader called with BytecodeLength = 1804, handle = 0000000001F29BB0, ClassLinkage = 0000000000000000
bytecode hash = 8c637393a767e3bf
shader registered for possible reloading: 8c637393a767e3bf_ps as bin -
returns result = 0, handle = 0000000001EB3DA8
HackerDevice::CreateVertexShader called with BytecodeLength = 652, handle = 0000000001F2B770, ClassLinkage = 0000000000000000
bytecode hash = 489c1f30e193e09f
shader registered for possible reloading: 489c1f30e193e09f_vs as bin -
returns result = 0, handle = 0000000001EB3C28
HackerDevice::CreateVertexShader called with BytecodeLength = 608, handle = 0000000001F39260, ClassLinkage = 0000000000000000
bytecode hash = 59378704ab3f9994
shader registered for possible reloading: 59378704ab3f9994_vs as bin -
returns result = 0, handle = 0000000001F1A768
HackerDevice::CreatePixelShader called with BytecodeLength = 532, handle = 0000000001F30240, ClassLinkage = 0000000000000000
bytecode hash = d50bb519cef93ca9
shader registered for possible reloading: d50bb519cef93ca9_ps as bin -
returns result = 0, handle = 0000000001F1A8A8
HackerDevice::CreatePixelShader called with BytecodeLength = 1080, handle = 0000000001F39A20, ClassLinkage = 0000000000000000
bytecode hash = f12d1ec6b2d5f02b
shader registered for possible reloading: f12d1ec6b2d5f02b_ps as bin -
returns result = 0, handle = 0000000001F1A9A8
HackerDevice::CreatePixelShader called with BytecodeLength = 660, handle = 0000000001F39A20, ClassLinkage = 0000000000000000
bytecode hash = 2619f8481feba267
shader registered for possible reloading: 2619f8481feba267_ps as bin -
returns result = 0, handle = 0000000001F1AAE8
HackerDevice::CreatePixelShader called with BytecodeLength = 1092, handle = 0000000001F1D090, ClassLinkage = 0000000000000000
bytecode hash = 7a82cb3d12101e65
shader registered for possible reloading: 7a82cb3d12101e65_ps as bin -
returns result = 0, handle = 0000000001F1ABE8
HackerDevice::CreatePixelShader called with BytecodeLength = 1276, handle = 000000002555F540, ClassLinkage = 0000000000000000
bytecode hash = 0db04256e5b456ff
shader registered for possible reloading: 0db04256e5b456ff_ps as bin -
returns result = 0, handle = 0000000001F1AD28
HackerDevice::CreateGeometryShader called with BytecodeLength = 988, handle = 0000000001F1D090
bytecode hash = f8ec4e031f557502
shader registered for possible reloading: f8ec4e031f557502_gs as bin -
returns result = 0, handle = 0000000001F1AE28
HackerDevice::CreateGeometryShader called with BytecodeLength = 1116, handle = 0000000001F1BFF0
bytecode hash = 090a134fe4f0a72e
shader registered for possible reloading: 090a134fe4f0a72e_gs as bin -
returns result = 0, handle = 0000000001F1AF68
HackerDevice::CreatePixelShader called with BytecodeLength = 748, handle = 0000000001F39260, ClassLinkage = 0000000000000000
bytecode hash = 989d6a47232b760e
shader registered for possible reloading: 989d6a47232b760e_ps as bin -
returns result = 0, handle = 0000000001F1B1A8
HackerDevice::CreateVertexShader called with BytecodeLength = 716, handle = 0000000001EAC890, ClassLinkage = 0000000000000000
bytecode hash = 987459d0ab8f74a0
shader registered for possible reloading: 987459d0ab8f74a0_vs as bin -
returns result = 0, handle = 0000000001F1B2A8
HackerDevice::CreatePixelShader called with BytecodeLength = 940, handle = 0000000001F39260, ClassLinkage = 0000000000000000
bytecode hash = 8704ffe1f1ae1118
shader registered for possible reloading: 8704ffe1f1ae1118_ps as bin -
returns result = 0, handle = 0000000001F1B3E8
HackerDevice::CreateVertexShader called with BytecodeLength = 1104, handle = 0000000001F26DE0, ClassLinkage = 0000000000000000
bytecode hash = b2293ce2e61dfc49
shader registered for possible reloading: b2293ce2e61dfc49_vs as bin -
returns result = 0, handle = 0000000025560B68
HackerDevice::CreatePixelShader called with BytecodeLength = 2340, handle = 0000000025566560, ClassLinkage = 0000000000000000
bytecode hash = a4918560526792e4
shader registered for possible reloading: a4918560526792e4_ps as bin -
returns result = 0, handle = 0000000025560C68
HackerDevice::CreatePixelShader called with BytecodeLength = 940, handle = 0000000001F39260, ClassLinkage = 0000000000000000
bytecode hash = 8704ffe1f1ae1118
shader registered for possible reloading: 8704ffe1f1ae1118_ps as bin -
returns result = 0, handle = 0000000001F1B3E8
HackerDevice::CreatePixelShader called with BytecodeLength = 2528, handle = 000000002556A670, ClassLinkage = 0000000000000000
bytecode hash = b30302255d250741
shader registered for possible reloading: b30302255d250741_ps as bin -
returns result = 0, handle = 0000000025560DA8
HackerDevice::CreateVertexShader called with BytecodeLength = 2748, handle = 000000002556B880, ClassLinkage = 0000000000000000
bytecode hash = fefd90470c9f3f76
shader registered for possible reloading: fefd90470c9f3f76_vs as bin -
returns result = 0, handle = 0000000025560EA8
HackerDevice::CreatePixelShader called with BytecodeLength = 3416, handle = 0000000025525090, ClassLinkage = 0000000000000000
bytecode hash = 12eec7eae3e09fbc
shader registered for possible reloading: 12eec7eae3e09fbc_ps as bin -
returns result = 0, handle = 0000000025560FE8
HackerDevice::CreateVertexShader called with BytecodeLength = 2652, handle = 0000000025526210, ClassLinkage = 0000000000000000
bytecode hash = 3ce041838d16e198
shader registered for possible reloading: 3ce041838d16e198_vs as bin -
returns result = 0, handle = 00000000255610E8
HackerDevice::CreatePixelShader called with BytecodeLength = 1844, handle = 0000000025525850, ClassLinkage = 0000000000000000
bytecode hash = f7710605e7b9b4b2
shader registered for possible reloading: f7710605e7b9b4b2_ps as bin -
returns result = 0, handle = 0000000025561228
HackerDevice::CreateVertexShader called with BytecodeLength = 2244, handle = 0000000025525850, ClassLinkage = 0000000000000000
bytecode hash = e0790ef4d504bf5d
shader registered for possible reloading: e0790ef4d504bf5d_vs as bin -
returns result = 0, handle = 0000000025561328
HackerDevice::CreatePixelShader called with BytecodeLength = 4656, handle = 00000000255485B0, ClassLinkage = 0000000000000000
bytecode hash = 7c49a75deba39688
shader registered for possible reloading: 7c49a75deba39688_ps as bin -
returns result = 0, handle = 0000000025561468
HackerDevice::CreateVertexShader called with BytecodeLength = 2864, handle = 0000000025551B20, ClassLinkage = 0000000000000000
bytecode hash = 8c5a5a3064da744f
shader registered for possible reloading: 8c5a5a3064da744f_vs as bin -
returns result = 0, handle = 0000000025561568
HackerDevice::CreatePixelShader called with BytecodeLength = 1844, handle = 000000002557E7D0, ClassLinkage = 0000000000000000
bytecode hash = 6b6318bd28999322
shader registered for possible reloading: 6b6318bd28999322_ps as bin -
returns result = 0, handle = 00000000255616A8
HackerDevice::CreatePixelShader called with BytecodeLength = 3720, handle = 0000000025580760, ClassLinkage = 0000000000000000
bytecode hash = 24a9ce9130e1cdf3
shader registered for possible reloading: 24a9ce9130e1cdf3_ps as bin -
returns result = 0, handle = 00000000255617A8
HackerDevice::CreatePixelShader called with BytecodeLength = 3608, handle = 00000000255855F0, ClassLinkage = 0000000000000000
bytecode hash = 7f7e155daadb7586
shader registered for possible reloading: 7f7e155daadb7586_ps as bin -
returns result = 0, handle = 00000000255618E8
HackerDevice::CreatePixelShader called with BytecodeLength = 2908, handle = 0000000025586600, ClassLinkage = 0000000000000000
bytecode hash = 11a02a266d9edb4c
shader registered for possible reloading: 11a02a266d9edb4c_ps as bin -
returns result = 0, handle = 0000000025585668
HackerDevice::CreatePixelShader called with BytecodeLength = 1836, handle = 0000000025580740, ClassLinkage = 0000000000000000
bytecode hash = c526d4d477bde07e
shader registered for possible reloading: c526d4d477bde07e_ps as bin -
returns result = 0, handle = 00000000255857A8
HackerDevice::CreatePixelShader called with BytecodeLength = 1364, handle = 0000000025580740, ClassLinkage = 0000000000000000
bytecode hash = aad190e958ca1e0c
shader registered for possible reloading: aad190e958ca1e0c_ps as bin -
returns result = 0, handle = 00000000255858A8
HackerDevice::CreatePixelShader called with BytecodeLength = 2324, handle = 0000000025593250, ClassLinkage = 0000000000000000
bytecode hash = b3aab81777f68c0e
shader registered for possible reloading: b3aab81777f68c0e_ps as bin -
returns result = 0, handle = 00000000255859E8
HackerDevice::CreateVertexShader called with BytecodeLength = 2552, handle = 0000000025593B70, ClassLinkage = 0000000000000000
bytecode hash = aad91ef4b23a5bba
Replacement shader found. Loading replacement HLSL code.
Source code loaded. Size = 5571
compiling replacement HLSL code with shader model vs_5_0
compile result of replacement HLSL shader: 0
--------------------------------------------- BEGIN ---------------------------------------------
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(40,14-15): warning X3578: Output value 'o3' is not completely initialized
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(42,14-15): warning X3578: Output value 'o5' is not completely initialized
---------------------------------------------- END ----------------------------------------------
shader successfully replaced.
shader registered for possible reloading: aad91ef4b23a5bba_vs as vs_5_0 - /
keeping original shader for filtering: aad91ef4b23a5bba-vs
returns result = 0, handle = 0000000025585AE8
HackerDevice::CreatePixelShader called with BytecodeLength = 4596, handle = 0000000025596E30, ClassLinkage = 0000000000000000
bytecode hash = 758bc9f9d7ea01b9
shader registered for possible reloading: 758bc9f9d7ea01b9_ps as bin -
returns result = 0, handle = 0000000025585D28
HackerDevice::CreateVertexShader called with BytecodeLength = 3052, handle = 000000002559A030, ClassLinkage = 0000000000000000
bytecode hash = 055ec18d6e898645
shader registered for possible reloading: 055ec18d6e898645_vs as bin -
returns result = 0, handle = 0000000025585E68
HackerDevice::CreatePixelShader called with BytecodeLength = 2020, handle = 0000000025580740, ClassLinkage = 0000000000000000
bytecode hash = 1dbb5a386497ef5d
shader registered for possible reloading: 1dbb5a386497ef5d_ps as bin -
returns result = 0, handle = 0000000025585F68
HackerDevice::CreateVertexShader called with BytecodeLength = 2340, handle = 000000002559C430, ClassLinkage = 0000000000000000
bytecode hash = ad91fa33764a592b
shader registered for possible reloading: ad91fa33764a592b_vs as bin -
returns result = 0, handle = 00000000255860A8
HackerDevice::CreateGeometryShader called with BytecodeLength = 2212, handle = 000000002559DD70
bytecode hash = 2a4a5e405157e45f
shader registered for possible reloading: 2a4a5e405157e45f_gs as bin -
returns result = 0, handle = 00000000255861A8
HackerDevice::CreatePixelShader called with BytecodeLength = 2720, handle = 000000002559E620, ClassLinkage = 0000000000000000
bytecode hash = d2d9046fc85b049e
shader registered for possible reloading: d2d9046fc85b049e_ps as bin -
returns result = 0, handle = 00000000255862E8
HackerDevice::CreateGeometryShader called with BytecodeLength = 2856, handle = 00000000255A0FD0
bytecode hash = e2a9057abd4beec7
shader registered for possible reloading: e2a9057abd4beec7_gs as bin -
returns result = 0, handle = 00000000255863E8
HackerDevice::CreatePixelShader called with BytecodeLength = 2020, handle = 00000000255A1400, ClassLinkage = 0000000000000000
bytecode hash = 1dbb5a386497ef5d
shader registered for possible reloading: 1dbb5a386497ef5d_ps as bin -
returns result = 0, handle = 0000000025586528
HackerDevice::CreatePixelShader called with BytecodeLength = 2720, handle = 00000000255A1BF0, ClassLinkage = 0000000000000000
bytecode hash = d2d9046fc85b049e
shader registered for possible reloading: d2d9046fc85b049e_ps as bin -
returns result = 0, handle = 000000002559E128
HackerDevice::CreatePixelShader called with BytecodeLength = 4596, handle = 00000000255A36B0, ClassLinkage = 0000000000000000
bytecode hash = 758bc9f9d7ea01b9
shader registered for possible reloading: 758bc9f9d7ea01b9_ps as bin -
returns result = 0, handle = 000000002559E268
HackerDevice::CreatePixelShader called with BytecodeLength = 4008, handle = 00000000255A4170, ClassLinkage = 0000000000000000
bytecode hash = 38ca2551d25dbe4e
shader registered for possible reloading: 38ca2551d25dbe4e_ps as bin -
returns result = 0, handle = 000000002559E368
HackerDevice::CreateVertexShader called with BytecodeLength = 3148, handle = 00000000255A9120, ClassLinkage = 0000000000000000
bytecode hash = a9a125f9e4690534
shader registered for possible reloading: a9a125f9e4690534_vs as bin -
returns result = 0, handle = 000000002559E4A8
HackerDevice::CreatePixelShader called with BytecodeLength = 2564, handle = 00000000255A44A0, ClassLinkage = 0000000000000000
bytecode hash = 71531d57bf434ff3
shader registered for possible reloading: 71531d57bf434ff3_ps as bin -
returns result = 0, handle = 000000002559E5A8
HackerDevice::CreatePixelShader called with BytecodeLength = 2844, handle = 00000000255A44A0, ClassLinkage = 0000000000000000
bytecode hash = 9ffd0c54e1191917
shader registered for possible reloading: 9ffd0c54e1191917_ps as bin -
returns result = 0, handle = 000000002559E6E8
HackerDevice::CreatePixelShader called with BytecodeLength = 2740, handle = 00000000255A44A0, ClassLinkage = 0000000000000000
bytecode hash = 53b756069614158f
shader registered for possible reloading: 53b756069614158f_ps as bin -
returns result = 0, handle = 00000000255AD828
HackerDevice::CreatePixelShader called with BytecodeLength = 2716, handle = 00000000255A44A0, ClassLinkage = 0000000000000000
bytecode hash = 0036a752c03c59f0
shader registered for possible reloading: 0036a752c03c59f0_ps as bin -
returns result = 0, handle = 00000000255AD928
HackerDevice::CreateVertexShader called with BytecodeLength = 2952, handle = 00000000255A44A0, ClassLinkage = 0000000000000000
bytecode hash = 82889657c6c158ed
Replacement shader found. Loading replacement HLSL code.
Source code loaded. Size = 6468
compiling replacement HLSL code with shader model vs_5_0
compile result of replacement HLSL shader: 0
--------------------------------------------- BEGIN ---------------------------------------------
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(41,14-15): warning X3578: Output value 'o3' is not completely initialized
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(42,14-15): warning X3578: Output value 'o4' is not completely initialized
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(44,14-15): warning X3578: Output value 'o6' is not completely initialized
---------------------------------------------- END ----------------------------------------------
shader successfully replaced.
shader registered for possible reloading: 82889657c6c158ed_vs as vs_5_0 - /
keeping original shader for filtering: 82889657c6c158ed-vs
returns result = 0, handle = 00000000255ADA68
HackerDevice::CreatePixelShader called with BytecodeLength = 4988, handle = 00000000255C4B60, ClassLinkage = 0000000000000000
bytecode hash = d880b81bbbc70ba0
shader registered for possible reloading: d880b81bbbc70ba0_ps as bin -
returns result = 0, handle = 00000000255ADCA8
HackerDevice::CreateVertexShader called with BytecodeLength = 3616, handle = 00000000255C4210, ClassLinkage = 0000000000000000
bytecode hash = b9e678d7abcaa440
Replacement shader found. Loading replacement HLSL code.
Source code loaded. Size = 7888
compiling replacement HLSL code with shader model vs_5_0
compile result of replacement HLSL shader: 0
--------------------------------------------- BEGIN ---------------------------------------------
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(69,3-53): warning X3206: implicit truncation of vector type
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(71,3-40): warning X3206: implicit truncation of vector type
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(74,10-40): warning X3206: 'dot': implicit truncation of vector type
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(41,14-15): warning X3578: Output value 'o3' is not completely initialized
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(43,14-15): warning X3578: Output value 'o5' is not completely initialized
---------------------------------------------- END ----------------------------------------------
shader successfully replaced.
shader registered for possible reloading: b9e678d7abcaa440_vs as vs_5_0 - /
keeping original shader for filtering: b9e678d7abcaa440-vs
returns result = 0, handle = 00000000255ADDA8
HackerDevice::CreatePixelShader called with BytecodeLength = 4988, handle = 00000000255CB290, ClassLinkage = 0000000000000000
bytecode hash = b503ed6167365872
shader registered for possible reloading: b503ed6167365872_ps as bin -
returns result = 0, handle = 00000000255ADFE8
HackerDevice::CreatePixelShader called with BytecodeLength = 4312, handle = 00000000255CB290, ClassLinkage = 0000000000000000
bytecode hash = 4a4efd710aa507f3
shader registered for possible reloading: 4a4efd710aa507f3_ps as bin -
returns result = 0, handle = 00000000255AE128
HackerDevice::CreateVertexShader called with BytecodeLength = 3540, handle = 00000000255C5040, ClassLinkage = 0000000000000000
bytecode hash = 8a003bdbbc669ae7
shader registered for possible reloading: 8a003bdbbc669ae7_vs as bin -
returns result = 0, handle = 00000000255AE228
HackerDevice::CreatePixelShader called with BytecodeLength = 2020, handle = 00000000255CFAA0, ClassLinkage = 0000000000000000
bytecode hash = f1e1e8775d606965
shader registered for possible reloading: f1e1e8775d606965_ps as bin -
returns result = 0, handle = 00000000255AE368
HackerDevice::CreatePixelShader called with BytecodeLength = 2760, handle = 00000000255D1290, ClassLinkage = 0000000000000000
bytecode hash = 8b0fc165893c4897
shader registered for possible reloading: 8b0fc165893c4897_ps as bin -
returns result = 0, handle = 00000000255AE468
HackerDevice::CreatePixelShader called with BytecodeLength = 904, handle = 0000000001F1D930, ClassLinkage = 0000000000000000
bytecode hash = 46a8482762dfdfea
shader registered for possible reloading: 46a8482762dfdfea_ps as bin -
returns result = 0, handle = 00000000255AE5A8
HackerDevice::CreatePixelShader called with BytecodeLength = 2280, handle = 00000000255D1290, ClassLinkage = 0000000000000000
bytecode hash = cd4699d82123bfb3
shader registered for possible reloading: cd4699d82123bfb3_ps as bin -
returns result = 0, handle = 00000000255AE6A8
HackerDevice::CreatePixelShader called with BytecodeLength = 2200, handle = 00000000255D1290, ClassLinkage = 0000000000000000
bytecode hash = 3f5a4b429a16d9d7
shader registered for possible reloading: 3f5a4b429a16d9d7_ps as bin -
returns result = 0, handle = 00000000255D2DE8
> starting at vertex shader #0. Number of vertex shaders in frame: 8
HackerDevice::CreatePixelShader called with BytecodeLength = 4148, handle = 00000000255E8FB0, ClassLinkage = 0000000000000000
bytecode hash = 610a06c820f54ee2
shader registered for possible reloading: 610a06c820f54ee2_ps as bin -
returns result = 0, handle = 00000000255D2EE8
HackerDevice::CreateVertexShader called with BytecodeLength = 2964, handle = 00000000255E8F00, ClassLinkage = 0000000000000000
bytecode hash = 8e2236c5c8818ed1
shader registered for possible reloading: 8e2236c5c8818ed1_vs as bin -
returns result = 0, handle = 00000000255D3028
>>>> vertex shader marked: vertex shader hash = 3ce041838d16e198
visited index buffer hash = 7de1e7e8
visited pixel shader hash = 12eec7eae3e09fbc
visited pixel shader hash = 24a9ce9130e1cdf3
visited pixel shader hash = 7f7e155daadb7586
StereoScreenShot failed to enable reverse stereo blit
creating HLSL representation.
error parsing shader> Unknown statement: ibfe
storing patched shader to C:\Users\Alejandro\Documents\Dolphin-x64 8717\ShaderFixes\3ce041838d16e198-vs_replace.txt
>Replacement shader found. Re-Loading replacement HLSL code from 3ce041838d16e198-vs_replace.txt
Reload source code loaded. Size = 5197
compiling replacement HLSL code with shader model vs_5_0
compile result for replacement HLSL shader: 0
--------------------------------------------- BEGIN ---------------------------------------------
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(37,14-15): warning X3578: Output value 'o1' is not completely initialized
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(38,14-15): warning X3578: Output value 'o2' is not completely initialized
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(39,14-15): warning X3578: Output value 'o3' is not completely initialized
C:\Users\Alejandro\Documents\Dolphin-x64 8717\wrapper1349(41,14-15): warning X3578: Output value 'o5' is not completely initialized
---------------------------------------------- END ----------------------------------------------
> successfully reloaded shader: 3ce041838d16e198-vs_replace.txt
> successfully copied Marked shader to ShaderFixes
HackerDXGISwapChain::SetFullscreenState(class HackerDXGISwapChain@0000000024468D60) called with
Fullscreen = 0
Target = 0000000000000000
returns 0
HackerDXGISwapChain::ResizeBuffers(class HackerDXGISwapChain@0000000024468D60) called
returns result = 887a0001
HackerDevice::CreateVertexShader called with BytecodeLength = 1104, handle = 00000000255E8290, ClassLinkage = 0000000000000000
bytecode hash = b2293ce2e61dfc49
shader registered for possible reloading: b2293ce2e61dfc49_vs as bin -
returns result = 0, handle = 0000000025560B68
HackerDevice::CreatePixelShader called with BytecodeLength = 2340, handle = 0000000025524DE0, ClassLinkage = 0000000000000000
bytecode hash = a4918560526792e4
shader registered for possible reloading: a4918560526792e4_ps as bin -
returns result = 0, handle = 0000000025560C68
HackerDevice::CreatePixelShader called with BytecodeLength = 940, handle = 00000000255E8290, ClassLinkage = 0000000000000000
bytecode hash = 8704ffe1f1ae1118
shader registered for possible reloading: 8704ffe1f1ae1118_ps as bin -
returns result = 0, handle = 0000000001F1B4E8
HackerDevice::CreateVertexShader called with BytecodeLength = 1104, handle = 00000000255E8290, ClassLinkage = 0000000000000000
bytecode hash = b2293ce2e61dfc49
shader registered for possible reloading: b2293ce2e61dfc49_vs as bin -
returns result = 0, handle = 0000000025560B68
HackerDevice::CreatePixelShader called with BytecodeLength = 2340, handle = 0000000025524DE0, ClassLinkage = 0000000000000000
bytecode hash = a4918560526792e4
shader registered for possible reloading: a4918560526792e4_ps as bin -
returns result = 0, handle = 0000000025560C68
HackerDevice::CreatePixelShader called with BytecodeLength = 940, handle = 00000000255E8290, ClassLinkage = 0000000000000000
bytecode hash = 8704ffe1f1ae1118
shader registered for possible reloading: 8704ffe1f1ae1118_ps as bin -
returns result = 0, handle = 0000000001F1B4E8
HackerDXGISwapChain::SetFullscreenState(class HackerDXGISwapChain@0000000024468D60) called with
Fullscreen = 0
Target = 0000000000000000
returns 0
HackerUnknown::Release(class HackerDXGISwapChain@0000000024468D60), counter=1, this=0000000024468D60
There are errors about variables not completely initialized. Those are the ones missing in the shader.
By the way, I dumped this with 3D Vision disabled, but the same happens in 3D.
[quote="DarkStarSword"][quote="Oomek"]I'm not getting anywhere recently. Tried also your shader injecting example but getting a lot of errors:[/quote]Not surprising - as I mentioned I hadn't tested any of that code (I wasn't even at home when I wrote that so I couldn't even run fxc to check for typos) and it was just an example to get you started. I've corrected the errors in the above post to make it compile, but haven't tried running them.
[/quote]
All the lines containning ps-o0 still throw a warning unfortunately, I've tried o0, but then the result is 4x the size and the injected shaders have no effect.
[code]
[ResourceBackup_o0]
[ResourceBackup_oD]
[ResourcePremultipliedInput1]
[ResourcePremultipliedInput2]
[ResourcePremultipliedResult]
[CustomShaderPremultiply]
vs=Shaders/premultiply_vs.txt
ps=Shaders/premultiply_ps.txt
WARNING: Unrecognised entry: resourcebackup_o0=reference ps-o0
resourcebackup_od=reference od
od=null
resourcepremultipliedresult=copy resourcepremultipliedinput2
WARNING: Unrecognised entry: ps-o0=resourcepremultipliedresult
ps-t100=resourcepremultipliedinput1
ps-t101=resourcepremultipliedinput2
draw=6, 0
WARNING: Unrecognised entry: post ps-o0=resourcebackup_o0
post od=resourcebackup_od
post ps-t100=null
post ps-t101=null
[ShaderOverride-Mixdown1]
Hash=dfcdc4e8b0ac57d3
ps-t117=resourcepremultipliedresult
post ps-t117=null
[ShaderOverride-Mixdown3]
Hash=87a1c7a31aaab7ac
ps-t117=resourcepremultipliedresult
post ps-t117=null
[ShaderOverride-SkyPS]
Hash=5fb7805badf885b7
resourcepremultipliedinput1=o0
resourcepremultipliedinput2=copy o0
o1=resourcepremultipliedinput2
post run=customshaderpremultiply
post o1=null
[Present]
[Constants]
x=0.00
RecreateCompatibleTexture: Creating cached resource
RecreateCompatibleTexture: Creating cached resource
RecreateCompatibleTexture: Creating cached resource
[/code]
I think I'll have to postpone all the features relying on the 3DM alpha functions, release the mod as it is now, forget about water speculars from headlights and temporarily swap godrays with some sprite starburst. I can always add it as an update later on.
Oomek said:I'm not getting anywhere recently. Tried also your shader injecting example but getting a lot of errors:
Not surprising - as I mentioned I hadn't tested any of that code (I wasn't even at home when I wrote that so I couldn't even run fxc to check for typos) and it was just an example to get you started. I've corrected the errors in the above post to make it compile, but haven't tried running them.
All the lines containning ps-o0 still throw a warning unfortunately, I've tried o0, but then the result is 4x the size and the injected shaders have no effect.
[ResourceBackup_o0]
[ResourceBackup_oD]
[ResourcePremultipliedInput1]
[ResourcePremultipliedInput2]
[ResourcePremultipliedResult]
[CustomShaderPremultiply]
vs=Shaders/premultiply_vs.txt
ps=Shaders/premultiply_ps.txt
WARNING: Unrecognised entry: resourcebackup_o0=reference ps-o0
resourcebackup_od=reference od
od=null
resourcepremultipliedresult=copy resourcepremultipliedinput2
WARNING: Unrecognised entry: ps-o0=resourcepremultipliedresult
ps-t100=resourcepremultipliedinput1
ps-t101=resourcepremultipliedinput2
draw=6, 0
WARNING: Unrecognised entry: post ps-o0=resourcebackup_o0
post od=resourcebackup_od
post ps-t100=null
post ps-t101=null
[ShaderOverride-Mixdown1]
Hash=dfcdc4e8b0ac57d3
ps-t117=resourcepremultipliedresult
post ps-t117=null
[ShaderOverride-Mixdown3]
Hash=87a1c7a31aaab7ac
ps-t117=resourcepremultipliedresult
post ps-t117=null
[ShaderOverride-SkyPS]
Hash=5fb7805badf885b7
resourcepremultipliedinput1=o0
resourcepremultipliedinput2=copy o0
o1=resourcepremultipliedinput2
post run=customshaderpremultiply
post o1=null
[Present]
[Constants]
x=0.00
RecreateCompatibleTexture: Creating cached resource
RecreateCompatibleTexture: Creating cached resource
RecreateCompatibleTexture: Creating cached resource
I think I'll have to postpone all the features relying on the 3DM alpha functions, release the mod as it is now, forget about water speculars from headlights and temporarily swap godrays with some sprite starburst. I can always add it as an update later on.
3DMigoto 1.2.24 is out
This release adds an experimental hooking mode for compatibility with certain games such as MGSV:GZ. This still has known issues and is not recommended for general use yet. If you wish to try it set hook to a combination of deferred_contexts, immediate_context and/or device, or hook=all as a shorthand for all three options (for MGSV:GZ use hook=deferred_contexts, MGSV:TPP needs hook=all, but still has an unresolved crash). You may also need to set force_cpu_affinity=1 if you get crashes.
This release fixes a regression copying index buffers, and fixes copying vertex & index buffers with games that use per-draw offsets.
Frame analysis' dump_vb_txt and dump_ib_txt options will now take per-draw offsets into account as well.
[quote="masterotaku"]I have problems when dumping shaders in Dolphin lately. Something must have changed in Dolphin, because old 3Dmigoto builds in new Dolphin builds have the same problem:[/quote]It was a missing instruction in the decompiler - I've added it in 3DMigoto 1.2.24
The fact that it is using that instruction (ifbe) does raise alarm bells to me though - that instruction is used to pull out and sign extend an integer contained within a 32bit bitfield. That would normally not be a problem, but the 3DMigoto decompiler uses 32bit floating point variables in HLSL in place of the 32bit untyped temporary registers that the assembly uses, but a 32bit floating point variable only contains 24 bits of precision, so in some cases between 0 and 8 low-order bits may be lost.
So far, this has not been an issue, and it may not be an issue here either, but these are the types of instructions that are most likely to be affected if it ever does become an issue so it's something to look out for. Fixing this in the decompiler would be non-trivial (and that's an understatement), so if it does cause a problem I suggest either patching the shader to use the correct types, or switching to assembly.
This release adds an experimental hooking mode for compatibility with certain games such as MGSV:GZ. This still has known issues and is not recommended for general use yet. If you wish to try it set hook to a combination of deferred_contexts, immediate_context and/or device, or hook=all as a shorthand for all three options (for MGSV:GZ use hook=deferred_contexts, MGSV:TPP needs hook=all, but still has an unresolved crash). You may also need to set force_cpu_affinity=1 if you get crashes.
This release fixes a regression copying index buffers, and fixes copying vertex & index buffers with games that use per-draw offsets.
Frame analysis' dump_vb_txt and dump_ib_txt options will now take per-draw offsets into account as well.
masterotaku said:I have problems when dumping shaders in Dolphin lately. Something must have changed in Dolphin, because old 3Dmigoto builds in new Dolphin builds have the same problem:
It was a missing instruction in the decompiler - I've added it in 3DMigoto 1.2.24
The fact that it is using that instruction (ifbe) does raise alarm bells to me though - that instruction is used to pull out and sign extend an integer contained within a 32bit bitfield. That would normally not be a problem, but the 3DMigoto decompiler uses 32bit floating point variables in HLSL in place of the 32bit untyped temporary registers that the assembly uses, but a 32bit floating point variable only contains 24 bits of precision, so in some cases between 0 and 8 low-order bits may be lost.
So far, this has not been an issue, and it may not be an issue here either, but these are the types of instructions that are most likely to be affected if it ever does become an issue so it's something to look out for. Fixing this in the decompiler would be non-trivial (and that's an understatement), so if it does cause a problem I suggest either patching the shader to use the correct types, or switching to assembly.
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
If you are doing the search for the brightest pixel on the GPU and the driver has run that search for both eyes and uses a stereo resource to pass it to the destination shader then yeah it probably would.
My experience with light shafts is that 80% of them work in roughly the same way and they usually have the wrong sun position as that is a 2D coordinate passed from the CPU, but that is fairly easy to fix.
The other 20% can get much more complex (offhand, the hardest by far was those used in Miasmata. Far Cry 4's regular light shafts were pretty difficult, The Forest was only possible after inventing the Unity reflection fix for various reasons, Dreamfall Chapters & The Long Dark are impossible (or at least extremely difficult) despite having the source code (perhaps if we patch the C# code in the game files it might be doable)).
Anyway, I recognise that this is not your goal so this is just food for thought.
The issue passing a UAV (specifically a structured buffer) to another shader in Batman was resolved in 1.2.22 (that was the next version I was referring to), but there is of course more work still to go (offhand - still need to be able to create new buffers & textures, passing a regular buffer may not work, no support for raw buffers yet, append/consume buffers might work by reference but are not tested, binding a UAV to a pixel shader as opposed to a compute shader still needs to be tested).
You answered your own question, but an extra point - I've been thinking about your headlight problem and I'm wondering if binding a RWTexture2D to a UAV slot might allow you to overcome this as you can read the texture in the shader, do your own blending and write it back out - AFAIK the OM blend state won't affect UAVs.
The code to do this has existed for some time (a RWTexture2D is just a Texture2D bound to a UAV slot, so just use ps-u1= instead of o1 and declare it as a RWTexture2D<float4> : register(u1); in the headers instead of an SV_Target1), but binding UAVs to pixel shaders is still untested so it might not work (documentation on the call was not clear, so I'm not sure I've used it right).
Binding them to compute shaders is tested and definitely works, but unlike pixel shaders a compute shader needs to be told how many times to run (Dispatch = X, Y, Z for number of thread groups and a declaration in the shader for how many threads to run for each group), so you would need to know in advance how large the resource is (there is currently no way to specify this dynamically in the d3dx.ini... some day I might end up adding a full expression parser to it out of necessity, but I'm trying to avoid that for now as it adds a lot more complexity - I could probably add support for DispatchIndirect as an alternative to allow a previous shader to write the dimensions in a buffer). Compute shaders also carry a higher risk of harming performance as they allow you to (easily) do things that the GPU pipeline is not optimised for.
Perhaps. You're still somewhat at the mercy of the input assembler, rasterizer, output merger and (if you care) sampler states that the game has left for you, but you could probably do so with something like (untested!):
ShaderFixes/premultiply_vs.hlsl
ShaderFixes/premultiply_ps.hlsl
Or alternatively you could use a compute shader if the resource size is fixed.
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 know about it? sunDirectionAndTime sounds like it's going to be a 3D vector in xyz either pointing towards or away from the sun.
Your unknowns:
- Is this a unit vector?
- What coordinate system is the vector in (view-space? world-space?)
- Is it something completely different? (e.g. polar coordinates?)
I'm assuming (based on what I would do) that it is likely to be a unit vector in either view-space or world-space.
To answer these you can do a couple of experiments by changing the shader to output something obvious (solid colour, etc) when various components in the shader are below/above a certain threshold.
You should do an experiment to test that none of the components are above 1.0 or below -1.0 regardless of camera rotation to give you some assurance that it is a unit vector (if it is not you should try to confirm that it is at least centered around the origin).
To answer what coordinate system it is in use a test on x > 0, then in game rotate the camera and observe what happens. I *think* the results will be that if the shader changes as the sun passes on the center of the screen and again at 180 degrees backwards you are very likely in view-space coordiantes. If it does not change while rotating the camera you are likely in world-space coordinates. A test on y may help confirm that it is in view-space (as opposed so something unusual), and a test on z should be 90 degrees out from your results testing x. (Again - I think this will be the observations, I haven't tried this experiment).
If it is in world-space coordinates, you will want to convert it to view-space first, typically by using a view matrix that is related to the 3D camera. Since this is a vector you don't want the camera position to affect this transformation (only rotation) you can set the homogeneous W coordinate to 0 before multiplying by the view matrix (or multiply a second coordinate at 0,0,0,1 and take the difference of the two).
Once in view-space you will want to project the vector to a coordinate at infinity (or close enough) by multiplying it by a large number - the value of the far clipping plane would be ideal if you have it. If the vector is not normalised you may want to do this first, or it is possible that it might already be the right magnitude if the game had already scaled it appropriately. If the vector was pointing away from the sun you should negate it.
Then multiply by the projection matrix to get it into clip-space (be sure to set the homogeneous W coordinate back to 1 before this multiply), divide by W to get the screen-space coordiantes, then divide by 2 and add 0.5 to get to texture-space.
Finding appropriate matrices may be easy or difficult. You might already have them in the shader, but I would caution you that if the shader is for a 2D effect the matrices are not guaranteed to be usable for this (they might be transforming from pixels to screen-space, or may be an identity matrix) and you may have to look elsewhere, but then again they might be fine, or perhaps there are two sets of matrices (possibly in separate constant buffers) and one set may be usable. If the matrices aren't available in this shader and you can't copy them from another shader you may have to get creative with the maths and whatever you do have.
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 started experimenting again after reading your elaborate and I accidentally discovered a proper sun direction vector hidden in skyParameters3.xyz The previous one did not apparently contain the values from the xml about the custom sky rotation and the sun angle. All I had to do was to multipliy that unit vector by a large number and mul that by the already premultiplied matrix viewProjection referenced from the vertex shader. It was that simple :) The rest of calculations as usual as you described except the y coordinate which had to be
r3.y = 1.0f - (0.5f + r3.y / 2.0f);
Now, I'm trying the method of premultiplying you gave me an example of. I hope to finish that light shafts today so I could try how it looks in stereo.
Big thanks mate.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Would you take a quick look and tell me if I'm doing it right? All I have is a black screen when I try to sample a texture referenced from a resource bound to u1.
Sky PS ( I commented in capitals the lines with the old method)
As you can see on the picture below I was using the OM problem to my advantage because for some strange reason the sky isn't drawn when I reference o0 and o1 but instead from the Sky PS I get the sun's halo and the ground objects. I needed your premultiplying example just for that operation from the picture to not to sample twice in the rays loop (it's actually a subtraction) but first I need to get rid of that bug when I accelerate.
Ps. To be clear. The first plan was to use the depth buffer as a mask, but it doesn't contain the lod3(bitmap) trees, so I cannot use it.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Any ideas?
Lord, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference.-------------------Vitals: Windows 10 64bit, Ryzen 5 2600x, GTX 1070, 16GB, 3D Vision, CV1
Handy Driver DiscussionHelix Mod - community fixes Bo3b's Shaderhacker School - How to fix 3D in games3dsolutionsgaming.com - videos, reviews and 3D fixes
I haven't changed anything yet in the injected vs and ps. Here is my ini section:
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
I see no mention of 3D in the "small" article on your upcoming mod, so is all this just for 2D. Or are you also working on a 3D compatibility patch for Dirt 3?
http://www.dsogaming.com/news/dirt-3-complete-edition-will-get-a-new-mod-that-aims-to-offer-realistic-lighting/
Dirt 3 is rated "excellent" by 3DVision, so my only job is to not to screw something up :)
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
I have Dirt 3 on my Steam Wish list and have been following your posts. But after seeing that brief article, I wanted to be sure that I am not to get my hopes up, thinking that I'll be using your mod.
It's really shaping up nice. Ty
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
You will also need to add
to both of these because according to MSDN "the runtime does not allow you to have both a UAV mapping for a resource and SRV mapping for the same resource active at the same time".
Looks right to me, with the caveat that I haven't tried a RWTexture2D myself (only RWStructuredBuffers), so I might be missing something.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
The HLSL part of some shaders is incomplete (while the ASM code seems OK), so after dumping a shader, it becomes invisible instantly in the game. Example of background 2D objects in Baten Kaitos (3ce041838d16e198-vs_replace.txt with the 4.0-8717 build):
d3d11_log.txt:
There are errors about variables not completely initialized. Those are the ones missing in the shader.
By the way, I dumped this with 3D Vision disabled, but the same happens in 3D.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
All the lines containning ps-o0 still throw a warning unfortunately, I've tried o0, but then the result is 4x the size and the injected shaders have no effect.
I think I'll have to postpone all the features relying on the 3DM alpha functions, release the mod as it is now, forget about water speculars from headlights and temporarily swap godrays with some sprite starburst. I can always add it as an update later on.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
This release adds an experimental hooking mode for compatibility with certain games such as MGSV:GZ. This still has known issues and is not recommended for general use yet. If you wish to try it set hook to a combination of deferred_contexts, immediate_context and/or device, or hook=all as a shorthand for all three options (for MGSV:GZ use hook=deferred_contexts, MGSV:TPP needs hook=all, but still has an unresolved crash). You may also need to set force_cpu_affinity=1 if you get crashes.
This release fixes a regression copying index buffers, and fixes copying vertex & index buffers with games that use per-draw offsets.
Frame analysis' dump_vb_txt and dump_ib_txt options will now take per-draw offsets into account as well.
It was a missing instruction in the decompiler - I've added it in 3DMigoto 1.2.24
The fact that it is using that instruction (ifbe) does raise alarm bells to me though - that instruction is used to pull out and sign extend an integer contained within a 32bit bitfield. That would normally not be a problem, but the 3DMigoto decompiler uses 32bit floating point variables in HLSL in place of the 32bit untyped temporary registers that the assembly uses, but a 32bit floating point variable only contains 24 bits of precision, so in some cases between 0 and 8 low-order bits may be lost.
So far, this has not been an issue, and it may not be an issue here either, but these are the types of instructions that are most likely to be affected if it ever does become an issue so it's something to look out for. Fixing this in the decompiler would be non-trivial (and that's an understatement), so if it does cause a problem I suggest either patching the shader to use the correct types, or switching to assembly.
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