3Dmigoto now open-source...
  128 / 143    
Hello everybody. Is somebody know how to calculate depth to nearest surface at software mouse coordinates and to send it's value from shader and receive it in mousevs.hlsl. As I know DX11 is'nt use ray tracing and it seem's to me that there will be many shaders from which I should send depth. And firstly I should send mouse's coordinates to shader(s) to calculate depth in shader
Hello everybody. Is somebody know how to calculate depth to nearest surface at software mouse coordinates and to send it's value from shader and receive it in mousevs.hlsl. As I know DX11 is'nt use ray tracing and it seem's to me that there will be many shaders from which I should send depth. And firstly I should send mouse's coordinates to shader(s) to calculate depth in shader

Posted 02/28/2018 05:53 PM   
At the bottom of mouse.hlsl you will see the code necessary to do this commented out - I put it in there as the most interesting example of the software mouse depth I could think of: [code] //float2 mouse_pos = (cursor_window / window_size * 2 - 1); //output.pos.x += adjust_from_depth_buffer(mouse_pos.x, mouse_pos.y); [/code] The mouse shader already has the mouse position and window size passed in (if you need this in another shader, use "cursor_x" and "cursor_y" instead as they have the "cursor_window / window_size" part pre-calculated and are already in the range 0:1 - you still need to multiply by 2 and subtract 1 to get them in the range -1:1 to use with a crosshair.hlsl, and in some games you may need to negate y). Speaking of crosshair.hlsl, you will need to grab a copy that has been adapted to a given engine and #include it in the mouse shader. Grab it from Subnautica if you are using this on Unity 5.5+ (edit: you will need to delete the lines about "InWorldHUDZBuffer", as that is specific to that game), or Dreamfall Chapters for Unity 5.4 or older. If you need it for a different engine I might already have one ready to go, or if you feel up to it you can take a crack at adapting it yourself (can be pretty difficult - if you don't get it exactly right the depth can be completely out of whack). You will need to copy the depth buffer into the mouse shader - my Unity template should set up most of what you need already, and so long as the game is using deferred lighting all you need to do is add these lines to the [CustomShaderSoftwareMouse] section: [code] vs-t110 = Resource_CameraDepthTexture vs-cb13 = Resource_UnityPerCamera post vs-t110 = null post vs-cb13 = null [/code] [quote="neovad1980"]As I know DX11 is'nt use ray tracing[/quote]crosshair.hlsl actually does do ray-tracing using the depth buffer ;-) [quote]and it seem's to me that there will be many shaders from which I should send depth.[/quote]Yeah - lighting shaders are usually a good choice and they tend to have the instructions and constant buffers you need to scale the depth buffer to get the linear depth as well. There's also a trick in 3DMigoto that can get the depth buffer in a more general way, but it *is not* guaranteed to be the depth buffer you were looking for, and you still need to scale it back to linear depth, so is often easier to just get it from a lighting shader: [code] [ResourceDepthBuffer] [ClearDepthStencilView] ResourceDepthBuffer = ref this [/code] If using that, you may need to copy it to be able to use it in a destination shader (depends how the game set it up), but that's a framerate killer if you don't limit it and there are a lot of HUD elements it is being copied to. You can limit it by copying it only the first time it is used like this: [code] [ResourceDepthBufferRef] [ResourceDepthBufferCopy] max_copies_per_frame=1 [ClearDepthStencilView] ResourceDepthBufferRef = ref this reset_per_frame_limits = ResourceDepthBufferCopy [ShaderOverrideHud] ; Or CustomShaderSoftwareMouse or wherever you need it hash = ... ResourceDepthBufferCopy = copy ResourceDepthBufferRef vs-t110 = ResourceDepthBufferCopy post vs-t110 = null [/code] If you find the mouse is sitting behind a transparent object there is even a trick you can use to capture these and have it rest in front - that's what the "InWorldHUDZBuffer" was all about in the Subnautica version of crosshair.hlsl as well as the [CustomShaderCaptureInWorldHUDDepth] and related sections in the d3dx.ini (this is used so the crosshair rests on the submarine HUD controls in that game). I also do something similar in Dreamfall Chapters to capture the depth of the Ghosts in the Dreamtime, but with a slightly different approach (either approach should have pretty much the same results. We didn't have support for clear= in 3DMigoto when I did DFC so I copied the regular depth buffer into the transparent depth buffer and used that in place of the original, whereas in Subnautica the transparent depth buffer only contains the relevant in-world HUD objects and nothing else, so both depth buffers are passed into crosshair.hlsl).
At the bottom of mouse.hlsl you will see the code necessary to do this commented out - I put it in there as the most interesting example of the software mouse depth I could think of:

//float2 mouse_pos = (cursor_window / window_size * 2 - 1);
//output.pos.x += adjust_from_depth_buffer(mouse_pos.x, mouse_pos.y);

The mouse shader already has the mouse position and window size passed in (if you need this in another shader, use "cursor_x" and "cursor_y" instead as they have the "cursor_window / window_size" part pre-calculated and are already in the range 0:1 - you still need to multiply by 2 and subtract 1 to get them in the range -1:1 to use with a crosshair.hlsl, and in some games you may need to negate y).

Speaking of crosshair.hlsl, you will need to grab a copy that has been adapted to a given engine and #include it in the mouse shader. Grab it from Subnautica if you are using this on Unity 5.5+ (edit: you will need to delete the lines about "InWorldHUDZBuffer", as that is specific to that game), or Dreamfall Chapters for Unity 5.4 or older. If you need it for a different engine I might already have one ready to go, or if you feel up to it you can take a crack at adapting it yourself (can be pretty difficult - if you don't get it exactly right the depth can be completely out of whack).

You will need to copy the depth buffer into the mouse shader - my Unity template should set up most of what you need already, and so long as the game is using deferred lighting all you need to do is add these lines to the [CustomShaderSoftwareMouse] section:

vs-t110 = Resource_CameraDepthTexture
vs-cb13 = Resource_UnityPerCamera
post vs-t110 = null
post vs-cb13 = null


neovad1980 said:As I know DX11 is'nt use ray tracing
crosshair.hlsl actually does do ray-tracing using the depth buffer ;-)

and it seem's to me that there will be many shaders from which I should send depth.
Yeah - lighting shaders are usually a good choice and they tend to have the instructions and constant buffers you need to scale the depth buffer to get the linear depth as well. There's also a trick in 3DMigoto that can get the depth buffer in a more general way, but it *is not* guaranteed to be the depth buffer you were looking for, and you still need to scale it back to linear depth, so is often easier to just get it from a lighting shader:

[ResourceDepthBuffer]

[ClearDepthStencilView]
ResourceDepthBuffer = ref this

If using that, you may need to copy it to be able to use it in a destination shader (depends how the game set it up), but that's a framerate killer if you don't limit it and there are a lot of HUD elements it is being copied to. You can limit it by copying it only the first time it is used like this:

[ResourceDepthBufferRef]

[ResourceDepthBufferCopy]
max_copies_per_frame=1

[ClearDepthStencilView]
ResourceDepthBufferRef = ref this
reset_per_frame_limits = ResourceDepthBufferCopy

[ShaderOverrideHud]
; Or CustomShaderSoftwareMouse or wherever you need it
hash = ...
ResourceDepthBufferCopy = copy ResourceDepthBufferRef
vs-t110 = ResourceDepthBufferCopy
post vs-t110 = null


If you find the mouse is sitting behind a transparent object there is even a trick you can use to capture these and have it rest in front - that's what the "InWorldHUDZBuffer" was all about in the Subnautica version of crosshair.hlsl as well as the [CustomShaderCaptureInWorldHUDDepth] and related sections in the d3dx.ini (this is used so the crosshair rests on the submarine HUD controls in that game). I also do something similar in Dreamfall Chapters to capture the depth of the Ghosts in the Dreamtime, but with a slightly different approach (either approach should have pretty much the same results. We didn't have support for clear= in 3DMigoto when I did DFC so I copied the regular depth buffer into the transparent depth buffer and used that in place of the original, whereas in Subnautica the transparent depth buffer only contains the relevant in-world HUD objects and nothing else, so both depth buffers are passed into crosshair.hlsl).

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 03/02/2018 08:08 PM   
[center][color="orange"][size="XL"]3Dmigoto 1.3.5[/size] [/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center] [list] [.] New "full_screen_on_key" method to force full screen instantly when a given key is pressed, which can be useful in a game where full_screen doesn't work or causes undesirable side effects.[/.] [.] load_library_redirect enabled again by default for out of the box compatibility with CryEngine and other games (Bo3b)[/.] [.] New "texture_hash" option to select a new texture hash algorithm that takes the full texture into account making it more resistent to collisions, and discards any padding in the texture that could in some cases cause a hash to be inconsistent. Performance may be lower with this, since it is hashing more of the texture. This should not be enabled when updating an existing fix, as it would break all the texture hashes.[/.] [.]Buffers loaded from files can now have their "stride" set, which allows loading vertex buffers from disk (including those dumped out by earlier frame analysis sessions)[/.] [.]Support for games using certain newer DirectX APIs[/.] [/list] [center][size="XL"][color="orange"][b]< The Big Frame Analysis Update >[/b][/color][/size][/center] [center][size="L"][color="green"]File Deduplication[/color][/size][/center] Frame analysis dumps will now perform much faster and consume far less disk space by detecting identical files and only writing them to disk once. This is especially significant when using dump_tex, but helps with any dumping mode. The "dedupes" folder contains the master copy of each dumped resource, and these are linked back into the main frame analysis folder. Depending on your Operating System, Privileges and Filesystem these will either be symbolic links, hard links or windows shortcuts: [list] [.]Symbolic Links: Enable developer mode in Windows 10 to use these (or run the game as admin, but I don't recommend that). Similar in some ways to Windows shortcuts, but "just works" in any application, and is of particular use with cygwin since these have been standard on Unix forever and scripts can work with these easily. Windows Explorer displays the shortcut arrow on these and correctly shows them as 0 bytes. Removing/renaming the master file will break any links to it, and moving the links to a different directory would also break them.[/.] [.]Hard Links: These will appear to be separate files, will not have a shortcut arrow and Windows Explorer will tell you they are taking up far more disk space than they actually are. No restrictions on what you can do with these - rename, move or delete them as you see fit. All links and the original must be deleted to reclaim disk space. Scripts can't locate the master file very easily. If an identical texture is dumped more than 1024 times, 3DMigoto will automatically rotate these so as to not exceed the maximum hard link limit.[/.] [.]Windows Shortcuts: Only used if symbolic and hard links are unavailable, such as on FAT32 filesystems. Doesn't work well with cygwin or any application that lacks explicit code to deal with them. Same issues as symbolic links in regards to removing/renaming files, but Windows goes out of its way to try to automatically repair them, so slightly less of an issue.[/.] [/list] By default, there is one "dedupes" folder per frame analysis session, but if you intend to perform many frame analysis sessions, you can enable the "share_dupes" option to use a single "FrameAnalysisDeduped" folder instead, which may make subsequent runs faster and consume less disk space, but means you can't just delete a specific frame analysis folder to reclaim the disk space it consumed. This may be of interest when using frame analysis to collect HUD textures or similar many times throughout a game. The filenames inside the dedupes folder are the hashes of the resources at the time they are dumped, which ordinarily will not match the hashes used for texture filtering (which can be found in the frame analysis filenames *outside* of the dedupes folder, the frame analysis log file, or ShaderUsage.txt). If you're curious they can be made to match - enable the new "texture_hash=1" option (this will change all the texture filtering hashes, so don't do it on an existing fix), ensure you are dumping the resources as "mono" and (if necessary) try enabling "track_texture_updates=1". Only static textures will match - render targets or anything that has been altered after it was created will never match their filtering hash. [center][size="L"][color="green"]Deferred Contexts (AKA Multi-Threaded Rendering)[/color][/size][/center] This release adds experimental support for frame analysis dumps in deferred contexts. If the frame analysis directory only contains a single "log.txt", the game is *NOT* using multi-threaded rendering and you don't need to worry, but if you also see any additional files like "log-0x000000000B6E2350.txt" those correspond to the deferred contexts, and you may wish to enable these options to be able to dump resources from them, which will be placed in subdirectories named like "ctx-0x000000000B6E2350". Two modes are supported: [list] [.]deferred_ctx_accurate: This creates a copy of the resources in memory and waits until the deferred context has finished to dump them to disk. This should allow all of frame analysis' features to work just as they would on the immediate context - showing the progression of render targets (including stereo dumps), dumping accurate constant buffers and so on. Beware that since the resources have to be held in memory it could run out and slow the system down to a crawl - I'm able to use dump_rt in DOAXVV with this option with no problems, but that's likely because I have 32GB of RAM and the dump only consumed 13GB - depending on the game and what options you have chosen a dump could consume hundreds of gigabytes (and de-duplication cannot take place early enough to reduce this), so in general I recommend restricting this option to use only where it is needed, such as setting up a trigger shader, or with the new "dump" command. 32bit games may be particularly limited.[/.] [.]deferred_ctx_immediate: This uses the immediate context to dump the resources (which side steps the memory issue of the accurate version), but beware that this will happen immediately *before* any updates to the resource on the GPU, and may even miss updates from the CPU as these are also deferred. This may be useful to collect static unchanging textures for filtering, but probably not much else - forget trying to use dump_rt with this, and I even found that constant buffers dumped using this option could be out of date, which may or may not matter to you. This option is not thread-safe, and has the potential to cause a crash or interfere with the 3D Vision stereo surface creation mode, and I had half a mind to remove it before release once I got the accurate version working, but decided to leave it in for now and get some feedback on both modes first.[/.] [/list] Note that it is possible that the deferred contexts dumps/log may be missing dumps from early in the frame if the game has started queuing commands to them during the previous frame. I haven't come across this, but there is no reason it couldn't happen. If you suspect it may have, you can try enabling the "hold" option and dumping out two frames instead of one - the second frame's dumps should be complete. [center][size="L"][color="green"]"dump" command[/color][/size][/center] The "dump" command can be used in any command list to instantly dump an arbitrary resource when frame analysis is active, optionally specifying analysis options specific to that resource. The filename will contain the ini section and resource name being dumped. e.g. To collect HUD textures for filtering, instead of dumping all textures you can now dump only the textures in the HUD shader's t0 slot: [code] [ShaderOverrideHUD] hash = xxxxxx dump = mono dds deferred_ctx_accurate ps-t0 [/code] e.g. You can now dump custom resources: [code] [CustomShaderAutoConvergence] ... dump = ResourceAutoConvergenceDepthDownscale128 dump = ResourceAutoConvergenceState dump = ResourceAutoConvergence [/code] e.g. You can now dump resources *before* the draw call, or at other specific times: [code] [CustomShaderCaptureInWorldHUDDepth] depth_write_mask = all ... dump = oD oD = ResourceInWorldHUDDepth dump = oD draw = from_caller dump = oD [/code] [center][size="L"][color="green"]Misc[/color][/size][/center] [list] [.] Dump type and format selection options are now split up - instead of "dump_rt_jps" you now say "dump_rt jps". The former will still work for now, but is considered deprecated and may be removed in the future. Refer to the d3dx.ini for the current options.[/.] [.] New "desc" analysis option to dump resource descriptions to .dsc files (a convenient alternative to finding these in the ShaderUsage.txt)[/.] [.] Fixed draw call numbers in deferred contexts frame analysis log files[/.] [.] analyse_options is now handled by the command list. This should be mostly transparent, but gives more flexibility in what may trigger these.[/.] [.] Fix dump_rt and dump_depth not working if export_usage was disabled[/.] [.] Stereo dumping is automatically disabled when 3D Vision is disabled[/.] [.] Texture filtering hashes now included in the filenames of all dumped resources[/.] [/list] [center][size="M"][color="orange"]Known Limitations[/color][/size][/center][list] [.] Frame Analysis will not dump out 1D and 3D resources as these are not supported by DirectXTK, which we use to create the .dds files. If you need to examine any 3D resources, use my volume debug shaders from WATCH_DOGS2 or Far Cry Primal instead.[/.] [.] Frame Analysis still only supports a limited amount of formats when dumping to .jps, dictated by what the underlying DirectXTK library supports.[/.] [/list]
3Dmigoto 1.3.5

  • New "full_screen_on_key" method to force full screen instantly when a given key is pressed, which can be useful in a game where full_screen doesn't work or causes undesirable side effects.

  • load_library_redirect enabled again by default for out of the box compatibility with CryEngine and other games (Bo3b)

  • New "texture_hash" option to select a new texture hash algorithm that takes the full texture into account making it more resistent to collisions, and discards any padding in the texture that could in some cases cause a hash to be inconsistent. Performance may be lower with this, since it is hashing more of the texture. This should not be enabled when updating an existing fix, as it would break all the texture hashes.

  • Buffers loaded from files can now have their "stride" set, which allows loading vertex buffers from disk (including those dumped out by earlier frame analysis sessions)

  • Support for games using certain newer DirectX APIs

< The Big Frame Analysis Update >

File Deduplication

Frame analysis dumps will now perform much faster and consume far less disk space by detecting identical files and only writing them to disk once. This is especially significant when using dump_tex, but helps with any dumping mode. The "dedupes" folder contains the master copy of each dumped resource, and these are linked back into the main frame analysis folder. Depending on your Operating System, Privileges and Filesystem these will either be symbolic links, hard links or windows shortcuts:

  • Symbolic Links: Enable developer mode in Windows 10 to use these (or run the game as admin, but I don't recommend that). Similar in some ways to Windows shortcuts, but "just works" in any application, and is of particular use with cygwin since these have been standard on Unix forever and scripts can work with these easily. Windows Explorer displays the shortcut arrow on these and correctly shows them as 0 bytes. Removing/renaming the master file will break any links to it, and moving the links to a different directory would also break them.

  • Hard Links: These will appear to be separate files, will not have a shortcut arrow and Windows Explorer will tell you they are taking up far more disk space than they actually are. No restrictions on what you can do with these - rename, move or delete them as you see fit. All links and the original must be deleted to reclaim disk space. Scripts can't locate the master file very easily. If an identical texture is dumped more than 1024 times, 3DMigoto will automatically rotate these so as to not exceed the maximum hard link limit.

  • Windows Shortcuts: Only used if symbolic and hard links are unavailable, such as on FAT32 filesystems. Doesn't work well with cygwin or any application that lacks explicit code to deal with them. Same issues as symbolic links in regards to removing/renaming files, but Windows goes out of its way to try to automatically repair them, so slightly less of an issue.

By default, there is one "dedupes" folder per frame analysis session, but if you intend to perform many frame analysis sessions, you can enable the "share_dupes" option to use a single "FrameAnalysisDeduped" folder instead, which may make subsequent runs faster and consume less disk space, but means you can't just delete a specific frame analysis folder to reclaim the disk space it consumed. This may be of interest when using frame analysis to collect HUD textures or similar many times throughout a game.

The filenames inside the dedupes folder are the hashes of the resources at the time they are dumped, which ordinarily will not match the hashes used for texture filtering (which can be found in the frame analysis filenames *outside* of the dedupes folder, the frame analysis log file, or ShaderUsage.txt). If you're curious they can be made to match - enable the new "texture_hash=1" option (this will change all the texture filtering hashes, so don't do it on an existing fix), ensure you are dumping the resources as "mono" and (if necessary) try enabling "track_texture_updates=1". Only static textures will match - render targets or anything that has been altered after it was created will never match their filtering hash.


Deferred Contexts (AKA Multi-Threaded Rendering)

This release adds experimental support for frame analysis dumps in deferred contexts. If the frame analysis directory only contains a single "log.txt", the game is *NOT* using multi-threaded rendering and you don't need to worry, but if you also see any additional files like "log-0x000000000B6E2350.txt" those correspond to the deferred contexts, and you may wish to enable these options to be able to dump resources from them, which will be placed in subdirectories named like "ctx-0x000000000B6E2350".

Two modes are supported:

  • deferred_ctx_accurate: This creates a copy of the resources in memory and waits until the deferred context has finished to dump them to disk. This should allow all of frame analysis' features to work just as they would on the immediate context - showing the progression of render targets (including stereo dumps), dumping accurate constant buffers and so on. Beware that since the resources have to be held in memory it could run out and slow the system down to a crawl - I'm able to use dump_rt in DOAXVV with this option with no problems, but that's likely because I have 32GB of RAM and the dump only consumed 13GB - depending on the game and what options you have chosen a dump could consume hundreds of gigabytes (and de-duplication cannot take place early enough to reduce this), so in general I recommend restricting this option to use only where it is needed, such as setting up a trigger shader, or with the new "dump" command. 32bit games may be particularly limited.

  • deferred_ctx_immediate: This uses the immediate context to dump the resources (which side steps the memory issue of the accurate version), but beware that this will happen immediately *before* any updates to the resource on the GPU, and may even miss updates from the CPU as these are also deferred. This may be useful to collect static unchanging textures for filtering, but probably not much else - forget trying to use dump_rt with this, and I even found that constant buffers dumped using this option could be out of date, which may or may not matter to you. This option is not thread-safe, and has the potential to cause a crash or interfere with the 3D Vision stereo surface creation mode, and I had half a mind to remove it before release once I got the accurate version working, but decided to leave it in for now and get some feedback on both modes first.

Note that it is possible that the deferred contexts dumps/log may be missing dumps from early in the frame if the game has started queuing commands to them during the previous frame. I haven't come across this, but there is no reason it couldn't happen. If you suspect it may have, you can try enabling the "hold" option and dumping out two frames instead of one - the second frame's dumps should be complete.


"dump" command

The "dump" command can be used in any command list to instantly dump an arbitrary resource when frame analysis is active, optionally specifying analysis options specific to that resource. The filename will contain the ini section and resource name being dumped.

e.g. To collect HUD textures for filtering, instead of dumping all textures you can now dump only the textures in the HUD shader's t0 slot:

[ShaderOverrideHUD]
hash = xxxxxx
dump = mono dds deferred_ctx_accurate ps-t0

e.g. You can now dump custom resources:

[CustomShaderAutoConvergence]
...
dump = ResourceAutoConvergenceDepthDownscale128
dump = ResourceAutoConvergenceState
dump = ResourceAutoConvergence

e.g. You can now dump resources *before* the draw call, or at other specific times:

[CustomShaderCaptureInWorldHUDDepth]
depth_write_mask = all
...
dump = oD
oD = ResourceInWorldHUDDepth
dump = oD
draw = from_caller
dump = oD


Misc

  • Dump type and format selection options are now split up - instead of "dump_rt_jps" you now say "dump_rt jps". The former will still work for now, but is considered deprecated and may be removed in the future. Refer to the d3dx.ini for the current options.

  • New "desc" analysis option to dump resource descriptions to .dsc files (a convenient alternative to finding these in the ShaderUsage.txt)

  • Fixed draw call numbers in deferred contexts frame analysis log files

  • analyse_options is now handled by the command list. This should be mostly transparent, but gives more flexibility in what may trigger these.

  • Fix dump_rt and dump_depth not working if export_usage was disabled

  • Stereo dumping is automatically disabled when 3D Vision is disabled

  • Texture filtering hashes now included in the filenames of all dumped resources


Known Limitations
  • Frame Analysis will not dump out 1D and 3D resources as these are not supported by DirectXTK, which we use to create the .dds files. If you need to examine any 3D resources, use my volume debug shaders from WATCH_DOGS2 or Far Cry Primal instead.

  • Frame Analysis still only supports a limited amount of formats when dumping to .jps, dictated by what the underlying DirectXTK library supports.

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 03/09/2018 06:38 PM   
Nifty. One of the most useful tools available in the 3DMigoto package just got even better. Thanks for the hard work put into this amazing update (among many others). Got a question, somewhat related to this. You've kinda explained in the past about locating and obtaining a useable depth buffer, but I'm still kinda iffy on this, and currently stuck on getting a 3D crosshair working for my Vermintide 2 fix (and also FFXV). By using the auto crosshair code, I'm getting nearly full separation without any variation, and I'm not sure if it's the depth buffer I'm grabbing is wrong, how I'm grabbing it is wrong, or if the code I"m using in the crosshair.hlsl is wrong... so too many variables here and hoping to narrow things down a bit and getting some questions I have answered will hopefully help with that. Is my best approach to use the dump_depth option and do a full frame analysis dump, and somehow determine from the images a decent candidate? In V2, I get a whole bunch of images that mostly red, but I could somewhat see things being added through the frames. I also get another set that is in black and white, but the image is actually divided into 4 quadrants and each one starts getting items filled up into them throughout the scenes. Do either of those tell me anything? Or is my best approach looking through the frame analysis log? I see stuff in there related to depth buffer, and various hashes, but not quite sure how to interpret any of that. Provided I find a candidate, is my best option then to do a ResourceDepthBuffer = oD (which I've never had success with), or is it better to find a texture that is used in the shader for calculating depth and copying that texture slot? (I've only ever had success with this, but of varying degrees) If the latter, what if that depth calculation is done in conjunction with a sampler? ie. r0.w = __tex_linear_depth.Sample(__samp_linear_depth_s, v1.xy).x; I've had no success with copying a sampler (d3dx.ini doesn't even recognize something like ps-s0), and trying to utilize the sample function in the crosshair.hlsl has 3DM spit back an error, something about not supporting a gradient operation (been a while since I tried, and going off memory. I could get the exact error if need be). Also when I've asked you about something similar (when I was working on the FFXIV mouse cursor) you mentioned about the depth buffer I was accessing was likely from the perspective of the light, which I can kinda understand as a concept, but how might this be differentiated from a depth buffer in relation to the camera? Or would that just be plain ol' common sense? Are there any good common candidates for looking for a depth buffer, like an AO shader, or somewhere else that's commonly used? (Edit: Looking back on previous discussion you mentioned Lighting shader being good, and not shadow maps, which are not necessarily easy to distinguish, but I'll go with that) Also, what's the deal with your fancy depth buffer downscaling I've seen you using. What's the point behind that? Also, if I manage to find a good candidate for the depth buffer, and I know for certain I've got the right near and far values (either from extracting from the projection matrix, or having them available as a resource), is the standard return (far*near/((1-z)*near) + (far*z)); a pretty sure thing? As we discussed before, I've also had success using your return camera_projection._m23 / (z + camera_projection._m22); method to work in FFXIV, but not work elsewhere. Again, in most cases where I have trouble, it's usually that they use the sampler method in the shader, so I'm not really able to extract a useable method there. Any other possibilities in this area? And, ummm, what's the difference or pro's & cons of using adjust_from_depth_buffer vs adjust_from_stereo2mono_depth_buffer? Is it more of an accuracy thing, or might one work in some situations better than the other (or possibly one work where the other would not)? Sorry, lots of questions here, they've kinda been building up for a long time and I've almost been afraid to ask since it felt like this should just be basic common knowledge, but yeah, would appreciate any info you could provide here. Edit: I looked back on our previous conversation where you mentioned to try using your fullscreen.hlsl and debug2D.hlsl files from your WatchDogs 2 fix to render what I think the depth buffer is live, and just tried that and got... nothing. I tried: [code] [Present] run = CustomShaderDebug2D ... [ShaderOverridePLight1] hash=5866ec3f15cabbd7 ResourceDebug2D = ref ps-t3 w7 = 1000 [ResourceDebug2D] [CustomShaderDebug2D] vs = ShaderFixes\full_screen.hlsl ps = ShaderFixes\debug_2d.hlsl blend = disable cull = none topology = triangle_strip o0 = bb ps-t100 = ResourceDebug2D Draw = 4, 0 post ps-t100 = null [/code] Am I missing something? I can kinda get the debugCB working (although it kinda glitches as soon as I move the camera), but absolutely no visual change on screen with the debug2D (and also tried DebugVolume since that seemed to be what you were mainly using in your WatchDogs2 d3dx.ini, it seemed).
Nifty. One of the most useful tools available in the 3DMigoto package just got even better. Thanks for the hard work put into this amazing update (among many others).

Got a question, somewhat related to this. You've kinda explained in the past about locating and obtaining a useable depth buffer, but I'm still kinda iffy on this, and currently stuck on getting a 3D crosshair working for my Vermintide 2 fix (and also FFXV). By using the auto crosshair code, I'm getting nearly full separation without any variation, and I'm not sure if it's the depth buffer I'm grabbing is wrong, how I'm grabbing it is wrong, or if the code I"m using in the crosshair.hlsl is wrong... so too many variables here and hoping to narrow things down a bit and getting some questions I have answered will hopefully help with that.

Is my best approach to use the dump_depth option and do a full frame analysis dump, and somehow determine from the images a decent candidate? In V2, I get a whole bunch of images that mostly red, but I could somewhat see things being added through the frames. I also get another set that is in black and white, but the image is actually divided into 4 quadrants and each one starts getting items filled up into them throughout the scenes. Do either of those tell me anything? Or is my best approach looking through the frame analysis log? I see stuff in there related to depth buffer, and various hashes, but not quite sure how to interpret any of that.

Provided I find a candidate, is my best option then to do a ResourceDepthBuffer = oD (which I've never had success with), or is it better to find a texture that is used in the shader for calculating depth and copying that texture slot? (I've only ever had success with this, but of varying degrees) If the latter, what if that depth calculation is done in conjunction with a sampler?
ie. r0.w = __tex_linear_depth.Sample(__samp_linear_depth_s, v1.xy).x;
I've had no success with copying a sampler (d3dx.ini doesn't even recognize something like ps-s0), and trying to utilize the sample function in the crosshair.hlsl has 3DM spit back an error, something about not supporting a gradient operation (been a while since I tried, and going off memory. I could get the exact error if need be).

Also when I've asked you about something similar (when I was working on the FFXIV mouse cursor) you mentioned about the depth buffer I was accessing was likely from the perspective of the light, which I can kinda understand as a concept, but how might this be differentiated from a depth buffer in relation to the camera? Or would that just be plain ol' common sense? Are there any good common candidates for looking for a depth buffer, like an AO shader, or somewhere else that's commonly used? (Edit: Looking back on previous discussion you mentioned Lighting shader being good, and not shadow maps, which are not necessarily easy to distinguish, but I'll go with that)

Also, what's the deal with your fancy depth buffer downscaling I've seen you using. What's the point behind that?

Also, if I manage to find a good candidate for the depth buffer, and I know for certain I've got the right near and far values (either from extracting from the projection matrix, or having them available as a resource), is the standard return (far*near/((1-z)*near) + (far*z)); a pretty sure thing? As we discussed before, I've also had success using your return camera_projection._m23 / (z + camera_projection._m22); method to work in FFXIV, but not work elsewhere. Again, in most cases where I have trouble, it's usually that they use the sampler method in the shader, so I'm not really able to extract a useable method there. Any other possibilities in this area?

And, ummm, what's the difference or pro's & cons of using adjust_from_depth_buffer vs adjust_from_stereo2mono_depth_buffer? Is it more of an accuracy thing, or might one work in some situations better than the other (or possibly one work where the other would not)?

Sorry, lots of questions here, they've kinda been building up for a long time and I've almost been afraid to ask since it felt like this should just be basic common knowledge, but yeah, would appreciate any info you could provide here.


Edit: I looked back on our previous conversation where you mentioned to try using your fullscreen.hlsl and debug2D.hlsl files from your WatchDogs 2 fix to render what I think the depth buffer is live, and just tried that and got... nothing. I tried:

[Present]
run = CustomShaderDebug2D
...

[ShaderOverridePLight1]
hash=5866ec3f15cabbd7
ResourceDebug2D = ref ps-t3
w7 = 1000

[ResourceDebug2D]

[CustomShaderDebug2D]
vs = ShaderFixes\full_screen.hlsl
ps = ShaderFixes\debug_2d.hlsl
blend = disable
cull = none
topology = triangle_strip
o0 = bb
ps-t100 = ResourceDebug2D
Draw = 4, 0
post ps-t100 = null


Am I missing something? I can kinda get the debugCB working (although it kinda glitches as soon as I move the camera), but absolutely no visual change on screen with the debug2D (and also tried DebugVolume since that seemed to be what you were mainly using in your WatchDogs2 d3dx.ini, it seemed).

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 03/09/2018 07:49 PM   
[quote="DJ-RK"]Got a question, somewhat related to this. You've kinda explained in the past about locating and obtaining a useable depth buffer, but I'm still kinda iffy on this, and currently stuck on getting a 3D crosshair working for my Vermintide 2 fix (and also FFXV).[/quote]Well, since FFXV is on the shared accounts, how about I install it and let's work through the process on that together via steam chat or Skype? I do like the forums since they keep a public record and others can hopefully learn from the posts as well, but this one might just be a little too finicky and we'll make faster progress working in real time I think. I don't see you in my friends list on Steam (or maybe I've just forgotten your username) - my username should be pretty easy to guess on both services if you want to add me ;-) [quote]By using the auto crosshair code, I'm getting nearly full separation without any variation, and I'm not sure if it's the depth buffer I'm grabbing is wrong, how I'm grabbing it is wrong, or if the code I"m using in the crosshair.hlsl is wrong... so too many variables here and hoping to narrow things down a bit and getting some questions I have answered will hopefully help with that.[/quote]Yeah, this is a pretty typical problem when adapting it to a new engine - until everything is correct together the results are so far out that it is hard to tell what has gone wrong. Best bet is to just work through everything one at a time - use the debug shaders (or now the "dump" frame analysis command) to check that the depth buffer and any constant buffers you need were sucesfully injected into the crosshair shader then try to work out whether the scaling is working, or if something else is going wrong. [quote]Is my best approach to use the dump_depth option and do a full frame analysis dump, and somehow determine from the images a decent candidate?[/quote]You can, but be wary of seeing a depth buffer used in an effect that can be turned off. e.g. if a game uses HBAO+ you will find a *linear* depth buffer you can use (meaning you don't need to scale it at all), but if a user disables HBAO+ you wouldn't have access to that depth buffer at all. The first place I always check is the deferred lighting shaders, since I'm usually fixing them anyway and and they almost always have a depth buffer input that I'll have already identified during the lighting fix and I can usually rely on them being used. [quote]In V2, I get a whole bunch of images that mostly red, but I could somewhat see things being added through the frames.[/quote]Red can be good - since depth buffers only have one channel they will tend to show as either red or grey, and since they are non-linear it's not uncommon for them to be in the range of "completely red" to "so close to completely red that only females can notice" (women can apparently percieve more shades of red than men, the theory being this was advantageous in the hunter/gatherer period - evolution didn't count on shaderhackers also needing this ability it seems). This is why ddsinfo.py has the --auto-scale option, and if you use the debug shaders you can try adding "result *= result;" half a dozen times or so at the end of the shader as a quick and dirty way of exaggerating the tiny differences. [quote]I also get another set that is in black and white, but the image is actually divided into 4 quadrants and each one starts getting items filled up into them throughout the scenes.[/quote]That sounds more like a cascaded shadow map, and definitely not what you want. [quote]Or is my best approach looking through the frame analysis log? I see stuff in there related to depth buffer, and various hashes, but not quite sure how to interpret any of that.[/quote]Not for this - the frame analysis log is most useful for tracing something throughout a frame (like, if you find a texture input to a shader is broken it might help trace where it came from). [quote]Provided I find a candidate, is my best option then to do a ResourceDepthBuffer = oD (which I've never had success with), or is it better to find a texture that is used in the shader for calculating depth and copying that texture slot? (I've only ever had success with this, but of varying degrees)[/quote]Either can work. I'd recommend going with finding a texture though, since that will generally be easier to copy into the crosshair shader and you can usually copy any constant buffers you need to scale it from the same source, and likely the shader will also have the code you need to scale it. If you do copy it from oD, try the example I provided in this comment (the one with ResourceDepthBufferCopy) to handle the (possibly) necessary copy without killing the fps: [url]https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/5299456/#5299456[/url] In that example I'm using [ClearDepthStencilView] to get access to the depth buffer, but the same thing applies if using a [ShaderOverride] - just change "ref this" to "ref oD". You may well be able to use ClearDepthStencilView to get the depth buffer as in that example, but you need to verify that it is the correct depth buffer - add "dump = ResourceDepthBufferRef" in the HUD shader you are copying it to and run frame analysis, or use the debug shader, and you would still need a way to calculate the linear depth. [quote]If the latter, what if that depth calculation is done in conjunction with a sampler? ie. r0.w = __tex_linear_depth.Sample(__samp_linear_depth_s, v1.xy).x; I've had no success with copying a sampler (d3dx.ini doesn't even recognize something like ps-s0), and trying to utilize the sample function in the crosshair.hlsl has 3DM spit back an error, something about not supporting a gradient operation (been a while since I tried, and going off memory. I could get the exact error if need be).[/quote]The sampler there isn't used for the depth calculation and you can just ignore it - you're interested in the instructions following this, not the sampler itself. All a sampler really does is work out what colour a pixel would be if it's sampled somewhere between two pixels, and a shader can emulate that with only load instructions and an interpolation routine (case in point: mouse.hlsl emulates samplers with four Loads and an interpolation, since none of the DirectX samplers were suitable for mouse cursors). Some day 3DMigoto may get support for copying samplers (they do have some uses that can't be emulated, like dealing with cube maps), but it's very low priority and probably more of interest to non-3D Vision modding. The only other difference I can think of worth mentioning is that a sampler takes a floating point coordiante in the range of 0:1, while a load takes an integer coordinate in the range 0:width/height, but that's easy to scale between them (that's what the GetDimensions call is for in crosshair.hlsl), provided you aren't trying to do so in a compute shader (where GetDimensions crashes the driver). [quote]Also when I've asked you about something similar (when I was working on the FFXIV mouse cursor) you mentioned about the depth buffer I was accessing was likely from the perspective of the light, which I can kinda understand as a concept, but how might this be differentiated from a depth buffer in relation to the camera? Or would that just be plain ol' common sense?[/quote]Here's some examples from The Witcher 3. Firstly, a screenshot of where I was in the game ([Present]dump = bb): [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74753/[/img] Here's the depth buffer we are after from the perspective of the camera (red = depth, green = stencil), scaled with ddsinfo.py --auto-scale: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74752/[/img] Here's another depth buffer from the perspective of the light that we don't want (this is actually mono, but I had stereo dumping enabled): [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74751/[/img] If you can actually see the depth buffer it should be pretty clear whether the perspective matches the camera or not. [quote]Also, what's the deal with your fancy depth buffer downscaling I've seen you using. What's the deal about all that?[/quote]There's two cases I downscale a depth buffer: 1. When using the more accurate stereo2mono version of crosshair.hlsl, as stereo2mono saturates the SLI bus and causes framerate to drop exponentially as the resolution is increased, which becomes significant above 1920x1080. By downscaling the depth buffer prior to running stereo2mono I can minimise the amount of bandwidth required on the SLI bus to eliminate the performance hit. On single GPU systems this makes no difference. If I don't need the accuracy of the stereo2mono version, I'll just use the regular version and forgo any downscaling to keep things simpler. 2. For the auto-convergence shader, since this samples the depth buffer in a lot of places and needs to find the closest point, and downscaling is an efficient way to perform that search and provides the same performance benefit as above for stereo2mono so the auto-convergence shader can consider the depth values from both eyes. [quote]Also, if I manage to find a good candidate for the depth buffer, and I know for certain I've got the right near and far values (either from extracting from the projection matrix, or having them available as a resource), is the standard return (far*near/((1-z)*near) + (far*z)); a pretty sure thing?[/quote]No, it's not - DirectX doesn't do anything to enforce how a game might encode the depth buffer, and there are plenty of variations out in the wild. It might work, but the best bet is always to copy whatever the game does. [quote]As we discussed before, I've also had success using your return camera_projection._m23 / (z + camera_projection._m22); method to work in FFXIV, but not work elsewhere. Again, in most cases where I have trouble, it's usually that they use the sampler method in the shader, so I'm not really able to extract a useable method there.[/quote]The problem won't be the sampler, so I'd go back and have another look at those. [quote]Any other possibilities in this area?[/quote]Yeah - this is my latest strategy - if you can copy the [inverse] projection matrix in this should be pretty solid - I'm not positive if it is actually universal or not, but it is definitely the closest I've come up with so far: [code] float z_to_w(float z) { // This is game specific - adjust as needed. // For DOAXVV we use the inverse projection matrix to derive this (this // approach works in a lot of games if you have some way to get this): float4 tmp = mul(float4(0, 0, z, 1), gInvProjection); return tmp.z / tmp.w; } [/code] If you only have the view-projection (or model-view-projection - anything that ends in "projection" will work) you can do a slight variation - convert to the other coordinate system, normalise, then convert back to projection space and use W as the linear depth. I think this should even work if a game is using reversed-Z projection (near & far are reversed), or when there is no far clipping plane at all (some UE4 games set up their projection matrices like this - attempting to derive the far clipping plane from the projection matrix will result in a divide by zero / infinite, and beware that the same thing may happen while calculating the linear depth with uninitialised portions of the depth buffer with this function, so you may need special handling for z==0 / z==1). [quote]Sorry, lots of questions here, they've kinda been building up for a long time and I've almost been afraid to ask since it felt like this should just be basic common knowledge, but yeah, would appreciate any info you could provide here.[/quote]Definitely not common knowledge. You're a pretty skilled shaderhacker, so if you aren't sure about something it's safe to say that probably no one else is either. [quote]Edit: I looked back on our previous conversation where you mentioned to try using your fullscreen.hlsl and debug2D.hlsl files from your WatchDogs 2 fix to render what I think the depth buffer is live, and just tried that and got... nothing. I tried:[/quote]That's a slightly older version (only by a few days). To make sure it's not an issue I already fixed, change this line: [code] o0 = bb [/code] to: [code] o0 = set_viewport bb [/code] The canonical place to find the latest version of this debug shader is now here: https://github.com/DarkStarSword/3d-fixes/tree/master/custom_shader_debug_2d [quote][code] ResourceDebug2D = ref ps-t3 [/code][/quote]It's probably fine to copy by reference here, but if something isn't working always try the other way as well, especially since performance won't matter for the debug shader. If you were copying oD before the game had finished writing to it copying by reference would be mandatory (and in that case you may need to do a copy at the time you use it, as in the example I linked to earlier), but if the game is using it as a texture it probably already finished all the writes it was going to do, and copying by value avoids potential issues with the game clearing it after this point and before you have seen it in the debug shader (e.g. a game might clear it before the present call), or potential issues if it happened to be bound as an output across the present call. [quote]Am I missing something? I can kinda get the debugCB working (although it kinda glitches as soon as I move the camera), but absolutely no visual change on screen with the debug2D (and also tried DebugVolume since that seemed to be what you were mainly using in your WatchDogs2 d3dx.ini, it seemed). [/quote]Most likely is the depth buffer was not copied in succesfully - debug_2d.hlsl detects the case where no texture is bound and bails out (so the screen isn't blank if there is nothing to see). You can comment out these lines to make sure the shader is running and confirm if that is why you aren't seeing anything: [code] if (!width || !height) discard; [/code] Also, do a frame analysis run while this debug shader is enabled and check the log file - it logs every 3DMigoto command that is executed (search the log for "3DMigoto") and notes anything special that happened - you should be able to see the copy by reference from ShaderOverridePLight1 in the log, and where this is later bound in CustomShaderDebug2D. If you see something like "3DMigoto Copy source was NULL" or "3DMigoto max_copies_per_frame exceeded" where you weren't expecting it that might provide a clue. It won't tell you if binding a resource failed - the DirectX call doesn't tell us, and we'd need to use the DirectX Debug layer to determine this (which would need the DirectX SDK to be installed, so even if we add that it would take some effort to get things set up to see this... but I'm thinking about it, because there is certainly some value in it). Also be aware that if a game is using an MSAA depth buffer the syntax to access it in the shader is slightly different (Texture2DMS and the Load has an extra ",0") - take a look at WATCH_DOGS2 where both MSAA and regular depth buffers are copied separately by 3DMigoto, and the crosshair.hlsl determines which one is currently valid.
DJ-RK said:Got a question, somewhat related to this. You've kinda explained in the past about locating and obtaining a useable depth buffer, but I'm still kinda iffy on this, and currently stuck on getting a 3D crosshair working for my Vermintide 2 fix (and also FFXV).
Well, since FFXV is on the shared accounts, how about I install it and let's work through the process on that together via steam chat or Skype? I do like the forums since they keep a public record and others can hopefully learn from the posts as well, but this one might just be a little too finicky and we'll make faster progress working in real time I think. I don't see you in my friends list on Steam (or maybe I've just forgotten your username) - my username should be pretty easy to guess on both services if you want to add me ;-)

By using the auto crosshair code, I'm getting nearly full separation without any variation, and I'm not sure if it's the depth buffer I'm grabbing is wrong, how I'm grabbing it is wrong, or if the code I"m using in the crosshair.hlsl is wrong... so too many variables here and hoping to narrow things down a bit and getting some questions I have answered will hopefully help with that.
Yeah, this is a pretty typical problem when adapting it to a new engine - until everything is correct together the results are so far out that it is hard to tell what has gone wrong. Best bet is to just work through everything one at a time - use the debug shaders (or now the "dump" frame analysis command) to check that the depth buffer and any constant buffers you need were sucesfully injected into the crosshair shader then try to work out whether the scaling is working, or if something else is going wrong.

Is my best approach to use the dump_depth option and do a full frame analysis dump, and somehow determine from the images a decent candidate?
You can, but be wary of seeing a depth buffer used in an effect that can be turned off. e.g. if a game uses HBAO+ you will find a *linear* depth buffer you can use (meaning you don't need to scale it at all), but if a user disables HBAO+ you wouldn't have access to that depth buffer at all. The first place I always check is the deferred lighting shaders, since I'm usually fixing them anyway and and they almost always have a depth buffer input that I'll have already identified during the lighting fix and I can usually rely on them being used.

In V2, I get a whole bunch of images that mostly red, but I could somewhat see things being added through the frames.
Red can be good - since depth buffers only have one channel they will tend to show as either red or grey, and since they are non-linear it's not uncommon for them to be in the range of "completely red" to "so close to completely red that only females can notice" (women can apparently percieve more shades of red than men, the theory being this was advantageous in the hunter/gatherer period - evolution didn't count on shaderhackers also needing this ability it seems). This is why ddsinfo.py has the --auto-scale option, and if you use the debug shaders you can try adding "result *= result;" half a dozen times or so at the end of the shader as a quick and dirty way of exaggerating the tiny differences.

I also get another set that is in black and white, but the image is actually divided into 4 quadrants and each one starts getting items filled up into them throughout the scenes.
That sounds more like a cascaded shadow map, and definitely not what you want.

Or is my best approach looking through the frame analysis log? I see stuff in there related to depth buffer, and various hashes, but not quite sure how to interpret any of that.
Not for this - the frame analysis log is most useful for tracing something throughout a frame (like, if you find a texture input to a shader is broken it might help trace where it came from).

Provided I find a candidate, is my best option then to do a ResourceDepthBuffer = oD (which I've never had success with), or is it better to find a texture that is used in the shader for calculating depth and copying that texture slot? (I've only ever had success with this, but of varying degrees)
Either can work. I'd recommend going with finding a texture though, since that will generally be easier to copy into the crosshair shader and you can usually copy any constant buffers you need to scale it from the same source, and likely the shader will also have the code you need to scale it.

If you do copy it from oD, try the example I provided in this comment (the one with ResourceDepthBufferCopy) to handle the (possibly) necessary copy without killing the fps:
https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/5299456/#5299456

In that example I'm using [ClearDepthStencilView] to get access to the depth buffer, but the same thing applies if using a [ShaderOverride] - just change "ref this" to "ref oD". You may well be able to use ClearDepthStencilView to get the depth buffer as in that example, but you need to verify that it is the correct depth buffer - add "dump = ResourceDepthBufferRef" in the HUD shader you are copying it to and run frame analysis, or use the debug shader, and you would still need a way to calculate the linear depth.

If the latter, what if that depth calculation is done in conjunction with a sampler?
ie. r0.w = __tex_linear_depth.Sample(__samp_linear_depth_s, v1.xy).x;
I've had no success with copying a sampler (d3dx.ini doesn't even recognize something like ps-s0), and trying to utilize the sample function in the crosshair.hlsl has 3DM spit back an error, something about not supporting a gradient operation (been a while since I tried, and going off memory. I could get the exact error if need be).
The sampler there isn't used for the depth calculation and you can just ignore it - you're interested in the instructions following this, not the sampler itself. All a sampler really does is work out what colour a pixel would be if it's sampled somewhere between two pixels, and a shader can emulate that with only load instructions and an interpolation routine (case in point: mouse.hlsl emulates samplers with four Loads and an interpolation, since none of the DirectX samplers were suitable for mouse cursors). Some day 3DMigoto may get support for copying samplers (they do have some uses that can't be emulated, like dealing with cube maps), but it's very low priority and probably more of interest to non-3D Vision modding. The only other difference I can think of worth mentioning is that a sampler takes a floating point coordiante in the range of 0:1, while a load takes an integer coordinate in the range 0:width/height, but that's easy to scale between them (that's what the GetDimensions call is for in crosshair.hlsl), provided you aren't trying to do so in a compute shader (where GetDimensions crashes the driver).

Also when I've asked you about something similar (when I was working on the FFXIV mouse cursor) you mentioned about the depth buffer I was accessing was likely from the perspective of the light, which I can kinda understand as a concept, but how might this be differentiated from a depth buffer in relation to the camera? Or would that just be plain ol' common sense?
Here's some examples from The Witcher 3. Firstly, a screenshot of where I was in the game ([Present]dump = bb):

Image

Here's the depth buffer we are after from the perspective of the camera (red = depth, green = stencil), scaled with ddsinfo.py --auto-scale:

Image

Here's another depth buffer from the perspective of the light that we don't want (this is actually mono, but I had stereo dumping enabled):

Image

If you can actually see the depth buffer it should be pretty clear whether the perspective matches the camera or not.

Also, what's the deal with your fancy depth buffer downscaling I've seen you using. What's the deal about all that?
There's two cases I downscale a depth buffer:

1. When using the more accurate stereo2mono version of crosshair.hlsl, as stereo2mono saturates the SLI bus and causes framerate to drop exponentially as the resolution is increased, which becomes significant above 1920x1080. By downscaling the depth buffer prior to running stereo2mono I can minimise the amount of bandwidth required on the SLI bus to eliminate the performance hit. On single GPU systems this makes no difference. If I don't need the accuracy of the stereo2mono version, I'll just use the regular version and forgo any downscaling to keep things simpler.

2. For the auto-convergence shader, since this samples the depth buffer in a lot of places and needs to find the closest point, and downscaling is an efficient way to perform that search and provides the same performance benefit as above for stereo2mono so the auto-convergence shader can consider the depth values from both eyes.

Also, if I manage to find a good candidate for the depth buffer, and I know for certain I've got the right near and far values (either from extracting from the projection matrix, or having them available as a resource), is the standard return (far*near/((1-z)*near) + (far*z)); a pretty sure thing?
No, it's not - DirectX doesn't do anything to enforce how a game might encode the depth buffer, and there are plenty of variations out in the wild. It might work, but the best bet is always to copy whatever the game does.

As we discussed before, I've also had success using your return camera_projection._m23 / (z + camera_projection._m22); method to work in FFXIV, but not work elsewhere. Again, in most cases where I have trouble, it's usually that they use the sampler method in the shader, so I'm not really able to extract a useable method there.
The problem won't be the sampler, so I'd go back and have another look at those.

Any other possibilities in this area?
Yeah - this is my latest strategy - if you can copy the [inverse] projection matrix in this should be pretty solid - I'm not positive if it is actually universal or not, but it is definitely the closest I've come up with so far:

float z_to_w(float z)
{
// This is game specific - adjust as needed.
// For DOAXVV we use the inverse projection matrix to derive this (this
// approach works in a lot of games if you have some way to get this):
float4 tmp = mul(float4(0, 0, z, 1), gInvProjection);
return tmp.z / tmp.w;
}

If you only have the view-projection (or model-view-projection - anything that ends in "projection" will work) you can do a slight variation - convert to the other coordinate system, normalise, then convert back to projection space and use W as the linear depth. I think this should even work if a game is using reversed-Z projection (near & far are reversed), or when there is no far clipping plane at all (some UE4 games set up their projection matrices like this - attempting to derive the far clipping plane from the projection matrix will result in a divide by zero / infinite, and beware that the same thing may happen while calculating the linear depth with uninitialised portions of the depth buffer with this function, so you may need special handling for z==0 / z==1).

Sorry, lots of questions here, they've kinda been building up for a long time and I've almost been afraid to ask since it felt like this should just be basic common knowledge, but yeah, would appreciate any info you could provide here.
Definitely not common knowledge. You're a pretty skilled shaderhacker, so if you aren't sure about something it's safe to say that probably no one else is either.

Edit: I looked back on our previous conversation where you mentioned to try using your fullscreen.hlsl and debug2D.hlsl files from your WatchDogs 2 fix to render what I think the depth buffer is live, and just tried that and got... nothing. I tried:
That's a slightly older version (only by a few days). To make sure it's not an issue I already fixed, change this line:

o0 = bb

to:

o0 = set_viewport bb

The canonical place to find the latest version of this debug shader is now here:

https://github.com/DarkStarSword/3d-fixes/tree/master/custom_shader_debug_2d

ResourceDebug2D = ref ps-t3
It's probably fine to copy by reference here, but if something isn't working always try the other way as well, especially since performance won't matter for the debug shader. If you were copying oD before the game had finished writing to it copying by reference would be mandatory (and in that case you may need to do a copy at the time you use it, as in the example I linked to earlier), but if the game is using it as a texture it probably already finished all the writes it was going to do, and copying by value avoids potential issues with the game clearing it after this point and before you have seen it in the debug shader (e.g. a game might clear it before the present call), or potential issues if it happened to be bound as an output across the present call.

Am I missing something? I can kinda get the debugCB working (although it kinda glitches as soon as I move the camera), but absolutely no visual change on screen with the debug2D (and also tried DebugVolume since that seemed to be what you were mainly using in your WatchDogs2 d3dx.ini, it seemed).
Most likely is the depth buffer was not copied in succesfully - debug_2d.hlsl detects the case where no texture is bound and bails out (so the screen isn't blank if there is nothing to see). You can comment out these lines to make sure the shader is running and confirm if that is why you aren't seeing anything:

if (!width || !height)
discard;

Also, do a frame analysis run while this debug shader is enabled and check the log file - it logs every 3DMigoto command that is executed (search the log for "3DMigoto") and notes anything special that happened - you should be able to see the copy by reference from ShaderOverridePLight1 in the log, and where this is later bound in CustomShaderDebug2D. If you see something like "3DMigoto Copy source was NULL" or "3DMigoto max_copies_per_frame exceeded" where you weren't expecting it that might provide a clue. It won't tell you if binding a resource failed - the DirectX call doesn't tell us, and we'd need to use the DirectX Debug layer to determine this (which would need the DirectX SDK to be installed, so even if we add that it would take some effort to get things set up to see this... but I'm thinking about it, because there is certainly some value in it).

Also be aware that if a game is using an MSAA depth buffer the syntax to access it in the shader is slightly different (Texture2DMS and the Load has an extra ",0") - take a look at WATCH_DOGS2 where both MSAA and regular depth buffers are copied separately by 3DMigoto, and the crosshair.hlsl determines which one is currently valid.

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 03/10/2018 10:13 PM   
[quote="DarkStarSword"]...[/quote] This is a thing of beauty. Once again, I can't thank you enough. Not only are you constantly working to improve 3DMigoto in ways in which most of us could never dream of, fixing games and engines which seemed untouchable, but you're also one of the most accessible dispensers of knowledge for us in need (within your own capacity, which understandably can be limited at times, as are all of us). You remind me very much of a particular person... a DJ and music producer based out of Toronto, one of Canada's biggest names in the industry, whom is a man I once idolized beyond measure. As much as I loved everything about his superstar persona, the thing that amazed me the most was how open, humble, and friendly he was to me on every interaction I had with him. Essentially, he made ME feel like the superstar whenever I spoke with him (as he does with everyone, I've gathered). As I started to learn the art of deejaying, I turned to him for support, and he gave it in spades. Over time, both as my skill and our friendship progressed, I looked to him less as a God among men and more as a wise big-brother, and I myself felt more as a peer of relatively comparable equal... a gift of value beyond words, and I feel some parallel here, so I hope this comparison I've made is taken in the form of the highest level of compliment and thanks I could offer. But yeah, had a long day at work so I will need to take some time to read and digest this info (and add it to my wonderful collection of bookmarks, mostly comprised of similar stuff as this from you), and perhaps take you up on the offer to work on the live example with you at some point. I'll add you to Steam post-haste.
DarkStarSword said:...


This is a thing of beauty. Once again, I can't thank you enough. Not only are you constantly working to improve 3DMigoto in ways in which most of us could never dream of, fixing games and engines which seemed untouchable, but you're also one of the most accessible dispensers of knowledge for us in need (within your own capacity, which understandably can be limited at times, as are all of us).

You remind me very much of a particular person... a DJ and music producer based out of Toronto, one of Canada's biggest names in the industry, whom is a man I once idolized beyond measure. As much as I loved everything about his superstar persona, the thing that amazed me the most was how open, humble, and friendly he was to me on every interaction I had with him. Essentially, he made ME feel like the superstar whenever I spoke with him (as he does with everyone, I've gathered). As I started to learn the art of deejaying, I turned to him for support, and he gave it in spades. Over time, both as my skill and our friendship progressed, I looked to him less as a God among men and more as a wise big-brother, and I myself felt more as a peer of relatively comparable equal... a gift of value beyond words, and I feel some parallel here, so I hope this comparison I've made is taken in the form of the highest level of compliment and thanks I could offer.

But yeah, had a long day at work so I will need to take some time to read and digest this info (and add it to my wonderful collection of bookmarks, mostly comprised of similar stuff as this from you), and perhaps take you up on the offer to work on the live example with you at some point. I'll add you to Steam post-haste.

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 03/11/2018 01:53 AM   
+1 I made Paypal donation to DSS
+1

I made Paypal donation to DSS

http://photos.3dvisionlive.com/chtiblue/album/530b52d4cb85770d6e000049/3Dvision with 55" LG OLED EG920 interlieved 3D (3840x2160) overide mode, GTX 2080 Ti XC Ultra EVGA, core i5 @4.3GHz, 16Gb@2130, windows 7&10 64bit, Dolby Atmos 5.1.4 Marantz 6010 AVR

Posted 03/11/2018 12:27 PM   
No idea if this is of any use, anyhow NVIDIA is making available a repository of driver binaries. You can find it here: https://driver-symbols.nvidia.com/ https://developer.nvidia.com/nvidia-driver-symbol-server Problem: During application development you may find yourself looking at a crash report with an attached crash dump - unfortunately there's no guarantee you'll have the same driver installed on your local system as is used in the dump (typically this happens when crash dumps come from QA or end users who are using a different driver), and so you may find yourself unable to accurately resolve the call-stack contained within the dump - a necessary component in figuring out what the bug actually is (and therefore fixing it).
No idea if this is of any use, anyhow

NVIDIA is making available a repository of driver binaries. You can find it here:

https://driver-symbols.nvidia.com/


https://developer.nvidia.com/nvidia-driver-symbol-server


Problem: During application development you may find yourself looking at a crash report with an attached crash dump - unfortunately there's no guarantee you'll have the same driver installed on your local system as is used in the dump (typically this happens when crash dumps come from QA or end users who are using a different driver), and so you may find yourself unable to accurately resolve the call-stack contained within the dump - a necessary component in figuring out what the bug actually is (and therefore fixing it).

Posted 03/12/2018 05:38 AM   
Hello, I'd like to replace a texture in IL2BOs to provide a kind of kneepad, but the idea is to replace it only when a key is pressed, otherwise the standard texture (a map) should be displayed. As I understood in the wiki I can only replace a texture, once for all...Am I wrong ? Edit : I found a way to do it.
Hello, I'd like to replace a texture in IL2BOs to provide a kind of kneepad, but the idea is to replace it only when a key is pressed, otherwise the standard texture (a map) should be displayed.
As I understood in the wiki I can only replace a texture, once for all...Am I wrong ?
Edit : I found a way to do it.

Posted 03/12/2018 09:06 PM   
[quote="lefuneste1"]Edit : I found a way to do it.[/quote] Can you tell me how you did that? So you have assigned a texture replacement in 3Dmigoto to a hotkey?
lefuneste1 said:Edit : I found a way to do it.


Can you tell me how you did that? So you have assigned a texture replacement in 3Dmigoto to a hotkey?

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 03/12/2018 10:43 PM   
Of course, even if is not fineshed yet, the proof of concept is done. Nothing really smart, anyway. At first I created a resource: [code][ResourceReplaceTexture1] filename = ReplacementTextures\foo.jpg [/code] Then I injected it in a new t1 texture in my shader (commented lines remined of previous tests) [code][ShaderOverrideMap] Hash=30a9f954a951f73a ; ResourceCopyTexture = ps-t0 ; ps-t1 = copy ResourceCopyTexture ps-t1 = ResourceReplaceTexture1 checktextureoverride = ps-t1[/code] (I do not check if the line checktexture is needed). And then I check in the shader that the texture can be used instead of the original one [code]// MAP display SamplerState sampler_tex_s : register(s0); Texture2D<float4> tex : register(t0); Texture2D<float4> tex1 : register(t1); // 3Dmigoto declarations #define cmp - Texture1D<float4> IniParams : register(t120); void main( float4 v0 : COLOR0, float2 v1 : TEXCOORD0, out float4 o0 : SV_Target0) { float4 r0; uint4 bitmask, uiDest; float4 fDest; float2 tmp; tmp.xy = v1.xy; r0.xyzw = tex.Sample(sampler_tex_s, v1.xy).xyzw; // r0.xyzw = tex1.Sample(sampler_tex_s, tmp.xy).xyzw; o0.w = v0.w * r0.w; o0.xyz = r0.xyz; // o0.w = 0; return; }[/code] I can manually switch the texture used by commenting the first or second Sample line. So I just need to set up a variable and make a test on 1st value in order to switch original texture use by new texture
Of course, even if is not fineshed yet, the proof of concept is done. Nothing really smart, anyway.
At first I created a resource:
[ResourceReplaceTexture1]
filename = ReplacementTextures\foo.jpg

Then I injected it in a new t1 texture in my shader (commented lines remined of previous tests)
[ShaderOverrideMap]
Hash=30a9f954a951f73a
; ResourceCopyTexture = ps-t0
; ps-t1 = copy ResourceCopyTexture
ps-t1 = ResourceReplaceTexture1
checktextureoverride = ps-t1
(I do not check if the line checktexture is needed).

And then I check in the shader that the texture can be used instead of the original one
// MAP display

SamplerState sampler_tex_s : register(s0);
Texture2D<float4> tex : register(t0);
Texture2D<float4> tex1 : register(t1);


// 3Dmigoto declarations
#define cmp -
Texture1D<float4> IniParams : register(t120);


void main(
float4 v0 : COLOR0,
float2 v1 : TEXCOORD0,
out float4 o0 : SV_Target0)
{
float4 r0;
uint4 bitmask, uiDest;
float4 fDest;
float2 tmp;

tmp.xy = v1.xy;

r0.xyzw = tex.Sample(sampler_tex_s, v1.xy).xyzw;
// r0.xyzw = tex1.Sample(sampler_tex_s, tmp.xy).xyzw;
o0.w = v0.w * r0.w;
o0.xyz = r0.xyz;
// o0.w = 0;
return;
}

I can manually switch the texture used by commenting the first or second Sample line. So I just need to set up a variable and make a test on 1st value in order to switch original texture use by new texture

Posted 03/13/2018 09:37 PM   
[quote="lefuneste1"]Of course, even if is not fineshed yet, the proof of concept is done. Nothing really smart, anyway.[/quote]Yeah, that's the best way to do it at the moment :) [quote]Then I injected it in a new t1 texture in my shader (commented lines remined of previous tests) [code][ShaderOverrideMap] ... checktextureoverride = ps-t1[/code] (I do not check if the line checktexture is needed).[/quote]It won't be necessary for the example you gave, but it is still useful for texture replacements, and you might actually want to consider using it. Technical details: That option enables the command list on the referenced slot - normally 3DMigoto will only run command lists in [ShaderOverride] sections, but not [TextureOverride] sections, because we only have 5 slots to check for command lists on each draw call for shaders (vertex, hull, domain, geometry, pixel), compared to 128*5 texture slots + 8 render target/UAV slots + 1 depth buffer slot + 14 constant buffer slots + 32 vertex buffer slots + 1 index buffer slot + 4 stream output slots = 700 total slots to check *on every draw call* if we wanted to run the command lists in [TextureOverride] sections (more if we enable full DirectX 11.1 support, which has an additional 56 UAV slots). That's a lot and wouldn't perform very well, especially given that in most cases there won't even be any command lists to run. checktextureoverride tells 3DMigoto to check a specific slot for a command list and run it if found to allow command lists on [TextureOverride] sections without killing performance. You can also combine checktextureoverride with with a [ShaderRegex] matching all (pixel) shaders to enable command lists on a given slot globally (like, maybe you want to use handling=skip on a specific index buffer to remove one specific object regardless of which shader it was used with), but if possible I recommend identifying specific shaders for best performance. So, in practice this is how you might use it for texture replacements: [code] [ShaderOverrideMap] Hash=30a9f954a951f73a ; Make sure there is nothing still bound in the replacement texture slot: ps-t1 = null ; Run [TextureOverride] command lists for the original texture slot: checktextureoverride = ps-t0 [ResourceReplaceTexture1] filename = ReplacementTextures\foo.jpg [TextureOverrideToReplace1] hash = xxxxxxxx ps-t1 = ResourceReplaceTexture1 [ResourceReplaceTexture2] filename = ReplacementTextures\bar.jpg [TextureOverrideToReplace2] hash = yyyyyyyy ps-t1 = ResourceReplaceTexture2 [/code] This allows you to load different replacement textures based on what the original texture is (this is effectively uMod for DX11). The checktextureoverride=ps-t0 is what allows the ps-t1=ResourceReplaceTexture lines in the [TextureOverride] sections to be run if their hash matches the texture in ps-t0 (some games may require track_texture_updates for this to be reliable, but it has a steep performance cost, so only enable it if necessary). In this case I'm still loading the replacement in ps-t1 so you can use code in the shader to decide which to use, but you could just as easily assign it to ps-t0 directly if you didn't want the enable/disable functionality in the shader. [quote]And then I check in the shader that the texture can be used instead of the original one ... I can manually switch the texture used by commenting the first or second Sample line. So I just need to set up a variable and make a test on 1st value in order to switch original texture use by new texture[/quote]Yep, you're on the right track there. Just add an IniParam for the toggle and you're golden :) You can also test if a replacement texture has been bound or not inside the shader, which is particularly important if replacing a texture by hash, since you may not have replacements for all possible textures. Something like this should work (assuming you are putting your toggle in iniParams x, and this is also why I added ps-t1=null in the above example, to make sure that nothing was bound in that slot if none of the TextureOverride sections matched): [code] // MAP display SamplerState sampler_tex_s : register(s0); Texture2D<float4> tex : register(t0); Texture2D<float4> tex1 : register(t1); // 3Dmigoto declarations #define cmp - Texture1D<float4> IniParams : register(t120); void main( float4 v0 : COLOR0, float2 v1 : TEXCOORD0, out float4 o0 : SV_Target0) { float4 r0; uint4 bitmask, uiDest; float4 fDest; uint width, height; tex1.GetDimensions(width, height); if (IniParams[0].x && width > 0) { r0.xyzw = tex1.Sample(sampler_tex_s, v1.xy).xyzw; } else { r0.xyzw = tex.Sample(sampler_tex_s, v1.xy).xyzw; } o0.w = v0.w * r0.w; o0.xyz = r0.xyz; return; } [/code] Note: this will not work with compute shaders, where I have learnt the hard way that GetDimensions() will cause a driver crash instead.
lefuneste1 said:Of course, even if is not fineshed yet, the proof of concept is done. Nothing really smart, anyway.
Yeah, that's the best way to do it at the moment :)

Then I injected it in a new t1 texture in my shader (commented lines remined of previous tests)
[ShaderOverrideMap]
...
checktextureoverride = ps-t1
(I do not check if the line checktexture is needed).
It won't be necessary for the example you gave, but it is still useful for texture replacements, and you might actually want to consider using it.

Technical details: That option enables the command list on the referenced slot - normally 3DMigoto will only run command lists in [ShaderOverride] sections, but not [TextureOverride] sections, because we only have 5 slots to check for command lists on each draw call for shaders (vertex, hull, domain, geometry, pixel), compared to 128*5 texture slots + 8 render target/UAV slots + 1 depth buffer slot + 14 constant buffer slots + 32 vertex buffer slots + 1 index buffer slot + 4 stream output slots = 700 total slots to check *on every draw call* if we wanted to run the command lists in [TextureOverride] sections (more if we enable full DirectX 11.1 support, which has an additional 56 UAV slots). That's a lot and wouldn't perform very well, especially given that in most cases there won't even be any command lists to run. checktextureoverride tells 3DMigoto to check a specific slot for a command list and run it if found to allow command lists on [TextureOverride] sections without killing performance. You can also combine checktextureoverride with with a [ShaderRegex] matching all (pixel) shaders to enable command lists on a given slot globally (like, maybe you want to use handling=skip on a specific index buffer to remove one specific object regardless of which shader it was used with), but if possible I recommend identifying specific shaders for best performance.

So, in practice this is how you might use it for texture replacements:

[ShaderOverrideMap]
Hash=30a9f954a951f73a
; Make sure there is nothing still bound in the replacement texture slot:
ps-t1 = null
; Run [TextureOverride] command lists for the original texture slot:
checktextureoverride = ps-t0

[ResourceReplaceTexture1]
filename = ReplacementTextures\foo.jpg
[TextureOverrideToReplace1]
hash = xxxxxxxx
ps-t1 = ResourceReplaceTexture1

[ResourceReplaceTexture2]
filename = ReplacementTextures\bar.jpg
[TextureOverrideToReplace2]
hash = yyyyyyyy
ps-t1 = ResourceReplaceTexture2

This allows you to load different replacement textures based on what the original texture is (this is effectively uMod for DX11). The checktextureoverride=ps-t0 is what allows the ps-t1=ResourceReplaceTexture lines in the [TextureOverride] sections to be run if their hash matches the texture in ps-t0 (some games may require track_texture_updates for this to be reliable, but it has a steep performance cost, so only enable it if necessary). In this case I'm still loading the replacement in ps-t1 so you can use code in the shader to decide which to use, but you could just as easily assign it to ps-t0 directly if you didn't want the enable/disable functionality in the shader.

And then I check in the shader that the texture can be used instead of the original one
...
I can manually switch the texture used by commenting the first or second Sample line. So I just need to set up a variable and make a test on 1st value in order to switch original texture use by new texture
Yep, you're on the right track there. Just add an IniParam for the toggle and you're golden :)

You can also test if a replacement texture has been bound or not inside the shader, which is particularly important if replacing a texture by hash, since you may not have replacements for all possible textures. Something like this should work (assuming you are putting your toggle in iniParams x, and this is also why I added ps-t1=null in the above example, to make sure that nothing was bound in that slot if none of the TextureOverride sections matched):

// MAP display

SamplerState sampler_tex_s : register(s0);
Texture2D<float4> tex : register(t0);
Texture2D<float4> tex1 : register(t1);


// 3Dmigoto declarations
#define cmp -
Texture1D<float4> IniParams : register(t120);

void main(
float4 v0 : COLOR0,
float2 v1 : TEXCOORD0,
out float4 o0 : SV_Target0)
{
float4 r0;
uint4 bitmask, uiDest;
float4 fDest;

uint width, height;

tex1.GetDimensions(width, height);
if (IniParams[0].x && width > 0) {
r0.xyzw = tex1.Sample(sampler_tex_s, v1.xy).xyzw;
} else {
r0.xyzw = tex.Sample(sampler_tex_s, v1.xy).xyzw;
}

o0.w = v0.w * r0.w;
o0.xyz = r0.xyz;
return;
}

Note: this will not work with compute shaders, where I have learnt the hard way that GetDimensions() will cause a driver crash instead.

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 03/13/2018 11:15 PM   
[quote="D-Man11"]No idea if this is of any use, anyhow[/quote]Hmmm... if that actually serves up symbols it might be very useful to work out may have caused crashes we sometimes see out in the driver with no context. I'm not sure it does though - sounds like they are only serving up binaries and wouldn't give any more detail than debugging something on my own system. Their comment on manual stack walking reflects a frustration I have with the Visual Studios debugger - it hides way too much by default. It's like they focussed on all the user friendly bits but neglected to flesh out the lower level debugging tools - I've had to use the raw memory view on multiple occasions to e.g. locate a variable saved somewhere on the stack that wasn't showing up in the GUI. This is particularly frustrating to me because I have written my own tools to do things like dump a mixed kernel & userspace stack from only a JTAG (hardware debugging) interface, decode register bitfields and fill in symbol information from debug info, and perform post-mortem analysis on raw memory & cache dumps extracted from crashed machines to identify hardware bugs (like when a cache line marked valid and clean != memory - that was fun). Having the right tools (and experience) here can make all the difference between this taking minutes or weeks, and I find their tools lacking - not terrible - they are a lot better than some I've used (the worst could initially access memory but not registers, and after enabling register access (which required the CPU clock be stopped) could no longer access memory with no way to switch back, which is a problem for dumping the stack where you need registers first, then memory second), but lacking.
D-Man11 said:No idea if this is of any use, anyhow
Hmmm... if that actually serves up symbols it might be very useful to work out may have caused crashes we sometimes see out in the driver with no context. I'm not sure it does though - sounds like they are only serving up binaries and wouldn't give any more detail than debugging something on my own system.

Their comment on manual stack walking reflects a frustration I have with the Visual Studios debugger - it hides way too much by default. It's like they focussed on all the user friendly bits but neglected to flesh out the lower level debugging tools - I've had to use the raw memory view on multiple occasions to e.g. locate a variable saved somewhere on the stack that wasn't showing up in the GUI. This is particularly frustrating to me because I have written my own tools to do things like dump a mixed kernel & userspace stack from only a JTAG (hardware debugging) interface, decode register bitfields and fill in symbol information from debug info, and perform post-mortem analysis on raw memory & cache dumps extracted from crashed machines to identify hardware bugs (like when a cache line marked valid and clean != memory - that was fun). Having the right tools (and experience) here can make all the difference between this taking minutes or weeks, and I find their tools lacking - not terrible - they are a lot better than some I've used (the worst could initially access memory but not registers, and after enabling register access (which required the CPU clock be stopped) could no longer access memory with no way to switch back, which is a problem for dumping the stack where you need registers first, then memory second), but lacking.

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 03/13/2018 11:39 PM   
I linked some other feature updates from Nvidia in that dx12 thread [url]https://forums.geforce.com/default/topic/1037433/3d-vision/directx-12/post/5303814/#5303814[/url] None of this stuff is within my knowledge base, my mind is simple. But I still like to check out Nvidia's blog, I find it interesting, even though it's all French to me. https://developer.nvidia.com/gameworks/blog
I linked some other feature updates from Nvidia in that dx12 thread
https://forums.geforce.com/default/topic/1037433/3d-vision/directx-12/post/5303814/#5303814

None of this stuff is within my knowledge base, my mind is simple. But I still like to check out Nvidia's blog, I find it interesting, even though it's all French to me.

https://developer.nvidia.com/gameworks/blog

Posted 03/14/2018 03:08 AM   
[center][color="orange"][size="XL"]3Dmigoto 1.3.6[/size] [/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center] [size="L"][color="green"]Frame Analysis[/color][/size][list] [.]Dumped resources now use the fully typed format from the views rather than the possibly typeless format from the resource, resulting in: [list] [.]Many resources can now be dumped as JPS that previously could only be dumped as DDS, meaning faster frame analysis sessions and easier files to work with[/.] [.]Many dumped DDS files will now have better compatibility with third party tools (including texconv from DirectXTex, and the DDS plugin for The GIMP), and Windows 10 seems to now be able to display thumbnails for many of these (however note that my ddsinfo.py will need updates to cope with these)[/.] [/list]The specific format used is now included in the deduped filename, since there may be multiple formats used for a single resource.[/.] [.]Frame analysis can now be aborted early by pressing F8 a second time (or releasing it early if using the hold mode). The overlay will indicate this and in the case of hold mode will indicate how many complete frames were dumped (which may be zero, if the button was released before the first frame had finished).[/.] [.]The overlay now confirms when frame analysis has completed and lists the frame analysis directory[/.] [.]The frame analysis log file now lists each resource being dumped or skipped, including the filename and deduplicated filename. Frame analysis messages are now prefixed with "3DMigoto" (same as the command list messages) to make them easy to search for.[/.] [.]StereoParams is no longer dumped[/.] [.]Fixed edge case where share_dupes and deferred_ctx wouldn't work together properly if deferred_ctx was not set globally[/.] [/list] [size="L"][color="green"]Misc[/color][/size][list] [.]Fixed regression introduced in v1.3.3 breaking forced full screen in Batman: Telltale[/.] [.]Fixed crash in draw=from_caller if the game used DrawAuto() or explicitly tried to draw nothing at all[/.] [.]New "stereo_active" ini param override (rarely needed as separation=0 usually implies this with some weird exceptions that masterotaku discovered like StereoFullHKConfig being enabled. Will be used by the soon to be updated auto-convergence shader in DOAXVV and LISBTS to handle specific edge cases on alt+tab)[/.] [.]The [Constants] section is now a command list run when the game starts and the config is reloaded, allowing for more complicated one-time initialisation[/.] [.]The main overlay is now drawn with an outline around each character to make them easier to read in games using bright pastel colours.[/.] [.]The main overlay now reports the convergence to two decimal places, since that level of precision can still make a noticeable difference.[/.] [.]Fixed issue where the overlay notifications could cause rendering artefacts in certain games (e.g. Elite Dangerous)[/.] [.]Numerous refcounting bugs fixed[/.] [/list]
3Dmigoto 1.3.6

Frame Analysis
  • Dumped resources now use the fully typed format from the views rather than the possibly typeless format from the resource, resulting in:
    • Many resources can now be dumped as JPS that previously could only be dumped as DDS, meaning faster frame analysis sessions and easier files to work with

    • Many dumped DDS files will now have better compatibility with third party tools (including texconv from DirectXTex, and the DDS plugin for The GIMP), and Windows 10 seems to now be able to display thumbnails for many of these (however note that my ddsinfo.py will need updates to cope with these)
    The specific format used is now included in the deduped filename, since there may be multiple formats used for a single resource.

  • Frame analysis can now be aborted early by pressing F8 a second time (or releasing it early if using the hold mode). The overlay will indicate this and in the case of hold mode will indicate how many complete frames were dumped (which may be zero, if the button was released before the first frame had finished).

  • The overlay now confirms when frame analysis has completed and lists the frame analysis directory

  • The frame analysis log file now lists each resource being dumped or skipped, including the filename and deduplicated filename. Frame analysis messages are now prefixed with "3DMigoto" (same as the command list messages) to make them easy to search for.

  • StereoParams is no longer dumped

  • Fixed edge case where share_dupes and deferred_ctx wouldn't work together properly if deferred_ctx was not set globally

Misc
  • Fixed regression introduced in v1.3.3 breaking forced full screen in Batman: Telltale

  • Fixed crash in draw=from_caller if the game used DrawAuto() or explicitly tried to draw nothing at all

  • New "stereo_active" ini param override (rarely needed as separation=0 usually implies this with some weird exceptions that masterotaku discovered like StereoFullHKConfig being enabled. Will be used by the soon to be updated auto-convergence shader in DOAXVV and LISBTS to handle specific edge cases on alt+tab)

  • The [Constants] section is now a command list run when the game starts and the config is reloaded, allowing for more complicated one-time initialisation

  • The main overlay is now drawn with an outline around each character to make them easier to read in games using bright pastel colours.

  • The main overlay now reports the convergence to two decimal places, since that level of precision can still make a noticeable difference.

  • Fixed issue where the overlay notifications could cause rendering artefacts in certain games (e.g. Elite Dangerous)

  • Numerous refcounting bugs fixed

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 03/14/2018 06:04 AM   
  128 / 143    
Scroll To Top