GIMP 2.10 in finally coming to fruition.
https://www.gimp.org/news/2017/12/12/gimp-2-9-8-released/
https://www.gimp.org/news/2018/03/26/gimp-2-10-0-rc1-released/
https://www.gimp.org/news/2018/04/17/gimp-2-10-0-rc2-released/
Current Public stable release is 2.88
https://www.gimp.org/downloads/
Why you should be excited
[quote="DarkStarSword"][center][color="orange"][size="XL"]3Dmigoto 1.3.10[/size]
[/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center]
[center][size="XL"][color="orange"]IMPORTANT: rasterizer_disable_scissor is no longer enabled by default![/color][/size][/center]This means that you will very likely start seeing issues due to scissor clipping emerge. You may choose to just set this back to 1 to keep things as they were, but the flip side is that disabling scissor clipping can break certain effects in ways that will not show up via the show_original key, which is why I've chosen to change the default.
Scissor clipping typically looks like this - where something adjusted in stereo 3D is clipped on a 2D screen depth rectangle. Note in this case the text next to "Select Monitor" is clipping incorrectly:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74910/[/img]
Disabling scissor clipping will in some cases fix the issue, but in other cases causes different problems, such as here where the text overflows:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74912/[/img]
Scissor clipping doesn't just apply to HUD elements - the same thing can happen to various effects in-game, and decals are often affected by it. Note that in some games you may see something that looks exactly the same as scissor clipping, but is caused by something else, such as an invisible mask shader that also needs to be stereoised.
There are several other options available to you to deal with scissor clipping that don't involve disabling it everywhere:
[olist]
[.]Disable or enable it on a per-shader basis:
[code]
[ShaderOverrideDecalsWithScissorClipping]
hash = ...
disable_scissor = 1
[/code][/.]
[.]Quick 'n' dirty way to see if scissor clipping is affecting you (note: will not work on any shaders in ShaderFixes, and I do not recommend shipping with this as it adds extra overhead to every draw call, but unlike rasterizer_disable_scissor, this works with show_original):
[code]
[ShaderRegexDisableScissorClipping]
shader_model = ps_4_0 ps_5_0
disable_scissor = 1
[/code][/.]
[.]Variant of 1 for cases where you need to override additional state or replace the draw call for some other reason:
[code]
[ShaderOverrideDecalsWithScissorClipping]
hash = ...
run = CustomShaderDisableScissorClippingAdvanced
[CustomShaderDisableScissorClippingAdvanced]
scissor_enable = false
rasterizer_state_merge = true
; Any other draw call state overrides you need go here
draw = from_caller
handling = skip
[/code][/.]
[.][size="XL"][b][color="green"]Fix scissor clipping to work properly in stereo 3D[/color][/b][/size]
You can now get the scissor rectangle in the shader, stereoise it and perform your own clipping in the pixel shader. e.g. To allow the UI to be properly stereoised with correct clipping in NieR Automata:
[code]
[ShaderOverrideMenuScissor1]
Hash = ed8095aa588ab158
disable_scissor = 1
x1 = scissor0_left
y1 = scissor0_top
z1 = scissor0_right
w1 = scissor0_bottom
x2 = rt_width
[/code]
Then in the pixel shader:
[code]
void main(
float4 v0 : SV_POSITION0,
...
{
// This matches the stereo correction in the vertex shader
float stereo_adjustment = StereoParams.Load(0).x * IniParams[0].x * 1.3;
// Load the scissor rectangle and stereoise it. Note that since both
// SV_Position and the scissor rectange are in pixels, the adjustment needs to
// be divided by the render target size and again by 2:
float4 scissor_rect = IniParams[1].xyzw;
scissor_rect.xz += floor(stereo_adjustment * IniParams[2].x / 2);
// Perform stereo adjusted scissor clipping:
if (any(v0.xy < scissor_rect.xy) || any(v0.xy >= scissor_rect.zw)) {
discard;
return;
}
[/code]
This results in the text being properly lined up in 3D and clipping correctly:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74911/[/img]
[/.]
[/olist]
[size="XL"][color="green"]Modular 3DMigoto Configuration / 3DMigoto as a Modding Platform[/color][/size]
3DMigoto has a new [Include] section which can specify additional configuration files to include - either including specific config files, or a directory to scan recursively to include all ini files, with the option to skip files matching some pattern.
The former is useful to help break up the d3dx.ini into separate logical sections that can be enabled or disabled just by commenting/uncommenting the include directive - the 3DVision2SBS, upscaling and software mouse shaders shipped with 3DMigoto now have their config boilerplate moved to a separate config file using this mechanism, and you can expect updates to my debugging shaders, auto-convergence, etc. to do the same shortly.
The later opens up the possibility to use 3DMigoto as a full modding *platform* for a given game, rather than just a single stand-alone mod. 3DMigoto's capabilities exceed some of the competing DX11 modding tools in many aspects, and interest in using it in other modding communities has been growing. The ability to recursively include config files is intended to support communities with multiple mod authors where coordinating everything in a single d3dx.ini is a limiting factor. Think about modding communities interested in things like texture and mesh replacements, where 3DMigoto is the *best* generalised DX11 injection tool for the former (e.g. other injection tools cannot live reload like 3DMigoto can, have very poor compatibility and cannot increase the resolution of replaced textures) and the *only* generalised DX11 injection tool for the later.
Sections in the included configuration files are "namespaced" and will be automatically renamed by 3DMigoto to keep them unique. e.g. [ResourceFoo] might become [Resource\Mods\bar\baz.ini\Foo]. Where these sections are referenced by other sections 3DMigoto will first check for a section in the same namespace (so "ps-t0 = ResourceFoo" still works), then the global namespace. You can refer to a section in another config file by using the fully namespaced version of the section name (which must be absolute).
Any external files referred to by included configuration files (e.g. by CustomShader or Resource sections) will be searched for relative to the config file first, then relative to the 3DMigoto directory if they aren't found.
Included configuration files are allowed to append to global sections (such as [Present]) and can override settings in most global sections if they choose. Note that this means that the command list order of the [Present] section can depend on the include order, and for this reason it is suggested that the include_recursive directive be placed before the upscaling, mouse and 3DVision2SBS shaders as these generally should be run last. 3DMigoto will also try to be consistent about the order it includes config files in when scanning recursively, so that if there are any order dependent interractions between them the results should at least be consistent.
3DMigoto still has its usual warnings for duplicate hashes between ShaderOverride & TextureOverride sections, but these have been relaxed a little, and the warning message now indicates this is a potential mod conflict and displays the conflicting section names (which includes the namespace showing which mods they came from). A mod can force the warning of duplicate ShaderOverride hashes to go away with "allow_duplicate_hash = overrule", and can set a "match_priority" in TextureOverride sections to define some order between mods and hide the warning.
There are some current limitations to this to this namespacing:
[list]
[.]There is only one global ShaderFixes folder, so mods that need additional files here will have to make this clear in their documentation. Adding the ability to load shaders from additional directories is very low priority because we have very good reasons for doing it the way we do.[/.]
[.]IniParams is not namespaced, which could easily become a point of contention between mods. I have plans to expand the custom Resource sections to allow them to be used in place of IniParams, as they do support namespacing, though the DirectX texture slots they must be bound to access them inside a shader do not. Once we have conditional logic in the command list I may also add separate namespaced variables that are not automatically used in the shaders, which could eliminate a lot of contention here.[/.]
[.]Texture filtering and checktextureoverride are not currently namespaced, and can match/trigger sections defined in a different mod. In some cases this may be intentional, as these are usually required to enable texture/mesh replacements and would normally be done once globally rather than in every single mod. Namespaced versions of these may be added in the future.[/.]
[/list]
[size="XL"][color="green"]Presets[/color][/size]
Presets can now be narrowed down by requiring multiple conditions to be met per frame, or defining a condition that will prevent the preset from being triggered that frame:
[code]
[PresetMultipleConditions]
; Require two unique triggers to activate this preset:
unique_triggers_required = 2
; Do something
; Preset only activated when a particular distortion shader is in use:
[ShaderOverrideDistort]
hash = ...
preset = PresetMultipleConditions
; *And* when a specific texture is in use:
[ShaderOverrideFog]
hash = ...
checktextureoverride = ps-t0
[TextureOverrideFogTexture]
hash = ...
preset = PresetMultipleConditions
; But not when this other shader is in use:
[ShaderOverrideSomethingThatSignifiesThePresetIsWrong]
hash = ...
exclude = PresetMultipleConditions
[/code]
[size="XL"][color="green"][TextureOverride] Draw Context Matching (e.g. partial mesh matching)[/color][/size]
[TextureOverride] sections have gained several new options:
[list]
[.]match_first_vertex = n[/.]
[.]match_first_index = n[/.]
[.]match_first_instance = n[/.]
[.]match_vertex_count = n[/.]
[.]match_index_count = n[/.]
[.]match_instance_count = n[/.]
[/list]This narrows down the circumstances in which the section will match when used for texture filtering or with checktextureoverride. The practical application of this is to allow matches on the index or vertex buffer hashes to be more specific - to match a specific mesh inside a buffer that contains many unrelated meshes, or a specific sub-part of a mesh drawn separately from the other parts. These can be used in conjunction with either matching by hash, or a fuzzy match on the resource description. match_priority can be used to set the order the sections are run in if multiple sections match.
[size="XL"][color="green"]Misc[/color][/size]
[list]
[.]New "drawindexed=auto" command to draw every index in the currently bound index buffer. Useful when a custom vertex + index buffer pair is loaded from disk (e.g. exported from the Blender 3DMigoto addon) to avoid the need to determine this manually each time the mesh is updated.[/.]
[.]Hunting mode will now skip all custom draw commands, not just draw=from_caller[/.]
[.]Custom textures loaded from disk can now override bind_flags in situations where 3DMigoto cannot determine these automatically, or to manipulate driver heuristics.[/.]
[.]The frame analysis "dump" command will now imply "deferred_ctx_accurate" if neither deferred context option was specified.[/.]
[.]New "BuiltInCommandListUnbindAllRenderTargets" command list to replace the version in the d3dx.ini template[/.]
[.]Fixed a long standing bug where texture filtering, checktextureoverride and potentially other cases could mistake a custom resource for a game resource and do the wrong thing, often seeming to change at random on F10 reload.[/.]
[.]The upscaling and software mouse shaders can now be re-ordered without editing either section, and other custom HUD shaders run before upscaling will work. This requires the latest version of the upscaling.ini file to work, so will not happen automatically if upgrading an existing fix.[/.]
[.]Fixed crash when reloading configuration while using hooking, and fixed a crash on launch in some games using hooking.[/.]
[.]Texture filtering will now use filter_index from the highest priority matching TextureOverride section that set a filter_index, i.e. a lower priority match that set a filter_index would be used in place of a higher priority match that did not set a filter_index. Any match by hash will still trump any match by resource description, even if the match by hash did not include a filter_index and the match by description did.[/.]
[/list]
[/quote]
IMPORTANT: rasterizer_disable_scissor is no longer enabled by default!
This means that you will very likely start seeing issues due to scissor clipping emerge. You may choose to just set this back to 1 to keep things as they were, but the flip side is that disabling scissor clipping can break certain effects in ways that will not show up via the show_original key, which is why I've chosen to change the default.
Scissor clipping typically looks like this - where something adjusted in stereo 3D is clipped on a 2D screen depth rectangle. Note in this case the text next to "Select Monitor" is clipping incorrectly:
Disabling scissor clipping will in some cases fix the issue, but in other cases causes different problems, such as here where the text overflows:
Scissor clipping doesn't just apply to HUD elements - the same thing can happen to various effects in-game, and decals are often affected by it. Note that in some games you may see something that looks exactly the same as scissor clipping, but is caused by something else, such as an invisible mask shader that also needs to be stereoised.
There are several other options available to you to deal with scissor clipping that don't involve disabling it everywhere:
Quick 'n' dirty way to see if scissor clipping is affecting you (note: will not work on any shaders in ShaderFixes, and I do not recommend shipping with this as it adds extra overhead to every draw call, but unlike rasterizer_disable_scissor, this works with show_original):
Variant of 1 for cases where you need to override additional state or replace the draw call for some other reason:
[ShaderOverrideDecalsWithScissorClipping]
hash = ...
run = CustomShaderDisableScissorClippingAdvanced
[CustomShaderDisableScissorClippingAdvanced]
scissor_enable = false
rasterizer_state_merge = true
; Any other draw call state overrides you need go here
draw = from_caller
handling = skip
Fix scissor clipping to work properly in stereo 3D
You can now get the scissor rectangle in the shader, stereoise it and perform your own clipping in the pixel shader. e.g. To allow the UI to be properly stereoised with correct clipping in NieR Automata:
void main(
float4 v0 : SV_POSITION0,
...
{
// This matches the stereo correction in the vertex shader
float stereo_adjustment = StereoParams.Load(0).x * IniParams[0].x * 1.3;
// Load the scissor rectangle and stereoise it. Note that since both
// SV_Position and the scissor rectange are in pixels, the adjustment needs to
// be divided by the render target size and again by 2:
float4 scissor_rect = IniParams[1].xyzw;
scissor_rect.xz += floor(stereo_adjustment * IniParams[2].x / 2);
This results in the text being properly lined up in 3D and clipping correctly:
Modular 3DMigoto Configuration / 3DMigoto as a Modding Platform
3DMigoto has a new [Include] section which can specify additional configuration files to include - either including specific config files, or a directory to scan recursively to include all ini files, with the option to skip files matching some pattern.
The former is useful to help break up the d3dx.ini into separate logical sections that can be enabled or disabled just by commenting/uncommenting the include directive - the 3DVision2SBS, upscaling and software mouse shaders shipped with 3DMigoto now have their config boilerplate moved to a separate config file using this mechanism, and you can expect updates to my debugging shaders, auto-convergence, etc. to do the same shortly.
The later opens up the possibility to use 3DMigoto as a full modding *platform* for a given game, rather than just a single stand-alone mod. 3DMigoto's capabilities exceed some of the competing DX11 modding tools in many aspects, and interest in using it in other modding communities has been growing. The ability to recursively include config files is intended to support communities with multiple mod authors where coordinating everything in a single d3dx.ini is a limiting factor. Think about modding communities interested in things like texture and mesh replacements, where 3DMigoto is the *best* generalised DX11 injection tool for the former (e.g. other injection tools cannot live reload like 3DMigoto can, have very poor compatibility and cannot increase the resolution of replaced textures) and the *only* generalised DX11 injection tool for the later.
Sections in the included configuration files are "namespaced" and will be automatically renamed by 3DMigoto to keep them unique. e.g. [ResourceFoo] might become [Resource\Mods\bar\baz.ini\Foo]. Where these sections are referenced by other sections 3DMigoto will first check for a section in the same namespace (so "ps-t0 = ResourceFoo" still works), then the global namespace. You can refer to a section in another config file by using the fully namespaced version of the section name (which must be absolute).
Any external files referred to by included configuration files (e.g. by CustomShader or Resource sections) will be searched for relative to the config file first, then relative to the 3DMigoto directory if they aren't found.
Included configuration files are allowed to append to global sections (such as [Present]) and can override settings in most global sections if they choose. Note that this means that the command list order of the [Present] section can depend on the include order, and for this reason it is suggested that the include_recursive directive be placed before the upscaling, mouse and 3DVision2SBS shaders as these generally should be run last. 3DMigoto will also try to be consistent about the order it includes config files in when scanning recursively, so that if there are any order dependent interractions between them the results should at least be consistent.
3DMigoto still has its usual warnings for duplicate hashes between ShaderOverride & TextureOverride sections, but these have been relaxed a little, and the warning message now indicates this is a potential mod conflict and displays the conflicting section names (which includes the namespace showing which mods they came from). A mod can force the warning of duplicate ShaderOverride hashes to go away with "allow_duplicate_hash = overrule", and can set a "match_priority" in TextureOverride sections to define some order between mods and hide the warning.
There are some current limitations to this to this namespacing:
There is only one global ShaderFixes folder, so mods that need additional files here will have to make this clear in their documentation. Adding the ability to load shaders from additional directories is very low priority because we have very good reasons for doing it the way we do.
IniParams is not namespaced, which could easily become a point of contention between mods. I have plans to expand the custom Resource sections to allow them to be used in place of IniParams, as they do support namespacing, though the DirectX texture slots they must be bound to access them inside a shader do not. Once we have conditional logic in the command list I may also add separate namespaced variables that are not automatically used in the shaders, which could eliminate a lot of contention here.
Texture filtering and checktextureoverride are not currently namespaced, and can match/trigger sections defined in a different mod. In some cases this may be intentional, as these are usually required to enable texture/mesh replacements and would normally be done once globally rather than in every single mod. Namespaced versions of these may be added in the future.
Presets
Presets can now be narrowed down by requiring multiple conditions to be met per frame, or defining a condition that will prevent the preset from being triggered that frame:
[PresetMultipleConditions]
; Require two unique triggers to activate this preset:
unique_triggers_required = 2
; Do something
; Preset only activated when a particular distortion shader is in use:
[ShaderOverrideDistort]
hash = ...
preset = PresetMultipleConditions
; *And* when a specific texture is in use:
[ShaderOverrideFog]
hash = ...
checktextureoverride = ps-t0
[TextureOverrideFogTexture]
hash = ...
preset = PresetMultipleConditions
; But not when this other shader is in use:
[ShaderOverrideSomethingThatSignifiesThePresetIsWrong]
hash = ...
exclude = PresetMultipleConditions
[TextureOverride] Draw Context Matching (e.g. partial mesh matching)
[TextureOverride] sections have gained several new options:
match_first_vertex = n
match_first_index = n
match_first_instance = n
match_vertex_count = n
match_index_count = n
match_instance_count = n
This narrows down the circumstances in which the section will match when used for texture filtering or with checktextureoverride. The practical application of this is to allow matches on the index or vertex buffer hashes to be more specific - to match a specific mesh inside a buffer that contains many unrelated meshes, or a specific sub-part of a mesh drawn separately from the other parts. These can be used in conjunction with either matching by hash, or a fuzzy match on the resource description. match_priority can be used to set the order the sections are run in if multiple sections match.
Misc
New "drawindexed=auto" command to draw every index in the currently bound index buffer. Useful when a custom vertex + index buffer pair is loaded from disk (e.g. exported from the Blender 3DMigoto addon) to avoid the need to determine this manually each time the mesh is updated.
Hunting mode will now skip all custom draw commands, not just draw=from_caller
Custom textures loaded from disk can now override bind_flags in situations where 3DMigoto cannot determine these automatically, or to manipulate driver heuristics.
The frame analysis "dump" command will now imply "deferred_ctx_accurate" if neither deferred context option was specified.
New "BuiltInCommandListUnbindAllRenderTargets" command list to replace the version in the d3dx.ini template
Fixed a long standing bug where texture filtering, checktextureoverride and potentially other cases could mistake a custom resource for a game resource and do the wrong thing, often seeming to change at random on F10 reload.
The upscaling and software mouse shaders can now be re-ordered without editing either section, and other custom HUD shaders run before upscaling will work. This requires the latest version of the upscaling.ini file to work, so will not happen automatically if upgrading an existing fix.
Fixed crash when reloading configuration while using hooking, and fixed a crash on launch in some games using hooking.
Texture filtering will now use filter_index from the highest priority matching TextureOverride section that set a filter_index, i.e. a lower priority match that set a filter_index would be used in place of a higher priority match that did not set a filter_index. Any match by hash will still trump any match by resource description, even if the match by hash did not include a filter_index and the match by description did.
3Dmigoto has long had texture loading features.
From the [url=https://forums.geforce.com/default/topic/809772/] Miasmata[/url] thread [color="orange"]EDIT:::: I mistakenly thought this was using 3Dmigoto, but it's dx9 and using the DLL from Helix, I'll leave it up, because it has info pertaining to dx9 games[/color]
[quote="ForgottenProdigy"]Any way to modify the textures? I got the rs extractor py but not sure what to do next.[/quote]
[quote="DarkStarSword"]Yes you can - this is how we were able to translate it into French. The only unknown at the moment is whether the game will accept a replacement texture of a higher resolution than the original - it might do (I keep meaning to test this, but haven't quite gotten around to it), but there is some extra metadata that I haven't decoded yet.
You can extract the textures with this command line (you will need python 2.7 installed to use rs5-extractor):
[code]rs5-extractor.py -f main.rs5 --filter IMAG -x --chunks[/code]
That will extract all the textures in directories under main, each of which will contain these files:
00-HEADER is a common thing I dump for all resources made up of multiple chunks (if --chunks was specified while extracting them), which contains the resource type ("IMAG" for textures) and resource name.
01-HEAD is the first chunk in the resource and is the part I haven't decoded yet.
02-DATA.dds is the texture in DDS format. You can open these in The GIMP with the dds plugin installed, or any other image editor that can read S3 compressed DDS files. These are encoded with DXT5 compression with mip-maps, though I've already confirmed that the game is happy to accept DXT1 compressed DDS files (for textures that don't use an alpha channel) and doesn't necessarily need mip-maps.
You can then repack things back into the main.rs5 with rs5-extractor.py as well. Before you start playing with it I recommend adding undo metadata to it, which will allow you to revert it to the vanilla state (if you installed the community patch it will have already done this):
[code]rs5-extractor.py -f main.rs5 --add-undo
Adding MIASMOD\UNDO...
Writing central directory...
Writing RS5 header...
RS5 Written
[/code]
To revert it back to the vanilla version and remove your changes, you can use this (this is part of what the uninstall button in the patcher does. Note that this also removes the undo metadata, so you may want to run --add-undo again before you add more files):
[code]rs5-extractor.py -f main.rs5 --revert
STUB: validate_undo()
Writing RS5 header...
[/code]
To add/update a file to the archive, you can do this:
[code]rs5-extractor.py -f main.rs5 -a main/TEX/J2/Note_A1
Adding chunks from main/TEX/J2/Note_A1...
01-HEAD
02-DATA.dds
Writing central directory...
Writing RS5 header...
RS5 Written
[/code]
Later I'll show you how you can pack your mod into an .rs5mod file which can be used with miasmod or the patcher from the community patch, making it easier to distribute it to other people.[/quote]
Guide to DDS GIMP plugin
https://steamcommunity.com/sharedfiles/filedetails/?id=816839147
From the Miasmata thread EDIT:::: I mistakenly thought this was using 3Dmigoto, but it's dx9 and using the DLL from Helix, I'll leave it up, because it has info pertaining to dx9 games
ForgottenProdigy said:Any way to modify the textures? I got the rs extractor py but not sure what to do next.
DarkStarSword said:Yes you can - this is how we were able to translate it into French. The only unknown at the moment is whether the game will accept a replacement texture of a higher resolution than the original - it might do (I keep meaning to test this, but haven't quite gotten around to it), but there is some extra metadata that I haven't decoded yet.
You can extract the textures with this command line (you will need python 2.7 installed to use rs5-extractor):
That will extract all the textures in directories under main, each of which will contain these files:
00-HEADER is a common thing I dump for all resources made up of multiple chunks (if --chunks was specified while extracting them), which contains the resource type ("IMAG" for textures) and resource name.
01-HEAD is the first chunk in the resource and is the part I haven't decoded yet.
02-DATA.dds is the texture in DDS format. You can open these in The GIMP with the dds plugin installed, or any other image editor that can read S3 compressed DDS files. These are encoded with DXT5 compression with mip-maps, though I've already confirmed that the game is happy to accept DXT1 compressed DDS files (for textures that don't use an alpha channel) and doesn't necessarily need mip-maps.
You can then repack things back into the main.rs5 with rs5-extractor.py as well. Before you start playing with it I recommend adding undo metadata to it, which will allow you to revert it to the vanilla state (if you installed the community patch it will have already done this):
rs5-extractor.py -f main.rs5 --add-undo
Adding MIASMOD\UNDO...
Writing central directory...
Writing RS5 header...
RS5 Written
To revert it back to the vanilla version and remove your changes, you can use this (this is part of what the uninstall button in the patcher does. Note that this also removes the undo metadata, so you may want to run --add-undo again before you add more files):
To add/update a file to the archive, you can do this:
rs5-extractor.py -f main.rs5 -a main/TEX/J2/Note_A1
Adding chunks from main/TEX/J2/Note_A1...
01-HEAD
02-DATA.dds
Writing central directory...
Writing RS5 header...
RS5 Written
Later I'll show you how you can pack your mod into an .rs5mod file which can be used with miasmod or the patcher from the community patch, making it easier to distribute it to other people.
So this means that games that do not include modding features, can now? or perhaps soon? have updated textures added fairly easily. As well as numerous other features, due to 3DMigoto
So this means that games that do not include modding features, can now? or perhaps soon? have updated textures added fairly easily. As well as numerous other features, due to 3DMigoto
Worth noting that Miasmata is DX9 and doesn't use 3DMigoto - the info about replacing textures in that thread was regarding some game-specific modding tools I wrote back in the day (screenshot of the French translation if you're interested: [url]https://steamcommunity.com/sharedfiles/filedetails/?id=238971677[/url]).
But yes, 3DMigoto can be used to mod textures, meshes (and of course shaders) in most DX11 games, and the command list implementation gives a modder a lot of power to do whatever they can dream up for graphics modding. Since it is game-neutral it offers a significant advantage (or at least a head-start) when working with a game that does not have dedicated modding tools :)
3DMigoto's texture replacement capabilities actually originated with my Far Cry 4 fix, where I wasn't so much replacing an existing texture as injecting a new one, but they are the same thing to 3DMigoto.
Worth noting that Miasmata is DX9 and doesn't use 3DMigoto - the info about replacing textures in that thread was regarding some game-specific modding tools I wrote back in the day (screenshot of the French translation if you're interested: https://steamcommunity.com/sharedfiles/filedetails/?id=238971677).
But yes, 3DMigoto can be used to mod textures, meshes (and of course shaders) in most DX11 games, and the command list implementation gives a modder a lot of power to do whatever they can dream up for graphics modding. Since it is game-neutral it offers a significant advantage (or at least a head-start) when working with a game that does not have dedicated modding tools :)
3DMigoto's texture replacement capabilities actually originated with my Far Cry 4 fix, where I wasn't so much replacing an existing texture as injecting a new one, but they are the same thing to 3DMigoto.
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"]Worth noting that Miasmata is DX9 and doesn't use 3DMigoto - the info about replacing textures in that thread was regarding some game-specific modding tools I wrote back in the day (screenshot of the French translation if you're interested: [url]https://steamcommunity.com/sharedfiles/filedetails/?id=238971677[/url]).[/quote]
[img]https://grantmeadmission.files.wordpress.com/2014/07/oops.jpg[/img]
edited, above post to reflect helix.dll is being used
DarkStarSword said:Worth noting that Miasmata is DX9 and doesn't use 3DMigoto - the info about replacing textures in that thread was regarding some game-specific modding tools I wrote back in the day (screenshot of the French translation if you're interested: https://steamcommunity.com/sharedfiles/filedetails/?id=238971677).
edited, above post to reflect helix.dll is being used
https://www.gimp.org/news/2017/12/12/gimp-2-9-8-released/
https://www.gimp.org/news/2018/03/26/gimp-2-10-0-rc1-released/
https://www.gimp.org/news/2018/04/17/gimp-2-10-0-rc2-released/
Current Public stable release is 2.88
https://www.gimp.org/downloads/
From the Miasmata thread EDIT:::: I mistakenly thought this was using 3Dmigoto, but it's dx9 and using the DLL from Helix, I'll leave it up, because it has info pertaining to dx9 games
Guide to DDS GIMP plugin
https://steamcommunity.com/sharedfiles/filedetails/?id=816839147
But yes, 3DMigoto can be used to mod textures, meshes (and of course shaders) in most DX11 games, and the command list implementation gives a modder a lot of power to do whatever they can dream up for graphics modding. Since it is game-neutral it offers a significant advantage (or at least a head-start) when working with a game that does not have dedicated modding tools :)
3DMigoto's texture replacement capabilities actually originated with my Far Cry 4 fix, where I wasn't so much replacing an existing texture as injecting a new one, but they are the same thing to 3DMigoto.
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
edited, above post to reflect helix.dll is being used