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

[Steve Lhomme]

On Thu, Nov 17, 2016 at 6:37 PM, Adrien Maglo <magsoft at videolan.org> wrote:
> Le 17/11/2016 à 18:03, Steve Lhomme a écrit :
>>>
>>> Why removing the trigonometry calculation? It was giving the exact
>>> minimal
>>> value for the zoom for any SAR and FOVy value.
>>
>>
>> First because I don't think it's right to modify the zoom value set by
>> the caller. If he has done his own calculation why do we change it to
>> some obscure formula ?
>
>
> It depends on how zoom is documented in the API.
> If we write that the zoom is the vector between the centre of the sphere and
> the position of the camera, then it is indeed not the case.
> If we write that the zoom is a value that varies between -1 and 1 and moves
> the camera between a minimum value obtained with the "obscure" formula and a
> maximum value currently set at 0.5 then in my opinion it makes sense.
>
>> Second because I don't see how the zoom can be related to the aspect
>> ratio. This is just a translation from the center to the border of the
>> sphere. Nothing will change if the source aspect ratio changes.
>
>
> 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.

>> 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.

> The general idea behind this API and the min value calculation was to not
> allow the caller to show the outside of the sphere and avoid black borders.
> This is a political choice. We could also say that we do not care about
> black borders and let the caller directly set the position of the camera.

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.

Overriding the calle value means it has no control of what his values
will end up doing (unless the formula is explained). That means
touch/mouse movements cannot be adapted to the zoom/fov values. 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.

>
> Best regards,
>
>
> --
> MagSoft
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel