Conformal perspective as an option in TDM?

[lowenz]

TDM really suffers from linear perspective deformation (see the moon in the sky when turning ), even lowering the FOV.

 

image hosting site

 

Isn't worthing some efforts to implement this shader as an engine part with the possibility for the player to choose between the classic - linear - perspective a more "shape-preserving" variant?

 

https://reshade.me/forum/shader-presentation/3916-distortion-correction-conformal-perspective

 

->

 

https://github.com/crosire/reshade-shaders/blob/master/Shaders/PerfectPerspective.fx

Edited July 4, 2018 by lowenz

[stgatilov]

Do I understand correctly that this thing works like:

1. You render full frame as usual.

2. You do a full-screen post-processing, which stretches some curvilinear part of the frame output onto the screen.

...?

 

The main problem, I guess, is that we must not distort GUI, weapons, tools, lightgem, text messages, etc.

[lowenz]

It's why I ask if it is possible to avoid the postprocessing shader solution and move the perspective correction to the engine rendering level way before.....no more "correction" at all.

[lowenz]

[nbohr1more]

I believe our Bloom post-process happens before the GUI overlay so this could be hooked into that block if so.

[nbohr1more]

Out of curiosity, have you tried adjusting r_fovRatio to compensate?

[Spooks]

Oh, thank you very much for that .fx, lowenz, I'll be adding that to my ReShade config. FoV distortion has been the biggest pet peeve for me in 3D games, it seems it's not a priority, nay, even a consideration, for most developers at all.

 

For another example of working curvilinear perspective in a game engine closer to ours, there is this mod: http://strlen.com/gfxengine/fisheyequake/

 

@nbohr Me, I've toyed with fovRatio plenty. It's not really perfect, if anything it just distorts the picture more.

[Springheel]

The distortion bugs me too, so I'd be interested in a fix if it won't mess up anything else.

[Oktokolo]

Is this even fixable in software?

If the FoV is not matching the distance of the player from the screen, the projection mismatch is perceived as distortion. Changing distance from or size of the monitor would fix it as would changing the rendered FoV to the real FoV that the screen occupies from the players position in physical space.

[lowenz]

Out of curiosity, have you tried adjusting r_fovRatio to compensate?

Compensate which scenario?

[lowenz]

I believe our Bloom post-process happens before the GUI overlay so this could be hooked into that block if so.

But it's always in a postprocessing pass, in a form of correction of the native linear perspective.

My proposal would be to implement the curvilinear perspective as a WHOLE alternative to the linear one, not just correct it.

Edited July 4, 2018 by lowenz

[stgatilov]

But it's always in a postprocessing pass, in a form of correction of the native linear perspective.

My proposal would be to implement the curvilinear perspective as a WHOLE alternative to the linear one, not just correct it.

It is not possible, due to how OpenGL works.

There is perspective 4x4 matrices, perspective division (clip -> ndc coords), all this is baked into rendering pipeline.

You cannot magically change all this for some nonlinear math, except if you wish to drop OpenGL and implement your own rendering engine directly on CUDA or OpenCL.

With this curvilinear perspective even 3D triangles are no longer triangles on-screen (if I'm not mistaken), so GPU cannot rasterize them as it usually does.

 

The only possibility is to render something in traditional perspective, then bind the obtained picture as texture and perform full-screen post-processing to get bended view.

So you either render player's view as usual and then stretch it, or you render cubemap (much slower) and then apply post-processing to it.

 

If there is a clear place where this postprocessing could be applied, then I guess it won't need much changes in renderer.

If it is so, someone can try to implement it even now (for 2.07) under cvar.

[lowenz]

It is not possible, due to how OpenGL works.

There is perspective 4x4 matrices, perspective division (clip -> ndc coords), all this is baked into rendering pipeline.

You cannot magically change all this for some nonlinear math, except if you wish to drop OpenGL and implement your own rendering engine directly on CUDA or OpenCL.

With this curvilinear perspective even 3D triangles are no longer triangles on-screen (if I'm not mistaken), so GPU cannot rasterize them as it usually does.

 

The only possibility is to render something in traditional perspective, then bind the obtained picture as texture and perform full-screen post-processing to get bended view.

So you either render player's view as usual and then stretch it, or you render cubemap (much slower) and then apply post-processing to it.

 

If there is a clear place where this postprocessing could be applied, then I guess it won't need much changes in renderer.

If it is so, someone can try to implement it even now (for 2.07) under cvar.

Bloom stage, as proposed before, is good but as a postprocessing option it could blur the image in a non-uniform (much more blur in the center of the image) way AND generate some clipping problem at the borders of the scene :/

Edited July 5, 2018 by lowenz

[Atomica]

.

Edited August 2, 2018 by Atomica

[lowenz]

Goddamnit. This isn't something I even noticed before you mentioned it... now I can't seem to ignore it.

 

The weird thing is that it seems to be pretty obvious in TDM now that I pay attention to it, but most other games don't seem to have this issue. Either that or I'm just noticing a more "fish-eyed" lens in TDM for some reason.

Large (>80/90) HORIZONTAL FoV causes the issue, in every engine using linear perspective.

Using 16:9 resolutions you must set an higher FoV than good old 4:3 ones, so the issue is always there and sometimes very noticeble.....

 

It's why back in the days devs started using norrow horizontal fov angles (65) - see Crysis 2/3 and so getting a "tunnel vision" - but the problem lies in the linear perspective itself.

Edited July 6, 2018 by lowenz

[Oktokolo]

- but the problem lies in the linear perspective itself.

No. If you change perspective, you get non-straight lines. They are much more annoying than non-perfect circles.

The real problem here is, that the distance between player and monitor does not match the rendered FoV for most people, because the screens are only occupying a small part of the humand FoV (except when playing on really big screens or with really low distance between screen and player).

Getting a bigger screen (or a VR headset) could fix it. Lowering the distance between player and screen could fix it too. Changing the projection will only make things worse.

[AluminumHaste]

Quake2XP has this working and it's open source.

 

https://sourceforge.net/p/quake2xp/code/HEAD/tree/

 

https://sourceforge.net/p/quake2xp/code/883/

[lowenz]

No. If you change perspective, you get non-straight lines. They are much more annoying than non-perfect circles.

I know (see the shader!), but you can tweak the parameters value to avoid a heavy curvature!

[Atomica]

.

Edited August 2, 2018 by Atomica

[AluminumHaste]

I think this is what you guys are talking about:

 

[lowenz]

Yes!

[lowenz]

Ah, the correction strategy in Q2XP is the same shader I posted

[nbohr1more]

New tracker:

https://bugs.thedarkmod.com/view.php?id=5520

[Xolvix]

This is interesting because I recently felt that there was something off about the FOV. By default it's set to 90 but the actual FOV seems more like 105, at least from visual comparison to games like Quake 3 when set to such FOVs. In the bug report linked above, @stgatilov has a comment suggesting the FOV is based off a virtual 640x480 screen (so a 4:3 resolution). This makes sense since in Doom source ports it's convention to have the FOV specified by the user mapped to a 4:3 display as well (reference), so while the default in GZDoom is 90, the rendered FOV is also more like 105. An actual FOV of 90 feels much closer which can be seen in modern games with FOV sliders that tell you the specific horizontal FOV (e.g. Dishonored).

[ate0ate]

3 hours ago, Xolvix said:

This is interesting because I recently felt that there was something off about the FOV. By default it's set to 90 but the actual FOV seems more like 105, at least from visual comparison to games like Quake 3 when set to such FOVs. In the bug report linked above, @stgatilov has a comment suggesting the FOV is based off a virtual 640x480 screen (so a 4:3 resolution). This makes sense since in Doom source ports it's convention to have the FOV specified by the user mapped to a 4:3 display as well (reference), so while the default in GZDoom is 90, the rendered FOV is also more like 105. An actual FOV of 90 feels much closer which can be seen in modern games with FOV sliders that tell you the specific horizontal FOV (e.g. Dishonored).

I agree with this. I play a lot of FPS type games, both retro and newer, and always use the same monitor setup. Most games I crank up to about 100 fov and things look pretty good for my setup to my eye. TDM looks higher than that at its default of an apparent 90 degree fov. Its the only game I actually turn down to 80, even 85 makes a surprising difference. It does feel somewhere slightly over 100 by default to me as well.