Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1439 from Armada651/ogl-stereo-3d
OGL: Stereoscopic 3D Support
- Loading branch information
Showing
48 changed files
with
773 additions
and
266 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,3 +32,5 @@ $99 of some treasures | |
040AE530 3F000063 | ||
$End Boss Has No HP | ||
|
||
[Video_Stereoscopy] | ||
StereoMonoEFBDepth = True |
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good on you for adding stereoscopic 3D support.
This totally breaks Dolphin VR though.
I don't even know if the Oculus SDK will accept 3D textures. :-(
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I was just trying to merge this into Dolphin VR as well... Looks like quite a challenge...
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CarlKenner Why 3d texture? Just add an additional step afterwards to merge this two images as you want and you'll get a Dolphin VR without any slowdowns compared to master.
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cegli I think you should give up merging it for now. I merged everything from master up to this commit, and pulled RachelBryk's merge after this one into my branch. So just pull my branch for now.
@degasus I thought blitting from the 3D texture to two 2D ones would make it slower.
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CarlKenner Only a bit, likely not noticeable. This way to render still has (a bit more than) the double GPU effort, but as long as your GPU is fine (don't play at 4xIR in stereo on a consumer GPU...) there is no additional slowdown. The old DolphinVR implementation did switch the framebuffer twice on every draw call, this was a huge CPU overhead within the driver.
But indeed, this commit makes some of your 3d patches obsolete, but I think it's worth to port DolphinVR over to this technic. So it's basicly:
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I'm not that stupid, I only switch the framebuffer once on every draw call. I realise that is still once too many, but at least I had the sense not to do it twice:
I'll see if I can merge these changes, but it will take a while, and there are some other features I need to add first and test on code that I know works, before I can mess up the code with my poor attempt at merging.
This method has additional hardware and driver requirements though, is that right? What are the requirements and how common are they likely to be for users?
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice idea. Haven't thought about this way to save one framebuffer binding call :D
Yeah, I see porting your patches to this framework is lots of work. but I hope you'll succed on the task.
The new requirement is basicly geometry shader aka OpenGL 3.2. It should be supported by every GPU we support right now. Geometry shaders are a hard dependency for all DX10 GPUS which we already require for integer shaders. But bad luck, some drivers doesn't offer this:
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The hard part will be getting the telescope to work. Link holds the telescope up to his left eye only, while his right eye still sees the world unmagnified until he closes his right eye.
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe Armada will have an idea on how to handle that. I never really thought about that case until you just mentioned it. 3D support is more or less about making it 3D; where as the oculus rift and other VR units would have stuff like the situation with Link's Telescope. Seems like a scary difference...
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CarlKenner It's not really necessary to port these changes to DolphinVR, as long as you don't enable the stereoscopic 3D option you can still continue to use your own method of 3D rendering. I'm actually interested in measuring the performance difference between the two different methods.
The most difficult part in merging will not be layered textures, as degasus explained you can just blit these to standard 2D textures. What's more difficult is that the current geometry shader is not compatible with the projection matrices supplied by the Oculus SDK. You'll have to revert commit 6cacfad where compatibility with stereo projection matrices was removed from the geometry shader.
About the telescope, if you want to black out one eye when holding the telescope the best method would be to give the telescope texture two layers where the second layer is completely black. The pixel shader will automatically sample the correct layer and it would black out only the right eye. The texture cache can already replace textures by custom ones, all that needs to be added is support for custom textures to be multi-layered. Ofcourse, this should only be done in a VR headset, it would look very strange for a 3D monitor to be black for one eye.
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Armada651 How I can enable 3d stereo rendering? I dont see the option
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@penkamaster The option isn't enabled yet. https://forums.dolphin-emu.org/Thread-stereoscpic-3d-side-by-side-ogl
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@penkamaster Look in the video ini, there is an option for it. But don't expect it to be feature complete
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've got it working in Dolphin VR. With the convergence at max, and the separation at about .4 it works well enough to play. The speed is pretty good too.
I just had to move glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0); out of m_post_processor->BlitFromTexture so the same function can be used to blit to the 2D eye framebuffers. Hopefully that means post-processing shaders can actually be used in Dolphin VR now (they weren't implemented before).
Now I just need to separate the separation into two separate parameters, one for the shear and one for the camera movement, and in VR mode I need to set the three parameters programmatically to match the Oculus SDK, rather than using the ones the user sets (there's no such thing as separation and convergence in VR, because VR has to match exactly what your eyes would see in the real world).
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CarlKenner Have a look at commit 51a4d6a that's when the geometry shader still used a shearing parameter.
ce05976
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought I found a bug, but I was wrong. Sorry.