Dolphin, the GameCube and Wii emulator - Forums

About time to expand the stereo separation with window size.
Right now, the stereo separation appears to be a fixed number of pixels, rather than a percentage of the display width.

Wind Waker:
Small window = really nice stereo effect.
Full-screen = Very small % of screen width = Barely 3D at all.

That's interesting. I noticed that a lot of the settings seem pretty weird.

(12-12-2014, 12:52 PM)OneUp03 Wrote: [ -> ]Might other 3D transmission formats work in the future? (Frame Sequential, Frame Packing) Might it also be possible to bind the depth and convergence sliders to macros like how Nvidia's 3DVision does?

Currently a D3D PR is waiting to be merged which will introduce support for Nvidia 3D Vision to display the native stereoscopy, this will be the first full-resolution Frame Sequential mode. After that I will implement Quad Buffering support which is the proper way to display full-resolution 3D and is officially supported by OpenGL and DirectX, but currently the only consumer cards that support it are AMD cards through their HD3D feature.

I'm not sure about Nvidia binding their depth and convergence values. They way I see it is that Nvidia defines the convergence values for every game they support and then only allow the user to adjust the depth value. We can hardly provide convergence values for every game, so the user has to be able to adjust it.

(12-12-2014, 03:06 PM)jimbo1qaz Wrote: [ -> ]About time to expand the stereo separation with window size.
Right now, the stereo separation appears to be a fixed number of pixels, rather than a percentage of the display width.

Wind Waker:
Small window = really nice stereo effect.
Full-screen = Very small % of screen width = Barely 3D at all.

Very well spotted! Indeed the 3D effect is currently a percentage of the screen, but apparently I still have to scale this percentage according to the EFB scale. Thanks for the feedback.

EDIT: Actually it seems I misread your post, I interpreted that you mean that the separation distance between the eye was currently changing between a small and a big window. This is not true, but it seems you suggested it actually should. I disagree with that, since your eyes have the same separation regardless of how large the window is. If you don't get enough depth in the 3D image, try increasing the separation value in the settings.

Was this changed at some point? I don't have access to my gaming PC at the moment, but I do remember the 3D effect popped FAR more when the window was small and low IR than when it was fullscreen. Because for a given set of options, objects were separated by a higher % of the screen when the screen was small.

(12-13-2014, 06:52 AM)jimbo1qaz Wrote: [ -> ]Was this changed at some point? I don't have access to my gaming PC at the moment, but I do remember the 3D effect popped FAR more when the window was small and low IR than when it was fullscreen. Because for a given set of options, objects were separated by a higher % of the screen when the screen was small.

This may have changed, but that was already some time ago before the feature was merged. You should switch to Anaglyph mode on a normal 2D monitor, then you can more clearly see the separation between the two images and compare them at small and big sizes.

Take screenshots if you can; that'd make it easy to see what you're seeing.

Yeah, at low IRs, the effect is far more prominent. Screenshots linked:
1X IR: https://www.dropbox.com/s/gu3g3bvtdbsu2gn/1x.png?dl=0
4X IR: https://www.dropbox.com/s/wt9614ww08f65mt/4x.png?dl=0

Having some issues on this end. Using the latest Git, if I enable Stereo3d and have Antialiasing enabled, it gives me one eye (usually with both renderings) and a glitched out view in the other eye.

If I enable stereo3d without antialiasing, I get both eyes, but rendered from one viewpoint (probably the left?)

I'm working on Dolphin VR for the Oculus Rift, and getting the same issues with side-by-side and Rift rendering.

This happens on both the latest Dolphin git and Dolphin VR git.

Currently on Arch Linux, latest beta nvidia graphics.

Here's rendering with AA enabled:



This is on Linux, so using the GLX backend. I got another dev to test it with OpenGL on Windows and they had no such issues.

Speaking of which, you're looking to remove certain screen-depth objects? On the VR branch, we've got an object-removal GUI and some pre-made codes to remove certain immersion-breaking things from the render. I don't think there's any plans to merge the Dolphin VR stuff into the main branch yet, since it requires the inclusion of the Oculus SDK (or well, not -requires-, it builds without, but without Oculus support)

Hey Guys, I'm one of the developers of Dolphin VR. I saw you're talking about adding an "Object Removal Function". You guys should check out my latest build of Dolphin VR, because it might solve a lot of the problems you are looking to solve already. No use in recoding the same thing! I have a per-game, user-definable object removal tab that allows users to remove objects from the game, on the fly. We've already added options to remove the fake 16:9 bars, heat effects, and other things that are broken in 3D for some popular games. It's pretty simple for a user to brute force their own code, without any knowledge of how the system works. It can also be used for fun in Non-VR games, to remove post processing effects or other things some users may find objectionable.

Here's the link to my GitHub, and the Oculus forum we usually have discussion at, if you're interested:
https://github.com/cegli/dolphin
and
https://forums.oculus.com/viewtopic.php?f=42&t=11241&start=600

Here's a link to the latest release:
https://forums.oculus.com/viewtopic.php?f=42&t=11241&start=540#p223873

I have some other things you might find interesting, like a hack to remove the EFB copy clears when EFB is disabled (fixes a ton of games that don't render properly in VR/3D), which was causing a lot of issues for us. I only have the part working for Direct3D because OpenGL mode is still in flux, but it should be simple enough to get working in OpenGL as well. The whole thing is still in a very beta state, but I'm hoping we can work together on some issues that plague both of us!

Edit: Also, I have an XInput hotkeys functionality implemented, which lets us change scale, use free-look, etc. with the gamepad. Less useful for you guys than for us, but you might find that interesting as well for changing 3D settings on the fly.

I really wish some of these features were made as PRs for Master instead of branches where I don't know about them.