3Dmigoto now open-source...
  106 / 143    
[quote="Oomek"] Forgive me for saying it, but using 3DM soley for fixing stereo effects is a waste of potential. [/quote] Agreed. Making hotkeys to disable or modify some effects is fun, especially when a game doesn't give you any options for them (although what I usually do is a lot simpler than what you are trying to do with shadows).
Oomek said:
Forgive me for saying it, but using 3DM soley for fixing stereo effects is a waste of potential.


Agreed. Making hotkeys to disable or modify some effects is fun, especially when a game doesn't give you any options for them (although what I usually do is a lot simpler than what you are trying to do with shadows).

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 10/05/2017 07:21 PM   
I have a question (or petition if it isn't possible currently, the most probable case): is there a way in "d3dx.ini" to have synchronized cycles/toggles when using different keys to change variables or separation or convergence? Assigning two keys for the same "Key =" would be a good step forwards, although incomplete. I'm asking because sometimes I make hotkeys for the same stuff in keyboard and controller, and it's jarring how values cycle in a separate way. For example, in my currently WIP Trails in the Sky fix, I made a hotkey in the controller to set "x = 0", but if I use the HUD depth hotkey after that, it doesn't start from the first value. The function I ask would be like this: I press a key that would trigger a "cycle", then 3Dmigoto checks the current value to see what step should be the current one in the cycle. If it's different, then it gets corrected. If the current value doesn't exist, then it could either go to the nearest higher value, or not be corrected, I don't know. Btw, about Trails in the Sky, I passed "rt_width" and "rt_height" to the main HUD vertex shader and used the width as an extra condition to not use HUD depth. That fixed the previous inability to restore the "picture" the game takes in the pause menu when the HUD is at depth when opening it. I still need to set x to 0 after opening it (maybe an extra filtering by some unique texture would help), but now it doesn't have the extra wrong depth that was very annoying.
I have a question (or petition if it isn't possible currently, the most probable case): is there a way in "d3dx.ini" to have synchronized cycles/toggles when using different keys to change variables or separation or convergence? Assigning two keys for the same "Key =" would be a good step forwards, although incomplete.

I'm asking because sometimes I make hotkeys for the same stuff in keyboard and controller, and it's jarring how values cycle in a separate way. For example, in my currently WIP Trails in the Sky fix, I made a hotkey in the controller to set "x = 0", but if I use the HUD depth hotkey after that, it doesn't start from the first value.

The function I ask would be like this: I press a key that would trigger a "cycle", then 3Dmigoto checks the current value to see what step should be the current one in the cycle. If it's different, then it gets corrected. If the current value doesn't exist, then it could either go to the nearest higher value, or not be corrected, I don't know.



Btw, about Trails in the Sky, I passed "rt_width" and "rt_height" to the main HUD vertex shader and used the width as an extra condition to not use HUD depth. That fixed the previous inability to restore the "picture" the game takes in the pause menu when the HUD is at depth when opening it. I still need to set x to 0 after opening it (maybe an extra filtering by some unique texture would help), but now it doesn't have the extra wrong depth that was very annoying.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 10/06/2017 07:25 PM   
[quote] I was thinking about 2 routes to draw those missing objects: 1. Store the geometry from the later shaders that draw the textured objects and use them in the additional pass of the vertex shader that calculate the depth buffer for the shadow map. The objects will be drawn 1 frame late, but because those are static there will be no offset in the depth map. 2. Store the transformation matrices of the orthogonal view and render additional pass after the textured objects by skipping the pixel shader and using those orthogonal view transform matrices. Then I could mix the result in the next frame with rendered depth buffer before shadow map shader is called. That would need to have some sort of orthogonal camera offset compensation in the custom shader that mixes the depth buffers, as the orthogonal view transform matrices will be late by 1 frame. [/quote] Both of those sound like plausible solutions. Number 2 sounds workable with the current feature level in 3DMigoto, but I guess getting the maths right could be tricky. I think you were asking about this earlier and I had some thoughts - have you explored that possibility very much? Number 1 is intriguing, and I have my own reasons for wanting something along similar lines (e.g. fixing the broken soldier x-ray effect in MGSV by capturing the original geometry of the soldier that works in stereo and using that instead of the x-ray geometry that is massively broken in stereo, but I don't know in advance which ones I will need), but we need to wary that we may need more support in 3DMigoto for that to work, and I don't have any target date in mind for that support, so if you're in a hurry I would caution against it - but, let's discuss anyway. [quote] What you described I see that the most difficult brickwall to crush would be handling multiple passes of the shaders drawing buildings. [/quote] Yes, I think so. 3DMigoto currently allows you to use the following draw/dispatch calls from any command list (not just custom shader sections): [code] draw = from_caller (special case, as you already know) Draw = VertexCount, StartVertexLocation DrawIndexed = IndexCount, StartIndexLocation, BaseVertexLocation DrawIndexedInstanced = IndexCountPerInstance, InstanceCount, StartIndexLocation, BaseVertexLocation, StartInstanceLocation DrawInstanced = VertexCountPerInstance, InstanceCount, StartVertexLocation, StartInstanceLocation Dispatch = ThreadGroupCountX, ThreadGroupCountY, ThreadGroupCountZ [/code] What is missing are: [code] DrawIndexedInstancedIndirect = ResourceFoo, AlignedByteOffsetForArgs DrawInstancedIndirect = ResourceFoo, AlignedByteOffsetForArgs DispatchIndirect = ResourceFoo, AlignedByteOffsetForArgs DrawAuto* [/code] The indirect draw calls are almost never used in games, but they are actually really interesting for us, because we offload so much of our logic to shaders on the GPU already, and these can allow those shaders to fill in the details of how many vertices, indexes and instances to draw... You could essentially have a buffer that is filled out by a custom shader to record the parameters passed to each draw call in turn so that later when you want to draw the geometry you use the indirect draw calls with varying offsets into that buffer The other thing we are missing, is a way to call DrawWhatever an arbitrary number of times that we don't know in advance. You could have a command list that calls it a set number of times and the vertex shader simply aborts once you have drawn all the geometry you want, but ultimately what we probably want here is flow control in the command lists, and more flexibility in ini param assignment (x = x + 1) to give us loops. I was only planning to introduce 'if' for conditional flow control at first, but maybe this is a reason to also think about adding at least one kind of loop (or at a pinch, maybe goto - but I'd rather stick to things that I can have 3DMigoto monitor for runaway infinite loops and forcefully abort if they exceed some threshold - we already have such a limit (64) when calling command lists or custom shaders recursively). The question is - what are you going to need, and is that going to be enough? Is there anything (else) we are missing? Can you do everything you need with certain draw calls you know in advance (and specifically know on the CPU, because 3DMigoto (currently**) lacks a way to read back information from the GPU (and that is slow anyway)), or might you also need to choose which draw call to use for each piece of geometry (in which case, do we need to expose more variables and possibly variable arrays you can use from the command lists to store that? Because, if you need to store something like that IniParams might start to feel rather small rather quickly)? * We actually do have DrawAuto supported, but we don't yet have support to configure shaders to use the stream output stage so it is only useful if the game is also using this, and I'm not aware of any that do. This is also potentially quite interesting for us because it could allow us to stream out a bunch of geometry for use in later rendering passes, and I have a couple of ideas that might be able to make use of this. I'm not sure it would be useful for your current situation though, since the geometry streamed out would be after any transformations have been applied, but maybe you could use a geometry shader to stream the transformed geometry to the rasterizer and untransformed geometry to the stream output... DrawAuto is so named because it automatically knows how much geometry to draw based on how much has been streamed into the buffers. ** I may already be thinking about adding an asynchronous variant of that for a shader controlled auto convergence feature in 3DMigoto... [quote]Making 3DM modular is a very interesting idea. It would surpass the ReShade wrapper by the magnitude of 100[/quote]I haven't personally used ReShade and am not familiar with it's capabilities and limitations, but just out of curiosity - why did you choose to go with 3DMigoto? I mean, I know very well just how powerful it is and I can see good reasons to use it, but I am not aware of how it stacks up to the competition for anything outside of stereo modding. [quote]Forgive me for saying it, but using 3DM solely for fixing stereo effects is a waste of potential.[/quote]I'm not saying we limit it to fixing stereo effects, but that is it's primary focus - with the features I've added I've gone with the approach of trying not to limit it to fixing the specific problems I was working on at the time, always thinking about ways I can generalise it so that it can solve other problems that I haven't thought of yet - and it just so happens that means that it's uses go far outside of stereo effects and that will continue :) But, there is a balancing act when adding new capabilities (for stereo or otherwise) because any new feature we add increases the complexity of the 3DMigoto code base, and while I feel fairly confident working on the resource copying code because I wrote it and know how it works, it is already quite complicated and I would pretty much guarantee that if a new programmer came onboard today and started expanding that or even just fixing current limitations or bugs, they would almost certainly introduce new bugs because it is quite complicated and they won't fully understand the implications of certain changes (I've been there when joining other projects). That means I'm wary of adding things that are going to result in a signifcant increase in complexity without a) a good reason, b) a clear benefit, c) no realistic or better alternative, d) a clear idea of how it will fit in and interact with the rest of the command list and resource copying code, and e) confidence that I'm not coding us into a corner that will make our lives harder later. Hence, why I need this discussion to help understand everything and flesh out the ideas before diving into the code. [quote]The custom resources that automaticaly build in a stack would be a nice feature. Instead of overriding the data it would add another element to the queue. When you consume the data by referencing to it, it could increment the pointer to the next/previous element.[/quote]I see you and I think the same - this is something I've thought would be useful as well. But see, in this sentence you have already stated some limitations and assumptions that I'm not sure we want - should this always be a queue? Why not a stack, or just allow random access? What is this array built on - DirectX already has resource arrays and we already have some support for those, so do we use that, or do we implement our own arrays on top of that***, or do we support both? How do we allocate this array - do we statically allocate it in advance, or dynamically increase it's size****? Do we really want the pointer to magically advance - what if we want to use one element multiple times? Once we have this array, how do we use it? Do we want a 'for each' style loop that can iterate over elements? Do we want to expose it all in a single resource slot (DirectX arrays only) or allow binding the view to select which subresource or array element is used? These kind of questions (and probably others I haven't thought of yet) would need to be answered before implementing this. *** Limiting us to using DirectX resource arrays would drastically simplify this and has some clear advantages in terms of binding these resource arrays to a shader, and I'm inclined to prefer that approach because it means only a linear increase in complexity instead of an exponential one, however one big downside I can see is that copying by reference only works at the level of the whole resource - so, this would mean requiring full subresource copies, which could very quickly add up to an unacceptable performance penalty. **** This would be another downside of using DirectX resource arrays - we need to allocate their size in advance unless we want to end up doing a bunch of subresource copies which would suck for performance. We could use a policy of only growing these and never shrinking them, limiting that performance cost to the first few times they are used. [quote][quote]I have made some progress towards support for append/consume/counter structured buffers, which could also be used to provide the atomic guarantees you need to update a counter from multiple shader invocations simultaneously, but it needs some rework of the view cache to make it useful, and I decided that was a little too risky for the last release given how much other stuff was already going in and I could make do without it. Let me know if you feel you need this.[/quote] Not sure about what you mean by saying atomic, is it what I just wrote but in different words?[/quote]"Atomic" just means that the read-modify-write sequence involved with e.g. incrementing a counter appears to happen as one logical unit - there can be no possible timing that would allow two threads to read the same value or writing back the incremented value out of order - each thread is guaranteed to read a unique value and the total amount the counter is incremented will match the number of threads that incremented it. One point of caution - atomic does *NOT* mean fast, and in fact is quite a bit slower than incrementing a value non-atomically (that doesn't mean it will be bad, but don't forget or underestimate it). Think of the read and increment as happening with a lock held, because on the hardware level that is almost exactly what is happening (in fact, on PowerPC atomic operations are implemented using the exact same lwarx & stwcx. instructions as locks*****. PowerPC is RISC, so assume that any other architecture that might appear to use fewer instructions are actually microcoded and doing pretty much the same thing under the hood - there are very few (sane) ways to implement locking primitives in hardware, so they all pretty much look the same when you get down deep enough, and they all operate on a principle of locking cache lines in some way, and GPUs are not special in this regard. Never underestimate the significance of caching effects on performance (desktop Intel peeps are beginning to learn this as they get around to slowly adding more cores and their caches are getting further apart and taking longer for cache lines to migrate between cores - I used to work for IBM, we made CPUs aimed at high end servers that have insanely high numbers of cores and threads and we've been dealing with this forever. We have dedicated performance teams that work on improving open source applications to not suck as the number of cores and threads increase). ***** [url]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/asm/atomic.h#n133[/url] This is more about how you go about filling up the custom resource and making sure that you don't have multiple threads trampling over each other. If you fire off a custom compute shader of just one single thread running in one single thread group to write to it you don't have to worry - and that's probably what I'd suggest to start with. I bought this up because I was thinking about your instanced geometry problem where you may want the buffer filled out from multiple threads / shader invocations simultaneously for performance reasons (or because you are piggy backing the updates in a shader from the game and are not in control of how many invocations there are), in which case you need some way for each thread/instance to know where in the buffer they need to write that doesn't trample over other threads or data already in the buffer. If that takes the form of a common counter that each thread accesses you need some way to atomically read and increment that counter so the threads don't trample over each other, which InterlockedAdd() and Append/Consume Structured Buffers give you. There are other possible approaches though, like making every thread use their thread ID / instance ID to determine the offset into the buffer that they own, but if you need to track this between multiple draw calls you may still need something to increment that counter, and you would need to do so in way that ensures that there is no race between threads.

I was thinking about 2 routes to draw those missing objects:

1. Store the geometry from the later shaders that draw the textured objects and use them in the additional pass of the vertex shader that calculate the depth buffer for the shadow map. The objects will be drawn 1 frame late, but because those are static there will be no offset in the depth map.

2. Store the transformation matrices of the orthogonal view and render additional pass after the textured objects by skipping the pixel shader and using those orthogonal view transform matrices. Then I could mix the result in the next frame with rendered depth buffer before shadow map shader is called. That would need to have some sort of orthogonal camera offset compensation in the custom shader that mixes the depth buffers, as the orthogonal view transform matrices will be late by 1 frame.

Both of those sound like plausible solutions. Number 2 sounds workable with the current feature level in 3DMigoto, but I guess getting the maths right could be tricky. I think you were asking about this earlier and I had some thoughts - have you explored that possibility very much?

Number 1 is intriguing, and I have my own reasons for wanting something along similar lines (e.g. fixing the broken soldier x-ray effect in MGSV by capturing the original geometry of the soldier that works in stereo and using that instead of the x-ray geometry that is massively broken in stereo, but I don't know in advance which ones I will need), but we need to wary that we may need more support in 3DMigoto for that to work, and I don't have any target date in mind for that support, so if you're in a hurry I would caution against it - but, let's discuss anyway.


What you described I see that the most difficult brickwall to crush would be handling multiple passes of the shaders drawing buildings.

Yes, I think so.

3DMigoto currently allows you to use the following draw/dispatch calls from any command list (not just custom shader sections):
draw = from_caller (special case, as you already know)
Draw = VertexCount, StartVertexLocation
DrawIndexed = IndexCount, StartIndexLocation, BaseVertexLocation
DrawIndexedInstanced = IndexCountPerInstance, InstanceCount, StartIndexLocation, BaseVertexLocation, StartInstanceLocation
DrawInstanced = VertexCountPerInstance, InstanceCount, StartVertexLocation, StartInstanceLocation
Dispatch = ThreadGroupCountX, ThreadGroupCountY, ThreadGroupCountZ


What is missing are:

DrawIndexedInstancedIndirect = ResourceFoo, AlignedByteOffsetForArgs
DrawInstancedIndirect = ResourceFoo, AlignedByteOffsetForArgs
DispatchIndirect = ResourceFoo, AlignedByteOffsetForArgs
DrawAuto*


The indirect draw calls are almost never used in games, but they are actually really interesting for us, because we offload so much of our logic to shaders on the GPU already, and these can allow those shaders to fill in the details of how many vertices, indexes and instances to draw... You could essentially have a buffer that is filled out by a custom shader to record the parameters passed to each draw call in turn so that later when you want to draw the geometry you use the indirect draw calls with varying offsets into that buffer

The other thing we are missing, is a way to call DrawWhatever an arbitrary number of times that we don't know in advance. You could have a command list that calls it a set number of times and the vertex shader simply aborts once you have drawn all the geometry you want, but ultimately what we probably want here is flow control in the command lists, and more flexibility in ini param assignment (x = x + 1) to give us loops. I was only planning to introduce 'if' for conditional flow control at first, but maybe this is a reason to also think about adding at least one kind of loop (or at a pinch, maybe goto - but I'd rather stick to things that I can have 3DMigoto monitor for runaway infinite loops and forcefully abort if they exceed some threshold - we already have such a limit (64) when calling command lists or custom shaders recursively).

The question is - what are you going to need, and is that going to be enough? Is there anything (else) we are missing? Can you do everything you need with certain draw calls you know in advance (and specifically know on the CPU, because 3DMigoto (currently**) lacks a way to read back information from the GPU (and that is slow anyway)), or might you also need to choose which draw call to use for each piece of geometry (in which case, do we need to expose more variables and possibly variable arrays you can use from the command lists to store that? Because, if you need to store something like that IniParams might start to feel rather small rather quickly)?

* We actually do have DrawAuto supported, but we don't yet have support to configure shaders to use the stream output stage so it is only useful if the game is also using this, and I'm not aware of any that do. This is also potentially quite interesting for us because it could allow us to stream out a bunch of geometry for use in later rendering passes, and I have a couple of ideas that might be able to make use of this. I'm not sure it would be useful for your current situation though, since the geometry streamed out would be after any transformations have been applied, but maybe you could use a geometry shader to stream the transformed geometry to the rasterizer and untransformed geometry to the stream output... DrawAuto is so named because it automatically knows how much geometry to draw based on how much has been streamed into the buffers.

** I may already be thinking about adding an asynchronous variant of that for a shader controlled auto convergence feature in 3DMigoto...

Making 3DM modular is a very interesting idea. It would surpass the ReShade wrapper by the magnitude of 100
I haven't personally used ReShade and am not familiar with it's capabilities and limitations, but just out of curiosity - why did you choose to go with 3DMigoto? I mean, I know very well just how powerful it is and I can see good reasons to use it, but I am not aware of how it stacks up to the competition for anything outside of stereo modding.

Forgive me for saying it, but using 3DM solely for fixing stereo effects is a waste of potential.
I'm not saying we limit it to fixing stereo effects, but that is it's primary focus - with the features I've added I've gone with the approach of trying not to limit it to fixing the specific problems I was working on at the time, always thinking about ways I can generalise it so that it can solve other problems that I haven't thought of yet - and it just so happens that means that it's uses go far outside of stereo effects and that will continue :)

But, there is a balancing act when adding new capabilities (for stereo or otherwise) because any new feature we add increases the complexity of the 3DMigoto code base, and while I feel fairly confident working on the resource copying code because I wrote it and know how it works, it is already quite complicated and I would pretty much guarantee that if a new programmer came onboard today and started expanding that or even just fixing current limitations or bugs, they would almost certainly introduce new bugs because it is quite complicated and they won't fully understand the implications of certain changes (I've been there when joining other projects).

That means I'm wary of adding things that are going to result in a signifcant increase in complexity without a) a good reason, b) a clear benefit, c) no realistic or better alternative, d) a clear idea of how it will fit in and interact with the rest of the command list and resource copying code, and e) confidence that I'm not coding us into a corner that will make our lives harder later. Hence, why I need this discussion to help understand everything and flesh out the ideas before diving into the code.

The custom resources that automaticaly build in a stack would be a nice feature. Instead of overriding the data it would add another element to the queue. When you consume the data by referencing to it, it could increment the pointer to the next/previous element.
I see you and I think the same - this is something I've thought would be useful as well. But see, in this sentence you have already stated some limitations and assumptions that I'm not sure we want - should this always be a queue? Why not a stack, or just allow random access? What is this array built on - DirectX already has resource arrays and we already have some support for those, so do we use that, or do we implement our own arrays on top of that***, or do we support both? How do we allocate this array - do we statically allocate it in advance, or dynamically increase it's size****? Do we really want the pointer to magically advance - what if we want to use one element multiple times? Once we have this array, how do we use it? Do we want a 'for each' style loop that can iterate over elements? Do we want to expose it all in a single resource slot (DirectX arrays only) or allow binding the view to select which subresource or array element is used?

These kind of questions (and probably others I haven't thought of yet) would need to be answered before implementing this.

*** Limiting us to using DirectX resource arrays would drastically simplify this and has some clear advantages in terms of binding these resource arrays to a shader, and I'm inclined to prefer that approach because it means only a linear increase in complexity instead of an exponential one, however one big downside I can see is that copying by reference only works at the level of the whole resource - so, this would mean requiring full subresource copies, which could very quickly add up to an unacceptable performance penalty.

**** This would be another downside of using DirectX resource arrays - we need to allocate their size in advance unless we want to end up doing a bunch of subresource copies which would suck for performance. We could use a policy of only growing these and never shrinking them, limiting that performance cost to the first few times they are used.

I have made some progress towards support for append/consume/counter structured buffers, which could also be used to provide the atomic guarantees you need to update a counter from multiple shader invocations simultaneously, but it needs some rework of the view cache to make it useful, and I decided that was a little too risky for the last release given how much other stuff was already going in and I could make do without it. Let me know if you feel you need this.


Not sure about what you mean by saying atomic, is it what I just wrote but in different words?
"Atomic" just means that the read-modify-write sequence involved with e.g. incrementing a counter appears to happen as one logical unit - there can be no possible timing that would allow two threads to read the same value or writing back the incremented value out of order - each thread is guaranteed to read a unique value and the total amount the counter is incremented will match the number of threads that incremented it. One point of caution - atomic does *NOT* mean fast, and in fact is quite a bit slower than incrementing a value non-atomically (that doesn't mean it will be bad, but don't forget or underestimate it). Think of the read and increment as happening with a lock held, because on the hardware level that is almost exactly what is happening (in fact, on PowerPC atomic operations are implemented using the exact same lwarx & stwcx. instructions as locks*****. PowerPC is RISC, so assume that any other architecture that might appear to use fewer instructions are actually microcoded and doing pretty much the same thing under the hood - there are very few (sane) ways to implement locking primitives in hardware, so they all pretty much look the same when you get down deep enough, and they all operate on a principle of locking cache lines in some way, and GPUs are not special in this regard. Never underestimate the significance of caching effects on performance (desktop Intel peeps are beginning to learn this as they get around to slowly adding more cores and their caches are getting further apart and taking longer for cache lines to migrate between cores - I used to work for IBM, we made CPUs aimed at high end servers that have insanely high numbers of cores and threads and we've been dealing with this forever. We have dedicated performance teams that work on improving open source applications to not suck as the number of cores and threads increase).

***** https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/asm/atomic.h#n133

This is more about how you go about filling up the custom resource and making sure that you don't have multiple threads trampling over each other. If you fire off a custom compute shader of just one single thread running in one single thread group to write to it you don't have to worry - and that's probably what I'd suggest to start with.

I bought this up because I was thinking about your instanced geometry problem where you may want the buffer filled out from multiple threads / shader invocations simultaneously for performance reasons (or because you are piggy backing the updates in a shader from the game and are not in control of how many invocations there are), in which case you need some way for each thread/instance to know where in the buffer they need to write that doesn't trample over other threads or data already in the buffer. If that takes the form of a common counter that each thread accesses you need some way to atomically read and increment that counter so the threads don't trample over each other, which InterlockedAdd() and Append/Consume Structured Buffers give you. There are other possible approaches though, like making every thread use their thread ID / instance ID to determine the offset into the buffer that they own, but if you need to track this between multiple draw calls you may still need something to increment that counter, and you would need to do so in way that ensures that there is no race between threads.

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

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

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

Posted 10/07/2017 03:01 PM   
[quote="masterotaku"]I have a question (or petition if it isn't possible currently, the most probable case): is there a way in "d3dx.ini" to have synchronized cycles/toggles when using different keys to change variables or separation or convergence? Assigning two keys for the same "Key =" would be a good step forwards, although incomplete. I'm asking because sometimes I make hotkeys for the same stuff in keyboard and controller, and it's jarring how values cycle in a separate way. For example, in my currently WIP Trails in the Sky fix, I made a hotkey in the controller to set "x = 0", but if I use the HUD depth hotkey after that, it doesn't start from the first value. The function I ask would be like this: I press a key that would trigger a "cycle", then 3Dmigoto checks the current value to see what step should be the current one in the cycle. If it's different, then it gets corrected. If the current value doesn't exist, then it could either go to the nearest higher value, or not be corrected, I don't know.[/quote]Can you add that to this feature request we have open so we don't lose track of it - I kind of see this as an extension of the feature request to allow a second key to cycle backwards: https://github.com/bo3b/3Dmigoto/issues/43 [quote]Btw, about Trails in the Sky, I passed "rt_width" and "rt_height" to the main HUD vertex shader and used the width as an extra condition to not use HUD depth. That fixed the previous inability to restore the "picture" the game takes in the pause menu when the HUD is at depth when opening it.[/quote]Good to know :) [quote]I still need to set x to 0 after opening it (maybe an extra filtering by some unique texture would help), but now it doesn't have the extra wrong depth that was very annoying.[/quote]What's x in this case? If it's something you are using for texture filtering, consider using something like this to set it only during the draw call you are filtering: [code] x = ps-t0 post x = 0 [/code]
masterotaku said:I have a question (or petition if it isn't possible currently, the most probable case): is there a way in "d3dx.ini" to have synchronized cycles/toggles when using different keys to change variables or separation or convergence? Assigning two keys for the same "Key =" would be a good step forwards, although incomplete.

I'm asking because sometimes I make hotkeys for the same stuff in keyboard and controller, and it's jarring how values cycle in a separate way. For example, in my currently WIP Trails in the Sky fix, I made a hotkey in the controller to set "x = 0", but if I use the HUD depth hotkey after that, it doesn't start from the first value.

The function I ask would be like this: I press a key that would trigger a "cycle", then 3Dmigoto checks the current value to see what step should be the current one in the cycle. If it's different, then it gets corrected. If the current value doesn't exist, then it could either go to the nearest higher value, or not be corrected, I don't know.
Can you add that to this feature request we have open so we don't lose track of it - I kind of see this as an extension of the feature request to allow a second key to cycle backwards:

https://github.com/bo3b/3Dmigoto/issues/43

Btw, about Trails in the Sky, I passed "rt_width" and "rt_height" to the main HUD vertex shader and used the width as an extra condition to not use HUD depth. That fixed the previous inability to restore the "picture" the game takes in the pause menu when the HUD is at depth when opening it.
Good to know :)

I still need to set x to 0 after opening it (maybe an extra filtering by some unique texture would help), but now it doesn't have the extra wrong depth that was very annoying.
What's x in this case? If it's something you are using for texture filtering, consider using something like this to set it only during the draw call you are filtering:
x = ps-t0
post x = 0

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

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

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

Posted 10/07/2017 03:14 PM   
[quote="DarkStarSword"]Can you add that to this feature request we have open so we don't lose track of it - I kind of see this as an extension of the feature request to allow a second key to cycle backwards: https://github.com/bo3b/3Dmigoto/issues/43[/quote] Done. [quote="DarkStarSword"]What's x in this case? If it's something you are using for texture filtering, consider using something like this to set it only during the draw call you are filtering: [code] x = ps-t0 post x = 0 [/code] [/quote] "x" is just the HUD depth value (I use values between 0 and 1). I still didn't try texture filtering, but there's something that fixes the pause menu picture when I open it, as long as I don't change "x" while using it (the left and right borders are clipped a bit. And I'm not compensating the Y variable depth when it's in use): [code] if (iniparams1.x==1 && iniparams2.x==4096 && r1.z<199) { o0.x-=stereo.x*iniparams.x*0.625; } [/code] "iniparams2.x" is the render target width, "iniparams1.x" is a condition in a ShaderOverride to use it with a certain pixel shader, and I use "r1.z" to filter certain geometry elements. It overcompensates in area transitions, but the pause picture is 100% OK regarding depth. Trying texture filtering is an extra step that I should try. My head is generating smoke already :p. Well, in any case this is for extra stuff that was my fault to implement, not something that needed a fix or anything. If you are curious, after that "if" condition, there is this "else": [code] else { if (iniparams1.x==1 && r1.z<199 && iniparams2.x==res.x) { if (iniparams.x>0) { o0.x+=stereo.x*iniparams.x+stereo.x*o0.y*0.25*iniparams.y; } else { o0.x+=stereo.x*iniparams.x; } o0.x=o0.x*iniparams.z; } } [/code] Stuff about HUD depth, toggle and Y variable depth. It shouldn't take long before I publish this fix anyway.
DarkStarSword said:Can you add that to this feature request we have open so we don't lose track of it - I kind of see this as an extension of the feature request to allow a second key to cycle backwards:

https://github.com/bo3b/3Dmigoto/issues/43


Done.

DarkStarSword said:What's x in this case? If it's something you are using for texture filtering, consider using something like this to set it only during the draw call you are filtering:
x = ps-t0
post x = 0



"x" is just the HUD depth value (I use values between 0 and 1). I still didn't try texture filtering, but there's something that fixes the pause menu picture when I open it, as long as I don't change "x" while using it (the left and right borders are clipped a bit. And I'm not compensating the Y variable depth when it's in use):

if (iniparams1.x==1 && iniparams2.x==4096 && r1.z<199)
{
o0.x-=stereo.x*iniparams.x*0.625;
}


"iniparams2.x" is the render target width, "iniparams1.x" is a condition in a ShaderOverride to use it with a certain pixel shader, and I use "r1.z" to filter certain geometry elements. It overcompensates in area transitions, but the pause picture is 100% OK regarding depth.

Trying texture filtering is an extra step that I should try. My head is generating smoke already :p. Well, in any case this is for extra stuff that was my fault to implement, not something that needed a fix or anything.

If you are curious, after that "if" condition, there is this "else":

else
{
if (iniparams1.x==1 && r1.z<199 && iniparams2.x==res.x)
{
if (iniparams.x>0)
{
o0.x+=stereo.x*iniparams.x+stereo.x*o0.y*0.25*iniparams.y;
}
else
{
o0.x+=stereo.x*iniparams.x;
}
o0.x=o0.x*iniparams.z;
}
}


Stuff about HUD depth, toggle and Y variable depth. It shouldn't take long before I publish this fix anyway.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 10/07/2017 04:15 PM   
[quote]I haven't personally used ReShade and am not familiar with it's capabilities and limitations, but just out of curiosity - why did you choose to go with 3DMigoto? I mean, I know very well just how powerful it is and I can see good reasons to use it, but I am not aware of how it stacks up to the competition for anything outside of stereo modding.[/quote] ReShade is a Direct3D wrapper/compiler with an extendable set of post process shaders which have an acces to the final back buffer and the depth buffer. It has a nice gui which allows you to tweak all the exposed variables from shaders in realtime using a mouse. There is no way though to dump/modify game’s shaders. I chose 3DMigoto as it allows to fix bugs/lazy coding/unnecessary compromises (“optimizations” for cheap gpus)/improve the visuals in shader code of some games. I first discovered it few years back when I wanted to disable the vignette in Mass Effect 2 and I fell in love. I will respond to the rest of your elaborate as soon as I force my brain out of the comfort zone which is single-threaded processing ;) Update: I used Helix in Mass Effect 2 mod as it is a DX9 game, then I discovered 3DMigoto.
I haven't personally used ReShade and am not familiar with it's capabilities and limitations, but just out of curiosity - why did you choose to go with 3DMigoto? I mean, I know very well just how powerful it is and I can see good reasons to use it, but I am not aware of how it stacks up to the competition for anything outside of stereo modding.

ReShade is a Direct3D wrapper/compiler with an extendable set of post process shaders which have an acces to the final back buffer and the depth buffer. It has a nice gui which allows you to tweak all the exposed variables from shaders in realtime using a mouse. There is no way though to dump/modify game’s shaders.

I chose 3DMigoto as it allows to fix bugs/lazy coding/unnecessary compromises (“optimizations” for cheap gpus)/improve the visuals in shader code of some games. I first discovered it few years back when I wanted to disable the vignette in Mass Effect 2 and I fell in love.

I will respond to the rest of your elaborate as soon as I force my brain out of the comfort zone which is single-threaded processing ;)

Update: I used Helix in Mass Effect 2 mod as it is a DX9 game, then I discovered 3DMigoto.

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 10/07/2017 08:01 PM   
I'm having troubles clearing the custom resource in depth buffer format When I do this the resource is black no matter what color I set it in the clear.ps.hlsl Strangely even if I comment the line [code]run = CustomShaderClearRT[/code] it's still black. The resource is displayed properly in the mixdown shader only when I comment another line [code]o0 = Resource-ShadowDepthBuildings[/code] [code] [Resource-ShadowDepthBuildings] format = R32_FLOAT [ResourceBackupRT] [ShaderOverride-Mixdown3] Hash = 87a1c7a31aaab7ac ps-t111 = Resource-ShadowDepthBuildings post ps-t111 = null [ShaderOverride-Buildings.vs] hash = dbbc54b506d62e0a post Resource-ShadowDepthBuildings = copy oD [CustomShaderClearRT] max_executions_per_frame = 1 blend = disable vs = Shaders\clear\clear.vs.hlsl ps = Shaders\clear\clear.ps.hlsl ResourceBackupRT = ref o0 oD = null o0 = copy_desc Resource-ShadowDepthBuildings o0 = Resource-ShadowDepthBuildings Draw = 6, 0 post o0 = ResourceBackupRT [Present] post run = CustomShaderClearRT [/code] UPDATE: nevermind, I made a copy of the depth buffer after it's cleared by the game from the first shader drawing the depth for shadows, so I do not have to clear it myself.
I'm having troubles clearing the custom resource in depth buffer format

When I do this the resource is black no matter what color I set it in the clear.ps.hlsl
Strangely even if I comment the line

run = CustomShaderClearRT

it's still black. The resource is displayed properly in the mixdown shader only when I comment another line

o0 = Resource-ShadowDepthBuildings

[Resource-ShadowDepthBuildings]
format = R32_FLOAT

[ResourceBackupRT]

[ShaderOverride-Mixdown3]
Hash = 87a1c7a31aaab7ac
ps-t111 = Resource-ShadowDepthBuildings
post ps-t111 = null

[ShaderOverride-Buildings.vs]
hash = dbbc54b506d62e0a
post Resource-ShadowDepthBuildings = copy oD

[CustomShaderClearRT]
max_executions_per_frame = 1
blend = disable
vs = Shaders\clear\clear.vs.hlsl
ps = Shaders\clear\clear.ps.hlsl
ResourceBackupRT = ref o0
oD = null
o0 = copy_desc Resource-ShadowDepthBuildings
o0 = Resource-ShadowDepthBuildings
Draw = 6, 0
post o0 = ResourceBackupRT

[Present]
post run = CustomShaderClearRT



UPDATE: nevermind, I made a copy of the depth buffer after it's cleared by the game from the first shader drawing the depth for shadows, so I do not have to clear it myself.

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 10/09/2017 04:20 PM   
Glad to hear you got it working. BTW 3DMigoto 1.2.66 will include a clear command to simplify this: https://github.com/bo3b/3Dmigoto/commit/0f5bb989b24180db939aa90aa86f90c3e738f70c
Glad to hear you got it working. BTW 3DMigoto 1.2.66 will include a clear command to simplify this:


https://github.com/bo3b/3Dmigoto/commit/0f5bb989b24180db939aa90aa86f90c3e738f70c

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

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

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

Posted 10/11/2017 07:04 AM   
[quote="DarkStarSword"]Glad to hear you got it working. BTW 3DMigoto 1.2.66 will include a clear command to simplify this:[/quote]WOW! I've been waiting for this for so long! Fantastic work DSS! I've spent 2 days at A&E as I've had a flare up of symptoms, but since it's calming down I would like to continue tinkering on where we stopped. I was trying to implement the first option of drawing shadows called from the main diffuse shader using the transformation matrices from the orthogonal view. I don't know why, but there is still something not overrriden from the diffuse shader that makes the depth output looking bad. The objects are drawn not on the whole 4k x 4k shadowmap but only on the viewport sized rectangle. I've temporarily scaled the custom vs output even further to fit that rectangle to see anything. [code][ResourceBackupCB3] [Resource-ShadowDepthBuildings] max_copies_per_frame=1 [ShaderOverride-ShadowDepthBuildings.vs] hash = 01b3ac67ae349a8a Resource-CameraParamsConstantBuffer = copy vs-cb3 Resource-ShadowDepthBuildings = copy oD [CustomShader-Buildings.vs] ResourceBackupCB3 = vs-cb3 vs-cb3 = Resource-CameraParamsConstantBuffer vs = Shaders\01b3ac67ae349a8a-vs_replace.hlsl ps = null oD = Resource-ShadowDepthBuildings o0 = null draw = from_caller post vs-cb3 = ResourceBackupCB3 [ShaderOverride-Buildings.vs] hash = dbbc54b506d62e0a post run = CustomShader-Buildings.vs[/code] 01b3ac67ae349a8a-vs_replace.hlsl [code]// Depth for shadows called from main diffuse shader cbuffer _Globals : register(b0) { float4x4 model : packoffset(c0); float4x4 modelViewProj : packoffset(c4); float4 ShadowDepth : packoffset(c8); float4 SlopeBiasVector : packoffset(c9); } cbuffer CameraParamsConstantBuffer : register(b3) { float4x4 projection : packoffset(c0); float4x4 viewProjection : packoffset(c4); row_major float3x4 view : packoffset(c8); row_major float3x4 viewI : packoffset(c11); float3 eyePositionWS : packoffset(c14); float4x4 inverseProj : packoffset(c15); bool leftEye : packoffset(c19); bool padding3[3] : packoffset(c20); } // 3Dmigoto declarations #define cmp - Texture1D<float4> IniParams : register(t120); Texture2D<float4> StereoParams : register(t125); void main( float3 v0 : POSITION0, float3 v1 : NORMAL0, out float4 o0 : SV_Position0) { float4 r0,r1; uint4 bitmask, uiDest; float4 fDest; r0.xyzw = viewProjection._m01_m11_m21_m31 * model._m11_m11_m11_m11; r0.xyzw = viewProjection._m00_m10_m20_m30 * model._m01_m01_m01_m01 + r0.xyzw; r0.xyzw = viewProjection._m02_m12_m22_m32 * model._m21_m21_m21_m21 + r0.xyzw; r0.xyzw = viewProjection._m03_m13_m23_m33 * model._m31_m31_m31_m31 + r0.xyzw; r0.xyzw = v0.yyyy * r0.xyzw; r1.xyzw = viewProjection._m01_m11_m21_m31 * model._m10_m10_m10_m10; r1.xyzw = viewProjection._m00_m10_m20_m30 * model._m00_m00_m00_m00 + r1.xyzw; r1.xyzw = viewProjection._m02_m12_m22_m32 * model._m20_m20_m20_m20 + r1.xyzw; r1.xyzw = viewProjection._m03_m13_m23_m33 * model._m30_m30_m30_m30 + r1.xyzw; r0.xyzw = r1.xyzw * v0.xxxx + r0.xyzw; r1.xyzw = viewProjection._m01_m11_m21_m31 * model._m12_m12_m12_m12; r1.xyzw = viewProjection._m00_m10_m20_m30 * model._m02_m02_m02_m02 + r1.xyzw; r1.xyzw = viewProjection._m02_m12_m22_m32 * model._m22_m22_m22_m22 + r1.xyzw; r1.xyzw = viewProjection._m03_m13_m23_m33 * model._m32_m32_m32_m32 + r1.xyzw; r0.xyzw = r1.xyzw * v0.zzzz + r0.xyzw; r1.xyzw = viewProjection._m01_m11_m21_m31 * model._m13_m13_m13_m13; r1.xyzw = viewProjection._m00_m10_m20_m30 * model._m03_m03_m03_m03 + r1.xyzw; r1.xyzw = viewProjection._m02_m12_m22_m32 * model._m23_m23_m23_m23 + r1.xyzw; r1.xyzw = viewProjection._m03_m13_m23_m33 + r1.xyzw; o0.xyzw = r1.xyzw + r0.xyzw; o0.xy *= 0.0625; return; }[/code] I have some doubts regarding the second way. From my observations it looks like the drawcalls of objects in the diffuse shader aren't queued exacty in the same order as in the orthogonal view drawing depth for the shadows (culling skips some objects that are still visible in the orthogonal view). Thus storing the geometry for reuse in the next pass of the depth for shadows seems to be a dead end.
DarkStarSword said:Glad to hear you got it working. BTW 3DMigoto 1.2.66 will include a clear command to simplify this:
WOW! I've been waiting for this for so long! Fantastic work DSS!


I've spent 2 days at A&E as I've had a flare up of symptoms, but since it's calming down I would like to continue tinkering on where we stopped.

I was trying to implement the first option of drawing shadows called from the main diffuse shader using the transformation matrices from the orthogonal view. I don't know why, but there is still something not overrriden from the diffuse shader that makes the depth output looking bad. The objects are drawn not on the whole 4k x 4k shadowmap but only on the viewport sized rectangle. I've temporarily scaled the custom vs output even further to fit that rectangle to see anything.

[ResourceBackupCB3]

[Resource-ShadowDepthBuildings]
max_copies_per_frame=1

[ShaderOverride-ShadowDepthBuildings.vs]
hash = 01b3ac67ae349a8a
Resource-CameraParamsConstantBuffer = copy vs-cb3
Resource-ShadowDepthBuildings = copy oD

[CustomShader-Buildings.vs]
ResourceBackupCB3 = vs-cb3
vs-cb3 = Resource-CameraParamsConstantBuffer
vs = Shaders\01b3ac67ae349a8a-vs_replace.hlsl
ps = null
oD = Resource-ShadowDepthBuildings
o0 = null
draw = from_caller
post vs-cb3 = ResourceBackupCB3

[ShaderOverride-Buildings.vs]
hash = dbbc54b506d62e0a
post run = CustomShader-Buildings.vs



01b3ac67ae349a8a-vs_replace.hlsl
// Depth for shadows called from main diffuse shader

cbuffer _Globals : register(b0)
{
float4x4 model : packoffset(c0);
float4x4 modelViewProj : packoffset(c4);
float4 ShadowDepth : packoffset(c8);
float4 SlopeBiasVector : packoffset(c9);
}

cbuffer CameraParamsConstantBuffer : register(b3)
{
float4x4 projection : packoffset(c0);
float4x4 viewProjection : packoffset(c4);
row_major float3x4 view : packoffset(c8);
row_major float3x4 viewI : packoffset(c11);
float3 eyePositionWS : packoffset(c14);
float4x4 inverseProj : packoffset(c15);
bool leftEye : packoffset(c19);
bool padding3[3] : packoffset(c20);
}



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


void main(
float3 v0 : POSITION0,
float3 v1 : NORMAL0,
out float4 o0 : SV_Position0)
{
float4 r0,r1;
uint4 bitmask, uiDest;
float4 fDest;


r0.xyzw = viewProjection._m01_m11_m21_m31 * model._m11_m11_m11_m11;
r0.xyzw = viewProjection._m00_m10_m20_m30 * model._m01_m01_m01_m01 + r0.xyzw;
r0.xyzw = viewProjection._m02_m12_m22_m32 * model._m21_m21_m21_m21 + r0.xyzw;
r0.xyzw = viewProjection._m03_m13_m23_m33 * model._m31_m31_m31_m31 + r0.xyzw;
r0.xyzw = v0.yyyy * r0.xyzw;
r1.xyzw = viewProjection._m01_m11_m21_m31 * model._m10_m10_m10_m10;
r1.xyzw = viewProjection._m00_m10_m20_m30 * model._m00_m00_m00_m00 + r1.xyzw;
r1.xyzw = viewProjection._m02_m12_m22_m32 * model._m20_m20_m20_m20 + r1.xyzw;
r1.xyzw = viewProjection._m03_m13_m23_m33 * model._m30_m30_m30_m30 + r1.xyzw;
r0.xyzw = r1.xyzw * v0.xxxx + r0.xyzw;
r1.xyzw = viewProjection._m01_m11_m21_m31 * model._m12_m12_m12_m12;
r1.xyzw = viewProjection._m00_m10_m20_m30 * model._m02_m02_m02_m02 + r1.xyzw;
r1.xyzw = viewProjection._m02_m12_m22_m32 * model._m22_m22_m22_m22 + r1.xyzw;
r1.xyzw = viewProjection._m03_m13_m23_m33 * model._m32_m32_m32_m32 + r1.xyzw;
r0.xyzw = r1.xyzw * v0.zzzz + r0.xyzw;
r1.xyzw = viewProjection._m01_m11_m21_m31 * model._m13_m13_m13_m13;
r1.xyzw = viewProjection._m00_m10_m20_m30 * model._m03_m03_m03_m03 + r1.xyzw;
r1.xyzw = viewProjection._m02_m12_m22_m32 * model._m23_m23_m23_m23 + r1.xyzw;
r1.xyzw = viewProjection._m03_m13_m23_m33 + r1.xyzw;
o0.xyzw = r1.xyzw + r0.xyzw;
o0.xy *= 0.0625;
return;
}



I have some doubts regarding the second way. From my observations it looks like the drawcalls of objects in the diffuse shader aren't queued exacty in the same order as in the orthogonal view drawing depth for the shadows (culling skips some objects that are still visible in the orthogonal view). Thus storing the geometry for reuse in the next pass of the depth for shadows seems to be a dead end.

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 10/12/2017 12:59 PM   
[quote="Oomek"]The objects are drawn not on the whole 4k x 4k shadowmap but only on the viewport sized rectangle.[/quote] Try the set_viewport modifier when assigning the depth buffer, as in: [code] oD = set_viewport Resource-ShadowDepthBuildings [/code]
Oomek said:The objects are drawn not on the whole 4k x 4k shadowmap but only on the viewport sized rectangle.

Try the set_viewport modifier when assigning the depth buffer, as in:
oD = set_viewport Resource-ShadowDepthBuildings

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

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

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

Posted 10/12/2017 05:02 PM   
hello, I discovered something weird with IL2 Bos. The value given in StereoParams did not allow to define eye. They are always positive. Even the side by side screen feature of the default mod displays images for both eyes on each half display. They made a very good implementation of 3dvision but some things are strange: for example separation does only change on a short range in game, even if the green number displayed by 3dmigoto showned huge values. So could it be possible to have a new information on 3dmigoto that may be the frame parity (even/odd) in order to be able to define which eye is displayed ?
hello,
I discovered something weird with IL2 Bos.
The value given in StereoParams did not allow to define eye. They are always positive. Even the side by side screen feature of the default mod displays images for both eyes on each half display.
They made a very good implementation of 3dvision but some things are strange: for example separation does only change on a short range in game, even if the green number displayed by 3dmigoto showned huge values.
So could it be possible to have a new information on 3dmigoto that may be the frame parity (even/odd) in order to be able to define which eye is displayed ?

Posted 10/12/2017 08:06 PM   
What is IL2 Bos? If it's something using 3D Vision Direct than that all makes sense because it is not the nvidia driver providing the second view or the stereo formula so 3DMigoto has no way to know which eye is which, the usual formula may or may not apply, and the separation and convergence values may or may not be meaningless, and the game probably won't be taking the monitor size into account either giving you a rubbish amount of depth or violating infinity. If you want to fix something in the game you either need to cooperate with it, figure out what stereo formula or stereo matrices they are using, work out how to determine which eye is which, etc. Or, set automatic_mode=1 in the d3dx.ini to disable the game's stereo renderer and use 3D Vision Automatic. Everything in 3DMigoto will then work as expected, and the problem you described with the limited separation will be solved (seriously, how hard is it for developers to get that right? Because so far the only one I've seen to get this right is Dirt 3, because it used the same value from the driver that 3D Vision Automatic uses to calculate this) but the downside is that there will probably be a bunch of broken effects that you would then need to fix.
What is IL2 Bos? If it's something using 3D Vision Direct than that all makes sense because it is not the nvidia driver providing the second view or the stereo formula so 3DMigoto has no way to know which eye is which, the usual formula may or may not apply, and the separation and convergence values may or may not be meaningless, and the game probably won't be taking the monitor size into account either giving you a rubbish amount of depth or violating infinity.

If you want to fix something in the game you either need to cooperate with it, figure out what stereo formula or stereo matrices they are using, work out how to determine which eye is which, etc.

Or, set automatic_mode=1 in the d3dx.ini to disable the game's stereo renderer and use 3D Vision Automatic. Everything in 3DMigoto will then work as expected, and the problem you described with the limited separation will be solved (seriously, how hard is it for developers to get that right? Because so far the only one I've seen to get this right is Dirt 3, because it used the same value from the driver that 3D Vision Automatic uses to calculate this) but the downside is that there will probably be a bunch of broken effects that you would then need to fix.

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

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

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

Posted 10/13/2017 03:15 AM   
Il2 battle of stalingrad: https://il2sturmovik.com/ They made a wonderfull 3dvision implementation coming with the VR. There are few things that did bother me that I fixed for 3dvision and VR with shaded modification function of 3dmigoto: sight size, label/icon masking by cockpit frame, zoom (for VR), color (for VR), eye separation (for VR) I just wanted to test if I can made some extra separation by shifting left and right eye images for 3dvision, but found that I can not have the eye information. I managed to find the eye for VR because the view are displayed for each eye in the same frame in VR. It should not be the case for 3dvision, so I do not know a robust way of finding the eye without StereoParams.
Il2 battle of stalingrad: https://il2sturmovik.com/


They made a wonderfull 3dvision implementation coming with the VR. There are few things that did bother me that I fixed for 3dvision and VR with shaded modification function of 3dmigoto: sight size, label/icon masking by cockpit frame, zoom (for VR), color (for VR), eye separation (for VR)
I just wanted to test if I can made some extra separation by shifting left and right eye images for 3dvision, but found that I can not have the eye information.
I managed to find the eye for VR because the view are displayed for each eye in the same frame in VR. It should not be the case for 3dvision, so I do not know a robust way of finding the eye without StereoParams.

Posted 10/13/2017 07:51 PM   
It might be in a constant buffer somewhere, or may be encoded directly into their projection matrix. A projection matrix with a stereo correction equivalent to the nvidia formula will look like: [code] [w, 0, 0, 0] [0, h, 0, 0] [a, 0, q, 1] [b, 0, Q, 0] a = eye * separation b = -eye * separation * convergence [/code] a is the off-center part of the projection matrix, and that *should* be present for a stereo correction even if it isn't equivalent to the nvidia formula, so you should be able to use whether that is positive or negative to work out which eye is being drawn. a defines infinity, and if it is missing infinity would be placed at screen depth. Depending on how they've done their stereo correction b may be in either the projection matrix, view matrix, or a separate camera offset (note that if it is not in the projection matrix it would be b/w if you want to use algebra to work out the equivalent separation & convergence values). b is the part that provides the actual stereo effect and places things at different depths as it describes how far apart the eyes are.
It might be in a constant buffer somewhere, or may be encoded directly into their projection matrix. A projection matrix with a stereo correction equivalent to the nvidia formula will look like:

[w, 0, 0, 0]
[0, h, 0, 0]
[a, 0, q, 1]
[b, 0, Q, 0]

a = eye * separation
b = -eye * separation * convergence


a is the off-center part of the projection matrix, and that *should* be present for a stereo correction even if it isn't equivalent to the nvidia formula, so you should be able to use whether that is positive or negative to work out which eye is being drawn. a defines infinity, and if it is missing infinity would be placed at screen depth.

Depending on how they've done their stereo correction b may be in either the projection matrix, view matrix, or a separate camera offset (note that if it is not in the projection matrix it would be b/w if you want to use algebra to work out the equivalent separation & convergence values). b is the part that provides the actual stereo effect and places things at different depths as it describes how far apart the eyes are.

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

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

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

Posted 10/14/2017 01:57 AM   
[quote="DarkStarSword"][quote="Oomek"]The objects are drawn not on the whole 4k x 4k shadowmap but only on the viewport sized rectangle.[/quote] Try the set_viewport modifier when assigning the depth buffer, as in: [code] oD = set_viewport Resource-ShadowDepthBuildings [/code][/quote] I'm an idiot. I thought set_vieport only affect the pixel shader. I have a question about that feature you are working on allowing to clear the resources from the ini. What would be faster? making a full copy of an empty back buffer filled with 1.0 or clearing the custom resource using your method?
DarkStarSword said:
Oomek said:The objects are drawn not on the whole 4k x 4k shadowmap but only on the viewport sized rectangle.

Try the set_viewport modifier when assigning the depth buffer, as in:
oD = set_viewport Resource-ShadowDepthBuildings

I'm an idiot. I thought set_vieport only affect the pixel shader.

I have a question about that feature you are working on allowing to clear the resources from the ini. What would be faster? making a full copy of an empty back buffer filled with 1.0 or clearing the custom resource using your method?

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 10/14/2017 10:07 AM   
  106 / 143    
Scroll To Top