Native 3D Vision support in Unity Games via Injector
  6 / 8    
I'm still getting random lockups and crashes while running the test app. They're definitely not as frequent though. Before it would crash almost immediately, now it seems to run anywhere from a few seconds up to a few minutes. Usually if it makes it through the first 15 seconds it runs for a bit. This could be issues with my installation, so take this with a grain of salt, but you may want to run some more tests. I noticed that in the logs some of the viewports, and maybe some of buffers that are being resized, are not equal to the actual screen dimensions. There's a few calls for 1024 2048 and other sizes. This could definitely cause issues with rendering. I made some modifications to 3dMigoto so that only sizes that matched the screen width would be doubled. I don't know how to obtain the proper screen dimensions so i just hard coded some values that matched my screen e.g. 1280x720. Doing this got rid of one of the artifacts in the shadows, but they're still being stretched out. Notice in the screen shot below there is no longer that square shadow on the top left corner like in the previous images. Doubling all the viewport calls was affecting the shadow rendering pass as well. Now the shadow pass is rendering properly but it's still not being properly applied to the final image. I could probably fix this by altering the shadow mapping coordinates that are used in the Unity shader but i would prefer to tackle the issue at the source. [url=http://www.iforce.co.nz/View.aspx?i=qdhy40qv.u5y.jpg][img]http://iforce.co.nz/i/qdhy40qv.u5y.jpg[/img][/url]
I'm still getting random lockups and crashes while running the test app. They're definitely not as frequent though. Before it would crash almost immediately, now it seems to run anywhere from a few seconds up to a few minutes. Usually if it makes it through the first 15 seconds it runs for a bit. This could be issues with my installation, so take this with a grain of salt, but you may want to run some more tests.

I noticed that in the logs some of the viewports, and maybe some of buffers that are being resized, are not equal to the actual screen dimensions. There's a few calls for 1024 2048 and other sizes. This could definitely cause issues with rendering. I made some modifications to 3dMigoto so that only sizes that matched the screen width would be doubled. I don't know how to obtain the proper screen dimensions so i just hard coded some values that matched my screen e.g. 1280x720. Doing this got rid of one of the artifacts in the shadows, but they're still being stretched out. Notice in the screen shot below there is no longer that square shadow on the top left corner like in the previous images. Doubling all the viewport calls was affecting the shadow rendering pass as well. Now the shadow pass is rendering properly but it's still not being properly applied to the final image. I could probably fix this by altering the shadow mapping coordinates that are used in the Unity shader but i would prefer to tackle the issue at the source.

Image

Like my work? You can send a donation via Paypal to sgs.rules@gmail.com

Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z

#76
Posted 05/27/2017 06:11 PM   
[quote="sgsrules"]I suspect that unity is getting it's viewport sizes that are used to render the main camera and the shadows from different sources. I've noticed that a lot of unity games are highly dependent on the desktop resolution before launching the game, unity seems to obtain a lot of it's dimensions based on actual screen size. For example, if i use nvidia's 4x DSR, Unity won't let me choose the 4x res unless i change the desktop resolution to 4x prior to launching the game. The main camera is probably obtaining it's size from the screen dimensions, which is why it's rendering correctly. The shadows on the other hand are probably getting there size directly from the size of the buffer. Would it be possible to override the size that is being reported? That way Unity won't know that it's actually a 2x size buffer.[/quote] Not sure I follow what's happening there. I changed the code back to force return the changed results. So for example the pDesc for the CreateSwapChain is returning the 2x value. Same with the RSSetViewPorts, and CreateTexture2D used for CreateDepthStencil. Those all need to be 2x, for drawing purposes, and there is not a good way to manage those at the 3Dmigoto level. So, that means I'd expect Unity to get those return values, where we've modified their original struct, even it was marked as const. So if they use it for sizing purposes, it should work. It's always possible they are doing at GetDesc of some form on a different parameter, but those should also return the 2x sizes. Might be one I've missed though. The only one in particular that seems like it needs tweaking is SwapChain::ResizeTarget. That is presently unchanged, and should likely be 2x-ed. (And probably DXGI_FORMAT_UNKNOWN forced, as we are forcing fullscreen.) How do I demonstrate this problem? To me, this seems like a projection or view matrix problem. Possibly it would be worth using DarkStarSword's approach of modifying the model/global space to avoid needing to tweak other matrices for the reflections.
sgsrules said:I suspect that unity is getting it's viewport sizes that are used to render the main camera and the shadows from different sources. I've noticed that a lot of unity games are highly dependent on the desktop resolution before launching the game, unity seems to obtain a lot of it's dimensions based on actual screen size. For example, if i use nvidia's 4x DSR, Unity won't let me choose the 4x res unless i change the desktop resolution to 4x prior to launching the game. The main camera is probably obtaining it's size from the screen dimensions, which is why it's rendering correctly. The shadows on the other hand are probably getting there size directly from the size of the buffer.

Would it be possible to override the size that is being reported? That way Unity won't know that it's actually a 2x size buffer.

Not sure I follow what's happening there.

I changed the code back to force return the changed results. So for example the pDesc for the CreateSwapChain is returning the 2x value. Same with the RSSetViewPorts, and CreateTexture2D used for CreateDepthStencil.

Those all need to be 2x, for drawing purposes, and there is not a good way to manage those at the 3Dmigoto level.

So, that means I'd expect Unity to get those return values, where we've modified their original struct, even it was marked as const. So if they use it for sizing purposes, it should work.


It's always possible they are doing at GetDesc of some form on a different parameter, but those should also return the 2x sizes. Might be one I've missed though.

The only one in particular that seems like it needs tweaking is SwapChain::ResizeTarget. That is presently unchanged, and should likely be 2x-ed. (And probably DXGI_FORMAT_UNKNOWN forced, as we are forcing fullscreen.)


How do I demonstrate this problem?

To me, this seems like a projection or view matrix problem. Possibly it would be worth using DarkStarSword's approach of modifying the model/global space to avoid needing to tweak other matrices for the reflections.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#77
Posted 05/27/2017 06:15 PM   
[quote="sgsrules"]I'm still getting random lockups and crashes while running the test app. They're definitely not as frequent though. Before it would crash almost immediately, now it seems to run anywhere from a few seconds up to a few minutes. Usually if it makes it through the first 15 seconds it runs for a bit. This could be issues with my installation, so take this with a grain of salt, but you may want to run some more tests. I noticed that in the logs some of the viewports, and maybe some of buffers that are being resized, are not equal to the actual screen dimensions. There's a few calls for 1024 2048 and other sizes. This could definitely cause issues with rendering. I made some modifications to 3dMigoto so that only sizes that matched the screen width would be doubled. I don't know how to obtain the proper screen dimensions so i just hard coded some values that matched my screen e.g. 1280x720. Doing this got rid of one of the artifacts in the shadows, but they're still being stretched out. Notice in the screen shot below there is no longer that square shadow on the top left corner like in the previous images. Doubling all the viewport calls was affecting the shadow rendering pass as well. Now the shadow pass is rendering properly but it's still not being properly applied to the final image. I could probably fix this by altering the shadow mapping coordinates that are used in the Unity shader but i would prefer to tackle the issue at the source. [url=http://www.iforce.co.nz/View.aspx?i=qdhy40qv.u5y.jpg][img]http://iforce.co.nz/i/qdhy40qv.u5y.jpg[/img][/url] [/quote] OK, good to know. I suspected that it would be necessary to only 2x widths that are screen/backbuffer width. I can do this easily in 3Dmigoto, so I'll add that later today. Sample app I've got does not draw stereo, but is in stereo mode, green light on, 3Dmigoto drawing overlay. When I run this app, it's running OK, without crashing. It does a freakish screen flash/window size something when launched, but otherwise no ill effects. (This setup is Win10, 381.x ) If you can continue to push your changes to GitHub, I can keep closer up to date with what you are seeing. If you don't want a public repo, BitBucket allows free private hosting. If you'd rather have admin access directly to 3Dmigoto, please let me know.
sgsrules said:I'm still getting random lockups and crashes while running the test app. They're definitely not as frequent though. Before it would crash almost immediately, now it seems to run anywhere from a few seconds up to a few minutes. Usually if it makes it through the first 15 seconds it runs for a bit. This could be issues with my installation, so take this with a grain of salt, but you may want to run some more tests.

I noticed that in the logs some of the viewports, and maybe some of buffers that are being resized, are not equal to the actual screen dimensions. There's a few calls for 1024 2048 and other sizes. This could definitely cause issues with rendering. I made some modifications to 3dMigoto so that only sizes that matched the screen width would be doubled. I don't know how to obtain the proper screen dimensions so i just hard coded some values that matched my screen e.g. 1280x720. Doing this got rid of one of the artifacts in the shadows, but they're still being stretched out. Notice in the screen shot below there is no longer that square shadow on the top left corner like in the previous images. Doubling all the viewport calls was affecting the shadow rendering pass as well. Now the shadow pass is rendering properly but it's still not being properly applied to the final image. I could probably fix this by altering the shadow mapping coordinates that are used in the Unity shader but i would prefer to tackle the issue at the source.

Image

OK, good to know. I suspected that it would be necessary to only 2x widths that are screen/backbuffer width. I can do this easily in 3Dmigoto, so I'll add that later today.

Sample app I've got does not draw stereo, but is in stereo mode, green light on, 3Dmigoto drawing overlay. When I run this app, it's running OK, without crashing. It does a freakish screen flash/window size something when launched, but otherwise no ill effects. (This setup is Win10, 381.x )

If you can continue to push your changes to GitHub, I can keep closer up to date with what you are seeing. If you don't want a public repo, BitBucket allows free private hosting. If you'd rather have admin access directly to 3Dmigoto, please let me know.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#78
Posted 05/27/2017 06:20 PM   
[quote="bo3b"]It's always possible they are doing at GetDesc of some form on a different parameter, but those should also return the 2x sizes. Might be one I've missed though. The only one in particular that seems like it needs tweaking is SwapChain::ResizeTarget. That is presently unchanged, and should likely be 2x-ed. (And probably DXGI_FORMAT_UNKNOWN forced, as we are forcing fullscreen.) [/quote] It seems like either of these could cause issues since the shadows are not using the proper viewport size. I find it odd that everything else is rendering correctly without me having to adjust the rendering viewport in unity, It would make more sense to me if everything was stretched out and not just the shadows. [quote="bo3b"]To me, this seems like a projection or view matrix problem. Possibly it would be worth using DarkStarSword's approach of modifying the model/global space to avoid needing to tweak other matrices for the reflections.[/quote]I'm fairly certain this is not a projection of view matrix issue. If i leave all the matrices as is the same thing renders in both eyes, but the shadows are still stretched out. I'm pretty sure it's either an issue with the viewport or Unity using the wrong screen coordinates while rendering the shadows. I made the simplest test case possible to make sure that the eye swapping and general setup worked first. I simply offset the camera position along it's x axis, even though it's not stereo we can still see if each target is rendering properly first. This way if things don't render properly we can rule out improper matrix setup. If i had modified any of the matrices I would've possibly wasted time trying to debug them. Simply offsetting the camera's position should not cause the shadows or anything else to go out of whack, which is clearly happening here. Once we can get things to properly render for each target I'll go ahead and apply the the proper matrix modifications. I'm not really worried about the rest of the code involved since i have it working without using 3D Vision Direct, albeit in a rather hacky way by overriding separation and using my own values with 3D Vision Automatic. [quote="bo3b"]Sample app I've got does not draw stereo, but is in stereo mode, green light on, 3Dmigoto drawing overlay. When I run this app, it's running OK, without crashing. It does a freakish screen flash/window size something when launched, but otherwise no ill effects. (This setup is Win10, 381.x ) [/quote] The crashing could be something with my setup, but try running it a few times. I've generally noticed that Unity games tend to resize their window a lot during initialization, which is probably the reason INSIDE gives me issues. I feel like we're pretty close, great work as usual Bo3B!
bo3b said:It's always possible they are doing at GetDesc of some form on a different parameter, but those should also return the 2x sizes. Might be one I've missed though.

The only one in particular that seems like it needs tweaking is SwapChain::ResizeTarget. That is presently unchanged, and should likely be 2x-ed. (And probably DXGI_FORMAT_UNKNOWN forced, as we are forcing fullscreen.)

It seems like either of these could cause issues since the shadows are not using the proper viewport size. I find it odd that everything else is rendering correctly without me having to adjust the rendering viewport in unity, It would make more sense to me if everything was stretched out and not just the shadows.
bo3b said:To me, this seems like a projection or view matrix problem. Possibly it would be worth using DarkStarSword's approach of modifying the model/global space to avoid needing to tweak other matrices for the reflections.
I'm fairly certain this is not a projection of view matrix issue. If i leave all the matrices as is the same thing renders in both eyes, but the shadows are still stretched out. I'm pretty sure it's either an issue with the viewport or Unity using the wrong screen coordinates while rendering the shadows.

I made the simplest test case possible to make sure that the eye swapping and general setup worked first. I simply offset the camera position along it's x axis, even though it's not stereo we can still see if each target is rendering properly first. This way if things don't render properly we can rule out improper matrix setup. If i had modified any of the matrices I would've possibly wasted time trying to debug them. Simply offsetting the camera's position should not cause the shadows or anything else to go out of whack, which is clearly happening here. Once we can get things to properly render for each target I'll go ahead and apply the the proper matrix modifications. I'm not really worried about the rest of the code involved since i have it working without using 3D Vision Direct, albeit in a rather hacky way by overriding separation and using my own values with 3D Vision Automatic.
bo3b said:Sample app I've got does not draw stereo, but is in stereo mode, green light on, 3Dmigoto drawing overlay. When I run this app, it's running OK, without crashing. It does a freakish screen flash/window size something when launched, but otherwise no ill effects. (This setup is Win10, 381.x )

The crashing could be something with my setup, but try running it a few times. I've generally noticed that Unity games tend to resize their window a lot during initialization, which is probably the reason INSIDE gives me issues.

I feel like we're pretty close, great work as usual Bo3B!

Like my work? You can send a donation via Paypal to sgs.rules@gmail.com

Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z

#79
Posted 05/27/2017 06:51 PM   
[quote="sgsrules"][quote="bo3b"]It's always possible they are doing at GetDesc of some form on a different parameter, but those should also return the 2x sizes. Might be one I've missed though. The only one in particular that seems like it needs tweaking is SwapChain::ResizeTarget. That is presently unchanged, and should likely be 2x-ed. (And probably DXGI_FORMAT_UNKNOWN forced, as we are forcing fullscreen.)[/quote]It seems like either of these could cause issues since the shadows are not using the proper viewport size. I find it odd that everything else is rendering correctly without me having to adjust the rendering viewport in unity, It would make more sense to me if everything was stretched out and not just the shadows.[/quote] OK, that sounds right, I'll go ahead and add ResizeTarget when I tweak the others to only do full-screen width 2x. [quote="sgsrules"][quote="bo3b"]To me, this seems like a projection or view matrix problem. Possibly it would be worth using DarkStarSword's approach of modifying the model/global space to avoid needing to tweak other matrices for the reflections.[/quote]I'm fairly certain this is not a projection of view matrix issue. If i leave all the matrices as is the same thing renders in both eyes, but the shadows are still stretched out. I'm pretty sure it's either an issue with the viewport or Unity using the wrong screen coordinates while rendering the shadows.[/quote] Ah, right, excellent test case. I agree with your usage here as a first pass validation. In the current test case on GitHub, I'm only seeing a single eye. I think there is no offset applied in that test case, and the shadows look OK. It looks like this, right eye drawn, left eye black. I did not rebuild the test app, just used checked-in exe. [img]http://sg.bo3b.net/test01_85.jps[/img] [quote="sgsrules"][quote="bo3b"]Sample app I've got does not draw stereo, but is in stereo mode, green light on, 3Dmigoto drawing overlay. When I run this app, it's running OK, without crashing. It does a freakish screen flash/window size something when launched, but otherwise no ill effects. (This setup is Win10, 381.x )[/quote]The crashing could be something with my setup, but try running it a few times. I've generally noticed that Unity games tend to resize their window a lot during initialization, which is probably the reason INSIDE gives me issues. I feel like we're pretty close, great work as usual Bo3B![/quote] Yup, run it maybe 20 times now. No crashes. Double draw at start, but does not resize or look different when it stabilizes. Agreed! Purty sweet, getting close to functional.
sgsrules said:
bo3b said:It's always possible they are doing at GetDesc of some form on a different parameter, but those should also return the 2x sizes. Might be one I've missed though.

The only one in particular that seems like it needs tweaking is SwapChain::ResizeTarget. That is presently unchanged, and should likely be 2x-ed. (And probably DXGI_FORMAT_UNKNOWN forced, as we are forcing fullscreen.)
It seems like either of these could cause issues since the shadows are not using the proper viewport size. I find it odd that everything else is rendering correctly without me having to adjust the rendering viewport in unity, It would make more sense to me if everything was stretched out and not just the shadows.

OK, that sounds right, I'll go ahead and add ResizeTarget when I tweak the others to only do full-screen width 2x.

sgsrules said:
bo3b said:To me, this seems like a projection or view matrix problem. Possibly it would be worth using DarkStarSword's approach of modifying the model/global space to avoid needing to tweak other matrices for the reflections.
I'm fairly certain this is not a projection of view matrix issue. If i leave all the matrices as is the same thing renders in both eyes, but the shadows are still stretched out. I'm pretty sure it's either an issue with the viewport or Unity using the wrong screen coordinates while rendering the shadows.

Ah, right, excellent test case. I agree with your usage here as a first pass validation.

In the current test case on GitHub, I'm only seeing a single eye. I think there is no offset applied in that test case, and the shadows look OK. It looks like this, right eye drawn, left eye black. I did not rebuild the test app, just used checked-in exe.

Image


sgsrules said:
bo3b said:Sample app I've got does not draw stereo, but is in stereo mode, green light on, 3Dmigoto drawing overlay. When I run this app, it's running OK, without crashing. It does a freakish screen flash/window size something when launched, but otherwise no ill effects. (This setup is Win10, 381.x )
The crashing could be something with my setup, but try running it a few times. I've generally noticed that Unity games tend to resize their window a lot during initialization, which is probably the reason INSIDE gives me issues.

I feel like we're pretty close, great work as usual Bo3B!

Yup, run it maybe 20 times now. No crashes. Double draw at start, but does not resize or look different when it stabilizes.

Agreed! Purty sweet, getting close to functional.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#80
Posted 05/27/2017 07:11 PM   
[quote="bo3b"]In the current test case on GitHub, I'm only seeing a single eye. I think there is no offset applied in that test case, [/quote]That's odd i get both eyes drawn. [quote="bo3b"]and the shadows look OK. [/quote]Lol, the shadows are definitely not ok, but i can see how you may think that without a proper reference image. The scene only includes two objects, a plane and a sphere. The square shadow in the background is the artifact from the viewport being doubled that i mentioned. The shadow on the right is actually the shadow of the sphere, except that the shadow mapping is being applied at double the width. [quote="bo3b"]It looks like this, right eye drawn, left eye black. I did not rebuild the test app, just used checked-in exe. [img]http://sg.bo3b.net/test01_85.jps[/img] [/quote]I updated the repo with a better test scene. It's basically the same thing except that i applied some checkerboard textures and replaced the sphere with a purple rotating cube so i could tell when it crashes, and a rotating sphere didn't make sense ;P The scene is just a plane, rotating cube, simple shadows and a red spotlight. Each eye should look something like this: [url=http://www.iforce.co.nz/View.aspx?i=zadezzv2.2ls.jpg][img]http://iforce.co.nz/i/zadezzv2.2ls.jpg[/img][/url] Instead it looks like this: [url=http://www.iforce.co.nz/View.aspx?i=xku0udyu.zuh.jpg][img]http://iforce.co.nz/i/xku0udyu.zuh.jpg[/img][/url]In this example the same thing is drawn in both eyes. The only thing that's being done is making calls to set the left and right eye targets, no offsets or matrix manipulations are done. Fixing the viewport calls so that they don't double every viewport will fix the shadow rendering pass that causes that black shadow in the background. Somehow adjusting the reported width should fix the application of the shadow so that it's not stretched across the whole buffer.. unless this is caused by something else. I built two copies of the test app: 3DVisionDirectForward.exe and 3DVisionDirectDeferred.exe. They're both in the repo under \UnityProject\TestBuilds. The above results are from using the forward renderer. The screenshot below is using the deferred renderer, which is really screwed up. I suspect that it's due to the same issues with how the dimensions or viewports are being reported or resized. [url=http://www.iforce.co.nz/View.aspx?i=wbyppnyo.2q4.jpg][img]http://iforce.co.nz/i/wbyppnyo.2q4.jpg[/img][/url] Check out the area on the top left corner of the plane, notice how there's a white plane, then a black one, and finally the checkerboard, each spaced apart from one another. The distance between the top right corners of the black and checkered planes is twice the distance between the white and black one. It looks like each pass in the deferred renderer is incrementally changing it's width, is it possible that it's doubling the viewport or buffer and then on subsequent passes it's using the already doubled width to double again?
bo3b said:In the current test case on GitHub, I'm only seeing a single eye. I think there is no offset applied in that test case,
That's odd i get both eyes drawn.
bo3b said:and the shadows look OK.
Lol, the shadows are definitely not ok, but i can see how you may think that without a proper reference image. The scene only includes two objects, a plane and a sphere. The square shadow in the background is the artifact from the viewport being doubled that i mentioned. The shadow on the right is actually the shadow of the sphere, except that the shadow mapping is being applied at double the width.
bo3b said:It looks like this, right eye drawn, left eye black. I did not rebuild the test app, just used checked-in exe.

Image
I updated the repo with a better test scene. It's basically the same thing except that i applied some checkerboard textures and replaced the sphere with a purple rotating cube so i could tell when it crashes, and a rotating sphere didn't make sense ;P The scene is just a plane, rotating cube, simple shadows and a red spotlight.

Each eye should look something like this:
Image
Instead it looks like this:
ImageIn this example the same thing is drawn in both eyes. The only thing that's being done is making calls to set the left and right eye targets, no offsets or matrix manipulations are done.

Fixing the viewport calls so that they don't double every viewport will fix the shadow rendering pass that causes that black shadow in the background. Somehow adjusting the reported width should fix the application of the shadow so that it's not stretched across the whole buffer.. unless this is caused by something else.

I built two copies of the test app: 3DVisionDirectForward.exe and 3DVisionDirectDeferred.exe. They're both in the repo under \UnityProject\TestBuilds. The above results are from using the forward renderer. The screenshot below is using the deferred renderer, which is really screwed up. I suspect that it's due to the same issues with how the dimensions or viewports are being reported or resized.
Image
Check out the area on the top left corner of the plane, notice how there's a white plane, then a black one, and finally the checkerboard, each spaced apart from one another. The distance between the top right corners of the black and checkered planes is twice the distance between the white and black one. It looks like each pass in the deferred renderer is incrementally changing it's width, is it possible that it's doubling the viewport or buffer and then on subsequent passes it's using the already doubled width to double again?

Like my work? You can send a donation via Paypal to sgs.rules@gmail.com

Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z

#81
Posted 05/27/2017 09:17 PM   
Made an update to the 3Dmigoto code, to only change full-screen width inputs for RSSetViewPorts, CreateTexture2D (DepthStencil), and added ResizeTargets. The ResizeTargets seems to make the launch smoother, one less screen flicker. Here is what it looks like with the current top-of-tree code. I only have access to the old test.exe. [img]http://sg.bo3b.net/test02_85.jps[/img] Let me know if that does not seem right.
Made an update to the 3Dmigoto code, to only change full-screen width inputs for RSSetViewPorts, CreateTexture2D (DepthStencil), and added ResizeTargets.

The ResizeTargets seems to make the launch smoother, one less screen flicker.

Here is what it looks like with the current top-of-tree code. I only have access to the old test.exe.

Image


Let me know if that does not seem right.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#82
Posted 05/30/2017 01:18 AM   
The square artifact in the background is gone but just by looking at the screenshot, I can tell it's still mapping the shadow across the whole buffer instead of just half of it. The sphere's shadow should be underneath the sphere not stretched off to the right. It should look something like this in each eye: [img]http://i.imgur.com/ck0NVLM.jpg[/img] I you use the latest test apps that are in the repo it's easier to see the issue, especially for the deferred renderer.
The square artifact in the background is gone but just by looking at the screenshot, I can tell it's still mapping the shadow across the whole buffer instead of just half of it. The sphere's shadow should be underneath the sphere not stretched off to the right. It should look something like this in each eye:
Image
I you use the latest test apps that are in the repo it's easier to see the issue, especially for the deferred renderer.

Like my work? You can send a donation via Paypal to sgs.rules@gmail.com

Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z

#83
Posted 05/30/2017 01:53 AM   
OK, I've got it! After you synced the GitHub, I downloaded the test apps, and found that the problem was that we were not also modifying the RenderTargetViews that are created in CreateTexture2D. After I added that check, following the same rules as for DepthStencil, we get this in even the deferred render case: [img]http://sg.bo3b.net/3DVisionDirectDeferred01_85.jps[/img] Code is checked in, top-of-tree.
OK, I've got it!

After you synced the GitHub, I downloaded the test apps, and found that the problem was that we were not also modifying the RenderTargetViews that are created in CreateTexture2D. After I added that check, following the same rules as for DepthStencil, we get this in even the deferred render case:

Image


Code is checked in, top-of-tree.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#84
Posted 05/30/2017 05:40 AM   
hell yeah, this is awesome! I tested it out and everything works, we don't even have to mess with unity's viewports. Things were still crashing on my system so i finally reinstalled the os and all my apps. It friggin took forever but it definitely beats having to install things from cds, or floppies for that matter... please insert disk 5 of 12... f#ck! Anyhow crashes are gone and it works flawlessly. I really wish i knew what was causing the crashes, the error logs showed read access violations, sometimes it was from null pointers. Since it was one of the only things that was causing my system to crash i initially thought that it was possibly an issue with my code. But I tested it on my other windows install (after i rebuilt my RAID array) and it was working fine. Thanks a bunch for adding this functionality to 3dMigoto! It looks like all the major issues have been resolved so I'll be diving back in to creating the unity plugin. Now that it's working with DX11 would it be possible to add in DX9 support? I know i previously said that we probably wouldn't need it for older games since most of them have already been fixed, but I've recently noticed even some of the newer games run on DX9 e.g. Tokyo 42: https://www.destructoid.com/review-tokyo-42-438666.phtml
hell yeah, this is awesome! I tested it out and everything works, we don't even have to mess with unity's viewports.

Things were still crashing on my system so i finally reinstalled the os and all my apps. It friggin took forever but it definitely beats having to install things from cds, or floppies for that matter... please insert disk 5 of 12... f#ck!

Anyhow crashes are gone and it works flawlessly. I really wish i knew what was causing the crashes, the error logs showed read access violations, sometimes it was from null pointers. Since it was one of the only things that was causing my system to crash i initially thought that it was possibly an issue with my code. But I tested it on my other windows install (after i rebuilt my RAID array) and it was working fine.

Thanks a bunch for adding this functionality to 3dMigoto! It looks like all the major issues have been resolved so I'll be diving back in to creating the unity plugin.

Now that it's working with DX11 would it be possible to add in DX9 support? I know i previously said that we probably wouldn't need it for older games since most of them have already been fixed, but I've recently noticed even some of the newer games run on DX9 e.g. Tokyo 42: https://www.destructoid.com/review-tokyo-42-438666.phtml

Like my work? You can send a donation via Paypal to sgs.rules@gmail.com

Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z

#85
Posted 05/31/2017 04:16 PM   
Made a new release of 3Dmigoto for you to use. Check [url]https://github.com/bo3b/3Dmigoto/releases[/url], this is version 1.2.60 now with Direct Mode support! Please let me know if you run into any problems with it. For DX9 support, no, we'd need to do a lot of work to get that running. We don't have source code for HelixMod, and thus would need to replicate 3Dmigoto into the DX9 world, which is too much work to justify, given that HelixMod is so fully featured. We could make a specific loader for DX9 Unity games for Direct Mode, but would require building something that patches the OS calls we need like CreateDeviceAndSwapChain. Best bet for older DX9 games is to use DarkStarSword's Python scripts.
Made a new release of 3Dmigoto for you to use. Check https://github.com/bo3b/3Dmigoto/releases, this is version 1.2.60 now with Direct Mode support!

Please let me know if you run into any problems with it.


For DX9 support, no, we'd need to do a lot of work to get that running. We don't have source code for HelixMod, and thus would need to replicate 3Dmigoto into the DX9 world, which is too much work to justify, given that HelixMod is so fully featured.

We could make a specific loader for DX9 Unity games for Direct Mode, but would require building something that patches the OS calls we need like CreateDeviceAndSwapChain.

Best bet for older DX9 games is to use DarkStarSword's Python scripts.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#86
Posted 06/03/2017 06:22 AM   
[quote="bo3b"]Made a new release of 3Dmigoto for you to use. Check [url]https://github.com/bo3b/3Dmigoto/releases[/url], this is version 1.2.60 now with Direct Mode support! Please let me know if you run into any problems with it. [/quote] Brilliant! will do. I'm assuming that this is the same version as tip of the github repo? [quote="bo3b"]For DX9 support, no, we'd need to do a lot of work to get that running. We don't have source code for HelixMod, and thus would need to replicate 3Dmigoto into the DX9 world, which is too much work to justify, given that HelixMod is so fully featured. We could make a specific loader for DX9 Unity games for Direct Mode, but would require building something that patches the OS calls we need like CreateDeviceAndSwapChain.[/quote] Yeah i kind of figured as much, but you mentioned it so i thought it would be less work than i imagined. [quote="bo3b"] Best bet for older DX9 games is to use DarkStarSword's Python scripts.[/quote] I could never get these to work with INSIDE, I ended up with tons of errors. It's the only game i tried it with. They don't work with every version of Unity. I know zero python or have any familiarity with some of the tools that DSS used. So i didn't know if my issues were because of user error or because the script was incompatible with the game. Another alternative would be to simply use my other method. The one where i use 3DVision automatic, set zero separation in 3dVision, and my use my own separation value in the app. But for this to work i still need to be able to target rendering in each eye. In 3dMigoto i was doing this by outputting the proper eye texture in a shader. I would know which eye was being targeted by reading the StereoParams in the shader. How do i do something similar in helix wrapper? is it as simple doing something like: [code] Texture2D<float4> StereoParams : register(s13); //then.. float4 stereo = StereoParams.Load(0); if(stereo.x<0) { //Render left eye } else { //Render right eye } [/code] First load the params for register s13 instead of t125(or whatever is setup in the ini). Then check the sign of StereoParams.x to see which eye is being drawn. is that right?
bo3b said:Made a new release of 3Dmigoto for you to use. Check https://github.com/bo3b/3Dmigoto/releases, this is version 1.2.60 now with Direct Mode support!

Please let me know if you run into any problems with it.

Brilliant! will do. I'm assuming that this is the same version as tip of the github repo?
bo3b said:For DX9 support, no, we'd need to do a lot of work to get that running. We don't have source code for HelixMod, and thus would need to replicate 3Dmigoto into the DX9 world, which is too much work to justify, given that HelixMod is so fully featured.
We could make a specific loader for DX9 Unity games for Direct Mode, but would require building something that patches the OS calls we need like CreateDeviceAndSwapChain.

Yeah i kind of figured as much, but you mentioned it so i thought it would be less work than i imagined.
bo3b said:
Best bet for older DX9 games is to use DarkStarSword's Python scripts.

I could never get these to work with INSIDE, I ended up with tons of errors. It's the only game i tried it with. They don't work with every version of Unity. I know zero python or have any familiarity with some of the tools that DSS used. So i didn't know if my issues were because of user error or because the script was incompatible with the game.

Another alternative would be to simply use my other method. The one where i use 3DVision automatic, set zero separation in 3dVision, and my use my own separation value in the app.

But for this to work i still need to be able to target rendering in each eye. In 3dMigoto i was doing this by outputting the proper eye texture in a shader. I would know which eye was being targeted by reading the StereoParams in the shader. How do i do something similar in helix wrapper? is it as simple doing something like:
Texture2D<float4> StereoParams : register(s13); 

//then..
float4 stereo = StereoParams.Load(0);
if(stereo.x<0)
{
//Render left eye
}
else
{
//Render right eye
}

First load the params for register s13 instead of t125(or whatever is setup in the ini). Then check the sign of StereoParams.x to see which eye is being drawn. is that right?

Like my work? You can send a donation via Paypal to sgs.rules@gmail.com

Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z

#87
Posted 06/03/2017 06:32 PM   
[quote="sgsrules"][quote="bo3b"]Made a new release of 3Dmigoto for you to use. Check [url]https://github.com/bo3b/3Dmigoto/releases[/url], this is version 1.2.60 now with Direct Mode support! Please let me know if you run into any problems with it.[/quote]Brilliant! will do. I'm assuming that this is the same version as tip of the github repo?[/quote]Yep, same as tip of tree. [quote="sgsrules"][quote="bo3b"]For DX9 support, no, we'd need to do a lot of work to get that running. We don't have source code for HelixMod, and thus would need to replicate 3Dmigoto into the DX9 world, which is too much work to justify, given that HelixMod is so fully featured. We could make a specific loader for DX9 Unity games for Direct Mode, but would require building something that patches the OS calls we need like CreateDeviceAndSwapChain.[/quote]Yeah i kind of figured as much, but you mentioned it so i thought it would be less work than i imagined. [/quote]Made more sense if we were going to make a standalone tool. But with SBS/TAB support and already setup for CreateDevice, it made sense to put this in 3Dmigoto instead. [quote="sgsrules"][quote="bo3b"]Best bet for older DX9 games is to use DarkStarSword's Python scripts.[/quote]I could never get these to work with INSIDE, I ended up with tons of errors. It's the only game i tried it with. They don't work with every version of Unity. I know zero python or have any familiarity with some of the tools that DSS used. So i didn't know if my issues were because of user error or because the script was incompatible with the game.[/quote] This is because the DX11 variants are more complicated and don't always work. 4everawake was the absolute master of these scripts, and even he could not get it to work correctly on Inside. He also noted that there were custom shaders that fell outside of the normal Unity shaders (flashlights in particular) and so he abandoned his fix. For DX9 games though- the DarkStarSword scripts are nearly flawless. That's why I suggest it probably it makes sense to just use his scripts for DX9 Unity games, and use your approach for DX11 Unity games. This is also why I was willing to sink more time than I wanted into these 3Dmigoto changes and figuring out the undocumented Direct Mode, because it opens up a viable path for pretty much any DX11 Unity game. [quote="sgsrules"]Another alternative would be to simply use my other method. The one where i use 3DVision automatic, set zero separation in 3dVision, and my use my own separation value in the app. But for this to work i still need to be able to target rendering in each eye. In 3dMigoto i was doing this by outputting the proper eye texture in a shader. I would know which eye was being targeted by reading the StereoParams in the shader. How do i do something similar in helix wrapper? is it as simple doing something like: [code] Texture2D<float4> StereoParams : register(s13); //then.. float4 stereo = StereoParams.Load(0); if(stereo.x<0) { //Render left eye } else { //Render right eye } [/code] First load the params for register s13 instead of t125(or whatever is setup in the ini). Then check the sign of StereoParams.x to see which eye is being drawn. is that right?[/quote]That is roughly the idea, but has some errors. The stereo param.x is for separation, not which eye is active. In the HelixMod case, it's a different texture, and ASM only. Plus getting that info out of the shader, back to the C# level would require something tricky, because we have no source code for HelixMod or other DX9 wrapper. Given the complexity of the problem, and the quality of the DarkStarSword DX9 Unity scripts, I think it makes the most sense to avoid all that extra work and just use his scripts for the DX9 case.
sgsrules said:
bo3b said:Made a new release of 3Dmigoto for you to use. Check https://github.com/bo3b/3Dmigoto/releases, this is version 1.2.60 now with Direct Mode support!

Please let me know if you run into any problems with it.
Brilliant! will do. I'm assuming that this is the same version as tip of the github repo?
Yep, same as tip of tree.


sgsrules said:
bo3b said:For DX9 support, no, we'd need to do a lot of work to get that running. We don't have source code for HelixMod, and thus would need to replicate 3Dmigoto into the DX9 world, which is too much work to justify, given that HelixMod is so fully featured.
We could make a specific loader for DX9 Unity games for Direct Mode, but would require building something that patches the OS calls we need like CreateDeviceAndSwapChain.
Yeah i kind of figured as much, but you mentioned it so i thought it would be less work than i imagined.
Made more sense if we were going to make a standalone tool. But with SBS/TAB support and already setup for CreateDevice, it made sense to put this in 3Dmigoto instead.


sgsrules said:
bo3b said:Best bet for older DX9 games is to use DarkStarSword's Python scripts.
I could never get these to work with INSIDE, I ended up with tons of errors. It's the only game i tried it with. They don't work with every version of Unity. I know zero python or have any familiarity with some of the tools that DSS used. So i didn't know if my issues were because of user error or because the script was incompatible with the game.
This is because the DX11 variants are more complicated and don't always work. 4everawake was the absolute master of these scripts, and even he could not get it to work correctly on Inside. He also noted that there were custom shaders that fell outside of the normal Unity shaders (flashlights in particular) and so he abandoned his fix.

For DX9 games though- the DarkStarSword scripts are nearly flawless. That's why I suggest it probably it makes sense to just use his scripts for DX9 Unity games, and use your approach for DX11 Unity games.

This is also why I was willing to sink more time than I wanted into these 3Dmigoto changes and figuring out the undocumented Direct Mode, because it opens up a viable path for pretty much any DX11 Unity game.


sgsrules said:Another alternative would be to simply use my other method. The one where i use 3DVision automatic, set zero separation in 3dVision, and my use my own separation value in the app.

But for this to work i still need to be able to target rendering in each eye. In 3dMigoto i was doing this by outputting the proper eye texture in a shader. I would know which eye was being targeted by reading the StereoParams in the shader. How do i do something similar in helix wrapper? is it as simple doing something like:
Texture2D<float4> StereoParams : register(s13); 

//then..
float4 stereo = StereoParams.Load(0);
if(stereo.x<0)
{
//Render left eye
}
else
{
//Render right eye
}

First load the params for register s13 instead of t125(or whatever is setup in the ini). Then check the sign of StereoParams.x to see which eye is being drawn. is that right?
That is roughly the idea, but has some errors. The stereo param.x is for separation, not which eye is active. In the HelixMod case, it's a different texture, and ASM only. Plus getting that info out of the shader, back to the C# level would require something tricky, because we have no source code for HelixMod or other DX9 wrapper.

Given the complexity of the problem, and the quality of the DarkStarSword DX9 Unity scripts, I think it makes the most sense to avoid all that extra work and just use his scripts for the DX9 case.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#88
Posted 06/03/2017 08:28 PM   
Don't want to add noise to this thread but its awfully quiet after such a lot of promising activity. Hope it sees the light of day after all the effort so far. This could be a great solution for my Jack Nicklaus Perfect Golf :)
Don't want to add noise to this thread but its awfully quiet after such a lot of promising activity. Hope it sees the light of day after all the effort so far. This could be a great solution for my Jack Nicklaus Perfect Golf :)

#89
Posted 06/15/2017 09:31 PM   
I was cleaning out my download folder and came across a zip file named DeWol_S3D_Demo. I had forgot about it or I would had mentioned it before. It runs on Unity 5 and has options for anaglyph, side by side, over/under, horizontal line interleaved and vertical line interleaved. It also has eye swap and IPD features among others. https://forum.unity.com/threads/stereo-3d-in-unity-3d.63874/ He added a TrackIR plugin from byBrick to it as well. https://www.youtube.com/watch?v=zYCOV7fKqrI Anyways, no idea if it's useful, but it's interesting nonetheless and works fluidly.
I was cleaning out my download folder and came across a zip file named DeWol_S3D_Demo. I had forgot about it or I would had mentioned it before. It runs on Unity 5 and has options for anaglyph, side by side, over/under, horizontal line interleaved and vertical line interleaved. It also has eye swap and IPD features among others.


https://forum.unity.com/threads/stereo-3d-in-unity-3d.63874/


He added a TrackIR plugin from byBrick to it as well.



Anyways, no idea if it's useful, but it's interesting nonetheless and works fluidly.

#90
Posted 11/25/2017 04:36 PM   
  6 / 8    
Scroll To Top