Menu
▾
▴
10 Attachments
#532 Prevent Screen Distortion on multi-monitor setups
assigned
nobody
None
enhancement
major
Graphics
2.0.0-dev
2024-03-10
2011-12-14
No
At present a single OpenGL viewport is used, which has the problem that on very wide screens the items in the perpherial vision are distorted.
I'm using a screen size 3840x1024, using the glance left/right I can see that the front wheels of an open-wheeler are getting rendered too large as I 'turn my head'.
I believe that this is caused by the single viewport, in that it is a flat plan infront of the camera. When items are drawn they are projected onto this 'screen' and as they are closer they are projected back and enlarged.
A solution might be to split the rendering into 3 (or however many) viewports, one for each monitor, where the frustum angle is adjusted to suit the monitor setup.
We may be able to use the fixed camera of #517 to implement this....
If splitting a wide view into a number of 'split screens', we could/should introduce the idea of distortion and blend masks.
That way we could support curved project screens such as:
http://www.youtube.com/watch?v=_cyJIGII6JE&list=UUpSdEDGUppf-I8SUMXjPBZQ&index=3&feature=plcp
mock up of blended split screens using glance left/right and gimp'ing screenshots
attached patch is a basic implementation. It 'steals' the new Fixed/Driver view (F2) when in multi-split screen when the splits are positioned side by side. This will have a weird behaviour if the split screens are not the same driver.
However there is definately something funky with the fov calculations, and this means the outside monitors have to be severally angled in to get a good perspective. Ideally we want to be able to specify a radius of the monitor from the user's eyes and have it just work correctly.
There is no compensation for bezel thickness at present.
patch applied in r4691, but there is still work to do handling bezel compensation and making view fov calcs properly
Related
Commit: [r4691]
temp patch on r4703 to play with aspect ratio
Related
Commit: [r4703]
checked in some more in r4712.
If you want to test out the split screen spanning, temporarily enable the monitor menu in:
https://sourceforge.net/apps/trac/speed-dreams/browser/trunk/src/modules/userinterface/legacymenu/mainscreens/optionsmenu.cpp?rev=4712#L90
Or add the following section to your '~/.speed-dreams-2/config/graph.xml' file
--
--
Related
Commit: [r4712]
I should also mention that the 'span split' mode only operates when the split screens are vertical splits (ie. for a 3 monitor setup - but can be used on windowed displays for testing).
At the moment it is up to the use ensure that the same driver and view/camera is selected for each split screen, otherwise the screen will look very odd.
Also if the split are not spanned (which can happen while changing camera) cycle through the arrangements with the '_' key.
Checked in some more changes to make the spanning of split screens work better, r5110 and r5111.
If you have a multi-monitor please test by setting SD full screen (may need to hand edit width/height in 'screen.xml') and in 'graph.xml' enable spanning with:
--
<attstr name="span splits" val="yes"/>
--
You should select the number of splits to the number of monitors you have (up to 6 if you're that lucky!!).
Related
Commit: [r5110]
Commit: [r5111]
The patch looks perfect to me (except this little detail : in advancedgraphconfig.cpp, the changeBezel() function is not named the same way as the other callbacks, like onChangeForest(), onChangeSpansplit(), ... etc).
Revised patch checked in r5116
Related
Commit: [r5116]
diagram showing 'arc ratio' when monitors are different distance from user
I'm running into issues where I can't see how to define the 'view port' (the monitor surface) when the monitor is not perpendicular to the user - ie. the monitors are not arranged at the same distance from the user.
This is shown in this diagram:
https://sourceforge.net/apps/trac/speed-dreams/attachment/ticket/532/monitor_arch.png
The 'Red' position is perhaps more normal that 'Green' (equal distance to all monitors), and at the moment we can not correctly display the image.
Does anyone one know how to define this in Plib/ssg? It seems it only cares about the nominal FOV, and not that the viewport is turned (thus fovV on the left edge is different to fovV on the right edge)..... suggestions?
Interesting....
http://www.opengl.org/discussion_boards/showthread.php/147425-Projection-to-a-non-perpendicular-view-plane
--
--
diagram showing 'arc ratio' when monitors are different distance from user
Checked in an attempt at the MonitorArc compensation (r5128), disabled by default - enable via the 'Advance Configuration' menu.
Please test this; my system is non-ideal as I have fairly small (4:3) monitors and I'd like to check that it's working in all situations.
Related
Commit: [r5128]
Here's how it's done in iRacing.
http://www.youtube.com/watch?v=rri19PqJ3qU
Made some advances on this last night and it should be working for the F2 cameras except for the (first) 2 driver view ones - there's something happening wrt the fact that there's a visual element close up.
Changing the 'near' limit on the camera makes the problem go away.... strange.
In theory this technique should be realatively easy to apply to the other perspective cameras, I'll try to do this next week sometime.
Hints on getting it set up.
1) Measure you distance to main monitor from the driver/user location. Calculate the FovY angle. You should manually zoom the display to this number to get life like represenation - the FovY is now stated in the '5' debug screens.
2) Measure perpendicular from side monitor(s) to figure out when the 'center of arc' is and the main distance by this to get the 'arc ratio'
3) Estimate the bezel compensation to get continuity between screen edges, ie lines/walls/armco look correct.
'Arc Ratio' is
0 if monitors flat on wall/in straight line
1 if monitors equal distance from driver
0-1 if arc center is behind driver
1-2 if arc center is infront of driver
With 3x 4:3 monitors my FovY is around 19', dist is 1m and arcratio is 0.8. Looks good for me, but need more testers.
comparing different cams to figure out why driver view does not work
Figured out a difference in the camera behaviour, but not how to fix it. The left/right values are the same for different cameras at same FovY, but 'near' is different - I had assumed that left/right were values at the 'near' distance, and had calculated correct as per that....
This is obviously not correct :-(
Need to figure out what left/right really are and how they relate.
montage showing various ArcRatios