Hm, it seems like 3DM fails to copy the resource with TextureCube type through a temp storage. When I do that I get tons of errors:
Resource copy RecreateCompatibleTexture failed: 0x80070057
Resource copy error: Could not create/update destination resource
Are the TextureCube types supported by the resource copying path yet?
Hmmm, I haven't tested copying cube maps explicitly but I would have expected it to work since the new resource description is only modified slightly from the original (usage, bind flags, cpu access flags, and sometimes format) - I'll have to try it when I get home.
I have been running into that error a little as I try out more combinations and find all the edge cases where it doesn't work without special casing it (things like needing to change the resource format of a depth buffer when it is created with bind flags for use in a texture slot). If this turns out to be one of those cases I may need to add some extra debug output to 3DMigoto to understand exactly what combination of flags it is using.
Edit: Is the scenario the same as your last post? If not, can you post all sections from your d3dx.ini that mention the resource so I can understand what flags 3DMigoto will be trying use for the temporary resource.
Hmmm, I haven't tested copying cube maps explicitly but I would have expected it to work since the new resource description is only modified slightly from the original (usage, bind flags, cpu access flags, and sometimes format) - I'll have to try it when I get home.
I have been running into that error a little as I try out more combinations and find all the edge cases where it doesn't work without special casing it (things like needing to change the resource format of a depth buffer when it is created with bind flags for use in a texture slot). If this turns out to be one of those cases I may need to add some extra debug output to 3DMigoto to understand exactly what combination of flags it is using.
Edit: Is the scenario the same as your last post? If not, can you post all sections from your d3dx.ini that mention the resource so I can understand what flags 3DMigoto will be trying use for the temporary resource.
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
No, its a completely different topic, I was trying to copy the cube map buffer from one shader to another.
Here is the ini part:
[code]
[ResourceEnvMap]
[ShaderOverride-de448b85220d5373]
Hash = de448b85220d5373
ResourceEnvMap = ps-t10
[ShaderOverride-76f43aebfc305c37]
Hash = 76f43aebfc305c37
ps-t110 = copy ResourceEnvMap
[/code]
and the inits from the pixel shader:
[code]
TextureCube<float4> _TEnvironmentMap : register(t10);
Texture2D<float4> _TScreenReflection : register(t11);
[/code]
_TScreenReflection initializes without any issues when I change t10 to t11.
ok, just copying a texture slot to texture slot so there shouldn't be anything too unusual for 3DMigoto to cope with there... I'll have a look tonight to see if there's anything specific to cube maps I might be missing - I'll let you know if I need any more info.
BTW I love that you are coming up with creative ways to use this feature :)
ok, just copying a texture slot to texture slot so there shouldn't be anything too unusual for 3DMigoto to cope with there... I'll have a look tonight to see if there's anything specific to cube maps I might be missing - I'll let you know if I need any more info.
BTW I love that you are coming up with creative ways to use this feature :)
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
I've just released 3DMigoto 1.2.11 a little early - it won't fix the cube map issue, but I'm not seeing the same symptom as you so I'd like you to run with this version as it should produce some more log messages when RecreateCompatibleTexture fails that might provide some insight. From my own testing I think I'll also need to copy more info from the original view than I currently do for cube maps to work, but that is a moot point if it can't even create the copy of the resource.
That said, you might be able to get the cube map copy working if you do all the copies by reference since you are only copying from a texture slot to another texture slot, so long as the game doesn't go and overwrite the resource in the meantime.
I've just released 3DMigoto 1.2.11 a little early - it won't fix the cube map issue, but I'm not seeing the same symptom as you so I'd like you to run with this version as it should produce some more log messages when RecreateCompatibleTexture fails that might provide some insight. From my own testing I think I'll also need to copy more info from the original view than I currently do for cube maps to work, but that is a moot point if it can't even create the copy of the resource.
That said, you might be able to get the cube map copy working if you do all the copies by reference since you are only copying from a texture slot to another texture slot, so long as the game doesn't go and overwrite the resource in the meantime.
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
[center][size="XL"][url=https://github.com/bo3b/3Dmigoto/releases/tag/1.2.11]3DMigoto 1.2.11[/url][/size][/center]
This version includes a whole lot of code rework under the hood:
[code]
$ git diff 1.2.10 1.2.11 --stat -- '*.h' '*.cpp'
DirectX11/CommandList.cpp | 709 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------
DirectX11/CommandList.h | 86 ++++++++++++++++++-------
DirectX11/FrameAnalysis.cpp | 88 ++++++++++++++++---------
DirectX11/HackerContext.cpp | 278 ++++++++++++++++++++++++++++---------------------------------------------------
DirectX11/HackerContext.h | 25 ++++----
DirectX11/HackerDXGI.cpp | 45 ++-----------
DirectX11/HackerDevice.cpp | 399 +++++++++---------------------------------------------------------------------------------------------------------
DirectX11/HackerDevice.h | 3 -
DirectX11/Hunting.cpp | 290 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------
DirectX11/Hunting.h | 1 +
DirectX11/IniHandler.cpp | 120 +++++++++++++++++++++++++++++++---
DirectX11/ResourceHash.cpp | 826 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DirectX11/ResourceHash.h | 168 ++++++++++++++++++++++++++++++++++++++++++++++++
DirectX11/globals.h | 68 ++++++++------------
version.h | 2 +-
15 files changed, 2182 insertions(+), 926 deletions(-)
[/code]
So I'd rate the chance of bugs as moderate - if you run into any problems please revert back to 1.2.10
[size="M"][b][color="orange"]This version includes several changes that might impact people using texture filtering![/color][/b][/size]
1. It adds a new track_texture_updates option to the d3dx.ini, which when enabled will track updates to textures from the CPU, as well as copies on the GPU and will update & propagate the texture hashes as necessary. If you have found a game where a texture seemed to posses different hashes at different times this option might solve it!
Additionally, if this feature is DISABLED, but hunting is enabled 3DMigoto will still perform some basic tracking and will note any hashes in the ShaderUsage.txt that might be impacted as contaminated. These will also show up in frame analysis filenames as the letters M, U, C, S in exclamation marks before the hash (the letters signify what operation may have contaminated the hash). If you see these in a texture you are trying to match, it's telling you that you may need to turn the feature on and restart the game.
If you have the option enabled then both the current and original hashes will be added to ShaderUsage.txt and frame analysis (in frame analysis, the original hash will be in brackets after the current hash).
2. Texture array hashes may have changed in some cases. This will be a subset of any hashes that changed in 1.2.9, and no one reported any problem then so I'm not expecting this to impact anyone.
3. Resources are only hashed if they are created through CreateTexture2D/CreateTexture3D - all other resources will now have a hash of 0. In practice, this should mostly be limited to 3DMigoto's internal textures and those copied using 3DMigoto, but it seems the swap chain's back buffer was also affected. I don't really plan to restore the code to hash these lazily again as we had a number of concerns about it, but if people need any of these resources hashed let me know and I'll see if I can do it properly. Note that 1D textures and buffers have never been hashed and will continue to show with a hash of 0.
[size="M"][b][color="green"]But there's lots of cool stuff too ^_^[/color][/b][/size]
- Reverse stereo blit can be invoked in arbitrary resource copying with the 'stereo2mono' keyword (may have some limitations if using anti-aliasing or copying from a depth buffer - need to confirm). I am using this to improve the accuracy of my auto stereo crosshair code.
- 'mono' and 'stereo' keywords added to resource copying to force the driver surface creation mode when creating a new resource (I haven't needed these specifically, but stereo2mono depended on this).
- A [Resource] section can now have a filename=blah parameter to load the custom resource with a texture. Use your imagination for this one - I'm using it to paint the region of the screen that contains various HUD elements and to blacklist/whitelist depth adjustments to individual icons contained in a larger texture.
- Vertex and index buffers can be injected into a shader in a texture slot (or a constant buffer slot, but they are harder to work with this purpose). Vertex buffers will be injected as a structured buffer and index buffers will be injected as a plain old regular buffer. These can be accessed from HLSL to get information from other vertices in the same draw call (I am using this in FC4 to locate the center of each UI icon).
- dump_vb_txt and dump_ib_txt frame analysis options are more useful as they take the data offset into account and dump out some more info. Vertex buffers may not interpret all the data correctly, but what they do interpret is still useful.
- The vertex/index/instance count of the current draw call (except "indirect" or "auto" draw calls) can be injected into an ini param by setting it to "vertex_count", "index_count" or "instance_count" from a ShaderOverride, which can be useful when combined with a vertex/index buffer (e.g. find the center of a word of text from a single draw call).
- ShaderUsage.txt now includes the description of the textures in the file (in the same way it already did for render targets and depth buffers). Note that if you have enabled track_texture_updates you will need to use the orig_hash to cross-reference these, not the current hash.
- [TextureOverride] sections now support many of the same commands as [ShaderOverride] and [Present] sections. But there's a catch - they will only be processed if you invoke them from a [ShaderOverride] section with something like "checktextureoverride = ps-t0". This is a prelude to full scene detection, but is already useful in some limited circumstances (I'm using it to detect a previous texture drawn in the current frame).
- Resource copying now includes a 'resolve_msaa' keyword, but [color="orange"]USE WITH CAUTION AS IT HAS COMPATIBILITY ISSUES THAT I DO NOT FULLY UNDERSTAND THE IMPLICATIONS OF![/color] On my GPU I can use it to resolve an MSAA colour texture, but I cannot resolve an MSAA depth buffer. I do not know how universal support for this is, so using it might be a recipe for a fix that only works for some people.
So I'd rate the chance of bugs as moderate - if you run into any problems please revert back to 1.2.10
This version includes several changes that might impact people using texture filtering!
1. It adds a new track_texture_updates option to the d3dx.ini, which when enabled will track updates to textures from the CPU, as well as copies on the GPU and will update & propagate the texture hashes as necessary. If you have found a game where a texture seemed to posses different hashes at different times this option might solve it!
Additionally, if this feature is DISABLED, but hunting is enabled 3DMigoto will still perform some basic tracking and will note any hashes in the ShaderUsage.txt that might be impacted as contaminated. These will also show up in frame analysis filenames as the letters M, U, C, S in exclamation marks before the hash (the letters signify what operation may have contaminated the hash). If you see these in a texture you are trying to match, it's telling you that you may need to turn the feature on and restart the game.
If you have the option enabled then both the current and original hashes will be added to ShaderUsage.txt and frame analysis (in frame analysis, the original hash will be in brackets after the current hash).
2. Texture array hashes may have changed in some cases. This will be a subset of any hashes that changed in 1.2.9, and no one reported any problem then so I'm not expecting this to impact anyone.
3. Resources are only hashed if they are created through CreateTexture2D/CreateTexture3D - all other resources will now have a hash of 0. In practice, this should mostly be limited to 3DMigoto's internal textures and those copied using 3DMigoto, but it seems the swap chain's back buffer was also affected. I don't really plan to restore the code to hash these lazily again as we had a number of concerns about it, but if people need any of these resources hashed let me know and I'll see if I can do it properly. Note that 1D textures and buffers have never been hashed and will continue to show with a hash of 0.
But there's lots of cool stuff too ^_^
- Reverse stereo blit can be invoked in arbitrary resource copying with the 'stereo2mono' keyword (may have some limitations if using anti-aliasing or copying from a depth buffer - need to confirm). I am using this to improve the accuracy of my auto stereo crosshair code.
- 'mono' and 'stereo' keywords added to resource copying to force the driver surface creation mode when creating a new resource (I haven't needed these specifically, but stereo2mono depended on this).
- A [Resource] section can now have a filename=blah parameter to load the custom resource with a texture. Use your imagination for this one - I'm using it to paint the region of the screen that contains various HUD elements and to blacklist/whitelist depth adjustments to individual icons contained in a larger texture.
- Vertex and index buffers can be injected into a shader in a texture slot (or a constant buffer slot, but they are harder to work with this purpose). Vertex buffers will be injected as a structured buffer and index buffers will be injected as a plain old regular buffer. These can be accessed from HLSL to get information from other vertices in the same draw call (I am using this in FC4 to locate the center of each UI icon).
- dump_vb_txt and dump_ib_txt frame analysis options are more useful as they take the data offset into account and dump out some more info. Vertex buffers may not interpret all the data correctly, but what they do interpret is still useful.
- The vertex/index/instance count of the current draw call (except "indirect" or "auto" draw calls) can be injected into an ini param by setting it to "vertex_count", "index_count" or "instance_count" from a ShaderOverride, which can be useful when combined with a vertex/index buffer (e.g. find the center of a word of text from a single draw call).
- ShaderUsage.txt now includes the description of the textures in the file (in the same way it already did for render targets and depth buffers). Note that if you have enabled track_texture_updates you will need to use the orig_hash to cross-reference these, not the current hash.
- [TextureOverride] sections now support many of the same commands as [ShaderOverride] and [Present] sections. But there's a catch - they will only be processed if you invoke them from a [ShaderOverride] section with something like "checktextureoverride = ps-t0". This is a prelude to full scene detection, but is already useful in some limited circumstances (I'm using it to detect a previous texture drawn in the current frame).
- Resource copying now includes a 'resolve_msaa' keyword, but USE WITH CAUTION AS IT HAS COMPATIBILITY ISSUES THAT I DO NOT FULLY UNDERSTAND THE IMPLICATIONS OF! On my GPU I can use it to resolve an MSAA colour texture, but I cannot resolve an MSAA depth buffer. I do not know how universal support for this is, so using it might be a recipe for a fix that only works for some people.
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="lefuneste"]
the sky in DCS10_90.jps is normal for each eye and is black for each eye in DCS09_90.jps.
If the stereo variable was working for this shader shouldn't have a black sky for only one eye ?
[/quote]
I found the problem I suppress the 3dvision profile using NVidiaInspector and I have now different images for each eye !
lefuneste said:
the sky in DCS10_90.jps is normal for each eye and is black for each eye in DCS09_90.jps.
If the stereo variable was working for this shader shouldn't have a black sky for only one eye ?
I found the problem I suppress the 3dvision profile using NVidiaInspector and I have now different images for each eye !
Sorry for the delay in response.
You were right! TextureCube referencing worked without any issues (I finally got almost real world reflection in puddles: just need some coordinates translation as the reflection is not properly aligned).
[img]http://i.imgur.com/DV5oaC1.jpg[/img]
[img]http://i.imgur.com/jQHulp8.jpg[/img]
Here is the detailed error generated by 3DM 1.2.11 when I attmept to copy.
[code]RecreateCompatibleTexture: Creating cached resource
Resource copy RecreateCompatibleTexture failed: 0x80070057
Width = 1024
Height = 1024
MipLevels = 11
ArraySize = 6
Format = R10G10B10A2_UNORM (24)
SampleDesc.Count = 1
SampleDesc.Quality = 0
Usage = 0
BindFlags = 0x8
CPUAccessFlags = 0x0
MiscFlags = 0x5
Resource copy error: Could not create/update destination resource[/code]
Sorry for the delay in response.
You were right! TextureCube referencing worked without any issues (I finally got almost real world reflection in puddles: just need some coordinates translation as the reflection is not properly aligned).
Here is the detailed error generated by 3DM 1.2.11 when I attmept to copy.
[quote="Oomek"]Sorry for the delay in response.
You were right! TextureCube referencing worked without any issues (I finally got almost real world reflection in puddles: just need some coordinates translation as the reflection is not properly aligned).[/quote]Great :)
[quote]Here is the detailed error generated by 3DM 1.2.11 when I attmept to copy.[/quote]Ahh, I think I see the problem - one of the misc flags isn't compatible with the bind flags 3DMigoto chose. Thanks for testing that :)
Oomek said:Sorry for the delay in response.
You were right! TextureCube referencing worked without any issues (I finally got almost real world reflection in puddles: just need some coordinates translation as the reflection is not properly aligned).
Great :)
Here is the detailed error generated by 3DM 1.2.11 when I attmept to copy.
Ahh, I think I see the problem - one of the misc flags isn't compatible with the bind flags 3DMigoto chose. Thanks for testing that :)
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
One issue though, when I change the car's reflection map quality in the game settings the referenced texture stops updating. I assume it's due to the change in the texture resolution. Is there any way to work around it?
One issue though, when I change the car's reflection map quality in the game settings the referenced texture stops updating. I assume it's due to the change in the texture resolution. Is there any way to work around it?
It's worth double checking that changing the quality didn't switch to a different set of shaders, which is fairly common.
The texture resolution shouldn't matter, and since you are copying by reference it is actually just using the same resource the game already created. MSAA textures can be a problem if they are copied into a shader model 4 shader, but if changing the setting changed it to use MSAA I'm sure it would have also changed to a different shader.
Another possibility is that the cube map is being assigned as both an input and an output at the same time on that quality setting. If that's the case, you want to unbind it from the pipeline after you have used it with 'post ps-t110 = null'
It's worth double checking that changing the quality didn't switch to a different set of shaders, which is fairly common.
The texture resolution shouldn't matter, and since you are copying by reference it is actually just using the same resource the game already created. MSAA textures can be a problem if they are copied into a shader model 4 shader, but if changing the setting changed it to use MSAA I'm sure it would have also changed to a different shader.
Another possibility is that the cube map is being assigned as both an input and an output at the same time on that quality setting. If that's the case, you want to unbind it from the pipeline after you have used it with 'post ps-t110 = null'
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
Adding the post line didn't help, is it how it's supposed to look like?
[code]
[ResourceEnvMap]
[ShaderOverride-61bb9c893fef673f]
Hash = 61bb9c893fef673f
ResourceEnvMap = reference ps-t10
[ShaderOverride-76f43aebfc305c37]
Hash = 76f43aebfc305c37
ps-t110 = ResourceEnvMap
post ps-t110 = null
[/code]
Pressing F10 only fixes the problem.
This is what I did so far, I'm rendering just the cubemap for debug purposes.
https://www.youtube.com/watch?v=1XvSdYkwP9Q
As you can see on the video there is a misaligment of the cubemap taken from the car's body when it's displayed on the road. Do you know by any chance if some coordinates translation would help to mitigate that misaligment? Or the cubemap needs to be rendered second time from the different point of view? I'm out of ideas.
This is what I did so far, I'm rendering just the cubemap for debug purposes.
As you can see on the video there is a misaligment of the cubemap taken from the car's body when it's displayed on the road. Do you know by any chance if some coordinates translation would help to mitigate that misaligment? Or the cubemap needs to be rendered second time from the different point of view? I'm out of ideas.
This looks awesome!
It probably is possible to do some adjustment to improve that, but I'm not an expert on the maths involved in cube map reflections, so I'm not sure what. I do know that there are whole whitepapers published on the subject of misaligned reflections from cube maps and reflection probes, so it's clearly not an easy subject.
One possibly naive idea is that since it appears to be aligned perfectly in the center of the screen and become more and more misaligned on the sides, perhaps you could use the screen X coordinate of the road to adjust where the cube map is sampled?
[quote="Oomek"]Adding the post line didn't help, is it how it's supposed to look like?[/quote]Yeah, that looks right.
[quote]Pressing F10 only fixes the problem.[/quote]Hmmm, that's an interesting data point. Pressing F10 will destroy all temporary and cached resources/views that 3DMigoto has created and recreate them... I wonder if the cached view is causing issues... Looks like I have Dirt 3 in my library, so I can take a look at this later.
It probably is possible to do some adjustment to improve that, but I'm not an expert on the maths involved in cube map reflections, so I'm not sure what. I do know that there are whole whitepapers published on the subject of misaligned reflections from cube maps and reflection probes, so it's clearly not an easy subject.
One possibly naive idea is that since it appears to be aligned perfectly in the center of the screen and become more and more misaligned on the sides, perhaps you could use the screen X coordinate of the road to adjust where the cube map is sampled?
Oomek said:Adding the post line didn't help, is it how it's supposed to look like?
Yeah, that looks right.
Pressing F10 only fixes the problem.
Hmmm, that's an interesting data point. Pressing F10 will destroy all temporary and cached resources/views that 3DMigoto has created and recreate them... I wonder if the cached view is causing issues... Looks like I have Dirt 3 in my library, so I can take a look at this later.
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
Resource copy RecreateCompatibleTexture failed: 0x80070057
Resource copy error: Could not create/update destination resource
Are the TextureCube types supported by the resource copying path yet?
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
I have been running into that error a little as I try out more combinations and find all the edge cases where it doesn't work without special casing it (things like needing to change the resource format of a depth buffer when it is created with bind flags for use in a texture slot). If this turns out to be one of those cases I may need to add some extra debug output to 3DMigoto to understand exactly what combination of flags it is using.
Edit: Is the scenario the same as your last post? If not, can you post all sections from your d3dx.ini that mention the resource so I can understand what flags 3DMigoto will be trying use for the temporary resource.
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
Here is the ini part:
and the inits from the pixel shader:
_TScreenReflection initializes without any issues when I change t10 to t11.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
BTW I love that you are coming up with creative ways to use this feature :)
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
That said, you might be able to get the cube map copy working if you do all the copies by reference since you are only copying from a texture slot to another texture slot, so long as the game doesn't go and overwrite the resource in the meantime.
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
This version includes a whole lot of code rework under the hood:
So I'd rate the chance of bugs as moderate - if you run into any problems please revert back to 1.2.10
This version includes several changes that might impact people using texture filtering!
1. It adds a new track_texture_updates option to the d3dx.ini, which when enabled will track updates to textures from the CPU, as well as copies on the GPU and will update & propagate the texture hashes as necessary. If you have found a game where a texture seemed to posses different hashes at different times this option might solve it!
Additionally, if this feature is DISABLED, but hunting is enabled 3DMigoto will still perform some basic tracking and will note any hashes in the ShaderUsage.txt that might be impacted as contaminated. These will also show up in frame analysis filenames as the letters M, U, C, S in exclamation marks before the hash (the letters signify what operation may have contaminated the hash). If you see these in a texture you are trying to match, it's telling you that you may need to turn the feature on and restart the game.
If you have the option enabled then both the current and original hashes will be added to ShaderUsage.txt and frame analysis (in frame analysis, the original hash will be in brackets after the current hash).
2. Texture array hashes may have changed in some cases. This will be a subset of any hashes that changed in 1.2.9, and no one reported any problem then so I'm not expecting this to impact anyone.
3. Resources are only hashed if they are created through CreateTexture2D/CreateTexture3D - all other resources will now have a hash of 0. In practice, this should mostly be limited to 3DMigoto's internal textures and those copied using 3DMigoto, but it seems the swap chain's back buffer was also affected. I don't really plan to restore the code to hash these lazily again as we had a number of concerns about it, but if people need any of these resources hashed let me know and I'll see if I can do it properly. Note that 1D textures and buffers have never been hashed and will continue to show with a hash of 0.
But there's lots of cool stuff too ^_^
- Reverse stereo blit can be invoked in arbitrary resource copying with the 'stereo2mono' keyword (may have some limitations if using anti-aliasing or copying from a depth buffer - need to confirm). I am using this to improve the accuracy of my auto stereo crosshair code.
- 'mono' and 'stereo' keywords added to resource copying to force the driver surface creation mode when creating a new resource (I haven't needed these specifically, but stereo2mono depended on this).
- A [Resource] section can now have a filename=blah parameter to load the custom resource with a texture. Use your imagination for this one - I'm using it to paint the region of the screen that contains various HUD elements and to blacklist/whitelist depth adjustments to individual icons contained in a larger texture.
- Vertex and index buffers can be injected into a shader in a texture slot (or a constant buffer slot, but they are harder to work with this purpose). Vertex buffers will be injected as a structured buffer and index buffers will be injected as a plain old regular buffer. These can be accessed from HLSL to get information from other vertices in the same draw call (I am using this in FC4 to locate the center of each UI icon).
- dump_vb_txt and dump_ib_txt frame analysis options are more useful as they take the data offset into account and dump out some more info. Vertex buffers may not interpret all the data correctly, but what they do interpret is still useful.
- The vertex/index/instance count of the current draw call (except "indirect" or "auto" draw calls) can be injected into an ini param by setting it to "vertex_count", "index_count" or "instance_count" from a ShaderOverride, which can be useful when combined with a vertex/index buffer (e.g. find the center of a word of text from a single draw call).
- ShaderUsage.txt now includes the description of the textures in the file (in the same way it already did for render targets and depth buffers). Note that if you have enabled track_texture_updates you will need to use the orig_hash to cross-reference these, not the current hash.
- [TextureOverride] sections now support many of the same commands as [ShaderOverride] and [Present] sections. But there's a catch - they will only be processed if you invoke them from a [ShaderOverride] section with something like "checktextureoverride = ps-t0". This is a prelude to full scene detection, but is already useful in some limited circumstances (I'm using it to detect a previous texture drawn in the current frame).
- Resource copying now includes a 'resolve_msaa' keyword, but USE WITH CAUTION AS IT HAS COMPATIBILITY ISSUES THAT I DO NOT FULLY UNDERSTAND THE IMPLICATIONS OF! On my GPU I can use it to resolve an MSAA colour texture, but I cannot resolve an MSAA depth buffer. I do not know how universal support for this is, so using it might be a recipe for a fix that only works for some people.
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 found the problem I suppress the 3dvision profile using NVidiaInspector and I have now different images for each eye !
You were right! TextureCube referencing worked without any issues (I finally got almost real world reflection in puddles: just need some coordinates translation as the reflection is not properly aligned).
Here is the detailed error generated by 3DM 1.2.11 when I attmept to copy.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Ahh, I think I see the problem - one of the misc flags isn't compatible with the bind flags 3DMigoto chose. Thanks for testing that :)
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
The texture resolution shouldn't matter, and since you are copying by reference it is actually just using the same resource the game already created. MSAA textures can be a problem if they are copied into a shader model 4 shader, but if changing the setting changed it to use MSAA I'm sure it would have also changed to a different shader.
Another possibility is that the cube map is being assigned as both an input and an output at the same time on that quality setting. If that's the case, you want to unbind it from the pipeline after you have used it with 'post ps-t110 = null'
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
Pressing F10 only fixes the problem.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
As you can see on the video there is a misaligment of the cubemap taken from the car's body when it's displayed on the road. Do you know by any chance if some coordinates translation would help to mitigate that misaligment? Or the cubemap needs to be rendered second time from the different point of view? I'm out of ideas.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
It probably is possible to do some adjustment to improve that, but I'm not an expert on the maths involved in cube map reflections, so I'm not sure what. I do know that there are whole whitepapers published on the subject of misaligned reflections from cube maps and reflection probes, so it's clearly not an easy subject.
One possibly naive idea is that since it appears to be aligned perfectly in the center of the screen and become more and more misaligned on the sides, perhaps you could use the screen X coordinate of the road to adjust where the cube map is sampled?
Yeah, that looks right.
Hmmm, that's an interesting data point. Pressing F10 will destroy all temporary and cached resources/views that 3DMigoto has created and recreate them... I wonder if the cached view is causing issues... Looks like I have Dirt 3 in my library, so I can take a look at this later.
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