3Dmigoto now open-source...
  119 / 120    
[quote="DarkStarSword"][quote="lefuneste1"]<snip> I'd need to see the log with debug=1 enabled to be more sure. [/quote] Here it is : http://www.mediafire.com/file/xwla3nb3kzgbtv9/d3d11_log.zip, but it is quite huge ! [quote] manually binding IniParams like that should have still worked. I take it you also changed IniParams in the shader to use t15 instead of t120? [/quote] Yes, this is by default in my mod. But I found long time ago (while trying to minimize 3dmigoto impact on fps) that if I used ini_params = -1 manual binding was not working. Maybe it is normal ?
DarkStarSword said:
lefuneste1 said:<snip>
I'd need to see the log with debug=1 enabled to be more sure.

Here it is : http://www.mediafire.com/file/xwla3nb3kzgbtv9/d3d11_log.zip, but it is quite huge !

manually binding IniParams like that should have still worked. I take it you also changed IniParams in the shader to use t15 instead of t120?


Yes, this is by default in my mod. But I found long time ago (while trying to minimize 3dmigoto impact on fps) that if I used ini_params = -1 manual binding was not working. Maybe it is normal ?

Posted 12/27/2017 10:10 AM   
[quote="lefuneste1"][quote="DarkStarSword"]<snip> I'd need to see the log with debug=1 enabled to be more sure. [/quote] Here it is : http://www.mediafire.com/file/xwla3nb3kzgbtv9/d3d11_log.zip, but it is quite huge ![/quote] I see calls to ClearState(), which suggests this is the same issue as FFXIV. I do also see this error though that I wouldn't normally expect - was 3D Vision disabled? [code]HackerDevice::CreateStereoParamResources NvAPI_Stereo_CreateHandleFromIUnknown failed: -144[/code] [quote] [quote] manually binding IniParams like that should have still worked. I take it you also changed IniParams in the shader to use t15 instead of t120? [/quote] Yes, this is by default in my mod. But I found long time ago (while trying to minimize 3dmigoto impact on fps) that if I used ini_params = -1 manual binding was not working. Maybe it is normal ?[/quote] Curious - sounds like we may have a bug somewhere. I can't see anything obvious at a quick glance - that should be created regardless of the slot we bind it to by default, but maybe we have something subtle, like a refcounting issue that frees it prematurely if it is not bound anywhere.
lefuneste1 said:
DarkStarSword said:<snip>
I'd need to see the log with debug=1 enabled to be more sure.

Here it is : http://www.mediafire.com/file/xwla3nb3kzgbtv9/d3d11_log.zip, but it is quite huge !

I see calls to ClearState(), which suggests this is the same issue as FFXIV.

I do also see this error though that I wouldn't normally expect - was 3D Vision disabled?

HackerDevice::CreateStereoParamResources NvAPI_Stereo_CreateHandleFromIUnknown failed: -144




manually binding IniParams like that should have still worked. I take it you also changed IniParams in the shader to use t15 instead of t120?


Yes, this is by default in my mod. But I found long time ago (while trying to minimize 3dmigoto impact on fps) that if I used ini_params = -1 manual binding was not working. Maybe it is normal ?

Curious - sounds like we may have a bug somewhere. I can't see anything obvious at a quick glance - that should be created regardless of the slot we bind it to by default, but maybe we have something subtle, like a refcounting issue that frees it prematurely if it is not bound anywhere.

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

Posted 12/27/2017 12:15 PM   
[quote="DarkStarSword"][ I do also see this error though that I wouldn't normally expect - was 3D Vision disabled? [code]HackerDevice::CreateStereoParamResources NvAPI_Stereo_CreateHandleFromIUnknown failed: -144[/code] [/quote] for the test used to generate the log, no, because I used 3dmigoto now more for VR than for 3Dvision. But I made the test in both VR and 3Dvision mode.
DarkStarSword said:[
I do also see this error though that I wouldn't normally expect - was 3D Vision disabled?

HackerDevice::CreateStereoParamResources NvAPI_Stereo_CreateHandleFromIUnknown failed: -144



for the test used to generate the log, no, because I used 3dmigoto now more for VR than for 3Dvision. But I made the test in both VR and 3Dvision mode.

Posted 12/29/2017 09:38 AM   
Hello, I'd like to replace some gauge texture in IL2Bos to add helpers regarding engine RPM/throttle parameters. So I put an analyse_options = log dump_tex_dds clear_rt in the right sahder and dump the texture. My problem is that I have the same texture Hash/vs/ps in filename but the textures differs ! For example : 000118-ps-t1=!S!=d231181e-vs=df8629c5384499e0-ps=06a6a4ebb05dcb7a.dds 000119-ps-t1=!S!=d231181e-vs=df8629c5384499e0-ps=06a6a4ebb05dcb7a.dds contain the same texture, but 000120-ps-t1=!S!=d231181e-vs=df8629c5384499e0-ps=06a6a4ebb05dcb7a.dds contain a different texture. If I look in log.txt file: [code] 00118 PSSetShaderResources(StartSlot:0, NumViews:3, ppShaderResourceViews:0x0000023F8D01E060) 0: view=0x0000023FFAA44AE8 resource=0x0000023F80B22D50 hash=6bbf85e7 1: view=0x0000023F99552C68 resource=0x0000023F97362950 hash=d231181e hash_contamination=UpdateSubresourceRegion, 2: view=0x0000023F8C1085E8 resource=0x0000023F8C6E4190 hash=5513fd45 [/code] [code] 000119 PSSetShaderResources(StartSlot:0, NumViews:3, ppShaderResourceViews:0x0000023F8D01E060) 0: view=0x0000023FFAA44AE8 resource=0x0000023F80B22D50 hash=6bbf85e7 1: view=0x0000023F99552C68 resource=0x0000023F97362950 hash=d231181e hash_contamination=UpdateSubresourceRegion, 2: view=0x0000023F8C1085E8 resource=0x0000023F8C6E4190 hash=5513fd45 [/code] [code] 000120 PSSetShaderResources(StartSlot:0, NumViews:3, ppShaderResourceViews:0x0000023F8D01E060) 0: view=0x0000023FFAA44AE8 resource=0x0000023F80B22D50 hash=6bbf85e7 1: view=0x0000023F99555A68 resource=0x0000023F97364E10 hash=d231181e hash_contamination=UpdateSubresourceRegion, 2: view=0x0000023F8C1085E8 resource=0x0000023F8C6E4190 hash=5513fd45 [/code] If I understand well, I can only use the hash=d231181e (in filename) in order to replace the texture, no ?
Hello,
I'd like to replace some gauge texture in IL2Bos to add helpers regarding engine RPM/throttle parameters.
So I put an analyse_options = log dump_tex_dds clear_rt in the right sahder and dump the texture.
My problem is that I have the same texture Hash/vs/ps in filename but the textures differs !
For example :
000118-ps-t1=!S!=d231181e-vs=df8629c5384499e0-ps=06a6a4ebb05dcb7a.dds
000119-ps-t1=!S!=d231181e-vs=df8629c5384499e0-ps=06a6a4ebb05dcb7a.dds
contain the same texture, but
000120-ps-t1=!S!=d231181e-vs=df8629c5384499e0-ps=06a6a4ebb05dcb7a.dds
contain a different texture.
If I look in log.txt file:
00118 PSSetShaderResources(StartSlot:0, NumViews:3, ppShaderResourceViews:0x0000023F8D01E060)
0: view=0x0000023FFAA44AE8 resource=0x0000023F80B22D50 hash=6bbf85e7
1: view=0x0000023F99552C68 resource=0x0000023F97362950 hash=d231181e hash_contamination=UpdateSubresourceRegion,
2: view=0x0000023F8C1085E8 resource=0x0000023F8C6E4190 hash=5513fd45


000119 PSSetShaderResources(StartSlot:0, NumViews:3, ppShaderResourceViews:0x0000023F8D01E060)
0: view=0x0000023FFAA44AE8 resource=0x0000023F80B22D50 hash=6bbf85e7
1: view=0x0000023F99552C68 resource=0x0000023F97362950 hash=d231181e hash_contamination=UpdateSubresourceRegion,
2: view=0x0000023F8C1085E8 resource=0x0000023F8C6E4190 hash=5513fd45


000120 PSSetShaderResources(StartSlot:0, NumViews:3, ppShaderResourceViews:0x0000023F8D01E060)
0: view=0x0000023FFAA44AE8 resource=0x0000023F80B22D50 hash=6bbf85e7
1: view=0x0000023F99555A68 resource=0x0000023F97364E10 hash=d231181e hash_contamination=UpdateSubresourceRegion,
2: view=0x0000023F8C1085E8 resource=0x0000023F8C6E4190 hash=5513fd45


If I understand well, I can only use the hash=d231181e (in filename) in order to replace the texture, no ?

Posted 01/02/2018 04:48 PM   
I also have a question about textures that I'm already replacing in Cuphead. When I dumped them, they were 4096x2048, with only the left 2048 pixels in use. However, when I replaced them (same textures but some different content), the game wanted 2048x2048 textures (4096x2048 was loading wrong coordinates for the elemets of those textures). I just cut the right part to have 2048x2048 textures and they work 100% OK. Is there a reason for this? It's the first time I have replaced textures.
I also have a question about textures that I'm already replacing in Cuphead. When I dumped them, they were 4096x2048, with only the left 2048 pixels in use. However, when I replaced them (same textures but some different content), the game wanted 2048x2048 textures (4096x2048 was loading wrong coordinates for the elemets of those textures). I just cut the right part to have 2048x2048 textures and they work 100% OK.

Is there a reason for this? It's the first time I have replaced textures.

Email for PayPal donations: masterotakusuko@gmail.com
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: Gainward Phoenix 1080 GLH
Monitor: Asus PG278QR
Speakers: Logitech Z506

Posted 01/02/2018 05:01 PM   
@lefuneste1 The !S! in the frame analysis filename means that 3DMigoto has identified a possible source of texture hash corruption (S means the game used CopySubresourceRegion() on the texture at some stage, there's also M for Map(), U for UpdateSubresource(), and C for CopyResource()). Try turning on track_texture_updates=1 to have 3DMigoto try to propagate and/or recalculate the hashes through these calls. The downside of enabling this is that performance will suffer (to the point where you may get some users wanting to turn it off), so it may be worth trying to find an alternative solution. I would really like to find a good solution to this that works for the general case that we could add into 3DMigoto, but everything seems to have some problems, so for now you either have to use hash tracking, ignore the problem or find an alternative solution. An alternative solution might be to find something other than the texture hash you can match against - perhaps the texture size, or some other render state. If you do have to match the contents of the texture you could potentially do so on the GPU instead - for example, in WATCH_DOGS2 most of the textures didn't have this problem, but the bullet texture did, so I chose not to enable hash tracking, and instead matched just the problematic texture on the GPU. I wouldn't recommend this for large textures (at least, not without some optimisation), but in this case the texture I was matching was quite small, so this worked well. The biggest problem here was that 3DMigoto (due to DirectTK bugs) dumped the texture with a TYPELESS format that I had to change to the correct format with a hex editor - and I don't have an easy set of instructions for knowing what to change it to (as it was, it took me a while to figure out I needed the SRGB variant of the format for this game): d3dx.ini: [code] [ShaderOverrideWaypointMarkersMinimapPS] hash = 0632b4741fa82155 ; ... ; There are also some other textures that we don't want to return to screen ; depth, but that suffer from hash contamination and matching the hash from ; 3DMigoto is unreliable without track_texture_updates=1, but we don't want to ; enable that due to the performance impact it incurs. Instead, we are going to ; match these on the GPU. For now, we pass a copy of the textures to match into ; the shader (later we could try using a hash algorithm that is suited to the ; parallel nature of the GPU. Using 3DMigoto's hash algorithm is not a good ; choice for various reasons, such as the fact that many textures use BC3 block ; compression, and 3DMigoto hashes the compressed data, whereas the GPU will ; read the uncompressed pixel data (maybe we could access it as a raw buffer to ; get access to the compressed data on the GPU?). Also, 3DMigoto has a bunch of ; backwards compatibility code we would like to do without, and CRC algorithms ; are not all that well suited to accelerating on a GPU). vs-t100 = ps-t0 vs-t101 = ResourceBullet post vs-t100 = null post vs-t101 = null ; Dump textures in mono so we can feed them back into the shaders to check for ; matches on the GPU. Note that typeless resources may get the wrong format ; (DXGI_FORMAT_BC3_TYPELESS instead of DXGI_FORMAT_BC3_UNORM_SRGB), so the ; resulting dds files might need hexediting to correct it (need to scrap ; DirectTK - it makes way too many assumptions instead of using the readily ; available correct information, and has too many arbitrary limitations): analyse_options = dump_tex_dds dump_rt mono ; ... [ResourceBullet] ; NOTE: Had to hexedit the dds dumped with frame analysis and change the ; DXGI_FORMAT at offset 0x80 from DXGI_FORMAT_BC3_TYPELESS (0x4c) to ; DXGI_FORMAT_BC3_UNORM_SRGB (0x4e). filename = ShaderFixes/2dcbd7e1-bullet.dds [/code] hud.hlsl: [code] bool textures_match(Texture2D<float4> tex1, Texture2D<float4> tex2) { uint w1, h1, w2, h2, x, y; tex1.GetDimensions(w1, h1); tex2.GetDimensions(w2, h2); if (w1 != w2 || h1 != h2) return false; for (y = 0; y < h1; y++) { for (x = 0; x < w1; x++) { if (any(tex1[uint2(x, y)] != tex2[uint2(x, y)])) return false; } } return true; } [/code] f04ddad1f29f69a9-vs_replace.txt: [code] ... do_hud_kill(o2); // Need to return minimap icons to screen depth, while leaving markers on the // road and bullets alone. Filter on the pixel shader used to draw the route // on the minimap + throw arcs + bullets in the world: if (IniParams[6].z == 1) { // For some reason inverting this test does not work (driver only modifying one return code path?) if (IniParams[6].w != 2) { // Throw arc. Inverting this test also does not work // Check against blacklisted textures that 3DMigoto can't filter due to hash // contamination (without incuring a performance penalty): if (!textures_match(ps_t0, bullet)) { to_screen_depth(o2); } // Do not adjust to HUD depth - off screen render target } } [/code] @masterotaku 3DMigoto has no way to know for sure if a texture/render target is mono 2D or stereo 3D, so it always attempts to dump them as stereo 3D by default, so you will get double width textures out, but if you are replacing them you should use single width textures. You can add the 'mono' keyword to analyse_options to dump them as mono instead, which I recommend using if you are using this for texture replacement (you can see above I did this).
@lefuneste1 The !S! in the frame analysis filename means that 3DMigoto has identified a possible source of texture hash corruption (S means the game used CopySubresourceRegion() on the texture at some stage, there's also M for Map(), U for UpdateSubresource(), and C for CopyResource()). Try turning on track_texture_updates=1 to have 3DMigoto try to propagate and/or recalculate the hashes through these calls.

The downside of enabling this is that performance will suffer (to the point where you may get some users wanting to turn it off), so it may be worth trying to find an alternative solution. I would really like to find a good solution to this that works for the general case that we could add into 3DMigoto, but everything seems to have some problems, so for now you either have to use hash tracking, ignore the problem or find an alternative solution.

An alternative solution might be to find something other than the texture hash you can match against - perhaps the texture size, or some other render state.

If you do have to match the contents of the texture you could potentially do so on the GPU instead - for example, in WATCH_DOGS2 most of the textures didn't have this problem, but the bullet texture did, so I chose not to enable hash tracking, and instead matched just the problematic texture on the GPU. I wouldn't recommend this for large textures (at least, not without some optimisation), but in this case the texture I was matching was quite small, so this worked well. The biggest problem here was that 3DMigoto (due to DirectTK bugs) dumped the texture with a TYPELESS format that I had to change to the correct format with a hex editor - and I don't have an easy set of instructions for knowing what to change it to (as it was, it took me a while to figure out I needed the SRGB variant of the format for this game):

d3dx.ini:
[ShaderOverrideWaypointMarkersMinimapPS]
hash = 0632b4741fa82155
; ...
; There are also some other textures that we don't want to return to screen
; depth, but that suffer from hash contamination and matching the hash from
; 3DMigoto is unreliable without track_texture_updates=1, but we don't want to
; enable that due to the performance impact it incurs. Instead, we are going to
; match these on the GPU. For now, we pass a copy of the textures to match into
; the shader (later we could try using a hash algorithm that is suited to the
; parallel nature of the GPU. Using 3DMigoto's hash algorithm is not a good
; choice for various reasons, such as the fact that many textures use BC3 block
; compression, and 3DMigoto hashes the compressed data, whereas the GPU will
; read the uncompressed pixel data (maybe we could access it as a raw buffer to
; get access to the compressed data on the GPU?). Also, 3DMigoto has a bunch of
; backwards compatibility code we would like to do without, and CRC algorithms
; are not all that well suited to accelerating on a GPU).
vs-t100 = ps-t0
vs-t101 = ResourceBullet
post vs-t100 = null
post vs-t101 = null
; Dump textures in mono so we can feed them back into the shaders to check for
; matches on the GPU. Note that typeless resources may get the wrong format
; (DXGI_FORMAT_BC3_TYPELESS instead of DXGI_FORMAT_BC3_UNORM_SRGB), so the
; resulting dds files might need hexediting to correct it (need to scrap
; DirectTK - it makes way too many assumptions instead of using the readily
; available correct information, and has too many arbitrary limitations):
analyse_options = dump_tex_dds dump_rt mono

; ...

[ResourceBullet]
; NOTE: Had to hexedit the dds dumped with frame analysis and change the
; DXGI_FORMAT at offset 0x80 from DXGI_FORMAT_BC3_TYPELESS (0x4c) to
; DXGI_FORMAT_BC3_UNORM_SRGB (0x4e).
filename = ShaderFixes/2dcbd7e1-bullet.dds


hud.hlsl:
bool textures_match(Texture2D<float4> tex1, Texture2D<float4> tex2)
{
uint w1, h1, w2, h2, x, y;

tex1.GetDimensions(w1, h1);
tex2.GetDimensions(w2, h2);

if (w1 != w2 || h1 != h2)
return false;

for (y = 0; y < h1; y++) {
for (x = 0; x < w1; x++) {
if (any(tex1[uint2(x, y)] != tex2[uint2(x, y)]))
return false;
}
}

return true;
}


f04ddad1f29f69a9-vs_replace.txt:
...
do_hud_kill(o2);

// Need to return minimap icons to screen depth, while leaving markers on the
// road and bullets alone. Filter on the pixel shader used to draw the route
// on the minimap + throw arcs + bullets in the world:
if (IniParams[6].z == 1) { // For some reason inverting this test does not work (driver only modifying one return code path?)
if (IniParams[6].w != 2) { // Throw arc. Inverting this test also does not work
// Check against blacklisted textures that 3DMigoto can't filter due to hash
// contamination (without incuring a performance penalty):
if (!textures_match(ps_t0, bullet)) {
to_screen_depth(o2);
}

// Do not adjust to HUD depth - off screen render target
}
}



@masterotaku 3DMigoto has no way to know for sure if a texture/render target is mono 2D or stereo 3D, so it always attempts to dump them as stereo 3D by default, so you will get double width textures out, but if you are replacing them you should use single width textures. You can add the 'mono' keyword to analyse_options to dump them as mono instead, which I recommend using if you are using this for texture replacement (you can see above I did this).

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

Posted 01/03/2018 01:33 AM   
Thanks, DSS. Now that I see other texture dumps, all of them have double width, with the right half being unused. Btw, add Prey (2017) to the list of games not working right with 3Dmigoto 1.2.68. It's a game that needs the 154KB "D3DCompiler_46.dll", the game loads 3Dmigoto right, but maybe the stereo params are wrong alongside the ini params, because effects are broken. Reloading shaders with F10 doesn't cause a bad "beep".
Thanks, DSS. Now that I see other texture dumps, all of them have double width, with the right half being unused.

Btw, add Prey (2017) to the list of games not working right with 3Dmigoto 1.2.68. It's a game that needs the 154KB "D3DCompiler_46.dll", the game loads 3Dmigoto right, but maybe the stereo params are wrong alongside the ini params, because effects are broken. Reloading shaders with F10 doesn't cause a bad "beep".

Email for PayPal donations: masterotakusuko@gmail.com
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: Gainward Phoenix 1080 GLH
Monitor: Asus PG278QR
Speakers: Logitech Z506

Posted 01/03/2018 10:59 AM   
Hey Guys, I just wanted to give a BIG THANK YOU to whomever added the Software Cursor for Migoto.. IT works great in LOTRO and was looking for a solution for that for years.. Thank you and keep up the good work.. If I had a million dollars to give all who keep Migoto updated it would not be enough ;) I really appreciate all you guys do.. Here is to a new 3D Year
Hey Guys,

I just wanted to give a BIG THANK YOU to whomever added the Software Cursor for Migoto.. IT works great in LOTRO and was looking for a solution for that for years..

Thank you and keep up the good work.. If I had a million dollars to give all who keep Migoto updated it would not be enough ;)

I really appreciate all you guys do.. Here is to a new 3D Year

Intel i5 3570K @ 4.5GHZ / Asus P8Z68-V Gen3 / eVGA 980GTX Factory OverClocked / 3 - Acer X1261P Projectors / 1 4'x10' Curved Screen PVC / TrackIR / HOTAS Cougar / Cougar MFD's / nThusim Warping software / Track IR / NVidia 3D Vision / Win 7 64bit SP1

Posted 01/03/2018 11:55 AM   
[center][color="orange"][size="XL"]3Dmigoto 1.2.69[/size][/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center] [size="L"][color="green"]Automatic Convergence[/color][/size] The convergence (and separation) can now be set from a buffer on the GPU, which opens up the possibility to write auto-convergence shaders. This is used in Life is Strange: Before the Storm to adjust the convergence based on the depth buffer to try to always maintain a small amount of pop-out to maximise the 3D effect, while preventing excessive popout that could make the scene uncomfortable to view and lowering the convergence when necessary to prevent objects near the camera from obscuring the view of the game. The key new feature in 3DMigoto that makes this possible is this: [code] [ResourceAutoConvergence] type = Buffer format = R32_FLOAT array = 1 [Present] pre run = CustomShaderAutoConvergence pre convergence = ResourceAutoConvergence [/code] "pre convergence = Resource..." will initiate a copy of the indicated buffer to the CPU, and will set the convergence to the first floating point value inside the buffer. It is important to note that this procedure is done asynchronously to avoid creating a performance bottleneck - whenever 3DMigoto executes this line it will only set the convergence if it previously initiated a copy that has now completed, and will only initiate a copy if one is not already in progress. In practice, this means the convergence that the custom shader has decided on will typically be applied to the frame after next, but you should not write code that relies on that assumption. Note that either "pre" or "post" must be explicitly specified to set the convergence. This is due to the fact that 3DMigoto historically only applied separation and convergence overrides like this to a single draw call, but specifying "pre" or "post" will change this behaviour so that it does not restore the original setting afterwards. If specifying this line directly in the [Present] section you should use "pre" as in the example above so that the new settings are applied for the next frame. In LiSBtS I moved that line into the [CustomShaderAutoConvergence] to keep the present section succinct, and in that case I used "post" so that it would update the convergence after the custom shader had run. If the shader chooses not to adjust the convergence for any reason, it should write 1.#QNAN or 1.#SNAN to the auto convergence buffer. In order to actually implement a full auto-convergence feature in a fix you will need far more than this. Refer to the fix for Life is Strange: Before the Storm for a complete implementation, which: [list] [.] Progressively downsamples the depth buffers from both eyes to find the closest object currently displayed[/.] [.] Includes the code to convert the value from the depth buffer to linear depth for *UNITY* games (other games/engines will need to modify this part)[/.] [.] Uses an auto-convergence algorithm based on the concept of a "popout bias" to try to maintain a given amount of popout that still works well for a wide range of game scenes, monitor sizes and viewing distances (this algorithm is experimental, but seems to be working pretty well to me. Feedback welcome)[/.] [.] Implements both slow and instant convergence transistions depending on how far out the convergence is from the target convergence[/.] [.] Implements "anti-judder" countermeasures to try to detect and stop situations where an auto-convergence adjustment might move something on or off screen, that in turn triggers another auto-convergence adjustment, that so on and so on alternates back and forth between two or more convergence values. This works fairly well already, but is an area I will be looking to improve on in the future.[/.] [.] Tracks manual user convergence adjustments and converts them into the equivelent popout adjustments[/.] [.] Implements a HUD to display the popout value on screen for a few seconds whenever the user adjusts it[/.] [.] Uses a hotkey to toggle auto-convergence on and off, displaying the state on the HUD[/.] [.] Detects if no depth buffer has been passed to the auto-convergence shader, with an optional debugging option to indicate this on the HUD[/.] [.] Should (untested) handle situations where stereo2mono is not working, and should fall back to using only the depth value from the right eye (stereo2mono may require StereoFlagsDX10=0x00000008 to work on SLI)[/.] [.] Uses a RWStructuredBuffer to keep track of state on the GPU between frames[/.] [/list] [size="L"][color="green"]Specifying Custom Buffer Initial Data[/color][/size] You can now specify the initial state of a custom buffer in the d3dx.ini. In order for this to work, a supported format must also be specified for the buffer, as that format will determine how the data field is parsed and how the initial data field is filled out. The format may either be specified with the format= setting, or as the first parameter in the data= line, e.g. [code] [ResourceBuffer] type = Buffer format = R32_FLOAT data = 0 1 2 3 4 5 6 7 8 [ResourceStructuredBuffer] type = StructuredBuffer data = R32_FLOAT 0 1 2 3 4 5 6 7 8 [/code] This supports a wide range of simple format types. All fields have to be the same size (e.g. R32G32B32A32 is OK, but D32S8X24 is not) and no field can be TYPELESS or unused (no X fields). 32-bit floating point formats are supported, but 16-bit and other unusual float sizes are not. 8, 16 and 32-bit signed and unsigned integer formats are all supported, and 8 and 16-bit normalized integer formats (SNORM and UNORM) are supported. Sub-byte formats are not supported, nor are block compressed or other esoteric formats. The initial data for complex structured buffers cannot be specified directly yet, but in many cases you can still initialise these by pretending they have a simpler format. This fake format must be specified as the first parameter in the data= line, not in the format= line, as the later may prevent the buffer from being bound as a view. A given data entry can be specified as a hex string, which can be used to embed a different type to fake a more complicated data structure. This provides another alternative to manually specifying the size of a buffer, which will be automatically determined from the format and initial data. Structured buffers will also have their stride set to the size of the initial data by default. These can still be manually specified to override this behaviour if desired. [size="L"][color="green"]Misc[/color][/size] [list] [.] The time since the game was launched (as a floating point value in seconds) can be passed to a shader like this: [code] [CustomShaderCustomHUD] ... x3 = time [/code] This can be used in conjunction with a state buffer on the GPU to implement something like a HUD shader that automatically disappears or fades out after some time has passed. Refer to the auto-convergence HUD shader in Life is Strange: Before the Storm for an example of this to display the auto-convergence popout value as the user adjusts it.[/.] [.] Custom buffers will now be initialised with zeroes by default[/.] [.] Ini params can now be set to the current separation, "eye separation" (nvidia meaning) and convergence. In most cases you won't need to do this since these values are available in StereoParams already, but the two situations where they might be useful are to get the up to date values if they may have been modified since StereoParams was last updated at the start of the frame (e.g. by the auto-convergence feature) or when 3D Vision has been disabled via Ctrl+T but for some reason you still want to know what these values were set to (StereoParams has them as 0 in this case): [code] x = separation y = eye_sep z = convergence [/code] This is used in the auto-convergence shader in LiSBtS to get the convergence value after it may (or may not) have been updated by the auto-convergence shader and just before the present call, and compares this to the convergence in the following frame to detect if the user is adjusting the convergence, and by how much.[/.] [/list] [size="L"][color="green"]Bug Fixes[/color][/size] [list] [.] Fix regression introduced in 1.2.68 where a game could unbind StereoParams and IniParams by calling ClearState[/.] [.] Fix long standing bug where shaders would sometimes become corrupted after pressing F10 (Possible symptoms included random objects turning jet black, going nuclear, missing, flickering, frozen or being misplaced, among other possible glitches)[/.] [.] Fix crash in The Division (Bo3b)[/.] [.] Fix crash in overlay if a shader tag line was too long[/.] [/list]
3Dmigoto 1.2.69


Automatic Convergence

The convergence (and separation) can now be set from a buffer on the GPU, which opens up the possibility to write auto-convergence shaders. This is used in Life is Strange: Before the Storm to adjust the convergence based on the depth buffer to try to always maintain a small amount of pop-out to maximise the 3D effect, while preventing excessive popout that could make the scene uncomfortable to view and lowering the convergence when necessary to prevent objects near the camera from obscuring the view of the game.

The key new feature in 3DMigoto that makes this possible is this:

[ResourceAutoConvergence]
type = Buffer
format = R32_FLOAT
array = 1

[Present]
pre run = CustomShaderAutoConvergence
pre convergence = ResourceAutoConvergence

"pre convergence = Resource..." will initiate a copy of the indicated buffer to the CPU, and will set the convergence to the first floating point value inside the buffer. It is important to note that this procedure is done asynchronously to avoid creating a performance bottleneck - whenever 3DMigoto executes this line it will only set the convergence if it previously initiated a copy that has now completed, and will only initiate a copy if one is not already in progress. In practice, this means the convergence that the custom shader has decided on will typically be applied to the frame after next, but you should not write code that relies on that assumption.

Note that either "pre" or "post" must be explicitly specified to set the convergence. This is due to the fact that 3DMigoto historically only applied separation and convergence overrides like this to a single draw call, but specifying "pre" or "post" will change this behaviour so that it does not restore the original setting afterwards. If specifying this line directly in the [Present] section you should use "pre" as in the example above so that the new settings are applied for the next frame. In LiSBtS I moved that line into the [CustomShaderAutoConvergence] to keep the present section succinct, and in that case I used "post" so that it would update the convergence after the custom shader had run.

If the shader chooses not to adjust the convergence for any reason, it should write 1.#QNAN or 1.#SNAN to the auto convergence buffer.

In order to actually implement a full auto-convergence feature in a fix you will need far more than this. Refer to the fix for Life is Strange: Before the Storm for a complete implementation, which:

  • Progressively downsamples the depth buffers from both eyes to find the closest object currently displayed
  • Includes the code to convert the value from the depth buffer to linear depth for *UNITY* games (other games/engines will need to modify this part)
  • Uses an auto-convergence algorithm based on the concept of a "popout bias" to try to maintain a given amount of popout that still works well for a wide range of game scenes, monitor sizes and viewing distances (this algorithm is experimental, but seems to be working pretty well to me. Feedback welcome)
  • Implements both slow and instant convergence transistions depending on how far out the convergence is from the target convergence
  • Implements "anti-judder" countermeasures to try to detect and stop situations where an auto-convergence adjustment might move something on or off screen, that in turn triggers another auto-convergence adjustment, that so on and so on alternates back and forth between two or more convergence values. This works fairly well already, but is an area I will be looking to improve on in the future.
  • Tracks manual user convergence adjustments and converts them into the equivelent popout adjustments
  • Implements a HUD to display the popout value on screen for a few seconds whenever the user adjusts it
  • Uses a hotkey to toggle auto-convergence on and off, displaying the state on the HUD
  • Detects if no depth buffer has been passed to the auto-convergence shader, with an optional debugging option to indicate this on the HUD
  • Should (untested) handle situations where stereo2mono is not working, and should fall back to using only the depth value from the right eye (stereo2mono may require StereoFlagsDX10=0x00000008 to work on SLI)
  • Uses a RWStructuredBuffer to keep track of state on the GPU between frames

Specifying Custom Buffer Initial Data

You can now specify the initial state of a custom buffer in the d3dx.ini. In order for this to work, a supported format must also be specified for the buffer, as that format will determine how the data field is parsed and how the initial data field is filled out. The format may either be specified with the format= setting, or as the first parameter in the data= line, e.g.

[ResourceBuffer]
type = Buffer
format = R32_FLOAT
data = 0 1 2 3 4 5 6 7 8

[ResourceStructuredBuffer]
type = StructuredBuffer
data = R32_FLOAT 0 1 2 3 4 5 6 7 8

This supports a wide range of simple format types. All fields have to be the same size (e.g. R32G32B32A32 is OK, but D32S8X24 is not) and no field can be TYPELESS or unused (no X fields). 32-bit floating point formats are supported, but 16-bit and other unusual float sizes are not. 8, 16 and 32-bit signed and unsigned integer formats are all supported, and 8 and 16-bit normalized integer formats (SNORM and UNORM) are supported. Sub-byte formats are not supported, nor are block compressed or other esoteric formats.

The initial data for complex structured buffers cannot be specified directly yet, but in many cases you can still initialise these by pretending they have a simpler format. This fake format must be specified as the first parameter in the data= line, not in the format= line, as the later may prevent the buffer from being bound as a view. A given data entry can be specified as a hex string, which can be used to embed a different type to fake a more complicated data structure.

This provides another alternative to manually specifying the size of a buffer, which will be automatically determined from the format and initial data. Structured buffers will also have their stride set to the size of the initial data by default. These can still be manually specified to override this behaviour if desired.

Misc
  • The time since the game was launched (as a floating point value in seconds) can be passed to a shader like this:

    [CustomShaderCustomHUD]
    ...
    x3 = time

    This can be used in conjunction with a state buffer on the GPU to implement something like a HUD shader that automatically disappears or fades out after some time has passed. Refer to the auto-convergence HUD shader in Life is Strange: Before the Storm for an example of this to display the auto-convergence popout value as the user adjusts it.

  • Custom buffers will now be initialised with zeroes by default

  • Ini params can now be set to the current separation, "eye separation" (nvidia meaning) and convergence. In most cases you won't need to do this since these values are available in StereoParams already, but the two situations where they might be useful are to get the up to date values if they may have been modified since StereoParams was last updated at the start of the frame (e.g. by the auto-convergence feature) or when 3D Vision has been disabled via Ctrl+T but for some reason you still want to know what these values were set to (StereoParams has them as 0 in this case):

    x = separation
    y = eye_sep
    z = convergence

    This is used in the auto-convergence shader in LiSBtS to get the convergence value after it may (or may not) have been updated by the auto-convergence shader and just before the present call, and compares this to the convergence in the following frame to detect if the user is adjusting the convergence, and by how much.

Bug Fixes
  • Fix regression introduced in 1.2.68 where a game could unbind StereoParams and IniParams by calling ClearState
  • Fix long standing bug where shaders would sometimes become corrupted after pressing F10 (Possible symptoms included random objects turning jet black, going nuclear, missing, flickering, frozen or being misplaced, among other possible glitches)
  • Fix crash in The Division (Bo3b)
  • Fix crash in overlay if a shader tag line was too long

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

Posted 01/12/2018 08:51 PM   
[quote="Th3_N3philim"]Hey Guys, I just wanted to give a BIG THANK YOU to whomever added the Software Cursor for Migoto.. IT works great in LOTRO and was looking for a solution for that for years..[/quote] You are most welcome ;-)
Th3_N3philim said:Hey Guys,

I just wanted to give a BIG THANK YOU to whomever added the Software Cursor for Migoto.. IT works great in LOTRO and was looking for a solution for that for years..

You are most welcome ;-)

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

Posted 01/12/2018 09:01 PM   
Can confirm The Division crash has been fixed, and FFXIV properly stereoizes again. Thanks for the update.
Can confirm The Division crash has been fixed, and FFXIV properly stereoizes again. Thanks for the update.

3D Gaming Rig: CPU: i5 6600K | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: GTX 1080 Ti | 2xSSDs for OS and Apps | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Hyper 212+ (Air) | Displays: BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 01/13/2018 06:15 AM   
Thanks for the update! All those features can be very useful if used right. [quote="DarkStarSword"] [size="L"][color="green"]Misc[/color][/size] [list] [.] The time since the game was launched (as a floating point value in seconds) can be passed to a shader like this: [code] [CustomShaderCustomHUD] ... x3 = time [/code] This can be used in conjunction with a state buffer on the GPU to implement something like a HUD shader that automatically disappears or fades out after some time has passed. Refer to the auto-convergence HUD shader in Life is Strange: Before the Storm for an example of this to display the auto-convergence popout value as the user adjusts it.[/.] [/quote] I assume time based random color dithering can be done with this, assuming the value is updated at least every frame and with all decimal numbers. [quote="DarkStarSword"] Fix long standing bug where shaders would sometimes become corrupted after pressing F10 (Possible symptoms included random objects turning jet black, going nuclear, missing, flickering, frozen or being misplaced, among other possible glitches) [/quote] Loving this. Pressing F10 was a serious risk in some games after some shader tweakings, and it forced me to restart games.
Thanks for the update! All those features can be very useful if used right.

DarkStarSword said:
Misc
[list]
  • The time since the game was launched (as a floating point value in seconds) can be passed to a shader like this:

    [CustomShaderCustomHUD]
    ...
    x3 = time

    This can be used in conjunction with a state buffer on the GPU to implement something like a HUD shader that automatically disappears or fades out after some time has passed. Refer to the auto-convergence HUD shader in Life is Strange: Before the Storm for an example of this to display the auto-convergence popout value as the user adjusts it.


  • I assume time based random color dithering can be done with this, assuming the value is updated at least every frame and with all decimal numbers.

    DarkStarSword said:
    Fix long standing bug where shaders would sometimes become corrupted after pressing F10 (Possible symptoms included random objects turning jet black, going nuclear, missing, flickering, frozen or being misplaced, among other possible glitches)


    Loving this. Pressing F10 was a serious risk in some games after some shader tweakings, and it forced me to restart games.

    Email for PayPal donations: masterotakusuko@gmail.com
    CPU: Intel Core i7 7700K @ 4.9GHz
    Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
    RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
    GPU: Gainward Phoenix 1080 GLH
    Monitor: Asus PG278QR
    Speakers: Logitech Z506

    Posted 01/13/2018 07:34 AM   
    [quote="masterotaku"] I assume time based random color dithering can be done with this, assuming the value is updated at least every frame and with all decimal numbers. [/quote] It's updated whenever the =time line is executed - if you put that in the [Present] section it will be once per frame, if you put it in a [ShaderOverride] section it will be updated just before that shader is called. It's passed as a floating point value with a resolution in milliseconds*, so you can multiply it by 1000 and cast to an integer if you need that. * The resolution is actually that of the system timer, so within the range of 10 to 16 milliseconds, which is in the same order of magnitude as a 60fps game. There will also be a loss of precision if the game is running for a long time due to the fact that 32-bit floating point value only has 24-bits of precision - this will equate to the following losses in resolution: After 4.5 hours, the resolution will drop to 2ms After 9 hours, the resolution will drop to 4ms After 18 hours, the resolution will drop to 8ms After 36 hours, the resolution will drop to 16ms - on par with system timer and 60fps games After 72 hours, the resolution will drop to 32ms - worse than system timer, 30fps accuracy For now I judged it as better to keep the value as being easier to work with than worry about either of these issues, but if we need something with a higher precision we can look at using higher resolution performance counters and changing the format used to pass the value to shaders to eliminate the precision loss over time.
    masterotaku said:
    I assume time based random color dithering can be done with this, assuming the value is updated at least every frame and with all decimal numbers.

    It's updated whenever the =time line is executed - if you put that in the [Present] section it will be once per frame, if you put it in a [ShaderOverride] section it will be updated just before that shader is called.

    It's passed as a floating point value with a resolution in milliseconds*, so you can multiply it by 1000 and cast to an integer if you need that.

    * The resolution is actually that of the system timer, so within the range of 10 to 16 milliseconds, which is in the same order of magnitude as a 60fps game.

    There will also be a loss of precision if the game is running for a long time due to the fact that 32-bit floating point value only has 24-bits of precision - this will equate to the following losses in resolution:

    After 4.5 hours, the resolution will drop to 2ms
    After 9 hours, the resolution will drop to 4ms
    After 18 hours, the resolution will drop to 8ms
    After 36 hours, the resolution will drop to 16ms - on par with system timer and 60fps games
    After 72 hours, the resolution will drop to 32ms - worse than system timer, 30fps accuracy

    For now I judged it as better to keep the value as being easier to work with than worry about either of these issues, but if we need something with a higher precision we can look at using higher resolution performance counters and changing the format used to pass the value to shaders to eliminate the precision loss over time.

    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

    Posted 01/13/2018 08:28 AM   
    Thanks DSS!!! Greats new features (Auto Convergence and Time) I remember Auto convergence in Tridef, but was very bad implemented because the convergence will go from one (low conv) to another (high conv) in 1 second multiples times...give me a headache. But i suppose the "anti-judder" countermeasures solve that :)...really great!! I will look Life is Strange: Before the Storm fix to see how to use that time feature.
    Thanks DSS!!! Greats new features (Auto Convergence and Time)

    I remember Auto convergence in Tridef, but was very bad implemented because the convergence will go from one (low conv) to another (high conv) in 1 second multiples times...give me a headache. But i suppose the "anti-judder" countermeasures solve that :)...really great!!

    I will look Life is Strange: Before the Storm fix to see how to use that time feature.
    Posted 01/13/2018 11:42 AM   
    Thanks for the update. It works now with Il2 bos. It gives some fps gain, 5 more on 55 fps with previous dll...
    Thanks for the update. It works now with Il2 bos. It gives some fps gain, 5 more on 55 fps with previous dll...

    Posted 01/13/2018 05:53 PM   
      119 / 120    
    Scroll To Top