3Dmigoto now open-source...
  131 / 143    
[quote="DarkStarSword"]filter_index should work with fuzzy matching, but only the highest priority matching section will take effect. The fact that matching by hash worked suggests you may have a second fuzzy match that is also matching this resource and taking priority over this one (when priorities are equal, the section name is used to determine the priority instead). Try adding "match_priority=1" to this section to indicate it takes priority over all those that didn't specify a priority.[/quote] Actually this was my only fuzzy match that I had in there as this is literally the first (and only) time I've attempted using fuzzy matching. I can still try adding the priority flag but I imagine it will be fruitless to do so. I know the obvious answer is that I may have the attributes themselves wrong, although I grabbed them from the associated drawcall in the frame analysis log, so I'm semi-confident they're correct. I've since deleted that FA dump, so I can't copy paste what I've already used, but the next time I do a HUD shader dump I'll add the equivalent texture info to this post later. I have managed a workaround (just have this particular texture type being covered under the "else" condition, rather than specifically matching the filter index in the shader, so I could just chalk this one up as a failed experiment and try again on the next one if nothing else is clearly evident.
DarkStarSword said:filter_index should work with fuzzy matching, but only the highest priority matching section will take effect. The fact that matching by hash worked suggests you may have a second fuzzy match that is also matching this resource and taking priority over this one (when priorities are equal, the section name is used to determine the priority instead). Try adding "match_priority=1" to this section to indicate it takes priority over all those that didn't specify a priority.


Actually this was my only fuzzy match that I had in there as this is literally the first (and only) time I've attempted using fuzzy matching. I can still try adding the priority flag but I imagine it will be fruitless to do so.

I know the obvious answer is that I may have the attributes themselves wrong, although I grabbed them from the associated drawcall in the frame analysis log, so I'm semi-confident they're correct. I've since deleted that FA dump, so I can't copy paste what I've already used, but the next time I do a HUD shader dump I'll add the equivalent texture info to this post later.

I have managed a workaround (just have this particular texture type being covered under the "else" condition, rather than specifically matching the filter index in the shader, so I could just chalk this one up as a failed experiment and try again on the next one if nothing else is clearly evident.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

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 04/06/2018 06:22 AM   
You can also use the ShaderUsage.txt to find the attributes if the texture hash appears in there. Can you do a quick test for me - instead of: [code] [ShaderOverride...] ... x = ps-t0 [TextureOverrideMap] ... filter_index=4 [/code] Try: [code] [ShaderOverride...] ... checktextureoverride = ps-t0 [TextureOverrideMap] ... x=4 [/code] If that works let me know and I'll take a closer look. If that works it may not necessarily mean that it is a bug in filter_index, because filter_index will only use the highest priority matching TextureOverride, while checktextureoverride will use all matching TextureOverrides in order of their priority... But it might give us a clue, and should at the very least confirm if your matching attributes are ok or not.
You can also use the ShaderUsage.txt to find the attributes if the texture hash appears in there.

Can you do a quick test for me - instead of:
[ShaderOverride...]
...
x = ps-t0
[TextureOverrideMap]
...
filter_index=4

Try:
[ShaderOverride...]
...
checktextureoverride = ps-t0
[TextureOverrideMap]
...
x=4


If that works let me know and I'll take a closer look. If that works it may not necessarily mean that it is a bug in filter_index, because filter_index will only use the highest priority matching TextureOverride, while checktextureoverride will use all matching TextureOverrides in order of their priority... But it might give us a clue, and should at the very least confirm if your matching attributes are ok or not.

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 04/06/2018 08:52 AM   
I want to get a few people's opinions on something - for a long time now 3DMigoto has made rasterizer_disable_scissor=1 the default. The reasoning behind that was that scissor clipping is almost always a bad thing in stereo 3D (it is inherently 2D, so it only works for screen depth or 2D effects), and *usually* harmless to disable. However, recently I've seen several reports where disabling scissor clipping was causing more severe issues: - Dead or Alive Xtreme Venus Vacation: Breaks shadows (I mistook this for a game bug too - will be fixed in the next update...) - .hack//G.U. : Breaks minimap - https://github.com/bo3b/3Dmigoto/issues/90 - [url]https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/5315705/#5315705[/url] So, I'm beginning to wonder if disabling scissor clipping by default is still the right choice, or whether we should go back to leaving it enabled by default and the shaderhackers disabling it when they need to. That would mean one more thing for shaderhackers to learn to recognise and deal with, but I'm confident that you all can do that ;-) Another point to consider is that rasterizer_disable_scissor requires a game restart to reliably take effect, so it's a hassle if we find we need to change it. However, 3DMigoto nowadays has "disable_scissor=1" (short for "run=BuiltinCustomShaderDisableScissorClipping", and you can see what [i]that[/i] is short for in the d3d11_log.txt), which can be applied on a per-shader basis and does *not* require a game restart to take effect. rasterizer_disable_scissor will perform marginally better, but I'd honestly be quite surprised if anyone noticed a measurable difference between them provided that there was at least one other ShaderOverride section (there is a performance difference between no ShaderOverrides vs 1+ ShaderOverrides). There's also the fact that 3DMigoto has evolved to the point where it is now one of the most powerful general purpose DX11 graphics modding tools in existence and some modders outside of our community are using it as well, but disabling scissor clipping only makes sense for 3D Vision modding. One thing I do want to do, is be able to pass the bounds of the scissor rectangle into the shader (via IniParams), so that e.g. if you find that scissor clipping is necessary for the HUD to display correctly, but leaving it enabled means that you have to leave the HUD at screen depth, this would give you a new option to disable scissor clipping, and re-implement it yourself in the pixel shader (via a position check and the "discard" instruction) with an adjusted depth.
I want to get a few people's opinions on something - for a long time now 3DMigoto has made rasterizer_disable_scissor=1 the default. The reasoning behind that was that scissor clipping is almost always a bad thing in stereo 3D (it is inherently 2D, so it only works for screen depth or 2D effects), and *usually* harmless to disable.

However, recently I've seen several reports where disabling scissor clipping was causing more severe issues:
- Dead or Alive Xtreme Venus Vacation: Breaks shadows (I mistook this for a game bug too - will be fixed in the next update...)
- .hack//G.U. : Breaks minimap - https://github.com/bo3b/3Dmigoto/issues/90
- https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/5315705/#5315705

So, I'm beginning to wonder if disabling scissor clipping by default is still the right choice, or whether we should go back to leaving it enabled by default and the shaderhackers disabling it when they need to. That would mean one more thing for shaderhackers to learn to recognise and deal with, but I'm confident that you all can do that ;-)

Another point to consider is that rasterizer_disable_scissor requires a game restart to reliably take effect, so it's a hassle if we find we need to change it. However, 3DMigoto nowadays has "disable_scissor=1" (short for "run=BuiltinCustomShaderDisableScissorClipping", and you can see what that is short for in the d3d11_log.txt), which can be applied on a per-shader basis and does *not* require a game restart to take effect. rasterizer_disable_scissor will perform marginally better, but I'd honestly be quite surprised if anyone noticed a measurable difference between them provided that there was at least one other ShaderOverride section (there is a performance difference between no ShaderOverrides vs 1+ ShaderOverrides).

There's also the fact that 3DMigoto has evolved to the point where it is now one of the most powerful general purpose DX11 graphics modding tools in existence and some modders outside of our community are using it as well, but disabling scissor clipping only makes sense for 3D Vision modding.

One thing I do want to do, is be able to pass the bounds of the scissor rectangle into the shader (via IniParams), so that e.g. if you find that scissor clipping is necessary for the HUD to display correctly, but leaving it enabled means that you have to leave the HUD at screen depth, this would give you a new option to disable scissor clipping, and re-implement it yourself in the pixel shader (via a position check and the "discard" instruction) with an adjusted depth.

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 04/06/2018 09:58 AM   
My general opinion is that a game in 2D with just 3Dmigoto shouldn't look any different from the original game. There are multiple games I have where minimaps or menus have content outside of bounds because of disabled scissor clipping (DS2, Grim Dawn, FFX, FFXII...). They are usually the ones where the HUD clips in a restrictive way in 3D if you enable clipping back. I sometimes prefer one option and sometimes the other. DSS, if with your idea it would be possible to extend the drawing area to just what the object (or even just max separation) needs, it would be great. It may make it possible to fix the Dark Souls 3 lighting / heatwave / ground messages clipping. By the way, who is using 3Dmigoto to make mods not related to 3D? At most I heard of some people using it to disable the HUD, but nothing else.
My general opinion is that a game in 2D with just 3Dmigoto shouldn't look any different from the original game.

There are multiple games I have where minimaps or menus have content outside of bounds because of disabled scissor clipping (DS2, Grim Dawn, FFX, FFXII...). They are usually the ones where the HUD clips in a restrictive way in 3D if you enable clipping back. I sometimes prefer one option and sometimes the other.

DSS, if with your idea it would be possible to extend the drawing area to just what the object (or even just max separation) needs, it would be great. It may make it possible to fix the Dark Souls 3 lighting / heatwave / ground messages clipping.

By the way, who is using 3Dmigoto to make mods not related to 3D? At most I heard of some people using it to disable the HUD, but nothing else.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 04/06/2018 11:27 AM   
[quote] By the way, who is using 3Dmigoto to make mods not related to 3D? At most I heard of some people using it to disable the HUD, but nothing else. [/quote]That I know of: oomek obviously was using it for his Dirt 3 graphics overhaul mod, Voodooman (and others?) use it for removing post-processing effects, we occasionally get people looking at its shader capabilities, and there might have been a little more to this throwaway comment in the last update: [quote="DarkStarSword"][size="L"][color="green"]Frame Analysis[/color][/size] There are some significant improvements to using "analyse_options = dump_vb txt" ... The vertex buffer text files now include enough information that they could theoretically be imported into a 3D modelling tool such as Blender, if an import script was written for this format (the import script would also need to process the matching index buffer and any other related vertex buffers), and used to reconstruct the game/mesh-specific binary vertex buffer format to re-inject a modified mesh back into the game. I've written a script to convert this vertex buffer text file back into a binary vertex buffer to facilitate simple edits, but a full import/export script does not exist yet.[/quote]You might be able to guess which communities would be interested in a generic DX11 mesh/texture replacement tool, but more on that later. Worth noting that 3DMigoto by itself exceeds the capabilities of Ninja Ripper (pending the Blender import/export script), Resorap and SpecialK combined for these areas, and has far better compatibility.
By the way, who is using 3Dmigoto to make mods not related to 3D? At most I heard of some people using it to disable the HUD, but nothing else.
That I know of: oomek obviously was using it for his Dirt 3 graphics overhaul mod, Voodooman (and others?) use it for removing post-processing effects, we occasionally get people looking at its shader capabilities, and there might have been a little more to this throwaway comment in the last update:

DarkStarSword said:Frame Analysis
There are some significant improvements to using "analyse_options = dump_vb txt"

...

The vertex buffer text files now include enough information that they could theoretically be imported into a 3D modelling tool such as Blender, if an import script was written for this format (the import script would also need to process the matching index buffer and any other related vertex buffers), and used to reconstruct the game/mesh-specific binary vertex buffer format to re-inject a modified mesh back into the game. I've written a script to convert this vertex buffer text file back into a binary vertex buffer to facilitate simple edits, but a full import/export script does not exist yet.
You might be able to guess which communities would be interested in a generic DX11 mesh/texture replacement tool, but more on that later.

Worth noting that 3DMigoto by itself exceeds the capabilities of Ninja Ripper (pending the Blender import/export script), Resorap and SpecialK combined for these areas, and has far better compatibility.
Attachments

blender_3dmigoto.png

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 04/06/2018 11:55 AM   
If anyone here is interested in using 3DMigoto for mesh replacements (or just ripping - it exports more data than Ninja Ripper does) you can now import 3DMigoto's frame analysis vertex buffer dumps (the txt versions) into Blender with this addon, and then export binary vertex & index buffers that you can use back in 3DMigoto to do a mesh replacement: https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/blender_3dmigoto.py I know that this addon won't work with every game yet - games that use multiple vertex buffers together are not supported yet (so, don't bother trying with Witcher 3 yet), not all DXGI formats are supported, there might be other variations on input layout that it can't cope with yet and it only works with meshes that use index buffers. If you want to experiment with it in a game that it definitely does work with, Dead or Alive Xtreme Venus Vacation is the one I've been playing around with and is free to play if you can decipher enough Japanese to install it: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74878/[/img] Mesh replacement works in a similar way to texture replacements, but there are a few extra details: Vertex buffers must specify the stride (found in the vb.txt file from frame analysis): [code] [ResourceTestVB] type = Buffer stride = 80 filename = ShaderFixes/test.vb [/code] Index buffers must specify the format (found in the ib.txt file from frame analysis, and it must be either R16_UINT or R32_UINT): [code] [ResourceTestIB] type = Buffer format = R16_UINT filename = ShaderFixes/test.ib [/code] The ShaderOverride is similar to texture replacement, but testing either the vertex or index buffer instead of a texture slot: [code] [ShaderOverrideBodyPS] hash = 88919121becebe35 analyse_options = deferred_ctx_accurate share_dupes dump_vb txt buf checktextureoverride = vb0 [/code] In the TextureOverride swap in the vertex & index buffers, and replace the draw call with the number of indices in the index buffer (briefly displayed during export from Blender, or half/quarter the filesize of the exported binary index buffer file depending on the index buffer format): [code] [TextureOverrideTestVB] hash = e450d0f0 ; TODO: match on sub-part of mesh AKA first index ; Replace mesh: vb0 = ResourceTestVB unless_null ib = ResourceTestIB unless_null ; Replace original draw call to change number of indices: handling = skip drawindexed = 31902, 0, 0 [/code]
If anyone here is interested in using 3DMigoto for mesh replacements (or just ripping - it exports more data than Ninja Ripper does) you can now import 3DMigoto's frame analysis vertex buffer dumps (the txt versions) into Blender with this addon, and then export binary vertex & index buffers that you can use back in 3DMigoto to do a mesh replacement:

https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/blender_3dmigoto.py

I know that this addon won't work with every game yet - games that use multiple vertex buffers together are not supported yet (so, don't bother trying with Witcher 3 yet), not all DXGI formats are supported, there might be other variations on input layout that it can't cope with yet and it only works with meshes that use index buffers. If you want to experiment with it in a game that it definitely does work with, Dead or Alive Xtreme Venus Vacation is the one I've been playing around with and is free to play if you can decipher enough Japanese to install it:

Image

Mesh replacement works in a similar way to texture replacements, but there are a few extra details:

Vertex buffers must specify the stride (found in the vb.txt file from frame analysis):

[ResourceTestVB]
type = Buffer
stride = 80
filename = ShaderFixes/test.vb

Index buffers must specify the format (found in the ib.txt file from frame analysis, and it must be either R16_UINT or R32_UINT):

[ResourceTestIB]
type = Buffer
format = R16_UINT
filename = ShaderFixes/test.ib

The ShaderOverride is similar to texture replacement, but testing either the vertex or index buffer instead of a texture slot:

[ShaderOverrideBodyPS]
hash = 88919121becebe35
analyse_options = deferred_ctx_accurate share_dupes dump_vb txt buf
checktextureoverride = vb0

In the TextureOverride swap in the vertex & index buffers, and replace the draw call with the number of indices in the index buffer (briefly displayed during export from Blender, or half/quarter the filesize of the exported binary index buffer file depending on the index buffer format):

[TextureOverrideTestVB]
hash = e450d0f0
; TODO: match on sub-part of mesh AKA first index
; Replace mesh:
vb0 = ResourceTestVB unless_null
ib = ResourceTestIB unless_null
; Replace original draw call to change number of indices:
handling = skip
drawindexed = 31902, 0, 0

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 04/09/2018 05:38 AM   
@ DarkStarSword and bo3b: I need some help with the DX10 3Dmigoto build (https://github.com/bo3b/3Dmigoto/releases/tag/0.1.1-alpha), regarding Devil May Cry 4 Special Edition. I can't use ASM shaders, right? At least I think it didn't work for me. The thing is that I finally know how to fix water reflections without breaking water edges, but the problem is that I need to fix it in the pixel shader. Trouble comes here because when I dump the shader 3Dmigoto makes a "boop", complaining that the use of ".Sample(" ([url]https://msdn.microsoft.com/en-us/library/windows/desktop/bb509695(v=vs.85).aspx[/url]) is using incorrect subscripts (".xyzw"). For the shader to load, I need to only use ".x" or just nothing. And I think this is making the effect look very different from the original (water opacity, distortion, etc). I have asked DJ-RK about this (he took a look at the shader) and he said that basically everything is fine compared to the ASM code except for the lines using ".Sample(". For example, the decision of using the refraction distortion code is inside a condition that checks if the "w" value of one of those ".Sample(" is greater than 0. With the normal condition, this HLSL shader never shows the effect, but if I reverse it, it shows up. I don't have the shader code here because I'm not home. I can post it in 10 hours or so. But here are screenshots: Fixed reflection in the VS but wrong edges: http://u.cubeupload.com/masterotaku/dmc4wrongedges.jpg Fixed reflection and correct edges in the PS, but different looking effect (distortion workaround enabled): http://u.cubeupload.com/masterotaku/dmc4wrongeffects.jpg Can you help with this, or make ASM shaders work in this build? I understand it can be a big amount of work, so just in case, I've done some workarounds (more than what the screenshot shows) in the shader to make it more similar to the original, but it's still different and driving me a bit mad :p. I'd prefer to have completely correct shaders before releasing this update to the public. Edit: thanks for posting the shader and your thoughts, DJ-RK.
@ DarkStarSword and bo3b: I need some help with the DX10 3Dmigoto build (https://github.com/bo3b/3Dmigoto/releases/tag/0.1.1-alpha), regarding Devil May Cry 4 Special Edition. I can't use ASM shaders, right? At least I think it didn't work for me.

The thing is that I finally know how to fix water reflections without breaking water edges, but the problem is that I need to fix it in the pixel shader. Trouble comes here because when I dump the shader 3Dmigoto makes a "boop", complaining that the use of ".Sample(" (https://msdn.microsoft.com/en-us/library/windows/desktop/bb509695(v=vs.85).aspx) is using incorrect subscripts (".xyzw"). For the shader to load, I need to only use ".x" or just nothing. And I think this is making the effect look very different from the original (water opacity, distortion, etc).

I have asked DJ-RK about this (he took a look at the shader) and he said that basically everything is fine compared to the ASM code except for the lines using ".Sample(". For example, the decision of using the refraction distortion code is inside a condition that checks if the "w" value of one of those ".Sample(" is greater than 0. With the normal condition, this HLSL shader never shows the effect, but if I reverse it, it shows up.

I don't have the shader code here because I'm not home. I can post it in 10 hours or so. But here are screenshots:

Fixed reflection in the VS but wrong edges: http://u.cubeupload.com/masterotaku/dmc4wrongedges.jpg
Fixed reflection and correct edges in the PS, but different looking effect (distortion workaround enabled): http://u.cubeupload.com/masterotaku/dmc4wrongeffects.jpg

Can you help with this, or make ASM shaders work in this build? I understand it can be a big amount of work, so just in case, I've done some workarounds (more than what the screenshot shows) in the shader to make it more similar to the original, but it's still different and driving me a bit mad :p. I'd prefer to have completely correct shaders before releasing this update to the public.

Edit: thanks for posting the shader and your thoughts, DJ-RK.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 04/13/2018 06:31 AM   
[quote="masterotaku"]I have asked DJ-RK about this (he took a look at the shader) and he said that basically everything is fine compared to the ASM code[/quote] Just to clarify, I looked through the resources in the cbuffers and how they are used in the shader, since I noticed a lot of them get split up like: [code]cbuffer CBScreen : register(b1) { float2 fScreenOffset : packoffset(c0); float2 fScreenScale : packoffset(c0.z); float2 fScreenSize : packoffset(c1); float2 fScreenInverseSize : packoffset(c1.z); float2 fScreenHalfPixelOffset : packoffset(c2); }[/code] and sometimes in ASM they will sometimes do something like "mul r0.xyz, r1.xyzw, cb1[0].xyzw" and rather than knowing to use the 2 separate resources like "r0.xyz = r1.xyzw * float4(fScreenOffset.xy, fScreenScale.xy)" instead the decompiler will just do something like "r0.xyz = r1.xyzw * fScreenOffset.xyxy". That's basically what I looked for and didn't find anything like that. I can't say with certainty that there's no other mistranslations, but what I can do is provide the pastebin link that you sent me earlier to save a bit of time for you getting it posted up here. ;) Here it is: [url]https://pastebin.com/tsX0H5Z2[/url]
masterotaku said:I have asked DJ-RK about this (he took a look at the shader) and he said that basically everything is fine compared to the ASM code


Just to clarify, I looked through the resources in the cbuffers and how they are used in the shader, since I noticed a lot of them get split up like:

cbuffer CBScreen : register(b1)
{
float2 fScreenOffset : packoffset(c0);
float2 fScreenScale : packoffset(c0.z);
float2 fScreenSize : packoffset(c1);
float2 fScreenInverseSize : packoffset(c1.z);
float2 fScreenHalfPixelOffset : packoffset(c2);
}


and sometimes in ASM they will sometimes do something like "mul r0.xyz, r1.xyzw, cb1[0].xyzw" and rather than knowing to use the 2 separate resources like "r0.xyz = r1.xyzw * float4(fScreenOffset.xy, fScreenScale.xy)" instead the decompiler will just do something like "r0.xyz = r1.xyzw * fScreenOffset.xyxy". That's basically what I looked for and didn't find anything like that. I can't say with certainty that there's no other mistranslations, but what I can do is provide the pastebin link that you sent me earlier to save a bit of time for you getting it posted up here. ;)

Here it is: https://pastebin.com/tsX0H5Z2

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

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 04/13/2018 07:02 AM   
[center][color="orange"][size="XL"]3Dmigoto 1.3.10[/size] [/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center] [center][size="XL"][color="orange"]IMPORTANT: rasterizer_disable_scissor is no longer enabled by default![/color][/size][/center]This means that you will very likely start seeing issues due to scissor clipping emerge. You may choose to just set this back to 1 to keep things as they were, but the flip side is that disabling scissor clipping can break certain effects in ways that will not show up via the show_original key, which is why I've chosen to change the default. Scissor clipping typically looks like this - where something adjusted in stereo 3D is clipped on a 2D screen depth rectangle. Note in this case the text next to "Select Monitor" is clipping incorrectly: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74910/[/img] Disabling scissor clipping will in some cases fix the issue, but in other cases causes different problems, such as here where the text overflows: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74912/[/img] Scissor clipping doesn't just apply to HUD elements - the same thing can happen to various effects in-game, and decals are often affected by it. Note that in some games you may see something that looks exactly the same as scissor clipping, but is caused by something else, such as an invisible mask shader that also needs to be stereoised. There are several other options available to you to deal with scissor clipping that don't involve disabling it everywhere: [olist] [.]Disable or enable it on a per-shader basis: [code] [ShaderOverrideDecalsWithScissorClipping] hash = ... disable_scissor = 1 [/code][/.] [.]Quick 'n' dirty way to see if scissor clipping is affecting you (note: will not work on any shaders in ShaderFixes, and I do not recommend shipping with this as it adds extra overhead to every draw call, but unlike rasterizer_disable_scissor, this works with show_original): [code] [ShaderRegexDisableScissorClipping] shader_model = ps_4_0 ps_5_0 disable_scissor = 1 [/code][/.] [.]Variant of 1 for cases where you need to override additional state or replace the draw call for some other reason: [code] [ShaderOverrideDecalsWithScissorClipping] hash = ... run = CustomShaderDisableScissorClippingAdvanced [CustomShaderDisableScissorClippingAdvanced] scissor_enable = false rasterizer_state_merge = true ; Any other draw call state overrides you need go here draw = from_caller handling = skip [/code][/.] [.][size="XL"][b][color="green"]Fix scissor clipping to work properly in stereo 3D[/color][/b][/size] You can now get the scissor rectangle in the shader, stereoise it and perform your own clipping in the pixel shader. e.g. To allow the UI to be properly stereoised with correct clipping in NieR Automata: [code] [ShaderOverrideMenuScissor1] Hash = ed8095aa588ab158 disable_scissor = 1 x1 = scissor0_left y1 = scissor0_top z1 = scissor0_right w1 = scissor0_bottom x2 = rt_width [/code] Then in the pixel shader: [code] void main( float4 v0 : SV_POSITION0, ... { // This matches the stereo correction in the vertex shader float stereo_adjustment = StereoParams.Load(0).x * IniParams[0].x * 1.3; // Load the scissor rectangle and stereoise it. Note that since both // SV_Position and the scissor rectange are in pixels, the adjustment needs to // be divided by the render target size and again by 2: float4 scissor_rect = IniParams[1].xyzw; scissor_rect.xz += floor(stereo_adjustment * IniParams[2].x / 2); // Perform stereo adjusted scissor clipping: if (any(v0.xy < scissor_rect.xy) || any(v0.xy >= scissor_rect.zw)) { discard; return; } [/code] This results in the text being properly lined up in 3D and clipping correctly: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74911/[/img] [/.] [/olist] [size="XL"][color="green"]Modular 3DMigoto Configuration / 3DMigoto as a Modding Platform[/color][/size] 3DMigoto has a new [Include] section which can specify additional configuration files to include - either including specific config files, or a directory to scan recursively to include all ini files, with the option to skip files matching some pattern. The former is useful to help break up the d3dx.ini into separate logical sections that can be enabled or disabled just by commenting/uncommenting the include directive - the 3DVision2SBS, upscaling and software mouse shaders shipped with 3DMigoto now have their config boilerplate moved to a separate config file using this mechanism, and you can expect updates to my debugging shaders, auto-convergence, etc. to do the same shortly. The later opens up the possibility to use 3DMigoto as a full modding *platform* for a given game, rather than just a single stand-alone mod. 3DMigoto's capabilities exceed some of the competing DX11 modding tools in many aspects, and interest in using it in other modding communities has been growing. The ability to recursively include config files is intended to support communities with multiple mod authors where coordinating everything in a single d3dx.ini is a limiting factor. Think about modding communities interested in things like texture and mesh replacements, where 3DMigoto is the *best* generalised DX11 injection tool for the former (e.g. other injection tools cannot live reload like 3DMigoto can, have very poor compatibility and cannot increase the resolution of replaced textures) and the *only* generalised DX11 injection tool for the later. Sections in the included configuration files are "namespaced" and will be automatically renamed by 3DMigoto to keep them unique. e.g. [ResourceFoo] might become [Resource\Mods\bar\baz.ini\Foo]. Where these sections are referenced by other sections 3DMigoto will first check for a section in the same namespace (so "ps-t0 = ResourceFoo" still works), then the global namespace. You can refer to a section in another config file by using the fully namespaced version of the section name (which must be absolute). Any external files referred to by included configuration files (e.g. by CustomShader or Resource sections) will be searched for relative to the config file first, then relative to the 3DMigoto directory if they aren't found. Included configuration files are allowed to append to global sections (such as [Present]) and can override settings in most global sections if they choose. Note that this means that the command list order of the [Present] section can depend on the include order, and for this reason it is suggested that the include_recursive directive be placed before the upscaling, mouse and 3DVision2SBS shaders as these generally should be run last. 3DMigoto will also try to be consistent about the order it includes config files in when scanning recursively, so that if there are any order dependent interractions between them the results should at least be consistent. 3DMigoto still has its usual warnings for duplicate hashes between ShaderOverride & TextureOverride sections, but these have been relaxed a little, and the warning message now indicates this is a potential mod conflict and displays the conflicting section names (which includes the namespace showing which mods they came from). A mod can force the warning of duplicate ShaderOverride hashes to go away with "allow_duplicate_hash = overrule", and can set a "match_priority" in TextureOverride sections to define some order between mods and hide the warning. There are some current limitations to this to this namespacing: [list] [.]There is only one global ShaderFixes folder, so mods that need additional files here will have to make this clear in their documentation. Adding the ability to load shaders from additional directories is very low priority because we have very good reasons for doing it the way we do.[/.] [.]IniParams is not namespaced, which could easily become a point of contention between mods. I have plans to expand the custom Resource sections to allow them to be used in place of IniParams, as they do support namespacing, though the DirectX texture slots they must be bound to access them inside a shader do not. Once we have conditional logic in the command list I may also add separate namespaced variables that are not automatically used in the shaders, which could eliminate a lot of contention here.[/.] [.]Texture filtering and checktextureoverride are not currently namespaced, and can match/trigger sections defined in a different mod. In some cases this may be intentional, as these are usually required to enable texture/mesh replacements and would normally be done once globally rather than in every single mod. Namespaced versions of these may be added in the future.[/.] [/list] [size="XL"][color="green"]Presets[/color][/size] Presets can now be narrowed down by requiring multiple conditions to be met per frame, or defining a condition that will prevent the preset from being triggered that frame: [code] [PresetMultipleConditions] ; Require two unique triggers to activate this preset: unique_triggers_required = 2 ; Do something ; Preset only activated when a particular distortion shader is in use: [ShaderOverrideDistort] hash = ... preset = PresetMultipleConditions ; *And* when a specific texture is in use: [ShaderOverrideFog] hash = ... checktextureoverride = ps-t0 [TextureOverrideFogTexture] hash = ... preset = PresetMultipleConditions ; But not when this other shader is in use: [ShaderOverrideSomethingThatSignifiesThePresetIsWrong] hash = ... exclude = PresetMultipleConditions [/code] [size="XL"][color="green"][TextureOverride] Draw Context Matching (e.g. partial mesh matching)[/color][/size] [TextureOverride] sections have gained several new options: [list] [.]match_first_vertex = n[/.] [.]match_first_index = n[/.] [.]match_first_instance = n[/.] [.]match_vertex_count = n[/.] [.]match_index_count = n[/.] [.]match_instance_count = n[/.] [/list]This narrows down the circumstances in which the section will match when used for texture filtering or with checktextureoverride. The practical application of this is to allow matches on the index or vertex buffer hashes to be more specific - to match a specific mesh inside a buffer that contains many unrelated meshes, or a specific sub-part of a mesh drawn separately from the other parts. These can be used in conjunction with either matching by hash, or a fuzzy match on the resource description. match_priority can be used to set the order the sections are run in if multiple sections match. [size="XL"][color="green"]Misc[/color][/size] [list] [.]New "drawindexed=auto" command to draw every index in the currently bound index buffer. Useful when a custom vertex + index buffer pair is loaded from disk (e.g. exported from the Blender 3DMigoto addon) to avoid the need to determine this manually each time the mesh is updated.[/.] [.]Hunting mode will now skip all custom draw commands, not just draw=from_caller[/.] [.]Custom textures loaded from disk can now override bind_flags in situations where 3DMigoto cannot determine these automatically, or to manipulate driver heuristics.[/.] [.]The frame analysis "dump" command will now imply "deferred_ctx_accurate" if neither deferred context option was specified.[/.] [.]New "BuiltInCommandListUnbindAllRenderTargets" command list to replace the version in the d3dx.ini template[/.] [.]Fixed a long standing bug where texture filtering, checktextureoverride and potentially other cases could mistake a custom resource for a game resource and do the wrong thing, often seeming to change at random on F10 reload.[/.] [.]The upscaling and software mouse shaders can now be re-ordered without editing either section, and other custom HUD shaders run before upscaling will work. This requires the latest version of the upscaling.ini file to work, so will not happen automatically if upgrading an existing fix.[/.] [.]Fixed crash when reloading configuration while using hooking, and fixed a crash on launch in some games using hooking.[/.] [.]Texture filtering will now use filter_index from the highest priority matching TextureOverride section that set a filter_index, i.e. a lower priority match that set a filter_index would be used in place of a higher priority match that did not set a filter_index. Any match by hash will still trump any match by resource description, even if the match by hash did not include a filter_index and the match by description did.[/.] [/list] @masterotaku - I'd appreciate a performance assessment of this version compared to 1.3.8 from you if you have time - 3DMigoto now tracks when resources are freed to fix the mistaken resource bug, and I want to know how well the technique I'm using for that performs.
3Dmigoto 1.3.10

IMPORTANT: rasterizer_disable_scissor is no longer enabled by default!
This means that you will very likely start seeing issues due to scissor clipping emerge. You may choose to just set this back to 1 to keep things as they were, but the flip side is that disabling scissor clipping can break certain effects in ways that will not show up via the show_original key, which is why I've chosen to change the default.

Scissor clipping typically looks like this - where something adjusted in stereo 3D is clipped on a 2D screen depth rectangle. Note in this case the text next to "Select Monitor" is clipping incorrectly:

Image

Disabling scissor clipping will in some cases fix the issue, but in other cases causes different problems, such as here where the text overflows:

Image

Scissor clipping doesn't just apply to HUD elements - the same thing can happen to various effects in-game, and decals are often affected by it. Note that in some games you may see something that looks exactly the same as scissor clipping, but is caused by something else, such as an invisible mask shader that also needs to be stereoised.

There are several other options available to you to deal with scissor clipping that don't involve disabling it everywhere:

  1. Disable or enable it on a per-shader basis:

    [ShaderOverrideDecalsWithScissorClipping]
    hash = ...
    disable_scissor = 1

  2. Quick 'n' dirty way to see if scissor clipping is affecting you (note: will not work on any shaders in ShaderFixes, and I do not recommend shipping with this as it adds extra overhead to every draw call, but unlike rasterizer_disable_scissor, this works with show_original):

    [ShaderRegexDisableScissorClipping]
    shader_model = ps_4_0 ps_5_0
    disable_scissor = 1

  3. Variant of 1 for cases where you need to override additional state or replace the draw call for some other reason:

    [ShaderOverrideDecalsWithScissorClipping]
    hash = ...
    run = CustomShaderDisableScissorClippingAdvanced

    [CustomShaderDisableScissorClippingAdvanced]
    scissor_enable = false
    rasterizer_state_merge = true
    ; Any other draw call state overrides you need go here
    draw = from_caller
    handling = skip

  4. Fix scissor clipping to work properly in stereo 3D
    You can now get the scissor rectangle in the shader, stereoise it and perform your own clipping in the pixel shader. e.g. To allow the UI to be properly stereoised with correct clipping in NieR Automata:

    [ShaderOverrideMenuScissor1]
    Hash = ed8095aa588ab158
    disable_scissor = 1
    x1 = scissor0_left
    y1 = scissor0_top
    z1 = scissor0_right
    w1 = scissor0_bottom
    x2 = rt_width

    Then in the pixel shader:

    void main(
    float4 v0 : SV_POSITION0,
    ...
    {
    // This matches the stereo correction in the vertex shader
    float stereo_adjustment = StereoParams.Load(0).x * IniParams[0].x * 1.3;

    // Load the scissor rectangle and stereoise it. Note that since both
    // SV_Position and the scissor rectange are in pixels, the adjustment needs to
    // be divided by the render target size and again by 2:
    float4 scissor_rect = IniParams[1].xyzw;
    scissor_rect.xz += floor(stereo_adjustment * IniParams[2].x / 2);

    // Perform stereo adjusted scissor clipping:
    if (any(v0.xy < scissor_rect.xy) || any(v0.xy >= scissor_rect.zw)) {
    discard;
    return;
    }

    This results in the text being properly lined up in 3D and clipping correctly:

    Image


Modular 3DMigoto Configuration / 3DMigoto as a Modding Platform
3DMigoto has a new [Include] section which can specify additional configuration files to include - either including specific config files, or a directory to scan recursively to include all ini files, with the option to skip files matching some pattern.

The former is useful to help break up the d3dx.ini into separate logical sections that can be enabled or disabled just by commenting/uncommenting the include directive - the 3DVision2SBS, upscaling and software mouse shaders shipped with 3DMigoto now have their config boilerplate moved to a separate config file using this mechanism, and you can expect updates to my debugging shaders, auto-convergence, etc. to do the same shortly.

The later opens up the possibility to use 3DMigoto as a full modding *platform* for a given game, rather than just a single stand-alone mod. 3DMigoto's capabilities exceed some of the competing DX11 modding tools in many aspects, and interest in using it in other modding communities has been growing. The ability to recursively include config files is intended to support communities with multiple mod authors where coordinating everything in a single d3dx.ini is a limiting factor. Think about modding communities interested in things like texture and mesh replacements, where 3DMigoto is the *best* generalised DX11 injection tool for the former (e.g. other injection tools cannot live reload like 3DMigoto can, have very poor compatibility and cannot increase the resolution of replaced textures) and the *only* generalised DX11 injection tool for the later.

Sections in the included configuration files are "namespaced" and will be automatically renamed by 3DMigoto to keep them unique. e.g. [ResourceFoo] might become [Resource\Mods\bar\baz.ini\Foo]. Where these sections are referenced by other sections 3DMigoto will first check for a section in the same namespace (so "ps-t0 = ResourceFoo" still works), then the global namespace. You can refer to a section in another config file by using the fully namespaced version of the section name (which must be absolute).

Any external files referred to by included configuration files (e.g. by CustomShader or Resource sections) will be searched for relative to the config file first, then relative to the 3DMigoto directory if they aren't found.

Included configuration files are allowed to append to global sections (such as [Present]) and can override settings in most global sections if they choose. Note that this means that the command list order of the [Present] section can depend on the include order, and for this reason it is suggested that the include_recursive directive be placed before the upscaling, mouse and 3DVision2SBS shaders as these generally should be run last. 3DMigoto will also try to be consistent about the order it includes config files in when scanning recursively, so that if there are any order dependent interractions between them the results should at least be consistent.

3DMigoto still has its usual warnings for duplicate hashes between ShaderOverride & TextureOverride sections, but these have been relaxed a little, and the warning message now indicates this is a potential mod conflict and displays the conflicting section names (which includes the namespace showing which mods they came from). A mod can force the warning of duplicate ShaderOverride hashes to go away with "allow_duplicate_hash = overrule", and can set a "match_priority" in TextureOverride sections to define some order between mods and hide the warning.

There are some current limitations to this to this namespacing:
  • There is only one global ShaderFixes folder, so mods that need additional files here will have to make this clear in their documentation. Adding the ability to load shaders from additional directories is very low priority because we have very good reasons for doing it the way we do.

  • IniParams is not namespaced, which could easily become a point of contention between mods. I have plans to expand the custom Resource sections to allow them to be used in place of IniParams, as they do support namespacing, though the DirectX texture slots they must be bound to access them inside a shader do not. Once we have conditional logic in the command list I may also add separate namespaced variables that are not automatically used in the shaders, which could eliminate a lot of contention here.

  • Texture filtering and checktextureoverride are not currently namespaced, and can match/trigger sections defined in a different mod. In some cases this may be intentional, as these are usually required to enable texture/mesh replacements and would normally be done once globally rather than in every single mod. Namespaced versions of these may be added in the future.


Presets
Presets can now be narrowed down by requiring multiple conditions to be met per frame, or defining a condition that will prevent the preset from being triggered that frame:

[PresetMultipleConditions]
; Require two unique triggers to activate this preset:
unique_triggers_required = 2
; Do something

; Preset only activated when a particular distortion shader is in use:
[ShaderOverrideDistort]
hash = ...
preset = PresetMultipleConditions

; *And* when a specific texture is in use:
[ShaderOverrideFog]
hash = ...
checktextureoverride = ps-t0
[TextureOverrideFogTexture]
hash = ...
preset = PresetMultipleConditions

; But not when this other shader is in use:
[ShaderOverrideSomethingThatSignifiesThePresetIsWrong]
hash = ...
exclude = PresetMultipleConditions


[TextureOverride] Draw Context Matching (e.g. partial mesh matching)
[TextureOverride] sections have gained several new options:
  • match_first_vertex = n
  • match_first_index = n
  • match_first_instance = n
  • match_vertex_count = n
  • match_index_count = n
  • match_instance_count = n
This narrows down the circumstances in which the section will match when used for texture filtering or with checktextureoverride. The practical application of this is to allow matches on the index or vertex buffer hashes to be more specific - to match a specific mesh inside a buffer that contains many unrelated meshes, or a specific sub-part of a mesh drawn separately from the other parts. These can be used in conjunction with either matching by hash, or a fuzzy match on the resource description. match_priority can be used to set the order the sections are run in if multiple sections match.

Misc
  • New "drawindexed=auto" command to draw every index in the currently bound index buffer. Useful when a custom vertex + index buffer pair is loaded from disk (e.g. exported from the Blender 3DMigoto addon) to avoid the need to determine this manually each time the mesh is updated.

  • Hunting mode will now skip all custom draw commands, not just draw=from_caller

  • Custom textures loaded from disk can now override bind_flags in situations where 3DMigoto cannot determine these automatically, or to manipulate driver heuristics.

  • The frame analysis "dump" command will now imply "deferred_ctx_accurate" if neither deferred context option was specified.

  • New "BuiltInCommandListUnbindAllRenderTargets" command list to replace the version in the d3dx.ini template

  • Fixed a long standing bug where texture filtering, checktextureoverride and potentially other cases could mistake a custom resource for a game resource and do the wrong thing, often seeming to change at random on F10 reload.

  • The upscaling and software mouse shaders can now be re-ordered without editing either section, and other custom HUD shaders run before upscaling will work. This requires the latest version of the upscaling.ini file to work, so will not happen automatically if upgrading an existing fix.

  • Fixed crash when reloading configuration while using hooking, and fixed a crash on launch in some games using hooking.

  • Texture filtering will now use filter_index from the highest priority matching TextureOverride section that set a filter_index, i.e. a lower priority match that set a filter_index would be used in place of a higher priority match that did not set a filter_index. Any match by hash will still trump any match by resource description, even if the match by hash did not include a filter_index and the match by description did.


@masterotaku - I'd appreciate a performance assessment of this version compared to 1.3.8 from you if you have time - 3DMigoto now tracks when resources are freed to fix the mistaken resource bug, and I want to know how well the technique I'm using for that performs.

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 04/14/2018 10:35 PM   
[quote="DarkStarSword"]The later opens up the possibility to use 3DMigoto as a full modding *platform* for a given game, rather than just a single stand-alone mod.[/quote] Wow, that could have so many possibilities and could be a game changer for PC gaming on so many levels. You should start a website where you could could list mods, like Nexxus. Taking a cut from mod authors.
DarkStarSword said:The later opens up the possibility to use 3DMigoto as a full modding *platform* for a given game, rather than just a single stand-alone mod.


Wow, that could have so many possibilities and could be a game changer for PC gaming on so many levels.

You should start a website where you could could list mods, like Nexxus. Taking a cut from mod authors.

Posted 04/14/2018 11:38 PM   
Alright, DSS. Then my tasks for tomorrow are: - Test Grim Dawn performance as always. - Try to fix clipping in all the games I can where disabling the scissor makes things overflow (Grim Dawn included), especially lighting in Dark Souls 3.
Alright, DSS. Then my tasks for tomorrow are:

- Test Grim Dawn performance as always.
- Try to fix clipping in all the games I can where disabling the scissor makes things overflow (Grim Dawn included), especially lighting in Dark Souls 3.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 04/14/2018 11:40 PM   
[quote="DarkStarSword"][center][color="orange"][size="XL"]3Dmigoto 1.3.10[/size] [/color][/center][/quote] Holy Hell, I feel like you literally read my mind for things I wanted to request, but didn't. I was thinking about the whole modular thing for a while now because it is so unwieldly working out of the same d3dx.ini file after building it tons of regexes, adding shaderoverrides and texture overrides, etc, and thought how it would be better if there were separate files we could make for these and just import them. Am I correct in thinking that this may now be done via the new include functionality? And for the presets update, I was actually wrapping my head around how to get a preset to function last night and wishes for certain expanded functionality there beyond just having textures and shaders trigger them. Was more specifically looking for the absence of a particular shader/texture to trigger a preset, which I worked around by creating a preset for while the texture appears and have the driver default convergence be the "preset" for it's absence, but it looks like this new functionality can achieve what I was hoping for last night. Guess since this has opened the discussion about features I've recently come to want, here couple other things I've run into recently that are on a bit of a wishlist: -Apparently no VK code exists for mapping a mousewheel scroll up/down. Would be nice if there was some way to do this. -Ability to assign convergence a constant value (eg. convergence = z1) -Mathematical operations handling of constants in the d3dx.ini in key/preset override sections (probably a lot easier said than done) Just wondering on the feasibility of those. Can submit feature requests through the Github page. Anyways, another amazing update that completely goes beyond expectations. Thank you so much for this!
DarkStarSword said:
3Dmigoto 1.3.10



Holy Hell, I feel like you literally read my mind for things I wanted to request, but didn't.

I was thinking about the whole modular thing for a while now because it is so unwieldly working out of the same d3dx.ini file after building it tons of regexes, adding shaderoverrides and texture overrides, etc, and thought how it would be better if there were separate files we could make for these and just import them. Am I correct in thinking that this may now be done via the new include functionality?

And for the presets update, I was actually wrapping my head around how to get a preset to function last night and wishes for certain expanded functionality there beyond just having textures and shaders trigger them. Was more specifically looking for the absence of a particular shader/texture to trigger a preset, which I worked around by creating a preset for while the texture appears and have the driver default convergence be the "preset" for it's absence, but it looks like this new functionality can achieve what I was hoping for last night.

Guess since this has opened the discussion about features I've recently come to want, here couple other things I've run into recently that are on a bit of a wishlist:
-Apparently no VK code exists for mapping a mousewheel scroll up/down. Would be nice if there was some way to do this.
-Ability to assign convergence a constant value (eg. convergence = z1)
-Mathematical operations handling of constants in the d3dx.ini in key/preset override sections (probably a lot easier said than done)

Just wondering on the feasibility of those. Can submit feature requests through the Github page. Anyways, another amazing update that completely goes beyond expectations. Thank you so much for this!

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

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 04/15/2018 04:16 AM   
[quote="DJ-RK"]Holy Hell, I feel like you literally read my mind for things I wanted to request, but didn't.[/quote]Can I add Clairvoyance to my CV? :-p [quote]I was thinking about the whole modular thing for a while now because it is so unwieldly working out of the same d3dx.ini file after building it tons of regexes, adding shaderoverrides and texture overrides, etc, and thought how it would be better if there were separate files we could make for these and just import them. Am I correct in thinking that this may now be done via the new include functionality?[/quote]Yes - this can be used to organise the config into separate logical files as you see fit :) I'm personally looking forward to just having a single line to comment/uncomment to enable my constant buffer debug shader instead of an entire block and an extra line in the [Present] section :) [quote]Guess since this has opened the discussion about features I've recently come to want, here couple other things I've run into recently that are on a bit of a wishlist: -Apparently no VK code exists for mapping a mousewheel scroll up/down. Would be nice if there was some way to do this.[/quote]Haha, now you're reading my mind - I noticed this same limitation the other day, but haven't started looking into solutions yet. [quote]-Ability to assign convergence a constant value (eg. convergence = z1)[/quote]I've been holding off on this because I want to add it at the same time as: [quote]-Mathematical operations handling of constants in the d3dx.ini in key/preset override sections (probably a lot easier said than done)[/quote]I've been planning to add this forever along with the conditional logic (this is what turns the command list from a list of commands into a turing complete programming language), but it has never quite made it to the top of my TODO list. There's a few cases where I have specifically wanted this recently though, so it's bubbling up higher and higher on my list and may materialise in the not too distant future ;-P
DJ-RK said:Holy Hell, I feel like you literally read my mind for things I wanted to request, but didn't.
Can I add Clairvoyance to my CV? :-p

I was thinking about the whole modular thing for a while now because it is so unwieldly working out of the same d3dx.ini file after building it tons of regexes, adding shaderoverrides and texture overrides, etc, and thought how it would be better if there were separate files we could make for these and just import them. Am I correct in thinking that this may now be done via the new include functionality?
Yes - this can be used to organise the config into separate logical files as you see fit :)

I'm personally looking forward to just having a single line to comment/uncomment to enable my constant buffer debug shader instead of an entire block and an extra line in the [Present] section :)

Guess since this has opened the discussion about features I've recently come to want, here couple other things I've run into recently that are on a bit of a wishlist:
-Apparently no VK code exists for mapping a mousewheel scroll up/down. Would be nice if there was some way to do this.
Haha, now you're reading my mind - I noticed this same limitation the other day, but haven't started looking into solutions yet.

-Ability to assign convergence a constant value (eg. convergence = z1)
I've been holding off on this because I want to add it at the same time as:

-Mathematical operations handling of constants in the d3dx.ini in key/preset override sections (probably a lot easier said than done)
I've been planning to add this forever along with the conditional logic (this is what turns the command list from a list of commands into a turing complete programming language), but it has never quite made it to the top of my TODO list. There's a few cases where I have specifically wanted this recently though, so it's bubbling up higher and higher on my list and may materialise in the not too distant future ;-P

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 04/15/2018 05:41 AM   
Haha, yep, go ahead and add that to your CV and feel free to add me as a reference! ;) Definitely glad to hear these are already up in the realm of possibility, and I certainly figured that I couldn't have been the first to think of these so no surprise to hear you're already on the ball with some of them (at least conceptually). Actually, I just remembered a couple more things for the wishlist: -Built in key for cycling through different marking_mode options -Ability to set key presets for different frame analysis analyse_options/dump settings. ie. One for just dumping out a HUD shader, another for dumping out all shaders after a certain one (ie. AO), and another for just doing a full dump Those two are probably responsible for the most d3dx.ini changes that occur during my workflow on a game, and would be awesome for a couple less reasons to go back and forth to the .ini file changing them. Edit: Actually, is that first thing already doable just by setting up my own preset keys? I mainly just switch between original and skip marking_mode, is that something that can be changed by setting up separate keys to assign a different value to that, or even just one key as a cycle?
Haha, yep, go ahead and add that to your CV and feel free to add me as a reference! ;)

Definitely glad to hear these are already up in the realm of possibility, and I certainly figured that I couldn't have been the first to think of these so no surprise to hear you're already on the ball with some of them (at least conceptually).

Actually, I just remembered a couple more things for the wishlist:

-Built in key for cycling through different marking_mode options
-Ability to set key presets for different frame analysis analyse_options/dump settings. ie. One for just dumping out a HUD shader, another for dumping out all shaders after a certain one (ie. AO), and another for just doing a full dump

Those two are probably responsible for the most d3dx.ini changes that occur during my workflow on a game, and would be awesome for a couple less reasons to go back and forth to the .ini file changing them.

Edit: Actually, is that first thing already doable just by setting up my own preset keys? I mainly just switch between original and skip marking_mode, is that something that can be changed by setting up separate keys to assign a different value to that, or even just one key as a cycle?

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

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 04/15/2018 06:10 AM   
Performance in Grim Dawn is the same in 1.3.10 as in 1.3.7. I tried the scissor clipping adjustment in two games: - In FFXII, two of the four HUD pixel shaders complained about "return;", saying that o0 and o1 weren't completely initialized. Why don't the other two complain about this, I wonder? That "* 1.3;" you do in the stereo adjustment wasn't good in this case. Just *1 is what this HUD needs. Too bad that text elements get extra depth for some reason (same shader as other normal depth things) so they can't use the clipping area correctly. Does anyone know what I can do about this? I've seen the same happen in Tekken 7. - In Grim Dawn, it's a mess. The code I use in FFXII disables most of the HUD PS shader most of the time, but clipping varies as I move in the game. It's strange, as if "v0.xy" changed depending on world position and not the screen position of the HUD... But the VS is normal when I add depth and stuff. I'll have to try more things.
Performance in Grim Dawn is the same in 1.3.10 as in 1.3.7.

I tried the scissor clipping adjustment in two games:

- In FFXII, two of the four HUD pixel shaders complained about "return;", saying that o0 and o1 weren't completely initialized. Why don't the other two complain about this, I wonder? That "* 1.3;" you do in the stereo adjustment wasn't good in this case. Just *1 is what this HUD needs. Too bad that text elements get extra depth for some reason (same shader as other normal depth things) so they can't use the clipping area correctly. Does anyone know what I can do about this? I've seen the same happen in Tekken 7.

- In Grim Dawn, it's a mess. The code I use in FFXII disables most of the HUD PS shader most of the time, but clipping varies as I move in the game. It's strange, as if "v0.xy" changed depending on world position and not the screen position of the HUD... But the VS is normal when I add depth and stuff. I'll have to try more things.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 04/15/2018 11:52 AM   
  131 / 143    
Scroll To Top