Big thank you DSS I will definitely try it when I get home;) I am really interested to see if this will work!
Big thank you again!
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="DarkStarSword"]Sounds like a driver heuristic issue. Depth buffer filtering might help:
[code]
[ShaderOverrideLensFlare]
hash=9dffde562be1ed0f
depth_filter=depth_inactive
[/code]
You can try normalising it such that W==convergence to neutralise the driver's stereo correction:
[code]
...
stereo = StereoParams.Load(0);
o0.x += stereo.x * (o0.w - stereo.y);
// Normalise the effect to W==convergence to neutralise the driver's stereo
// correction. Only do this while stereo is enabled, convergence is not zero
// and the effect is in front of the camera (otherwise bad things happen):
if (stereo.y && o0.w > 0) {
o0 = o0 / o0.w * stereo.y;
}
[/code]
[/quote]
Big thank you!!! This worked perfectly!!!!
// Normalise the effect to W==convergence to neutralise the driver's stereo
// correction. Only do this while stereo is enabled, convergence is not zero
// and the effect is in front of the camera (otherwise bad things happen):
if (stereo.y && o0.w > 0) {
o0 = o0 / o0.w * stereo.y;
}
Big thank you!!! This worked perfectly!!!!
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Hi DarkStarSword,
I have a quick question. I have a shader that for some reason it decides to work only on ONE eye. On the other eye this is completely skipped. I found out it has to do with SLI being enabled.
Is there a way to make that PS being called 2 times? One time for each eye from 3DMigoto?
Is about a PS. In one eye I get the image darker than the other. I found out is actually a PS that makes the tone-mapping for the whole scene...
Thank you in advance!
EDIT:
I managed to correct the shader:
Original CODE
[code]
ld_structured_indexable(structured_buffer, stride=28)(mixed,mixed,mixed,mixed) r0.y, cb0[0].x, l(24), t0.xxxx
ld_structured_indexable(structured_buffer, stride=28)(mixed,mixed,mixed,mixed) r0.z, cb0[0].x, l(16), t0.xxxx
[/code]
Fixed CODE
[code]
ld_structured_indexable(structured_buffer, stride=28)(mixed,mixed,mixed,mixed) r0.y, cb0[0].x, l(24), t0.xxxx
ld_structured_indexable(structured_buffer, stride=28)(mixed,mixed,mixed,mixed) r0.y, cb0[0].x, l(16), t0.xxxx
[/code]
Basically I am sampling in r0.y both times. This seems to correct it. as r0.z is calculated later on.
In any case very weird behavior for SLI. But this basically fixed the issue I was seeing and now light-exposure is correctly applied in both eyes;)
I have a quick question. I have a shader that for some reason it decides to work only on ONE eye. On the other eye this is completely skipped. I found out it has to do with SLI being enabled.
Is there a way to make that PS being called 2 times? One time for each eye from 3DMigoto?
Is about a PS. In one eye I get the image darker than the other. I found out is actually a PS that makes the tone-mapping for the whole scene...
Basically I am sampling in r0.y both times. This seems to correct it. as r0.z is calculated later on.
In any case very weird behavior for SLI. But this basically fixed the issue I was seeing and now light-exposure is correctly applied in both eyes;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Since there are a few new shaderhackers learning how to fix shadows at the moment I thought I'd put together a bit of a tips & tricks video on the subject:
[center]https://www.youtube.com/watch?v=GssPDoVtQfA[/center]
Since there are a few new shaderhackers learning how to fix shadows at the moment I thought I'd put together a bit of a tips & tricks video on the subject:
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
Awesome video DarkStarSword!!! I did looked at it and it proves to be very useful to identify shaders;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Hi all,
after fixing most issues issues with point lights in Risen 2 I run again in to problems with some light shaders. Some of them additionally have shadows and/or specular highlights in them. For now, let me focus onto the shadow issues:
From the light source there are six squares which are projected onto the surrounding surfaces. In the pixel shader, a texkill instruction is used which should clip these squares so that there is no overlap and no gaps. I observed, that the borders of the squares get worse when applying the fix for the point light itself.
As a solution I added an additional texcoord for the unmodified world coordinate and passed them to the pixel shader for the border calculations. This resulted in the original situation but with the point light itself fixed. By modifying the new texcoord, I can move the whole cube structure arround but the borders are unaffected.
Further observations showed that the border issue is dependent on the view angle AND the position of the player character relative to the light source. When the player is positioned on an axis in the light coordinate system and the camera looks to the light source, the border problem almost vanishes.
Another problem is the depth of the shadow. It is drawn on a surface from the light source to ground or the lower screen edge. I can adjust the depth of that plane but I'm unable to put them to the correct depth on the whole surface. When moving arround there is also a jumping issue.
Below are the commented shaders.
@DarkStarSword
Nice video :) It seems that my light "jumping" issue is quite common.
texldl r30, c200.z, s1
add r30.w, r20.w, -r30.y
//mad r20.x, r30.x, -r30.w, r20.x // put on screen depth, some border issue still there
//add r20.x, r20.x, c200.x // moves LR relative to screen, range: +/-50
// o0 is corrected by driver
mov o0, r20
// Shadows are separated into both eyes without correction, correction makes it worse.
// However, the shadows are on a plane from the light source to ground without fix.
// The border problem is reduces if towards the light source when standing on an axis of the light source.
// Usual point light o3 fix
texldl r30, c200.z, s1
add r30.w, r20.w, -r30.y
//mul r30.w, r30.w, c200.x // no solution, borders are best without correction, but still wrong
mad r20.x, r30.x, r30.w, r20.x // makes boundary problem worse, fixes light center
// -> corrected and uncorrected version of o3 required (o10)
mad r0.xy, vPos, c2, c2.zwzw
texld r1, r0, s0 // Sample depth
mov r28, r1 // Store depth
mul r0.z, r1.x, c1.y // r0.z <- scaled depth
nrm_pp r1.xyz, v2
dp3 r0.w, c0, r1 // sth with dir and depth
rcp r0.w, r0.w // 1 / above
mul r0.z, r0.w, r0.z // scale above
mul r2.xyz, r0.z, r1 // r0.z: scaled depth, r1: normalized v2 (fixed in VS)
// Duplicate of code above for v9 instead of v2
mul r10.z, r28.x, c1.y
nrm_pp r11.xyz, v9
dp3 r10.w, c0, r11 // sth with dir and depth
rcp r10.w, r10.w // 1 / above
mul r10.z, r10.w, r10.z // scale above
mul r12.xyz, r10.z, r11
// Usual point light fix
//mad_pp r3.xyz, r1, -r0.z, v3 // Split this instruction
mul r20.xyz, r1, -r0.z
// Pixel shader correction formula
texld r29, c200.z, s13
mul r29.w, c200.y, r28.x // c * depth
// Strange, but convergence must not be used in this fix!
//mul r29.w, r29.w, r29.y // c * conv * depth
add r29.w, r29.w, -c200.x // 1 - (.)
mul r29.w, r29.w, r29.x // (.) * sep
// Transform correction from screen to world coordinates
mul r30.x, r29.w, c220.x
mul r30.y, r29.w, c221.x
mul r30.z, r29.w, c222.x
mul r30.w, r29.w, c223.x
// Squares can be moved with fix, but borders do not align
mul r30.x, r29.w, c220.x
mul r30.y, r29.w, c221.x
mul r30.z, r29.w, c222.x
mul r30.w, r29.w, c223.x
// This makes one border better, the other worse, alignment of depth not correct ?
// Shadow depth changes and sometimes a border splits in two
//add r2.xyz, r2.xyz, r30.xyz
// After any fix, the shadows stay on plane from light source to lower screen edge.
// Border issues are dependent on view angle and player position relative to light source.
// Border: one eye double lighted, other eye has a gap
//mov oC0, v5 // blue left of player, yellow right of player
//mov oC0, v6 // blue if player SE of light source
//mov oC0, v7 // ???
//mov oC0, v8 // ???
//add r4.x, r4.x, c201.x // moves LR relative to light source, range: +/- 0.05
//add r4.y, r4.y, c201.x // up down ?
//add r4.z, r4.z, c201.x // ??? + disable, - nothing
// r4 := r2 in other coordinate system (each square ?)
add r2, -r4_abs.xyzz, r0.z
// Shader gets killed if abs(r4.xyz) > r0.z
texkill r2 // TODO: some fix here
// without texkill: pyramid structure from center of light visible
rcp r0.w, r0.z
mul r2, r0.w, r4.xyxy
mad r2, r2, v1.xyxy, v1.zwzw
mul_pp r4.xy, r0, v4
texld_pp r4, r4, s3 // disable: shadow blurs
mad r4, r4, c5.y, c5.z
mad r5, r4.xzyz, c3.x, r2.zwzw
Can anyone tell me if I am missing something as it seems it doesn't do anything no matter what hashes I put in in the texture:(
Also, "x2=ps-t0" maps only to "<Register id=0 handle=00000000340189D0>5d534876</Register>".
If my texture is in "register id=3" for example I need to say "x2=ps-t3" right?:)
Thank you in advance!
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote]If my texture is in "register id=3" for example I need to say "x2=ps-t3" right?:)[/quote]
Yes!...the id="X" is the "ps-t"X"
The rest looks good.
[quote="DHR"][quote]If my texture is in "register id=3" for example I need to say "x2=ps-t3" right?:)[/quote]
Yes!...the id="X" is the "ps-t"X"
The rest looks good.[/quote]
Thx! Interesting, cause I also change my texture but, it also changes other textures as well, like the stereo correction is applied to multiple textures... I wonder if the same slot with the same hash can't be used by the engine to load multiple textures??
Very strange....
I think i'll try the frame analysis next and see;)
If my texture is in "register id=3" for example I need to say "x2=ps-t3" right?:)
Yes!...the id="X" is the "ps-t"X"
The rest looks good.
Thx! Interesting, cause I also change my texture but, it also changes other textures as well, like the stereo correction is applied to multiple textures... I wonder if the same slot with the same hash can't be used by the engine to load multiple textures??
Very strange....
I think i'll try the frame analysis next and see;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Yupp, using Frame Analysis, I got the exact same Hash and ps-t19 as I originally find. But the problem is with the above code in the VS it seems to apply the stereo to everything else as well:( not only my texture:(
Edit: I had to do some check inside the vertex to isolate around the crosshair to fix it;) (I think it works reliable now).
Yupp, using Frame Analysis, I got the exact same Hash and ps-t19 as I originally find. But the problem is with the above code in the VS it seems to apply the stereo to everything else as well:( not only my texture:(
Edit: I had to do some check inside the vertex to isolate around the crosshair to fix it;) (I think it works reliable now).
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Try to use the VS instead of PS in the shaderoverride part
[code][ShaderOverrideLaserDot]
;Hash=c29c1520c740ec9e PS
Hash=da2b136433ed2798[/code]
Also maybe the same texture cover more stuff in the HUD for example, not always is one texture --> one icon/dot/letter/etc... DSS use in FC3 the iconfilter by color to do a more precise separation (i'm still try to understand how to do it)
Also maybe the same texture cover more stuff in the HUD for example, not always is one texture --> one icon/dot/letter/etc... DSS use in FC3 the iconfilter by color to do a more precise separation (i'm still try to understand how to do it)
I managed to get it working;) I also had to remove the stereo correction inserted by the driver and and clamp around that area;) Now is working perfectly;))
Big thank you for the Help! FC3 is definitely something to keep an eye for;)
I managed to get it working;) I also had to remove the stereo correction inserted by the driver and and clamp around that area;) Now is working perfectly;))
Big thank you for the Help! FC3 is definitely something to keep an eye for;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Catching up on this thread...
[quote="mx-2"]Hi all,
after fixing most issues issues with point lights in Risen 2 I run again in to problems with some light shaders. Some of them additionally have shadows and/or specular highlights in them. For now, let me focus onto the shadow issues:[/quote]I sent you a pull request on github with the pattern that seems to work for these:
https://github.com/mx-2/3d-fix/pull/1
I haven't compared them to exactly what you did in these shaders, but it seems the main twist here was that after correcting the shadows in r2, the same correction had to be applied to r1 as well by dividing by r0.z.
btw I checked out your WIP from github and the game is looking really nice in 3D - great work :)
[quote="DHR"]Also maybe the same texture cover more stuff in the HUD for example, not always is one texture --> one icon/dot/letter/etc... DSS use in FC3 the iconfilter by color to do a more precise separation (i'm still try to understand how to do it)[/quote]
It was FC4, and yeah - this is the icon filter I used:
[img]https://raw.githubusercontent.com/bo3b/3Dmigoto/master/FC4/ShaderFixes/82efdcb5-icon-filter.png[/img]
The image was extracted with frame analysis (analyse_options = mono dump_tex), slightly desaturated (to make sure there were no solid colours that I wanted to use), then I painted over the center of the icons I needed to filter with different colours depending on what I wanted to do with them. I save it as a .png image to make sure that jpeg compression artefacts won't change my colours. The image is loaded back using a [ResourceIconFitler] section with filename=ShaderFixes/82efdcb5-icon-filter.png, and can then be assigned to an input slot of the HUD shader.
Then comes the tricky part - finding the center of the texture for the current icon. This is so that each vertex can be sure they are checking the same icon on the texture, otherwise each corner could match the icon next to it (this is also why I only painted a circle over the center of each icon as that would be enough to match, but still allow me to see which icon it was originally). For FC4 this was relatively easy, but it can be tricky and it is shader specific.
First, you want to dump out the vertex and index buffers for the shader with analyse_options=dump_vb_txt dump_ib_txt. If the shader is not using an index buffer your life will be much easier as you can look up other vertices of the same icon relatively easily, provided that each icon is drawn using two triangles / six vertices. If it is using an index buffer you might not be able to find the other vertices you need as Microsoft neglected to give us an SV_IndexID to look them up with (if only one icon is drawn at a time you *might* be ok to assume it will use the first six indexes), though I have some crazy ideas of trying to inject a geometry shader to see if that can help, but haven't tried this yet.
Copy the vertex buffer for the HUD shader into another texture slot (e.g. vb-t100 = vb0), and 3DMigoto will automatically convert it to a StructuredBuffer so that the vertices can be indexed easily. You will need to define a structure in the shader that matches the vertex buffer, but determining that involves a bit of black magic at the moment. The best way is to examine the vertex buffers you dumped out earlier to see if you can work out how it maps to the various v inputs of the vertex shader. A few things to keep in mind:
- The vertex buffer dump will tell you the stride you need to match.
- The order of parameters will usually more or less match the order in the vertex buffer (but may not)
- The input position might be declared as a float4 in the shader, but might only be a float2 or float3 in the vertex buffer (in which case w is implicitly set to 1, so you will have to do that part manually if you need it to calculate a position).
- An input colour might be declared as a float4 or similar in the vertex shader, but in the vertex buffer it is more likely to be a 32bit RGB value, so you should use a uint (not a uint4 or float4) for that so the size will match (4 bytes).
- If the draw call did not include a vertex count (e.g. if an index buffer is in use) or you are on an older version of 3DMigoto, the vertex buffer might contain many more entries than you actually care about, and the layout of each may not match. Check the index buffer to see which you need to care about.
You might end up with something that looks similar to this:
[code]
struct vb_entry
{
float2 position;
float2 texcoord;
uint color;
};
StructuredBuffer<struct vb_entry> vb_struct : register(t100);
[/code]
If the texture coordinate is calculated in the shader (and not just passed straight through to an output) you will need to define a function to perform that same calculation, but with inputs read from another vertex. This is not so likely for a texture coordinate, but if you were trying to find the center of the icon on the screen you would do this for the position.
You will need to look up diagonally opposite corners and average their texture coordinates to find the center. You might look at the vertex buffers to find two diagonally opposite corners, or you could just add up all six and average them. To find the starting vertex for the current icon for shaders that are NOT using an index buffer, divide SV_VertexID (which you should add to the list of inputs) by 6 then multiply it by 6 to round it down (not 6.0 - it is important that an integer division and multiplication is used here). Then you can look up the icon filter with something similar to:
[code]
uint width, height;
id = id / 6 * 6; // Round SV_VertexID down to the first vertex in this icon
IconFilter.GetDimensions(width, height);
// Find icon center (using vertex 0 & 2 as diagonally opposite vertices in this
// case - confirmed through examination of vertex buffer):
float2 coord1 = vb_struct[id].texcoord;
float2 coord2 = vb_struct[id + 2].texcoord;
uint2 coord = round((coord1 + coord2) / 2 * float2(width, height));
[/code]
mx-2 said:Hi all,
after fixing most issues issues with point lights in Risen 2 I run again in to problems with some light shaders. Some of them additionally have shadows and/or specular highlights in them. For now, let me focus onto the shadow issues:
I haven't compared them to exactly what you did in these shaders, but it seems the main twist here was that after correcting the shadows in r2, the same correction had to be applied to r1 as well by dividing by r0.z.
btw I checked out your WIP from github and the game is looking really nice in 3D - great work :)
DHR said:Also maybe the same texture cover more stuff in the HUD for example, not always is one texture --> one icon/dot/letter/etc... DSS use in FC3 the iconfilter by color to do a more precise separation (i'm still try to understand how to do it)
It was FC4, and yeah - this is the icon filter I used:
The image was extracted with frame analysis (analyse_options = mono dump_tex), slightly desaturated (to make sure there were no solid colours that I wanted to use), then I painted over the center of the icons I needed to filter with different colours depending on what I wanted to do with them. I save it as a .png image to make sure that jpeg compression artefacts won't change my colours. The image is loaded back using a [ResourceIconFitler] section with filename=ShaderFixes/82efdcb5-icon-filter.png, and can then be assigned to an input slot of the HUD shader.
Then comes the tricky part - finding the center of the texture for the current icon. This is so that each vertex can be sure they are checking the same icon on the texture, otherwise each corner could match the icon next to it (this is also why I only painted a circle over the center of each icon as that would be enough to match, but still allow me to see which icon it was originally). For FC4 this was relatively easy, but it can be tricky and it is shader specific.
First, you want to dump out the vertex and index buffers for the shader with analyse_options=dump_vb_txt dump_ib_txt. If the shader is not using an index buffer your life will be much easier as you can look up other vertices of the same icon relatively easily, provided that each icon is drawn using two triangles / six vertices. If it is using an index buffer you might not be able to find the other vertices you need as Microsoft neglected to give us an SV_IndexID to look them up with (if only one icon is drawn at a time you *might* be ok to assume it will use the first six indexes), though I have some crazy ideas of trying to inject a geometry shader to see if that can help, but haven't tried this yet.
Copy the vertex buffer for the HUD shader into another texture slot (e.g. vb-t100 = vb0), and 3DMigoto will automatically convert it to a StructuredBuffer so that the vertices can be indexed easily. You will need to define a structure in the shader that matches the vertex buffer, but determining that involves a bit of black magic at the moment. The best way is to examine the vertex buffers you dumped out earlier to see if you can work out how it maps to the various v inputs of the vertex shader. A few things to keep in mind:
- The vertex buffer dump will tell you the stride you need to match.
- The order of parameters will usually more or less match the order in the vertex buffer (but may not)
- The input position might be declared as a float4 in the shader, but might only be a float2 or float3 in the vertex buffer (in which case w is implicitly set to 1, so you will have to do that part manually if you need it to calculate a position).
- An input colour might be declared as a float4 or similar in the vertex shader, but in the vertex buffer it is more likely to be a 32bit RGB value, so you should use a uint (not a uint4 or float4) for that so the size will match (4 bytes).
- If the draw call did not include a vertex count (e.g. if an index buffer is in use) or you are on an older version of 3DMigoto, the vertex buffer might contain many more entries than you actually care about, and the layout of each may not match. Check the index buffer to see which you need to care about.
You might end up with something that looks similar to this:
If the texture coordinate is calculated in the shader (and not just passed straight through to an output) you will need to define a function to perform that same calculation, but with inputs read from another vertex. This is not so likely for a texture coordinate, but if you were trying to find the center of the icon on the screen you would do this for the position.
You will need to look up diagonally opposite corners and average their texture coordinates to find the center. You might look at the vertex buffers to find two diagonally opposite corners, or you could just add up all six and average them. To find the starting vertex for the current icon for shaders that are NOT using an index buffer, divide SV_VertexID (which you should add to the list of inputs) by 6 then multiply it by 6 to round it down (not 6.0 - it is important that an integer division and multiplication is used here). Then you can look up the icon filter with something similar to:
uint width, height;
id = id / 6 * 6; // Round SV_VertexID down to the first vertex in this icon
IconFilter.GetDimensions(width, height);
// Find icon center (using vertex 0 & 2 as diagonally opposite vertices in this
// case - confirmed through examination of vertex buffer):
float2 coord1 = vb_struct[id].texcoord;
float2 coord2 = vb_struct[id + 2].texcoord;
uint2 coord = round((coord1 + coord2) / 2 * float2(width, height));
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="DarkStarSword"]Catching up on this thread...
I sent you a pull request on github with the pattern that seems to work for these:
https://github.com/mx-2/3d-fix/pull/1
I haven't compared them to exactly what you did in these shaders, but it seems the main twist here was that after correcting the shadows in r2, the same correction had to be applied to r1 as well by dividing by r0.z.
[/quote]
I've just merged it. Works perfectly! It seems that I tried more and more difficult things and missed r2. Big thanks for your help.
[quote="DarkStarSword"]
btw I checked out your WIP from github and the game is looking really nice in 3D - great work :)
[/quote]
Yes it'd definitely playable now - only some minor things like specular highlights are missing. I'll post some details about that issues the next days.
I haven't compared them to exactly what you did in these shaders, but it seems the main twist here was that after correcting the shadows in r2, the same correction had to be applied to r1 as well by dividing by r0.z.
I've just merged it. Works perfectly! It seems that I tried more and more difficult things and missed r2. Big thanks for your help.
DarkStarSword said:
btw I checked out your WIP from github and the game is looking really nice in 3D - great work :)
Yes it'd definitely playable now - only some minor things like specular highlights are missing. I'll post some details about that issues the next days.
Big thank you again!
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Big thank you!!! This worked perfectly!!!!
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
I have a quick question. I have a shader that for some reason it decides to work only on ONE eye. On the other eye this is completely skipped. I found out it has to do with SLI being enabled.
Is there a way to make that PS being called 2 times? One time for each eye from 3DMigoto?
Is about a PS. In one eye I get the image darker than the other. I found out is actually a PS that makes the tone-mapping for the whole scene...
Thank you in advance!
EDIT:
I managed to correct the shader:
Original CODE
Fixed CODE
Basically I am sampling in r0.y both times. This seems to correct it. as r0.z is calculated later on.
In any case very weird behavior for SLI. But this basically fixed the issue I was seeing and now light-exposure is correctly applied in both eyes;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
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
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
after fixing most issues issues with point lights in Risen 2 I run again in to problems with some light shaders. Some of them additionally have shadows and/or specular highlights in them. For now, let me focus onto the shadow issues:
From the light source there are six squares which are projected onto the surrounding surfaces. In the pixel shader, a texkill instruction is used which should clip these squares so that there is no overlap and no gaps. I observed, that the borders of the squares get worse when applying the fix for the point light itself.
As a solution I added an additional texcoord for the unmodified world coordinate and passed them to the pixel shader for the border calculations. This resulted in the original situation but with the point light itself fixed. By modifying the new texcoord, I can move the whole cube structure arround but the borders are unaffected.
Further observations showed that the border issue is dependent on the view angle AND the position of the player character relative to the light source. When the player is positioned on an axis in the light coordinate system and the camera looks to the light source, the border problem almost vanishes.
Another problem is the depth of the shadow. It is drawn on a surface from the light source to ground or the lower screen edge. I can adjust the depth of that plane but I'm unable to put them to the correct depth on the whole surface. When moving arround there is also a jumping issue.
Below are the commented shaders.
@DarkStarSword
Nice video :) It seems that my light "jumping" issue is quite common.
VS3C816E83
PS114D15FE
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
3DMigoto v.1.27.
I am trying to apply a custom separation in a VS based on texture filtering.
My VS
My settings in the ini file:
And the PS for that shader as seen in the ShaderUsage.txt:
Can anyone tell me if I am missing something as it seems it doesn't do anything no matter what hashes I put in in the texture:(
Also, "x2=ps-t0" maps only to "<Register id=0 handle=00000000340189D0>5d534876</Register>".
If my texture is in "register id=3" for example I need to say "x2=ps-t3" right?:)
Thank you in advance!
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Yes!...the id="X" is the "ps-t"X"
The rest looks good.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Thx! Interesting, cause I also change my texture but, it also changes other textures as well, like the stereo correction is applied to multiple textures... I wonder if the same slot with the same hash can't be used by the engine to load multiple textures??
Very strange....
I think i'll try the frame analysis next and see;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Edit: I had to do some check inside the vertex to isolate around the crosshair to fix it;) (I think it works reliable now).
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Also maybe the same texture cover more stuff in the HUD for example, not always is one texture --> one icon/dot/letter/etc... DSS use in FC3 the iconfilter by color to do a more precise separation (i'm still try to understand how to do it)
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Big thank you for the Help! FC3 is definitely something to keep an eye for;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
I sent you a pull request on github with the pattern that seems to work for these:
https://github.com/mx-2/3d-fix/pull/1
I haven't compared them to exactly what you did in these shaders, but it seems the main twist here was that after correcting the shadows in r2, the same correction had to be applied to r1 as well by dividing by r0.z.
btw I checked out your WIP from github and the game is looking really nice in 3D - great work :)
It was FC4, and yeah - this is the icon filter I used:
The image was extracted with frame analysis (analyse_options = mono dump_tex), slightly desaturated (to make sure there were no solid colours that I wanted to use), then I painted over the center of the icons I needed to filter with different colours depending on what I wanted to do with them. I save it as a .png image to make sure that jpeg compression artefacts won't change my colours. The image is loaded back using a [ResourceIconFitler] section with filename=ShaderFixes/82efdcb5-icon-filter.png, and can then be assigned to an input slot of the HUD shader.
Then comes the tricky part - finding the center of the texture for the current icon. This is so that each vertex can be sure they are checking the same icon on the texture, otherwise each corner could match the icon next to it (this is also why I only painted a circle over the center of each icon as that would be enough to match, but still allow me to see which icon it was originally). For FC4 this was relatively easy, but it can be tricky and it is shader specific.
First, you want to dump out the vertex and index buffers for the shader with analyse_options=dump_vb_txt dump_ib_txt. If the shader is not using an index buffer your life will be much easier as you can look up other vertices of the same icon relatively easily, provided that each icon is drawn using two triangles / six vertices. If it is using an index buffer you might not be able to find the other vertices you need as Microsoft neglected to give us an SV_IndexID to look them up with (if only one icon is drawn at a time you *might* be ok to assume it will use the first six indexes), though I have some crazy ideas of trying to inject a geometry shader to see if that can help, but haven't tried this yet.
Copy the vertex buffer for the HUD shader into another texture slot (e.g. vb-t100 = vb0), and 3DMigoto will automatically convert it to a StructuredBuffer so that the vertices can be indexed easily. You will need to define a structure in the shader that matches the vertex buffer, but determining that involves a bit of black magic at the moment. The best way is to examine the vertex buffers you dumped out earlier to see if you can work out how it maps to the various v inputs of the vertex shader. A few things to keep in mind:
- The vertex buffer dump will tell you the stride you need to match.
- The order of parameters will usually more or less match the order in the vertex buffer (but may not)
- The input position might be declared as a float4 in the shader, but might only be a float2 or float3 in the vertex buffer (in which case w is implicitly set to 1, so you will have to do that part manually if you need it to calculate a position).
- An input colour might be declared as a float4 or similar in the vertex shader, but in the vertex buffer it is more likely to be a 32bit RGB value, so you should use a uint (not a uint4 or float4) for that so the size will match (4 bytes).
- If the draw call did not include a vertex count (e.g. if an index buffer is in use) or you are on an older version of 3DMigoto, the vertex buffer might contain many more entries than you actually care about, and the layout of each may not match. Check the index buffer to see which you need to care about.
You might end up with something that looks similar to this:
If the texture coordinate is calculated in the shader (and not just passed straight through to an output) you will need to define a function to perform that same calculation, but with inputs read from another vertex. This is not so likely for a texture coordinate, but if you were trying to find the center of the icon on the screen you would do this for the position.
You will need to look up diagonally opposite corners and average their texture coordinates to find the center. You might look at the vertex buffers to find two diagonally opposite corners, or you could just add up all six and average them. To find the starting vertex for the current icon for shaders that are NOT using an index buffer, divide SV_VertexID (which you should add to the list of inputs) by 6 then multiply it by 6 to round it down (not 6.0 - it is important that an integer division and multiplication is used here). Then you can look up the icon filter with something similar to:
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've just merged it. Works perfectly! It seems that I tried more and more difficult things and missed r2. Big thanks for your help.
Yes it'd definitely playable now - only some minor things like specular highlights are missing. I'll post some details about that issues the next days.
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix