[vlc-devel] [PATCH 5/5] opengl: limit the fov and zoom to sane values

[Adrien Maglo]

Le 18/11/2016 à 10:31, Steve Lhomme a écrit :
>> We are calculating here the minimum value of the zoom to not show the
>> outside of the sphere. In the limit case, the view frustum pyramid is
>> tangent to the sphere. Consequently this values does depend on pyramid
>> shape, so the aspect ratio and the FOV. We can discuss the trigonometry
>> proof if needed.
>
> Out of curiosity yes. Also because I will have to implement it in
> Direct3D as well.

Here is the hand written proof.
http://magsoft.dinauz.org/videolan/demo_360_min_zoom.pdf
Please let me know if it is not clear.

>>> Third because the formula was apparently never going close to the
>>> border of the sphere, and thus never having a proper "little planet"
>>> aspect from there.
>>
>>
>> Thomas and I both tested several times this formula and it worked well. I
>> will recheck that the results are correct with current HEAD.
>
> It's OK. I re-tested it and I managed to get the little planet effect
> as I wanted.

Great.

> The problem IMO is to override the values set by the caller. For
> example it's possible to have fish-eye view of the 360° world, that
> includes the black sides of the sphere. But by forcing it with
> whatever input you feed, you can never see it.
>
> https://goo.gl/photos/hyjcfHiVvT2gAitLA with FOV at 80 and zoom at
> -1.65 (I had to remove the clipping in INPUT_CONTROL_UPDATE_VIEWPOINT
> to achieve this). So maybe we should allow values further than -1.
> Otherwise we have to have such projections in a different way.

Do we really want such projection?
Is there any other player that proposes this option?

> Overriding the calle value means it has no control of what his values
> will end up doing (unless the formula is explained).

Well, the zoom variable can be documented as a value in [-1, 1] that 
moves a camera within a range that depends on the aspect ratio and the FOV.

> That means
> touch/mouse movements cannot be adapted to the zoom/fov values.

Why they could not be be adapted to the [-1, 1] range?

> The
> current proposed mouse patch uses hardcoded values regardless of those
> factors but that's inefficient when zoom-in/fov-out or
> zoom-out/fov-in.

I do not understand this statement. The only hardcoded value is the 
maximum zoom at 0.5. The minimum zoom is dynamically modified in 
function of the FOV and the aspect ratio.

I can understand it may be a good idea to let to the developer set any 
zoom value he/she wants even if black borders are displayed. He/she is 
responsible for the experience inside its application.

However, I do not think it would be a good idea to let VLC final users 
zoom out to much and show black borders. They would not understand what 
they are and think this is a glitch.
I have never seen a VR player that allows that.

Best regards,


-- 
MagSoft