A patch list indicates that it is using tessellated geometry where the triangles are generated on the fly in a hull+domain shader on the GPU - SV_Position will likely be control points for a bezier curve rather than precise positions to place a vertex, and I'd probably have to look at this specific case to see what we could do here.
In some ways it might be easier to add geometry stream output support to 3DMigoto to capture the geometry after the tessellation stage - that is on my TODO list, but I've never had a pressing need for it so it's quite low priority.
Tessellation is usually reserved for things like terrain or water - what are you trying to import?
It's also something that can often be disabled by lowering the graphics settings in a lot of games.
A patch list indicates that it is using tessellated geometry where the triangles are generated on the fly in a hull+domain shader on the GPU - SV_Position will likely be control points for a bezier curve rather than precise positions to place a vertex, and I'd probably have to look at this specific case to see what we could do here.
In some ways it might be easier to add geometry stream output support to 3DMigoto to capture the geometry after the tessellation stage - that is on my TODO list, but I've never had a pressing need for it so it's quite low priority.
Tessellation is usually reserved for things like terrain or water - what are you trying to import?
It's also something that can often be disabled by lowering the graphics settings in a lot of games.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="DarkStarSword"]A patch list indicates that it is using tessellated geometry where the triangles are generated on the fly in a hull+domain shader on the GPU - SV_Position will likely be control points for a bezier curve rather than precise positions to place a vertex, and I'd probably have to look at this specific case to see what we could do here.
In some ways it might be easier to add geometry stream output support to 3DMigoto to capture the geometry after the tessellation stage - that is on my TODO list, but I've never had a pressing need for it so it's quite low priority.
Tessellation is usually reserved for things like terrain or water - what are you trying to import?
It's also something that can often be disabled by lowering the graphics settings in a lot of games.[/quote]
It's an armor mesh. I also dumped it with ninjaripper and got an editable mesh, but unlike 3dmigoto there's no re-import back into the game in ninjaripper. When I tried disabling tesselation 3dmigoto still dumped the same thing.
DarkStarSword said:A patch list indicates that it is using tessellated geometry where the triangles are generated on the fly in a hull+domain shader on the GPU - SV_Position will likely be control points for a bezier curve rather than precise positions to place a vertex, and I'd probably have to look at this specific case to see what we could do here.
In some ways it might be easier to add geometry stream output support to 3DMigoto to capture the geometry after the tessellation stage - that is on my TODO list, but I've never had a pressing need for it so it's quite low priority.
Tessellation is usually reserved for things like terrain or water - what are you trying to import?
It's also something that can often be disabled by lowering the graphics settings in a lot of games.
It's an armor mesh. I also dumped it with ninjaripper and got an editable mesh, but unlike 3dmigoto there's no re-import back into the game in ninjaripper. When I tried disabling tesselation 3dmigoto still dumped the same thing.
Hi mates. I´m fixing "Air Missions Hind" and all is going well but the game has some noticeable "triangle flicker" at the screen edges... i can recall that i already saw this issue in some others 3d fix games too. So i think that this is something related to 3d vision itself or related to 3dmigoto i really don't know. Perhaps this is a simple issue but that i don't know how to fix ...Any idea?
I'm using 3dmigoto 1.3.12, passive lg monitor 1920x1080, win7, gtx 1070. This game runs in dx11 x32.
Thanks in any advice!
Hi mates. I´m fixing "Air Missions Hind" and all is going well but the game has some noticeable "triangle flicker" at the screen edges... i can recall that i already saw this issue in some others 3d fix games too. So i think that this is something related to 3d vision itself or related to 3dmigoto i really don't know. Perhaps this is a simple issue but that i don't know how to fix ...Any idea?
I'm using 3dmigoto 1.3.12, passive lg monitor 1920x1080, win7, gtx 1070. This game runs in dx11 x32.
Thanks in any advice!
It's fairly common for objects to disappear right near the edge of the screen in 3D Vision due to "frustum culling" - the game thinks the objects are not visible so it just doesn't render them, though I'm not entirely sure if that's what you mean by "triangle flicker". The driver has a built in hot key to cycle two methods to hide it (something + F11 - I can't check right now because the nvidia control panel is being stupid and I don't want to reboot to fix it), either by stretching the image or covering it with black bars.
Depending on exactly what is disappearing you may or may not be able to solve it by editing shaders - if entire objects are disappearing all at once you won't, but that's usually pretty visually minor and easy to ignore. If it's something that is being partially cut off (like the sky, water or terrain) you might be able to edit the shaders to try to do something about it. A formula that works well for *some* of these cases (by stretching the effect) is:
[code]
separation = StereoParams.Load(0).x;
o0.x = o0.x * (1 + separation);
[/code]
assuming o0 is SV_Position in the vertex shader.
It's fairly common for objects to disappear right near the edge of the screen in 3D Vision due to "frustum culling" - the game thinks the objects are not visible so it just doesn't render them, though I'm not entirely sure if that's what you mean by "triangle flicker". The driver has a built in hot key to cycle two methods to hide it (something + F11 - I can't check right now because the nvidia control panel is being stupid and I don't want to reboot to fix it), either by stretching the image or covering it with black bars.
Depending on exactly what is disappearing you may or may not be able to solve it by editing shaders - if entire objects are disappearing all at once you won't, but that's usually pretty visually minor and easy to ignore. If it's something that is being partially cut off (like the sky, water or terrain) you might be able to edit the shaders to try to do something about it. A formula that works well for *some* of these cases (by stretching the effect) is:
[quote="DarkStarSword"]It's fairly common for objects to disappear right near the edge of the screen in 3D Vision due to "frustum culling" - the game thinks the objects are not visible so it just doesn't render them, though I'm not entirely sure if that's what you mean by "triangle flicker". The driver has a built in hot key to cycle two methods to hide it (something + F11 - I can't check right now because the nvidia control panel is being stupid and I don't want to reboot to fix it), either by stretching the image or covering it with black bars.
Depending on exactly what is disappearing you may or may not be able to solve it by editing shaders - if entire objects are disappearing all at once you won't, but that's usually pretty visually minor and easy to ignore. If it's something that is being partially cut off (like the sky, water or terrain) you might be able to edit the shaders to try to do something about it. A formula that works well for *some* of these cases (by stretching the effect) is:
[code]
separation = StereoParams.Load(0).x;
o0.x = o0.x * (1 + separation);
[/code]
assuming o0 is SV_Position in the vertex shader.[/quote]
Thanks by the tip mate!
Yes, it's mainly the terrain. Well in truth perhaps for small parts of any object that appears at the edges.
It's a small glitch, i will look at some shaders to test your formula. Will post my finds later.
Thanks again!
DarkStarSword said:It's fairly common for objects to disappear right near the edge of the screen in 3D Vision due to "frustum culling" - the game thinks the objects are not visible so it just doesn't render them, though I'm not entirely sure if that's what you mean by "triangle flicker". The driver has a built in hot key to cycle two methods to hide it (something + F11 - I can't check right now because the nvidia control panel is being stupid and I don't want to reboot to fix it), either by stretching the image or covering it with black bars.
Depending on exactly what is disappearing you may or may not be able to solve it by editing shaders - if entire objects are disappearing all at once you won't, but that's usually pretty visually minor and easy to ignore. If it's something that is being partially cut off (like the sky, water or terrain) you might be able to edit the shaders to try to do something about it. A formula that works well for *some* of these cases (by stretching the effect) is:
Thanks by the tip mate!
Yes, it's mainly the terrain. Well in truth perhaps for small parts of any object that appears at the edges.
It's a small glitch, i will look at some shaders to test your formula. Will post my finds later.
Thanks again!
Hi DarkStarSword,
I can confirm that the main issue is with the terrain. Vegetation and building also pop up at the edges but its not a big issue. Using nvidia crtl+f11 obviously "fix" the problem just because it cut off the borders but as we know isn't a real solution and its a bad one. I tried your code suggestion above without success. But i'm not sure if i put it in the correct place on the VS code. So I attached the terrain VS...can you look at it for me? I will then test it here. Thanks again!
[url]https://www.dropbox.com/s/x03vrame0a5gji9/terrain_VS.7z?dl=0[/url]
I can confirm that the main issue is with the terrain. Vegetation and building also pop up at the edges but its not a big issue. Using nvidia crtl+f11 obviously "fix" the problem just because it cut off the borders but as we know isn't a real solution and its a bad one. I tried your code suggestion above without success. But i'm not sure if i put it in the correct place on the VS code. So I attached the terrain VS...can you look at it for me? I will then test it here. Thanks again! https://www.dropbox.com/s/x03vrame0a5gji9/terrain_VS.7z?dl=0
Terrain is unfortunately probably not going to work with that formula - it would work for flat surfaces like sky and water where the stretching won't cause any adverse issues, but terrain has 3D detail that would become misaligned with the objects on it.
Looking at the shader there is probably nothing you can do to fix it - there is no height map or any other way to reconstruct the missing terrain. At best you could maybe fudge it by filling in the side of the screen with something less distracting - possibly a solid colour or gradient, maybe some fake terrain or duplicating the terrain pass first stretched with z buffer writes off to fill in the side then the original shader to fill in the rest, or injecting a shader that stretches out the pixels at the side of the screen.
I don't have examples to point you to for any of these - they are purely theoretical, and attempting any one of them would be quite advanced and would probably still not look very good.
Terrain is unfortunately probably not going to work with that formula - it would work for flat surfaces like sky and water where the stretching won't cause any adverse issues, but terrain has 3D detail that would become misaligned with the objects on it.
Looking at the shader there is probably nothing you can do to fix it - there is no height map or any other way to reconstruct the missing terrain. At best you could maybe fudge it by filling in the side of the screen with something less distracting - possibly a solid colour or gradient, maybe some fake terrain or duplicating the terrain pass first stretched with z buffer writes off to fill in the side then the original shader to fill in the rest, or injecting a shader that stretches out the pixels at the side of the screen.
I don't have examples to point you to for any of these - they are purely theoretical, and attempting any one of them would be quite advanced and would probably still not look very good.
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
That is far ahead of my knowledge and as you said the result can be not be that good. It's a pity that 3dvision didn't really fix this issue inside the driver. I started the question in a hope of a easy fix that i yet did not known about.
I also have Tridef and it also works very well with this game (the hud and all screen info are at screen depth, this is why i started the fix with 3dmigoto) and the interesting thing is that with tridef this issue is almost absent. Perhaps Tridef fix this issue on the fly or just cut off a bit but without stretching or black bars and the result is much more natural.
Anyway isn't a big issue. The game is almost 100% fixed and it's very fun! Thanks mate by your help and to support this community!
That is far ahead of my knowledge and as you said the result can be not be that good. It's a pity that 3dvision didn't really fix this issue inside the driver. I started the question in a hope of a easy fix that i yet did not known about.
I also have Tridef and it also works very well with this game (the hud and all screen info are at screen depth, this is why i started the fix with 3dmigoto) and the interesting thing is that with tridef this issue is almost absent. Perhaps Tridef fix this issue on the fly or just cut off a bit but without stretching or black bars and the result is much more natural.
Anyway isn't a big issue. The game is almost 100% fixed and it's very fun! Thanks mate by your help and to support this community!
[center][color="orange"][size="XL"]3Dmigoto 1.3.14[/size]
[/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center]
[center][size="L"][color="green"]User Input No Longer Processed While Alt+Tabbed Out[/color][/size][/center]
Enable the new "check_foreground_window = 1" option in the d3dx.ini to ignore input whenever the game window is not in the foreground. Please test this and let me know if you find any game where it [i]doesn't[/i] work, as I would like to make it the default in the future but I need to know that I'm not about to break input in some games first.
[center][size="L"][color="green"]Named Global Variables[/color][/size][/center]
You can declare unlimited named global variables in the [Constants] section, e.g.
[code]
[Constants]
global $costume_mods = 1
global $shadow_mode = 1
global $shader_type
[/code]
The optional initialises here can only set simple initial values (unlike the equivalent in local variables these are not assignment commands - this allows variables declared in an included ini file to be set from the d3dx.ini [Constants] section), so if you wanted something more sophisticated than a boring old number, just add an assignment right under them, e.g.
[code]
global $start_time
$start_time = time
[/code]
Once declared the variables can be used in any command list, [Key] binding or [Preset], e.g.
[code]
[KeyShadows]
Key = shift F2
type = cycle
$shadow_mode = 0, 2, 1
run = CommandListShadowsOrig, CommandListShadowsOff, CommandListShadowsOn
[ShaderOverrideShadow]
hash = 7afeeb590579796f
$shader_type = 5
if $costume_mods && $shadow_mode == 1
...
endif
[/code]
These variables are namespaced by the ini file they were declared in. To access a variable declared in a different ini file specify the full namespace:
[code]
$\ShaderFixes\3dvision2sbs.ini\mode = 5
[/code]
[center][size="L"][color="green"]Persistent Settings[/color][/size][/center]
You can declare global variables as persist(ent), which will automatically save them to a d3dx_user.ini file whenever F10 (or whatever is bound to reload_config) is pressed or when the game is exited (without crashing):
[code]
[Constants]
global persist $costume_mods = 1
global persist $shadow_mode = 1
[/code]
You can use the wipe_user_config key binding (Ctrl+Alt+F10 in the template d3dx.ini) to delete the d3dx_user.ini file and reload the config - you might want to do this e.g. to double check what a new user would see launching the game for the first time, to get rid of warnings about undeclared variables after deleting a persistent variable, or just to discard any saved settings.
If you need to do any initialisation after the d3dx_user.ini has been loaded you can use post commands in the [Constants] command list, e.g.
[code]
[Constants]
global persist $shadow_mode = 1
; Remind user if they saved shadows in off or original state:
post run = CommandListShadowsMsg
[CommandListShadowsMsg]
; To remind user of the current setting on launch / reload
if $shadow_mode == 0
run = CommandListShadowsOrig
elif $shadow_mode == 2
run = CommandListShadowsOff
;elif $shadow_mode == 1
; run = CommandListShadowsOn
endif
[/code]
IniParams cannot (yet) be saved persistently in this manner, but you can achieve this fairly easily if you keep the IniParam and a global variable synchronised, e.g.
[code]
[Constants]
global persist $saved_x2
post x2 = $saved_x2
[KeySetX2]
key = x
type = cycle
x2 = 1, 2, 3
$saved_x2 = 1, 2, 3
[/code]
Likewise, convergence is not automatically saved as yet, but you may be able to achieve this via something like:
[code]
[Constants]
global persist $saved_convergence
post convergence = $saved_convergence
[Present]
post $saved_convergence = convergence
[/code]
Note that depending on how the game handles it's windows and full screen mode on launch this may be ineffective if the convergence is restored too early. Don't forget that the user can always use Ctrl+F7 to save their convergence in the driver profile (if StereoProfile is set), and this will be restored regardless of what dances the application does with it's windows and full screen mode so don't try to do anything too fancy if that will suffice.
[center][size="L"][color="green"]Local Variables[/color][/size][/center]
While global variables have to be declared in [Constants], local variables can be declared in any command list but are only accessible within that command list. Their values will persist between the pre and post phases of the command list, making them suitable for backing up and restoring an IniParam across a draw call, e.g.
[code]
[CustomShaderDebug2D]
...
local $bak_x = x
local $bak_y = y
x = $amplify
y = $flip
Draw = 4, 0
post x = $bak_x
post y = $bak_y
[/code]
There is a small distinction from global variables in the initialiser - that is an assignment command and can therefore assign the variable to the result of any expression in one go rather than requiring a second line. If the initialiser is omitted the variable will be declared without being assigned and will remember the last value it held (or 0).
For the programmers out there, note that these local variables are like "static" variables in other languages - they are scoped locally, but there is only ever a single instance of each - this allows them to maintain their value between the pre and post phases, but limits their use in certain recursive algorithms or potentially some multi-threaded cases. I do have some unmerged code to add stack allocated local variables for those cases, so if there is ever a need for this let me know.
[center][size="L"][color="green"]IniParams[/color][/size][/center]
The cap of 8x4 IniParams has been removed - 3DMigoto will now automatically make IniParams exactly large enough to fit the highest variable index you used, though if you go above 255x4 (= 4KB, one full page of memory) it will notify you that seems a little excessive (but won't stop you either).
Note that there is some small overhead every time an IniParam is changed as 3DMigoto has to send the new values to the GPU, and this overhead will scale with the largest IniParam variable index you used and how often IniParams are updated each frame. This should usually be fairly minimal, and 3DMigoto does automatically do some optimisations to reduce this cost (such as merging batches of IniParams updates together), but if you used a large variable number or updated IniParams an excessive number of times each frame it could start impacting performance - you can keep an eye on the number of IniParams updates per frame and the current size of IniParams on the summary page of the performance monitor.
[.]The 3DVision2SBS and software mouse shaders shipped with 3DMigoto no longer use any IniParams (they do, but they back up and restore the previous values), so you no longer need to worry about which IniParams you can and can't use. I've also given the debug, help text / notification and auto-convergence shaders in my 3d-fixes repo the same treatment.[/.]
[center][size="L"][color="green"][Key] type=cycle Improvements[/color][/size][/center]
Key binding cycles are now smarter, and will try to synchronise themselves to the current state of the variables / IniParams / stereo settings that they affect - this is particularly designed to work well with persistent global variables, but is also useful for any case where a variable of any type may be set by several different things.
e.g. if you had a cycle key binding that cycles x between 0,1,2,3,4,5,6,7,8,9 and last set x to 3, but then something else sets x to 7 then pressing this key again will cycle x to 8 (previously it would have resumed at 4). This works so long as the settings in one of the cycles matches the current reality (e.g. if something else set x to 20 it could not resync as that is not an option in the cycle and would continue from wherever it was last in the cycle).
Consider using these instead of type=toggle when you are toggling between two specific values (type=toggle is still useful when you want to be able to restore a previous value without knowing what it is).
This is now the new default behaviour, but if you wanted the old behaviour for some reason add "smart = false" to the [Key] section.
Additionally:
[list]
[.]Character limits have been removed from type=cycle options in case you want very long cycles, or specify separate command lists to run for each phase[/.]
[.]If a command list is used with a type=cycle/activate key binding, the post phase will be delayed until after transitions have run for the current frame. If there is no transition the post phase should be able to see the newly set values from the key binding.[/.]
[/list]
[center][size="L"][color="green"]3DMigoto Overlay in SBS / TAB / 3D Vision Direct[/color][/size][/center]
The 3DMigoto hunting and performance overlays will now work correctly in SBS/TAB output modes. A new "special = draw_3dmigoto_overlay" command has been added to the command list to facilitate drawing the 3DMigoto overlay at an arbitrary time, allowing it to be drawn before the 3DVision2SBS shader has converted the output mode. This same command can also be used to make the 3DMigoto overlay render in both eyes in games that use 3D Vision Direct:
[code]
[Present]
direct_mode_eye = left
special = draw_3dmigoto_overlay
direct_mode_eye = right
special = draw_3dmigoto_overlay
[/code]
In fact, somewhat related to this we can actually use 3DMigoto to fix the one-eye Steam overlay issue in 3D Vision direct games as well:
[code]
[System]
hook = recommended
[ShaderOverrideSteamOverlay]
hash = 730f4315d7549467
direct_mode_eye = left
draw = from_caller
direct_mode_eye = right
draw = from_caller
handling = skip
[/code]
[center][size="L"][color="green"]else if[/color][/size][/center]
The command list finally has "else if" (or "elif" for short / Python enthusiasts) flow control, so you no longer need to nest ifs inside else blocks.
[center][size="L"][color="green"]Custom [Resource] initial data= improvements[/color][/size][/center]
The data= line now tolerates extra whitespace between items, and now supports a text initialiser. This allows text buffers to be specified easily in the d3dx.ini (e.g. for use with my help text & notification shader):
[code]
[ResourceCostumeModsEnabled]
type = Buffer
data = "Costume Mods Enabled"
[/code]
The "format = DXGI_FORMAT_R8_UINT" is now automatically implied when using a text initialiser.
[center][size="L"][color="green"][TextureOverride] "this" resource copy target[/color][/size][/center]
A [TextureOverride]'s command list invoked via checktextureoverride=<slot> can now access <slot> via "this" without having to know exactly which slot was checked. This is useful for texture swaps where a given texture may appear in a number of different slots at different times:
[code]
[ShaderOverrideFabric]
hash = ...
checktextureoverride = ps-t0
checktextureoverride = ps-t1
checktextureoverride = ps-t2
[TextureOverrideFabric]
hash = d2bd141c
this = ResourceTransparentTex
[ResourceTransparentTex]
filename = transparent.png
[/code]
[center][size="L"][color="green"]No more bind_flags overrides![/color][/size][/center]
3DMigoto can now deduce the bind flags required in more situations, meaning most of the cases where bind_flags had to be specified manually before are gone - any time you needed to specify a [i]single[/i] bind flag is covered by this, including cases where a custom resource was only ever indirectly accessed via assigning it by reference to a second custom resource, as well custom resources assigned to the new indirect "this" target in [TextureOverride] sections.
There may still be some (much rarer) situations where 3DMigoto cannot deduce when two or more bind flags are required together (as before this only applies to custom resources that are accessed indirectly).
[center][size="L"][color="green"]Performance Monitor[/color][/size][/center]
The summary page of the performance monitor now includes a number of extra measurements and statistics. Use this to track how many full / reference / stereo2mono / etc copies you are performing each frame to spot any cases where you might be performing excessive amounts of high cost operations on the GPU so that you can look for ways to reduce or eliminate these.
The performance monitor will now also note if the command list optimiser was unable to optimise out all implicit post checktextureoverride commands due to post commands existing in a [TextureOverride] section (or a command list called from one), which will be noted on the summary page with a listing of all offending commands on an extra page at the end.
Future 3DMigoto updates may be able to reduce some of the measured impacts (e.g. eliminating certain types of map lookups, reducing the runtime ShaderRegex and software cursor overheads, reducing NvAPI calls), but as they tend to be the kind of changes that are nearly guaranteed to introduce new bugs and this release is already large enough I opted to leave them for another day.
[center][size="L"][color="green"]Frame Analysis Profiles[/color][/size][/center]
This isn't technically a feature in and of itself, but it combines together several existing and new features to allow quickly switching between different frame analysis profiles:
[code]
[Constants]
; Frame Analysis Profile (Ctrl+F8 to change):
global persist $dump_skin_clothes = 1
global persist $dump_hair_fingernails = 0
global persist $dump_ui = 0
global persist $dump_modded_meshes = 0
[KeyFrameAnalysisProfile]
key = Ctrl F8
type = cycle
; Restrict this key binding to only work while the hunting overlay is displayed:
condition = hunting == 1
$dump_skin_clothes = 1, 1, 0, 0
$dump_hair_fingernails = 0, 1, 0, 0
$dump_ui = 0, 0, 1, 0
$dump_modded_meshes = 0, 0, 1, 1
$dump_render_targets = 0, 0, 0, 0
run = CommandListFASC, CommandListFAHF, CommandListFAUI, CommandListFALogOnly
[Present]
; Example of how you would set different starting global analyse_options:
if $dump_render_targets
post analyse_options = persist deferred_ctx_accurate dump_rt stereo jps
endif
[ShaderOverrideHUD]
hash = ...
if $dump_ui
dump = deferred_ctx_accurate share_dupes ps-t0 mono dds
endif
[CommandListSkin]
if $dump_skin_clothes
; Dump body textures:
dump = deferred_ctx_accurate share_dupes ps-t0 mono dds
dump = deferred_ctx_accurate share_dupes ps-t3 mono dds
; Dump mesh:
analyse_options = deferred_ctx_accurate share_dupes dump_vb txt buf
; Dump skinning matrices:
dump = deferred_ctx_accurate vs-cb2 txt buf
endif
; Disable mesh replacements during frame analysis because the Blender frame
; analysis import script must work with the original meshes (modded meshes can
; be re-imported directly)... unless we are just grabbing the log file, in
; which case we want to do the replacement so that we can see it in the log file:
if (!frame_analysis || $dump_modded_meshes)
; Enable body texture replacement by texture hash:
checktextureoverride = ps-t0
; Enable mesh replacement by either vertex or indexbuffer hash, must be done
; after texture replacements, because this will replace the draw call:
checktextureoverride = vb0
checktextureoverride = ib
endif
; This uses DarkStarSword's help & notification text shader to indicate the
; current frame analysis profile:
[CommandListFASC]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFASC
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFASC]
type = Buffer
data = "Frame Analysis Profile: Skin & Clothes"
[CommandListFAHF]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFAHF
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFAHF]
type = Buffer
data = "Frame Analysis Profile: Skin, Clothes, Hair & Fingernails"
[CommandListFAUI]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFAUI
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFAUI]
type = Buffer
data = "Frame Analysis Profile: UI"
[CommandListFALogOnly]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFALogOnly
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFALogOnly]
type = Buffer
data = "Frame Analysis Profile: Log file only"
[/code]
[center][size="L"][color="green"]Misc[/color][/size][/center]
[list]
[.]Fixed IniParams GPU resource not being updated on config reload if no IniParams were set to non-zero[/.]
[.]Config reload no longer resets the marking mode changed via next_marking_mode, unless it has actually been changed in the file (this was intended for a previous release, but was bugged)[/.]
[.]Fix crash if no marking_mode is set in the d3dx.ini and the hunting overlay is displayed[/.]
[.]"If/elif/else/endif" flow control no longer counts towards the command list recursion safety limit to allow for more elif clauses and nested if blocks[/.]
[.]Some improvements to how "if/elif/else/endif" is logged in the frame analysis log file[/.]
[.]Fixed use of incorrect delete in ShaderRegex for a little less undefined behaviour[/.]
[.]Fixed the per-draw call separation & convergence overrides failing to restore the previous values[/.]
[.]"separation" is now an alias for "raw_separation" in expressions for consistency with the term used to set the separation[/.]
[.]In hunting mode 3DMigoto will issue a warning if the deprecated "partner" option is used in a [ShaderOverride] section that features any command list commands and provide a suggestion as to what you probably wanted to use instead[/.]
[.]In hunting mode 3DMigoto will issue a deprecation warning if the "depth_filter" option is used and suggest an alternative that offers more flexibility[/.]
[.]3DMigoto will issue a dire warning if frame analysis is attempted if hunting was not enabled on launch[/.]
[.]The various [Clear...View] command lists now correctly run the post list instead of running the pre list twice[/.]
[.]Fixed IniParams case sensitivity in [Key] sections[/.]
[.]Minor performance improvement in hunting mode in games that use deferred contexts[/.]
[.]Fixed invalid subscript errors on texture loads & samples in the decompiler (there are still other cases of the invalid subscript error remaining)[/.]
[.]"hunting" and "frame_analysis" operands added to the expression parser. hunting has the same meaning as the value in the d3dx.ini, frame_analysis indicates when a frame analysis is actually in progress (intended for dumping meshes to momentarily disable mesh swaps to ensure that what is dumped will be importable into Blender)[/.]
[.]Fuzzy TextureOverride matching is now in the form "[ operator ] value | field_name [ * field_name ] [ * multiplier ] [ / divider ]", which allows "match_byte_width = res_width * res_height" used to match certain raw buffers in Resident Evil 7[/.]
[/list]
[center][size="L"][color="green"]Potentially Backwards Incompatible Behaviour Changes[/color][/size][/center]
These are some changes in behaviour that have a small potential to break a fix that may have relied on past behaviour (however I do not anticipate that anyone will be impacted):
[list]
[.]As detailed above, type=cycle key bindings now automatically synchronise their cycle to the current reality[/.]
[.]"pre run = ", "post run = ", "pre checktextureoverride = " and "post checktextureoverride = " will now run both pre and post phases of the target command list(s) one after the other - previously only a single phase of the target list (matching the phase specified in this command) would be run. This makes "post run = CommandListFoo" a little less surprising since all the commands in CommandListFoo will now be run, and this now more closely matches the behaviour of "run = CustomShaderFoo". If neither pre or post is specified the behaviour is unchanged - the target command list's pre phase will run during this command list's pre phase and the target's post phase will be run during this command list's post phase.[/.]
[/list]
User Input No Longer Processed While Alt+Tabbed Out
Enable the new "check_foreground_window = 1" option in the d3dx.ini to ignore input whenever the game window is not in the foreground. Please test this and let me know if you find any game where it doesn't work, as I would like to make it the default in the future but I need to know that I'm not about to break input in some games first.
Named Global Variables
You can declare unlimited named global variables in the [Constants] section, e.g.
[Constants]
global $costume_mods = 1
global $shadow_mode = 1
global $shader_type
The optional initialises here can only set simple initial values (unlike the equivalent in local variables these are not assignment commands - this allows variables declared in an included ini file to be set from the d3dx.ini [Constants] section), so if you wanted something more sophisticated than a boring old number, just add an assignment right under them, e.g.
global $start_time
$start_time = time
Once declared the variables can be used in any command list, [Key] binding or [Preset], e.g.
[KeyShadows]
Key = shift F2
type = cycle
$shadow_mode = 0, 2, 1
run = CommandListShadowsOrig, CommandListShadowsOff, CommandListShadowsOn
These variables are namespaced by the ini file they were declared in. To access a variable declared in a different ini file specify the full namespace:
$\ShaderFixes\3dvision2sbs.ini\mode = 5
Persistent Settings
You can declare global variables as persist(ent), which will automatically save them to a d3dx_user.ini file whenever F10 (or whatever is bound to reload_config) is pressed or when the game is exited (without crashing):
[Constants]
global persist $costume_mods = 1
global persist $shadow_mode = 1
You can use the wipe_user_config key binding (Ctrl+Alt+F10 in the template d3dx.ini) to delete the d3dx_user.ini file and reload the config - you might want to do this e.g. to double check what a new user would see launching the game for the first time, to get rid of warnings about undeclared variables after deleting a persistent variable, or just to discard any saved settings.
If you need to do any initialisation after the d3dx_user.ini has been loaded you can use post commands in the [Constants] command list, e.g.
[Constants]
global persist $shadow_mode = 1
; Remind user if they saved shadows in off or original state:
post run = CommandListShadowsMsg
[CommandListShadowsMsg]
; To remind user of the current setting on launch / reload
if $shadow_mode == 0
run = CommandListShadowsOrig
elif $shadow_mode == 2
run = CommandListShadowsOff
;elif $shadow_mode == 1
; run = CommandListShadowsOn
endif
IniParams cannot (yet) be saved persistently in this manner, but you can achieve this fairly easily if you keep the IniParam and a global variable synchronised, e.g.
[Constants]
global persist $saved_x2
post x2 = $saved_x2
[KeySetX2]
key = x
type = cycle
x2 = 1, 2, 3
$saved_x2 = 1, 2, 3
Likewise, convergence is not automatically saved as yet, but you may be able to achieve this via something like:
[Constants]
global persist $saved_convergence
post convergence = $saved_convergence
[Present]
post $saved_convergence = convergence
Note that depending on how the game handles it's windows and full screen mode on launch this may be ineffective if the convergence is restored too early. Don't forget that the user can always use Ctrl+F7 to save their convergence in the driver profile (if StereoProfile is set), and this will be restored regardless of what dances the application does with it's windows and full screen mode so don't try to do anything too fancy if that will suffice.
Local Variables
While global variables have to be declared in [Constants], local variables can be declared in any command list but are only accessible within that command list. Their values will persist between the pre and post phases of the command list, making them suitable for backing up and restoring an IniParam across a draw call, e.g.
[CustomShaderDebug2D]
...
local $bak_x = x
local $bak_y = y
x = $amplify
y = $flip
Draw = 4, 0
post x = $bak_x
post y = $bak_y
There is a small distinction from global variables in the initialiser - that is an assignment command and can therefore assign the variable to the result of any expression in one go rather than requiring a second line. If the initialiser is omitted the variable will be declared without being assigned and will remember the last value it held (or 0).
For the programmers out there, note that these local variables are like "static" variables in other languages - they are scoped locally, but there is only ever a single instance of each - this allows them to maintain their value between the pre and post phases, but limits their use in certain recursive algorithms or potentially some multi-threaded cases. I do have some unmerged code to add stack allocated local variables for those cases, so if there is ever a need for this let me know.
IniParams
The cap of 8x4 IniParams has been removed - 3DMigoto will now automatically make IniParams exactly large enough to fit the highest variable index you used, though if you go above 255x4 (= 4KB, one full page of memory) it will notify you that seems a little excessive (but won't stop you either).
Note that there is some small overhead every time an IniParam is changed as 3DMigoto has to send the new values to the GPU, and this overhead will scale with the largest IniParam variable index you used and how often IniParams are updated each frame. This should usually be fairly minimal, and 3DMigoto does automatically do some optimisations to reduce this cost (such as merging batches of IniParams updates together), but if you used a large variable number or updated IniParams an excessive number of times each frame it could start impacting performance - you can keep an eye on the number of IniParams updates per frame and the current size of IniParams on the summary page of the performance monitor.
The 3DVision2SBS and software mouse shaders shipped with 3DMigoto no longer use any IniParams (they do, but they back up and restore the previous values), so you no longer need to worry about which IniParams you can and can't use. I've also given the debug, help text / notification and auto-convergence shaders in my 3d-fixes repo the same treatment.
[Key] type=cycle Improvements
Key binding cycles are now smarter, and will try to synchronise themselves to the current state of the variables / IniParams / stereo settings that they affect - this is particularly designed to work well with persistent global variables, but is also useful for any case where a variable of any type may be set by several different things.
e.g. if you had a cycle key binding that cycles x between 0,1,2,3,4,5,6,7,8,9 and last set x to 3, but then something else sets x to 7 then pressing this key again will cycle x to 8 (previously it would have resumed at 4). This works so long as the settings in one of the cycles matches the current reality (e.g. if something else set x to 20 it could not resync as that is not an option in the cycle and would continue from wherever it was last in the cycle).
Consider using these instead of type=toggle when you are toggling between two specific values (type=toggle is still useful when you want to be able to restore a previous value without knowing what it is).
This is now the new default behaviour, but if you wanted the old behaviour for some reason add "smart = false" to the [Key] section.
Additionally:
Character limits have been removed from type=cycle options in case you want very long cycles, or specify separate command lists to run for each phase
If a command list is used with a type=cycle/activate key binding, the post phase will be delayed until after transitions have run for the current frame. If there is no transition the post phase should be able to see the newly set values from the key binding.
3DMigoto Overlay in SBS / TAB / 3D Vision Direct
The 3DMigoto hunting and performance overlays will now work correctly in SBS/TAB output modes. A new "special = draw_3dmigoto_overlay" command has been added to the command list to facilitate drawing the 3DMigoto overlay at an arbitrary time, allowing it to be drawn before the 3DVision2SBS shader has converted the output mode. This same command can also be used to make the 3DMigoto overlay render in both eyes in games that use 3D Vision Direct:
[Present]
direct_mode_eye = left
special = draw_3dmigoto_overlay
direct_mode_eye = right
special = draw_3dmigoto_overlay
In fact, somewhat related to this we can actually use 3DMigoto to fix the one-eye Steam overlay issue in 3D Vision direct games as well:
[System]
hook = recommended
[ShaderOverrideSteamOverlay]
hash = 730f4315d7549467
direct_mode_eye = left
draw = from_caller
direct_mode_eye = right
draw = from_caller
handling = skip
else if
The command list finally has "else if" (or "elif" for short / Python enthusiasts) flow control, so you no longer need to nest ifs inside else blocks.
Custom [Resource] initial data= improvements
The data= line now tolerates extra whitespace between items, and now supports a text initialiser. This allows text buffers to be specified easily in the d3dx.ini (e.g. for use with my help text & notification shader):
[ResourceCostumeModsEnabled]
type = Buffer
data = "Costume Mods Enabled"
The "format = DXGI_FORMAT_R8_UINT" is now automatically implied when using a text initialiser.
[TextureOverride] "this" resource copy target
A [TextureOverride]'s command list invoked via checktextureoverride=<slot> can now access <slot> via "this" without having to know exactly which slot was checked. This is useful for texture swaps where a given texture may appear in a number of different slots at different times:
3DMigoto can now deduce the bind flags required in more situations, meaning most of the cases where bind_flags had to be specified manually before are gone - any time you needed to specify a single bind flag is covered by this, including cases where a custom resource was only ever indirectly accessed via assigning it by reference to a second custom resource, as well custom resources assigned to the new indirect "this" target in [TextureOverride] sections.
There may still be some (much rarer) situations where 3DMigoto cannot deduce when two or more bind flags are required together (as before this only applies to custom resources that are accessed indirectly).
Performance Monitor
The summary page of the performance monitor now includes a number of extra measurements and statistics. Use this to track how many full / reference / stereo2mono / etc copies you are performing each frame to spot any cases where you might be performing excessive amounts of high cost operations on the GPU so that you can look for ways to reduce or eliminate these.
The performance monitor will now also note if the command list optimiser was unable to optimise out all implicit post checktextureoverride commands due to post commands existing in a [TextureOverride] section (or a command list called from one), which will be noted on the summary page with a listing of all offending commands on an extra page at the end.
Future 3DMigoto updates may be able to reduce some of the measured impacts (e.g. eliminating certain types of map lookups, reducing the runtime ShaderRegex and software cursor overheads, reducing NvAPI calls), but as they tend to be the kind of changes that are nearly guaranteed to introduce new bugs and this release is already large enough I opted to leave them for another day.
Frame Analysis Profiles
This isn't technically a feature in and of itself, but it combines together several existing and new features to allow quickly switching between different frame analysis profiles:
[Constants]
; Frame Analysis Profile (Ctrl+F8 to change):
global persist $dump_skin_clothes = 1
global persist $dump_hair_fingernails = 0
global persist $dump_ui = 0
global persist $dump_modded_meshes = 0
[KeyFrameAnalysisProfile]
key = Ctrl F8
type = cycle
; Restrict this key binding to only work while the hunting overlay is displayed:
condition = hunting == 1
$dump_skin_clothes = 1, 1, 0, 0
$dump_hair_fingernails = 0, 1, 0, 0
$dump_ui = 0, 0, 1, 0
$dump_modded_meshes = 0, 0, 1, 1
$dump_render_targets = 0, 0, 0, 0
run = CommandListFASC, CommandListFAHF, CommandListFAUI, CommandListFALogOnly
[Present]
; Example of how you would set different starting global analyse_options:
if $dump_render_targets
post analyse_options = persist deferred_ctx_accurate dump_rt stereo jps
endif
[CommandListSkin]
if $dump_skin_clothes
; Dump body textures:
dump = deferred_ctx_accurate share_dupes ps-t0 mono dds
dump = deferred_ctx_accurate share_dupes ps-t3 mono dds
; Dump mesh:
analyse_options = deferred_ctx_accurate share_dupes dump_vb txt buf
; Dump skinning matrices:
dump = deferred_ctx_accurate vs-cb2 txt buf
endif
; Disable mesh replacements during frame analysis because the Blender frame
; analysis import script must work with the original meshes (modded meshes can
; be re-imported directly)... unless we are just grabbing the log file, in
; which case we want to do the replacement so that we can see it in the log file:
if (!frame_analysis || $dump_modded_meshes)
; Enable body texture replacement by texture hash:
checktextureoverride = ps-t0
; Enable mesh replacement by either vertex or indexbuffer hash, must be done
; after texture replacements, because this will replace the draw call:
checktextureoverride = vb0
checktextureoverride = ib
endif
; This uses DarkStarSword's help & notification text shader to indicate the
; current frame analysis profile:
[CommandListFASC]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFASC
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFASC]
type = Buffer
data = "Frame Analysis Profile: Skin & Clothes"
[CommandListFAHF]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFAHF
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFAHF]
type = Buffer
data = "Frame Analysis Profile: Skin, Clothes, Hair & Fingernails"
[CommandListFAUI]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFAUI
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFAUI]
type = Buffer
data = "Frame Analysis Profile: UI"
[CommandListFALogOnly]
Resource\ShaderFixes\help.ini\Notification = ref ResourceFALogOnly
run = CustomShader\ShaderFixes\help.ini\FormatText
$\ShaderFixes\help.ini\notification_timeout = time + 2.0
[ResourceFALogOnly]
type = Buffer
data = "Frame Analysis Profile: Log file only"
Misc
Fixed IniParams GPU resource not being updated on config reload if no IniParams were set to non-zero
Config reload no longer resets the marking mode changed via next_marking_mode, unless it has actually been changed in the file (this was intended for a previous release, but was bugged)
Fix crash if no marking_mode is set in the d3dx.ini and the hunting overlay is displayed
"If/elif/else/endif" flow control no longer counts towards the command list recursion safety limit to allow for more elif clauses and nested if blocks
Some improvements to how "if/elif/else/endif" is logged in the frame analysis log file
Fixed use of incorrect delete in ShaderRegex for a little less undefined behaviour
Fixed the per-draw call separation & convergence overrides failing to restore the previous values
"separation" is now an alias for "raw_separation" in expressions for consistency with the term used to set the separation
In hunting mode 3DMigoto will issue a warning if the deprecated "partner" option is used in a [ShaderOverride] section that features any command list commands and provide a suggestion as to what you probably wanted to use instead
In hunting mode 3DMigoto will issue a deprecation warning if the "depth_filter" option is used and suggest an alternative that offers more flexibility
3DMigoto will issue a dire warning if frame analysis is attempted if hunting was not enabled on launch
The various [Clear...View] command lists now correctly run the post list instead of running the pre list twice
Fixed IniParams case sensitivity in [Key] sections
Minor performance improvement in hunting mode in games that use deferred contexts
Fixed invalid subscript errors on texture loads & samples in the decompiler (there are still other cases of the invalid subscript error remaining)
"hunting" and "frame_analysis" operands added to the expression parser. hunting has the same meaning as the value in the d3dx.ini, frame_analysis indicates when a frame analysis is actually in progress (intended for dumping meshes to momentarily disable mesh swaps to ensure that what is dumped will be importable into Blender)
Fuzzy TextureOverride matching is now in the form "[ operator ] value | field_name [ * field_name ] [ * multiplier ] [ / divider ]", which allows "match_byte_width = res_width * res_height" used to match certain raw buffers in Resident Evil 7
These are some changes in behaviour that have a small potential to break a fix that may have relied on past behaviour (however I do not anticipate that anyone will be impacted):
As detailed above, type=cycle key bindings now automatically synchronise their cycle to the current reality
"pre run = ", "post run = ", "pre checktextureoverride = " and "post checktextureoverride = " will now run both pre and post phases of the target command list(s) one after the other - previously only a single phase of the target list (matching the phase specified in this command) would be run. This makes "post run = CommandListFoo" a little less surprising since all the commands in CommandListFoo will now be run, and this now more closely matches the behaviour of "run = CustomShaderFoo". If neither pre or post is specified the behaviour is unchanged - the target command list's pre phase will run during this command list's pre phase and the target's post phase will be run during this command list's post phase.
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
About new 3Dmigoto 1.3.14 and iniparams...i need more than 4 variables (xyzx) to be accessed on a vs/ps code by "float4 iniParams = IniParams.Load(0)". Is this now possible? (Sorry for the dumb/newby question)
About new 3Dmigoto 1.3.14 and iniparams...i need more than 4 variables (xyzx) to be accessed on a vs/ps code by "float4 iniParams = IniParams.Load(0)". Is this now possible? (Sorry for the dumb/newby question)
It's actually been possible to have 32 (8x4) IniParams for a long time, and now it's virtually unlimited. In the ini file you refer to higher IniParam variables like "x1", "x2", "w7", etc. In the shader you can access them via "IniParams[1].x", "IniParams[2].x", "IniParams[7].w", etc. [s](the "IniParams.Load(1).x" syntax also works, but I find it unnecessarily verbose)[/s]
In assembly to access higher IniParams variables you change the first number in the literal to the variable index (keep things simpler by always loading a full set of .xyzw variables on the same index), e.g. to access x7, y7, z7 and w7:
[code]
dcl_resource_texture1d (float,float,float,float) t120
ld_indexable(texture1d)(float,float,float,float) r10.xyzw, l(7, 0, 0, 0), t120.xyzw
[/code]
It's actually been possible to have 32 (8x4) IniParams for a long time, and now it's virtually unlimited. In the ini file you refer to higher IniParam variables like "x1", "x2", "w7", etc. In the shader you can access them via "IniParams[1].x", "IniParams[2].x", "IniParams[7].w", etc. (the "IniParams.Load(1).x" syntax also works, but I find it unnecessarily verbose)
In assembly to access higher IniParams variables you change the first number in the literal to the variable index (keep things simpler by always loading a full set of .xyzw variables on the same index), e.g. to access x7, y7, z7 and w7:
[quote="DarkStar Sword"]It's actually been possible to have 32 (8x4) IniParams for a long time, and now it's virtually unlimited. In the ini file you refer to higher IniParam variables like "x1", "x2", "w7", etc. In the shader you can access them via "IniParams[1].x", "IniParams[2].x", "IniParams[7].w", etc. (the "IniParams.Load(1).x" syntax also works, but I find it unnecessarily verbose)
In assembly to access higher IniParams variables you change the first number in the literal to the variable index (keep things simpler by always loading a full set of .xyzw variables on the same index), e.g. to access x7, y7, z7 and w7:
[code]
dcl_resource_texture1d (float,float,float,float) t120
ld_indexable(texture1d)(float,float,float,float) r10.xyzw, l(7, 0, 0, 0), t120.xyzw
[/code][/quote]
Hi DarkStar Sword,
Thanks again by the tips. I'm new here and didnt knew about this. Anyhow, after some tests:
Works:
[code]if (IniParams[1].y == 1) {discard;}[/code]
But this one don't work:
[code] if (IniParams.Load(1).y == 1) {discard;} [/code]
(3dmigoto 1.3.12)
DarkStar Sword said:It's actually been possible to have 32 (8x4) IniParams for a long time, and now it's virtually unlimited. In the ini file you refer to higher IniParam variables like "x1", "x2", "w7", etc. In the shader you can access them via "IniParams[1].x", "IniParams[2].x", "IniParams[7].w", etc. (the "IniParams.Load(1).x" syntax also works, but I find it unnecessarily verbose)
In assembly to access higher IniParams variables you change the first number in the literal to the variable index (keep things simpler by always loading a full set of .xyzw variables on the same index), e.g. to access x7, y7, z7 and w7:
If anyone is using my auto-convergence shader, I've given it a fairly large update which you can find in my DOAXVV mod (The LiS2 version has not been updated). It's mostly under the hood changes (no improvements to the judder issue), but it can now take advantage of 3DMigoto 1.3.14's ability to save settings to remember the user's popout bias. The tunable settings are now all contained within the auto_convergence.ini file using named global variables, and [ResourceDepthBuffer] is now declared in the auto_convergence.ini, so you will need to update your code that sets it to use the full namespace:
[code]Resource\ShaderFixes\auto_convergence.ini\DepthBuffer = ...[/code]
If anyone is using my auto-convergence shader, I've given it a fairly large update which you can find in my DOAXVV mod (The LiS2 version has not been updated). It's mostly under the hood changes (no improvements to the judder issue), but it can now take advantage of 3DMigoto 1.3.14's ability to save settings to remember the user's popout bias. The tunable settings are now all contained within the auto_convergence.ini file using named global variables, and [ResourceDepthBuffer] is now declared in the auto_convergence.ini, so you will need to update your code that sets it to use the full namespace:
In some ways it might be easier to add geometry stream output support to 3DMigoto to capture the geometry after the tessellation stage - that is on my TODO list, but I've never had a pressing need for it so it's quite low priority.
Tessellation is usually reserved for things like terrain or water - what are you trying to import?
It's also something that can often be disabled by lowering the graphics settings in a lot of games.
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
It's an armor mesh. I also dumped it with ninjaripper and got an editable mesh, but unlike 3dmigoto there's no re-import back into the game in ninjaripper. When I tried disabling tesselation 3dmigoto still dumped the same thing.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
I'm using 3dmigoto 1.3.12, passive lg monitor 1920x1080, win7, gtx 1070. This game runs in dx11 x32.
Thanks in any advice!
Depending on exactly what is disappearing you may or may not be able to solve it by editing shaders - if entire objects are disappearing all at once you won't, but that's usually pretty visually minor and easy to ignore. If it's something that is being partially cut off (like the sky, water or terrain) you might be able to edit the shaders to try to do something about it. A formula that works well for *some* of these cases (by stretching the effect) is:
assuming o0 is SV_Position in the vertex shader.
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
Thanks by the tip mate!
Yes, it's mainly the terrain. Well in truth perhaps for small parts of any object that appears at the edges.
It's a small glitch, i will look at some shaders to test your formula. Will post my finds later.
Thanks again!
I can confirm that the main issue is with the terrain. Vegetation and building also pop up at the edges but its not a big issue. Using nvidia crtl+f11 obviously "fix" the problem just because it cut off the borders but as we know isn't a real solution and its a bad one. I tried your code suggestion above without success. But i'm not sure if i put it in the correct place on the VS code. So I attached the terrain VS...can you look at it for me? I will then test it here. Thanks again!
https://www.dropbox.com/s/x03vrame0a5gji9/terrain_VS.7z?dl=0
Looking at the shader there is probably nothing you can do to fix it - there is no height map or any other way to reconstruct the missing terrain. At best you could maybe fudge it by filling in the side of the screen with something less distracting - possibly a solid colour or gradient, maybe some fake terrain or duplicating the terrain pass first stretched with z buffer writes off to fill in the side then the original shader to fill in the rest, or injecting a shader that stretches out the pixels at the side of the screen.
I don't have examples to point you to for any of these - they are purely theoretical, and attempting any one of them would be quite advanced and would probably still not look very good.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
I also have Tridef and it also works very well with this game (the hud and all screen info are at screen depth, this is why i started the fix with 3dmigoto) and the interesting thing is that with tridef this issue is almost absent. Perhaps Tridef fix this issue on the fly or just cut off a bit but without stretching or black bars and the result is much more natural.
Anyway isn't a big issue. The game is almost 100% fixed and it's very fun! Thanks mate by your help and to support this community!
Enable the new "check_foreground_window = 1" option in the d3dx.ini to ignore input whenever the game window is not in the foreground. Please test this and let me know if you find any game where it doesn't work, as I would like to make it the default in the future but I need to know that I'm not about to break input in some games first.
You can declare unlimited named global variables in the [Constants] section, e.g.
The optional initialises here can only set simple initial values (unlike the equivalent in local variables these are not assignment commands - this allows variables declared in an included ini file to be set from the d3dx.ini [Constants] section), so if you wanted something more sophisticated than a boring old number, just add an assignment right under them, e.g.
Once declared the variables can be used in any command list, [Key] binding or [Preset], e.g.
These variables are namespaced by the ini file they were declared in. To access a variable declared in a different ini file specify the full namespace:
You can declare global variables as persist(ent), which will automatically save them to a d3dx_user.ini file whenever F10 (or whatever is bound to reload_config) is pressed or when the game is exited (without crashing):
You can use the wipe_user_config key binding (Ctrl+Alt+F10 in the template d3dx.ini) to delete the d3dx_user.ini file and reload the config - you might want to do this e.g. to double check what a new user would see launching the game for the first time, to get rid of warnings about undeclared variables after deleting a persistent variable, or just to discard any saved settings.
If you need to do any initialisation after the d3dx_user.ini has been loaded you can use post commands in the [Constants] command list, e.g.
IniParams cannot (yet) be saved persistently in this manner, but you can achieve this fairly easily if you keep the IniParam and a global variable synchronised, e.g.
Likewise, convergence is not automatically saved as yet, but you may be able to achieve this via something like:
Note that depending on how the game handles it's windows and full screen mode on launch this may be ineffective if the convergence is restored too early. Don't forget that the user can always use Ctrl+F7 to save their convergence in the driver profile (if StereoProfile is set), and this will be restored regardless of what dances the application does with it's windows and full screen mode so don't try to do anything too fancy if that will suffice.
While global variables have to be declared in [Constants], local variables can be declared in any command list but are only accessible within that command list. Their values will persist between the pre and post phases of the command list, making them suitable for backing up and restoring an IniParam across a draw call, e.g.
There is a small distinction from global variables in the initialiser - that is an assignment command and can therefore assign the variable to the result of any expression in one go rather than requiring a second line. If the initialiser is omitted the variable will be declared without being assigned and will remember the last value it held (or 0).
For the programmers out there, note that these local variables are like "static" variables in other languages - they are scoped locally, but there is only ever a single instance of each - this allows them to maintain their value between the pre and post phases, but limits their use in certain recursive algorithms or potentially some multi-threaded cases. I do have some unmerged code to add stack allocated local variables for those cases, so if there is ever a need for this let me know.
The cap of 8x4 IniParams has been removed - 3DMigoto will now automatically make IniParams exactly large enough to fit the highest variable index you used, though if you go above 255x4 (= 4KB, one full page of memory) it will notify you that seems a little excessive (but won't stop you either).
Note that there is some small overhead every time an IniParam is changed as 3DMigoto has to send the new values to the GPU, and this overhead will scale with the largest IniParam variable index you used and how often IniParams are updated each frame. This should usually be fairly minimal, and 3DMigoto does automatically do some optimisations to reduce this cost (such as merging batches of IniParams updates together), but if you used a large variable number or updated IniParams an excessive number of times each frame it could start impacting performance - you can keep an eye on the number of IniParams updates per frame and the current size of IniParams on the summary page of the performance monitor.
Key binding cycles are now smarter, and will try to synchronise themselves to the current state of the variables / IniParams / stereo settings that they affect - this is particularly designed to work well with persistent global variables, but is also useful for any case where a variable of any type may be set by several different things.
e.g. if you had a cycle key binding that cycles x between 0,1,2,3,4,5,6,7,8,9 and last set x to 3, but then something else sets x to 7 then pressing this key again will cycle x to 8 (previously it would have resumed at 4). This works so long as the settings in one of the cycles matches the current reality (e.g. if something else set x to 20 it could not resync as that is not an option in the cycle and would continue from wherever it was last in the cycle).
Consider using these instead of type=toggle when you are toggling between two specific values (type=toggle is still useful when you want to be able to restore a previous value without knowing what it is).
This is now the new default behaviour, but if you wanted the old behaviour for some reason add "smart = false" to the [Key] section.
Additionally:
The 3DMigoto hunting and performance overlays will now work correctly in SBS/TAB output modes. A new "special = draw_3dmigoto_overlay" command has been added to the command list to facilitate drawing the 3DMigoto overlay at an arbitrary time, allowing it to be drawn before the 3DVision2SBS shader has converted the output mode. This same command can also be used to make the 3DMigoto overlay render in both eyes in games that use 3D Vision Direct:
In fact, somewhat related to this we can actually use 3DMigoto to fix the one-eye Steam overlay issue in 3D Vision direct games as well:
The command list finally has "else if" (or "elif" for short / Python enthusiasts) flow control, so you no longer need to nest ifs inside else blocks.
The data= line now tolerates extra whitespace between items, and now supports a text initialiser. This allows text buffers to be specified easily in the d3dx.ini (e.g. for use with my help text & notification shader):
The "format = DXGI_FORMAT_R8_UINT" is now automatically implied when using a text initialiser.
A [TextureOverride]'s command list invoked via checktextureoverride=<slot> can now access <slot> via "this" without having to know exactly which slot was checked. This is useful for texture swaps where a given texture may appear in a number of different slots at different times:
3DMigoto can now deduce the bind flags required in more situations, meaning most of the cases where bind_flags had to be specified manually before are gone - any time you needed to specify a single bind flag is covered by this, including cases where a custom resource was only ever indirectly accessed via assigning it by reference to a second custom resource, as well custom resources assigned to the new indirect "this" target in [TextureOverride] sections.
There may still be some (much rarer) situations where 3DMigoto cannot deduce when two or more bind flags are required together (as before this only applies to custom resources that are accessed indirectly).
The summary page of the performance monitor now includes a number of extra measurements and statistics. Use this to track how many full / reference / stereo2mono / etc copies you are performing each frame to spot any cases where you might be performing excessive amounts of high cost operations on the GPU so that you can look for ways to reduce or eliminate these.
The performance monitor will now also note if the command list optimiser was unable to optimise out all implicit post checktextureoverride commands due to post commands existing in a [TextureOverride] section (or a command list called from one), which will be noted on the summary page with a listing of all offending commands on an extra page at the end.
Future 3DMigoto updates may be able to reduce some of the measured impacts (e.g. eliminating certain types of map lookups, reducing the runtime ShaderRegex and software cursor overheads, reducing NvAPI calls), but as they tend to be the kind of changes that are nearly guaranteed to introduce new bugs and this release is already large enough I opted to leave them for another day.
This isn't technically a feature in and of itself, but it combines together several existing and new features to allow quickly switching between different frame analysis profiles:
These are some changes in behaviour that have a small potential to break a fix that may have relied on past behaviour (however I do not anticipate that anyone will be impacted):
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
(the "IniParams.Load(1).x" syntax also works, but I find it unnecessarily verbose)In assembly to access higher IniParams variables you change the first number in the literal to the variable index (keep things simpler by always loading a full set of .xyzw variables on the same index), e.g. to access x7, y7, z7 and w7:
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
Hi DarkStar Sword,
Thanks again by the tips. I'm new here and didnt knew about this. Anyhow, after some tests:
Works:
But this one don't work:
(3dmigoto 1.3.12)
Thanks DSS!!
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword