3Dmigoto now open-source...
  139 / 141    
I'm assuming you have "filename_reg" enabled to get filenames that look like that? Those numbers just count how many draw calls there have been in the frame so far, so they tend to vary a lot and it's not something we expose to check against anywhere (we could add it, but I'm not sure it would actually be of much help in practice). If you are trying to match a particular iteration of a texture you can keep your own counter during the frame, e.g. you might do something like this: [code] [Present] ; Reset the counter each frame: x = 0 [ShaderOverrideFoo] hash = xxxxxx checktextureoverride = ps-t0 [TextureOverrideBar] hash = 12345678 x = x + 1 if x == 2 ; Do something for the 2nd texture drawn with this shader+texture combo endif [/code]
I'm assuming you have "filename_reg" enabled to get filenames that look like that?

Those numbers just count how many draw calls there have been in the frame so far, so they tend to vary a lot and it's not something we expose to check against anywhere (we could add it, but I'm not sure it would actually be of much help in practice).

If you are trying to match a particular iteration of a texture you can keep your own counter during the frame, e.g. you might do something like this:

[Present]
; Reset the counter each frame:
x = 0

[ShaderOverrideFoo]
hash = xxxxxx
checktextureoverride = ps-t0

[TextureOverrideBar]
hash = 12345678
x = x + 1
if x == 2
; Do something for the 2nd texture drawn with this shader+texture combo
endif

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

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

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

Posted 12/04/2018 05:33 PM   
i currently using the dedubed folder and using the hash here and search for this in the log file and this often reveal another hash as original that i have to use.
i currently using the dedubed folder and using the hash here and search for this in the log file and this often reveal another hash as original that i have to use.

Like my work? Donations can be made via PayPal to: rauti@inetmx.de

Posted 12/04/2018 07:01 PM   
[quote="DarkStarSword"][quote="DarkStarSword"]@Losti: This is an alternate to deny_cpu_read for CryEngine that performs better - this is from Lichdom, so it may be a different shader in KDC (or possibly other differences - let me know if you have trouble).[/quote]Here's an update to this that will hopefully eliminate any remaining flickering and can hopefully be adapted to solve your occlusion culling issues in Dead Rising as well. Whereas my prior attempt merged the left and right depth buffers together into some sort of weird hybrid, this attempt de-stereoises the depth buffer in a sort of reverse-compatibility mode operation so that the depth values should line up with what the game is expecting. Once again this is from Lichdom, so may have to be adapted for KCD and Dead Rising. I've put together two versions of this - one is more accurate, but uses some expensive atomic operations and two shaders, while the second skips those expensive operations to save performance at the cost of some corruption on the resulting depth buffer - whether that will be enough to matter or not I can't say, but it seems fine where I'm testing in Lichdom. I had some rather unexpected results using UAVs with pixel shaders while setting this up - the pixel shader ran for both eyes insofar as the bound depth buffer (ps-t0) and render target (o0) were concerned, but both eyes ended up writing to just the right eye's view of the UAV (ps-u1). I've ended up exploiting that a little below, but it's worth checking if the debug output looks correct in case there are any differences for you. For reference I had SLI *enabled* while doing this and StereoFlagsDX10 set to 0x00000008 (either of which could conceivably affect this, though I haven't experimented with different options as yet). . . . . . [/quote] amazing....i think but i am too stupid to implement it....getting error compiling custom shader difning this and create the HLSLS files you provide: [code] [ShaderOverrideFlicker] hash = 73efe2bcbef48f11 ; This shader downscales the depth buffer prior to sending it to the CPU for ; occlusion culling. The CPU will only get a mono copy, which results in ; incorrect occlusion culling and appears as flickering geometry in the ; distance that is just to the right of something in the foreground. ; if stereo_active ; CHOOSE ONE (FIXME: I should switch this over to "post" for better ; performance, but that changes which binds are used in a few places ; and I wanted this closer to what will be required for Dead Rising): run = CustomShaderOcclusionCullingFlattenDepthBufferWithAtomicOps ;run = CustomShaderOcclusionCullingFlattenDepthBufferRaceCondition endif ; The depth buffer used for occlusion culling is a weird scale that complicates ; finding the linear depth. Grab the regular depth target instead: [ResourceZBuffer] [ClearDepthStencilView] ResourceZBuffer = ref this [ResourceOcclusionCullingFlattenDepthBufferUint] ; This resource is used for atomic operations to avoid race conditions, and ; must be a uint. It seems (rather unexpectedly, and possibly due to a driver ; bug) that when used as a pixel shader UAV both eyes will write to just one ; side of this buffer if it is forced stereo, so may as well just keep it mono: format = R32_UINT mode = mono [ResourceOcclusionCullingFlattenDepthBufferFloat] ; This buffer serves two purposes: ; 1. During the first flattening stage it's width, height and stereo determines ; how many pixel shader invocations will run, but the pixel shader will not ; write to it. We want depth values to be combined from both eyes, so we set ; it stereo. ; 2. This buffer is written to by the second shader that translates the ; normalised depth values in the uint buffer back to the original floating ; point range that the game is expecting. Since this has already been ; reduced to mono in phase 1 we would only need mono for this, but requiring ; stereo for 1. trumps this. ; Part of the reason these two purposes are conflated in a single buffer is in ; part due to DirectX API limitations - if we bind a different o0 for the ; second shader, DirectX will unbind ps-u1. That's not a show stopper, but it ; would mean having to perform a bit of a dance to get things where we want ; them, and having this one buffer serve two purposes allows us to skip ; changing any of the render target or UAV binds between shaders. mode = stereo [CustomShaderOcclusionCullingFlattenDepthBufferWithAtomicOps] ; This shader will take a stereo depth buffer and perform a sort of ; reverse-compatibility mode transformation on it to move the depth values to ; their mono locations so that once the occlusion culling buffer is read out on ; the CPU things will more or less match up with what it expects. ps = ShaderFixes\cryengine_occlusion_culling_flatten_depth_buffer.hlsl ; ; We only want to invoke this once during the downscaling process. Dead ; Rising's frame analysis looks like there are two indenendent occlusion ; culling buffers being read out, so this should possibly be removed for that ; game: max_executions_per_frame = 1 ; ; ps-t0 already contains the depth buffer we need to flatten (game specific) ; ; Create our UAVs and render targets to match the depth buffer size in ps-t0: ResourceOcclusionCullingFlattenDepthBufferUint = copy_desc ps-t0 ResourceOcclusionCullingFlattenDepthBufferFloat = copy_desc ps-t0 ; ; Clear the flattened depth buffer we are using as a UAV: clear = ResourceOcclusionCullingFlattenDepthBufferUint 0 ; ; Remove any potentially incompatible render targets: run = BuiltInCommandListUnbindAllRenderTargets ; ; o0 must be set to a resource the same size as the depth buffer we are working ; on as this determines how many pixel shader invocations will run, even though ; this shader does not actually write to it: o0 = set_viewport ResourceOcclusionCullingFlattenDepthBufferFloat ; ; Bind the flattened depth buffer as a UAV to allow the pixel shader to draw ; arbitrary pixels rather than just SV_Target: ps-u1 = ResourceOcclusionCullingFlattenDepthBufferUint ; ; Bind the PER_FRAME constant buffer to get the view-projection matrix and ; calculate linear depth (game specific): ps-cb13 = vs-cb3 ; ; Bind the depth buffer used to calculate the linear depth (but in this game's ; case not the same depth values we will be passing to the CPU): ps-t100 = ResourceZBuffer ; ; Invoke the flattening shader: draw = from_caller ; ; Load up the shader for the next stage with o0 and ps-u1 still bound: post run = CustomShaderOcclusionCullingDenormaliseDepthBuffer [CustomShaderOcclusionCullingDenormaliseDepthBuffer] ; This shader converts the normalised depth values back to the range the game is after. ;ps = ShaderFixes\cryengine_occlusion_culling_denormalise_depth_buffer.hlsl ; ; ps-u1 is still bound with the normalised flattened depth buffer and o0 is ; still bound with the floating point flattened depth buffer (see above for an ; explanation). ; ; Invoke the denormalising shader: draw = from_caller ; ; Bind the output back to the input for the game to use in the next stage. ; Since DirectX forbids resources being bound as both input and output ; simultaneously we unbind it from o0 first (or, if we did this outside the ; CustomShader we could rely on 3DMigoto having restored the original o0): post o0 = null post ps-t0 = ResourceOcclusionCullingFlattenDepthBufferFloat ; ; Clean up anything we bound that 3DMigoto won't automatically restore (the ; CustomShader section will take care of restoring o0 and ps-u1) post ps-cb13 = null post ps-t100 = null ; ; Optional debugging to view the resulting flattened depth buffer: ;post Resource\ShaderFixes\debug_2d.ini\Debug2D = ref ResourceOcclusionCullingFlattenDepthBufferFloat [/code]
DarkStarSword said:
DarkStarSword said:@Losti: This is an alternate to deny_cpu_read for CryEngine that performs better - this is from Lichdom, so it may be a different shader in KDC (or possibly other differences - let me know if you have trouble).
Here's an update to this that will hopefully eliminate any remaining flickering and can hopefully be adapted to solve your occlusion culling issues in Dead Rising as well. Whereas my prior attempt merged the left and right depth buffers together into some sort of weird hybrid, this attempt de-stereoises the depth buffer in a sort of reverse-compatibility mode operation so that the depth values should line up with what the game is expecting. Once again this is from Lichdom, so may have to be adapted for KCD and Dead Rising.

I've put together two versions of this - one is more accurate, but uses some expensive atomic operations and two shaders, while the second skips those expensive operations to save performance at the cost of some corruption on the resulting depth buffer - whether that will be enough to matter or not I can't say, but it seems fine where I'm testing in Lichdom.

I had some rather unexpected results using UAVs with pixel shaders while setting this up - the pixel shader ran for both eyes insofar as the bound depth buffer (ps-t0) and render target (o0) were concerned, but both eyes ended up writing to just the right eye's view of the UAV (ps-u1). I've ended up exploiting that a little below, but it's worth checking if the debug output looks correct in case there are any differences for you. For reference I had SLI *enabled* while doing this and StereoFlagsDX10 set to 0x00000008 (either of which could conceivably affect this, though I haven't experimented with different options as yet).
.
.
.
.
.


amazing....i think but i am too stupid to implement it....getting error compiling custom shader difning this and create the HLSLS files you provide:

[ShaderOverrideFlicker]
hash = 73efe2bcbef48f11
; This shader downscales the depth buffer prior to sending it to the CPU for
; occlusion culling. The CPU will only get a mono copy, which results in
; incorrect occlusion culling and appears as flickering geometry in the
; distance that is just to the right of something in the foreground.
;
if stereo_active
; CHOOSE ONE (FIXME: I should switch this over to "post" for better
; performance, but that changes which binds are used in a few places
; and I wanted this closer to what will be required for Dead Rising):
run = CustomShaderOcclusionCullingFlattenDepthBufferWithAtomicOps
;run = CustomShaderOcclusionCullingFlattenDepthBufferRaceCondition
endif

; The depth buffer used for occlusion culling is a weird scale that complicates
; finding the linear depth. Grab the regular depth target instead:
[ResourceZBuffer]
[ClearDepthStencilView]
ResourceZBuffer = ref this




[ResourceOcclusionCullingFlattenDepthBufferUint]
; This resource is used for atomic operations to avoid race conditions, and
; must be a uint. It seems (rather unexpectedly, and possibly due to a driver
; bug) that when used as a pixel shader UAV both eyes will write to just one
; side of this buffer if it is forced stereo, so may as well just keep it mono:
format = R32_UINT
mode = mono
[ResourceOcclusionCullingFlattenDepthBufferFloat]
; This buffer serves two purposes:
; 1. During the first flattening stage it's width, height and stereo determines
; how many pixel shader invocations will run, but the pixel shader will not
; write to it. We want depth values to be combined from both eyes, so we set
; it stereo.
; 2. This buffer is written to by the second shader that translates the
; normalised depth values in the uint buffer back to the original floating
; point range that the game is expecting. Since this has already been
; reduced to mono in phase 1 we would only need mono for this, but requiring
; stereo for 1. trumps this.
; Part of the reason these two purposes are conflated in a single buffer is in
; part due to DirectX API limitations - if we bind a different o0 for the
; second shader, DirectX will unbind ps-u1. That's not a show stopper, but it
; would mean having to perform a bit of a dance to get things where we want
; them, and having this one buffer serve two purposes allows us to skip
; changing any of the render target or UAV binds between shaders.
mode = stereo

[CustomShaderOcclusionCullingFlattenDepthBufferWithAtomicOps]
; This shader will take a stereo depth buffer and perform a sort of
; reverse-compatibility mode transformation on it to move the depth values to
; their mono locations so that once the occlusion culling buffer is read out on
; the CPU things will more or less match up with what it expects.
ps = ShaderFixes\cryengine_occlusion_culling_flatten_depth_buffer.hlsl
;
; We only want to invoke this once during the downscaling process. Dead
; Rising's frame analysis looks like there are two indenendent occlusion
; culling buffers being read out, so this should possibly be removed for that
; game:
max_executions_per_frame = 1
;
; ps-t0 already contains the depth buffer we need to flatten (game specific)
;
; Create our UAVs and render targets to match the depth buffer size in ps-t0:
ResourceOcclusionCullingFlattenDepthBufferUint = copy_desc ps-t0
ResourceOcclusionCullingFlattenDepthBufferFloat = copy_desc ps-t0
;
; Clear the flattened depth buffer we are using as a UAV:
clear = ResourceOcclusionCullingFlattenDepthBufferUint 0
;
; Remove any potentially incompatible render targets:
run = BuiltInCommandListUnbindAllRenderTargets
;
; o0 must be set to a resource the same size as the depth buffer we are working
; on as this determines how many pixel shader invocations will run, even though
; this shader does not actually write to it:
o0 = set_viewport ResourceOcclusionCullingFlattenDepthBufferFloat
;
; Bind the flattened depth buffer as a UAV to allow the pixel shader to draw
; arbitrary pixels rather than just SV_Target:
ps-u1 = ResourceOcclusionCullingFlattenDepthBufferUint
;
; Bind the PER_FRAME constant buffer to get the view-projection matrix and
; calculate linear depth (game specific):
ps-cb13 = vs-cb3
;
; Bind the depth buffer used to calculate the linear depth (but in this game's
; case not the same depth values we will be passing to the CPU):
ps-t100 = ResourceZBuffer
;
; Invoke the flattening shader:
draw = from_caller
;
; Load up the shader for the next stage with o0 and ps-u1 still bound:
post run = CustomShaderOcclusionCullingDenormaliseDepthBuffer
[CustomShaderOcclusionCullingDenormaliseDepthBuffer]
; This shader converts the normalised depth values back to the range the game is after.
;ps = ShaderFixes\cryengine_occlusion_culling_denormalise_depth_buffer.hlsl
;
; ps-u1 is still bound with the normalised flattened depth buffer and o0 is
; still bound with the floating point flattened depth buffer (see above for an
; explanation).
;
; Invoke the denormalising shader:
draw = from_caller
;
; Bind the output back to the input for the game to use in the next stage.
; Since DirectX forbids resources being bound as both input and output
; simultaneously we unbind it from o0 first (or, if we did this outside the
; CustomShader we could rely on 3DMigoto having restored the original o0):
post o0 = null
post ps-t0 = ResourceOcclusionCullingFlattenDepthBufferFloat
;
; Clean up anything we bound that 3DMigoto won't automatically restore (the
; CustomShader section will take care of restoring o0 and ps-u1)
post ps-cb13 = null
post ps-t100 = null
;
; Optional debugging to view the resulting flattened depth buffer:
;post Resource\ShaderFixes\debug_2d.ini\Debug2D = ref ResourceOcclusionCullingFlattenDepthBufferFloat

Like my work? Donations can be made via PayPal to: rauti@inetmx.de

Posted 12/04/2018 07:40 PM   
[quote="DarkStarSword"]I'm assuming you have "filename_reg" enabled to get filenames that look like that? Those numbers just count how many draw calls there have been in the frame so far, so they tend to vary a lot and it's not something we expose to check against anywhere (we could add it, but I'm not sure it would actually be of much help in practice). If you are trying to match a particular iteration of a texture you can keep your own counter during the frame, e.g. you might do something like this: [code] [Present] ; Reset the counter each frame: x = 0 [ShaderOverrideFoo] hash = xxxxxx checktextureoverride = ps-t0 [TextureOverrideBar] hash = 12345678 x = x + 1 if x == 2 ; Do something for the 2nd texture drawn with this shader+texture combo endif [/code][/quote] Thanks, assigning unique values to the x variable inside ShaderOverrides and checking its value in corresponding TextureOverrides took care of the problems that I had with textures overwriting each other.
DarkStarSword said:I'm assuming you have "filename_reg" enabled to get filenames that look like that?

Those numbers just count how many draw calls there have been in the frame so far, so they tend to vary a lot and it's not something we expose to check against anywhere (we could add it, but I'm not sure it would actually be of much help in practice).

If you are trying to match a particular iteration of a texture you can keep your own counter during the frame, e.g. you might do something like this:

[Present]
; Reset the counter each frame:
x = 0

[ShaderOverrideFoo]
hash = xxxxxx
checktextureoverride = ps-t0

[TextureOverrideBar]
hash = 12345678
x = x + 1
if x == 2
; Do something for the 2nd texture drawn with this shader+texture combo
endif


Thanks, assigning unique values to the x variable inside ShaderOverrides and checking its value in corresponding TextureOverrides took care of the problems that I had with textures overwriting each other.

Posted 12/06/2018 03:29 AM   
Hi mates, I finished 3d fix using 3d migoto for Outcast: Second Contact going ahead from the Andrey Shulzhenko's fix here: [url]https://forums.geforce.com/default/topic/1028843/?comment=5268339[/url]. Using 3dmigoto 1.2.67. All things were fixed finally (shaders, hud, water reflections etc)... but i have a problem...the fix is absolutely ok when using hunting=1. If I disable the hunting (hunting=0 or 2) the shadows are not in place. Another fact, and perhaps here is the main clue for the problem, is that when using hunting=1 the game start as it was in a major resolution (using a lg passive in interlace mode 1920x1080, fullscreen). Then I close the game and start again. Now the screen is ok and the 3d fix runs as intend. Note that this screen size/resolution issue only occurs when using hunting=1. I tried also 3dmigoto 1.3x... the game start already with the correct screen size/resolution ...but now even using hunting=1 the 3d fix is not ok (shadows are out the place). Any help? Im not at my home now, later i can upload the fix here and post some pics. And also excuse me by my english, its not my native language. Thanks in any advice!
Hi mates,

I finished 3d fix using 3d migoto for Outcast: Second Contact going ahead from the Andrey Shulzhenko's fix here: https://forums.geforce.com/default/topic/1028843/?comment=5268339. Using 3dmigoto 1.2.67. All things were fixed finally (shaders, hud, water reflections etc)... but i have a problem...the fix is absolutely ok when using hunting=1. If I disable the hunting (hunting=0 or 2) the shadows are not in place. Another fact, and perhaps here is the main clue for the problem, is that when using hunting=1 the game start as it was in a major resolution (using a lg passive in interlace mode 1920x1080, fullscreen). Then I close the game and start again. Now the screen is ok and the 3d fix runs as intend. Note that this screen size/resolution issue only occurs when using hunting=1.
I tried also 3dmigoto 1.3x... the game start already with the correct screen size/resolution ...but now even using hunting=1 the 3d fix is not ok (shadows are out the place). Any help?
Im not at my home now, later i can upload the fix here and post some pics. And also excuse me by my english, its not my native language.
Thanks in any advice!

Posted 12/10/2018 03:15 PM   
Can you try a few different versions of 3DMigoto 1.3.x to narrow down which version the behaviour changed in? And yes, please do upload the fix, some screenshots of the issue, and the d3d11_log.txt
Can you try a few different versions of 3DMigoto 1.3.x to narrow down which version the behaviour changed in?

And yes, please do upload the fix, some screenshots of the issue, and the d3d11_log.txt

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

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

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

Posted 12/10/2018 05:05 PM   
Here some pics syde by side and in interleave (1920x1080). The correct ones were made using 3dmigoto 1.2.67 with hunting=1. The wrong ones were taken with hunting=0 or 2. Note that 3dmigoto 1.2.67 and hunting=1 start the game with wrong screen size (i dont know why) and IMO this is exactly what makes the difference here. I tried 1.273, 1.3x (various versions) and all then start the game with correct screen size and always with wrong 3d dont matters hunting settings. I just want to release the fix using last stable 3dmigoto with hunting=0 for public but cant do it by these exposed reasons. [url]https://www.dropbox.com/s/fjxbnf4bqqx7isj/OC4.png?dl=0[/url] [url]https://www.dropbox.com/s/579oq6r30sb45r9/OC41.png?dl=0[/url] [url]https://www.dropbox.com/s/swiyos7s544zrg8/OC2.png?dl=0[/url] [url]https://www.dropbox.com/s/h8ytt40y03g59vc/OC21.png?dl=0[/url]
Here some pics syde by side and in interleave (1920x1080). The correct ones were made using 3dmigoto 1.2.67 with hunting=1. The wrong ones were taken with hunting=0 or 2. Note that 3dmigoto 1.2.67 and hunting=1 start the game with wrong screen size (i dont know why) and IMO this is exactly what makes the difference here. I tried 1.273, 1.3x (various versions) and all then start the game with correct screen size and always with wrong 3d dont matters hunting settings. I just want to release the fix using last stable 3dmigoto with hunting=0 for public but cant do it by these exposed reasons.

https://www.dropbox.com/s/fjxbnf4bqqx7isj/OC4.png?dl=0
https://www.dropbox.com/s/579oq6r30sb45r9/OC41.png?dl=0

https://www.dropbox.com/s/swiyos7s544zrg8/OC2.png?dl=0
https://www.dropbox.com/s/h8ytt40y03g59vc/OC21.png?dl=0

Posted 12/11/2018 02:22 AM   
Here the fix: [url]https://www.dropbox.com/s/8ucd7j6fpt5ejp3/OutcastSC_StereoFix_1_1b.7z?dl=0[/url]

Posted 12/11/2018 02:27 AM   
[quote="arubinig"]Note that 3dmigoto 1.2.67 and hunting=1 start the game with wrong screen size[/quote] That helps narrow things down, but there are still several remaining possibilities - to work out which I'll need to to check the behaviour in 1.2.68, 1.2.69, 1.2.70, 1.2.71 and 1.2.72*. Please let me know the behaviour of both the screen size and whether the fix works with hunting=1 in each version - I suspect that those are actually two separate issues. Looking at your fix I gather this is a Unity game? Can you please let me know which version this is - right click on the executable -> Properties -> Details, and let me know the "File Version", "Product Version" and give me the exact file size of the executable in bytes. I may also need a copy of the d3d11_log.txt and a frame analysis log taken with a recent version of 3DMigoto (1.3.12) to check some other possibilities. Also, which version of Windows are you running? (and if Windows 7, is KB 2670838 installed?) This may make a difference to which Rendering APIs and feature levels Unity is trying to use. * 1.2.68 possibilities [b]- No longer forcing StereoParams to be bound on every draw call[/b] (note related bug fixes in 1.2.68 & 1.2.72) - Bug fixes in Overlay (hunting=1) + Hunting mode using wrong DirectX object when hooking - Frame analysis separated from context introduces new differences between hunting=0/1/2 (note reverted in 1.2.70, reintroduced in 1.3.1) 1.2.69 possibilities [b]- Bug fixes to prevent StereoParams being unbound in certain games[/b] - Forcefully disabled newer DirectX APIs exclusive to Windows 10 to fix crashes in games using them - Fixed theoretical refcounting bug on games using shader libraries (no known games actually use this) - Merged certain data structures together - Fixed shaders getting mixed up on reload 1.2.70 possibilities - Undid separation of frame analysis from context - [b]Fixed hunting overlay bug interfering with resolution changes (very likely related to the resolution issue)[/b] - Significant changes to TextureOverrides 1.2.71 possibilities - Fixed bug in upscaling that could potentially interfere with resolution changes, and other upscaling issues - Update hooking library - Improved refresh rate overrides to work with UE4 games 1.2.72 possibilities - Fixed upscaling bug using wrong DirectX object when hooking [b]- Fixed games using multi-threaded rendering from being able to unbind StereoParams[/b] 1.2.73 possibilities - Fixed major bug where outdated shader caches (ShaderFixes/*.bin) could override newer shader .txt files - Changes to try to force usable filesystem permissions when dumping shaders - Changed default load_library_redirect behaviour So as you can see I need you to narrow down the exact 3DMigoto version(s) that the behaviour changed in so I can work out which possibilities are the most likely.
arubinig said:Note that 3dmigoto 1.2.67 and hunting=1 start the game with wrong screen size

That helps narrow things down, but there are still several remaining possibilities - to work out which I'll need to to check the behaviour in 1.2.68, 1.2.69, 1.2.70, 1.2.71 and 1.2.72*. Please let me know the behaviour of both the screen size and whether the fix works with hunting=1 in each version - I suspect that those are actually two separate issues.

Looking at your fix I gather this is a Unity game? Can you please let me know which version this is - right click on the executable -> Properties -> Details, and let me know the "File Version", "Product Version" and give me the exact file size of the executable in bytes.

I may also need a copy of the d3d11_log.txt and a frame analysis log taken with a recent version of 3DMigoto (1.3.12) to check some other possibilities.

Also, which version of Windows are you running? (and if Windows 7, is KB 2670838 installed?)
This may make a difference to which Rendering APIs and feature levels Unity is trying to use.


*
1.2.68 possibilities
- No longer forcing StereoParams to be bound on every draw call (note related bug fixes in 1.2.68 & 1.2.72)
- Bug fixes in Overlay (hunting=1) + Hunting mode using wrong DirectX object when hooking
- Frame analysis separated from context introduces new differences between hunting=0/1/2 (note reverted in 1.2.70, reintroduced in 1.3.1)

1.2.69 possibilities
- Bug fixes to prevent StereoParams being unbound in certain games
- Forcefully disabled newer DirectX APIs exclusive to Windows 10 to fix crashes in games using them
- Fixed theoretical refcounting bug on games using shader libraries (no known games actually use this)
- Merged certain data structures together
- Fixed shaders getting mixed up on reload

1.2.70 possibilities
- Undid separation of frame analysis from context
- Fixed hunting overlay bug interfering with resolution changes (very likely related to the resolution issue)
- Significant changes to TextureOverrides

1.2.71 possibilities
- Fixed bug in upscaling that could potentially interfere with resolution changes, and other upscaling issues
- Update hooking library
- Improved refresh rate overrides to work with UE4 games

1.2.72 possibilities
- Fixed upscaling bug using wrong DirectX object when hooking
- Fixed games using multi-threaded rendering from being able to unbind StereoParams

1.2.73 possibilities
- Fixed major bug where outdated shader caches (ShaderFixes/*.bin) could override newer shader .txt files
- Changes to try to force usable filesystem permissions when dumping shaders
- Changed default load_library_redirect behaviour

So as you can see I need you to narrow down the exact 3DMigoto version(s) that the behaviour changed in so I can work out which possibilities are the most likely.

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

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

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

Posted 12/11/2018 05:51 AM   
Thanks by the help mate. When come back to home i will look at your directions above. For now just few infos and a new clue to narrow the problem. Yes, its a Unity game, running windows 7 64bits (more info later). Yesterday at night i noticed that the problem is really not related to the hunting settings. if I start the game (with any of the tested 3dmigoto), alt+tab, and then quit the game by right click on its icon on the windows bar (close program), then restart...voila...the 3dfix will be ok. Like I said, this is true for any 3dmigoto version tested, dont matters what hunting settings are. (just alt+tab or just change resolutions dont work, its always neeed to quit the game first). What was happening with 3dmigoto 1.2.67 with hunting=1 is that as it start the game with wrong resolution i was quiting the game and then restarting again. So, now is clear that quit and restart is that makes the 3dfix works correctly.
Thanks by the help mate. When come back to home i will look at your directions above.

For now just few infos and a new clue to narrow the problem. Yes, its a Unity game, running windows 7 64bits (more info later).

Yesterday at night i noticed that the problem is really not related to the hunting settings. if I start the game (with any of the tested 3dmigoto), alt+tab, and then quit the game by right click on its icon on the windows bar (close program), then restart...voila...the 3dfix will be ok. Like I said, this is true for any 3dmigoto version tested, dont matters what hunting settings are. (just alt+tab or just change resolutions dont work, its always neeed to quit the game first).

What was happening with 3dmigoto 1.2.67 with hunting=1 is that as it start the game with wrong resolution i was quiting the game and then restarting again. So, now is clear that quit and restart is that makes the 3dfix works correctly.

Posted 12/11/2018 01:53 PM   
Since it's a Unity game, have you tried the "-window-mode exclusive" launch parameter?
Since it's a Unity game, have you tried the "-window-mode exclusive" launch parameter?

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

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

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

Posted 12/11/2018 02:17 PM   
Hi mate! Good news! "-window-mode exclusive" didn't worked and sometimes lead to halt on the game screen load. But then I searched the net and find this one: "-screen-fullscreen 1" that works flawlessly. All 3dmigoto versions tested (including 1.3.12) are now working and hunting settings don't matter - as it must be . The problem was really (and only) related to that old Unity issue with fullscreen...and i never saw this type of issue before - the game enters in 3d normally but is just a bit offset until we find a way to fix the fullscreen issue!! Well, now the fix is ready! Just for curiosity Unity engine build: 5.6.3, KB2670838 is installed. As things are going well now, do you think that is a good idea to actualize the game 3dmigoto for the last one 1.3.12 to be released on Helix blog? I'm asking because I'm new on shader hacker univerve and also read on 3dmigoto GitHub repository that the stable version is 1.2.73. Many thanks by the help!!
Hi mate!

Good news! "-window-mode exclusive" didn't worked and sometimes lead to halt on the game screen load. But then I searched the net and find this one: "-screen-fullscreen 1" that works flawlessly. All 3dmigoto versions tested (including 1.3.12) are now working and hunting settings don't matter - as it must be . The problem was really (and only) related to that old Unity issue with fullscreen...and i never saw this type of issue before - the game enters in 3d normally but is just a bit offset until we find a way to fix the fullscreen issue!!

Well, now the fix is ready!
Just for curiosity Unity engine build: 5.6.3, KB2670838 is installed.

As things are going well now, do you think that is a good idea to actualize the game 3dmigoto for the last one 1.3.12 to be released on Helix blog? I'm asking because I'm new on shader hacker univerve and also read on 3dmigoto GitHub repository that the stable version is 1.2.73.

Many thanks by the help!!

Posted 12/11/2018 08:09 PM   
1.3.12 is stable, and you should generally always use the latest version to make sure you have all the latest bug fixes and features.
1.3.12 is stable, and you should generally always use the latest version to make sure you have all the latest bug fixes and features.

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

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

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

Posted 12/11/2018 08:21 PM   
[quote="DarkStarSword"]1.3.12 is stable, and you should generally always use the latest version to make sure you have all the latest bug fixes and features.[/quote] Ok! Its already done, will be over 1.3.12 Thanks again!!
DarkStarSword said:1.3.12 is stable, and you should generally always use the latest version to make sure you have all the latest bug fixes and features.

Ok! Its already done, will be over 1.3.12
Thanks again!!

Posted 12/11/2018 08:59 PM   
3dmigoto dumped a mesh like this instead of triangle_list 3_control_point_patchlist SV_POSITION TEXCOORD NORMAL TANGENT BINORMAL COLOR BLENDWEIGHT BLENDINDICES Do you think it's possible to convert that to a triangle_list for that blender import script? I assume SV_POSITION is vertex coordinates, TEXCOORD is UV. Is the rest of it useless stuff? :)
3dmigoto dumped a mesh like this instead of triangle_list

3_control_point_patchlist

SV_POSITION
TEXCOORD
NORMAL
TANGENT
BINORMAL
COLOR
BLENDWEIGHT
BLENDINDICES

Do you think it's possible to convert that to a triangle_list for that blender import script? I assume SV_POSITION is vertex coordinates, TEXCOORD is UV. Is the rest of it useless stuff? :)

Posted 12/14/2018 05:37 AM   
  139 / 141    
Scroll To Top