Field of View issues

[hytel]

My first VSG application is coming along. It's a combination of the vsgQt Viewer example, the vsgExamples vsgshadow example, and much more. In general, most things are working. One thing that hasn't been quite right for as long as i can remember is the way in which the scene adapts as the viewer is widened. In the vsgshadows example, I can widen the view as wide as I want, and the shapes are not distorted. In mine, the wider I make the viewer, the more narrow the objects. I have looked almost everywhere I can think of. I can't pin down the exact logic within the VSG framework that keeps the view consitent. I have the same 30 degree vertical perspective matrix setup as the examples. I'm using a combined initialization that is mostly pulled from these two example applications. The window definitely resizes just fine as I pull the Qt viewer's QMainWindow edge. It's definitely making it to things like the "WindowResizeHandler" visitor. Any ideas why my application doesn't keep the view of objects looking normal but the vsgshadows example does?

[AnyOldName3]

This could potentially be a regression from the recent switch to using dynamic viewports by default. I can't reproduce it on my machine with any of the vsgQt examples or vsgQt-based apps that I've got access to, though, so we're going to need more information here to isolate what's unique to your app.

[hytel]

Without trying to make things too complex, here's what I'm seeing. This is how the scene comes up:

And, if I just collapse the view vertically, it now looks like this:

I guess I'm interesting in WHERE vsg does it's magic to maintain the vertical FOV (I'm specifying 30 degrees just like the example), but compensates with the horizontal during resize operations. And, why might that logic not be triggered in my case. I basically have the QT initialization from the VSG Qt viewer example, and the scene and such initialization from the VSG shadow example. With several other modifications. Clearly the viewport and window are reacting in some ways to the resize.

[AnyOldName3]

That's a very extreme FoV. There are a bunch of ways the maths can break down when they're that wide. E.g. if there's a fixed 60° vertical FoV and the viewport's more than four times wider than it is tall, the naive approach would make the horizontal FoV more than 180°, and the maths involved with projection matrices simply doesn't support angles approaching or above 180°. Traditionally, that's dealt with by splitting up the viewport into multiple chunks with smaller FoVs.

[robertosfield]

Does this issue exist if you just load your models into vsgviewer example?

Does this issue exist if you just load your models into vsgqtviewer example?

Which version of the VSG and vsgQt are you building against?

The update of the FOV is done within the WindowResizeHandler::::apply(vsg::View& view) method:

https://github.com/vsg-dev/VulkanSceneGraph/blob/master/src/vsg/app/WindowResizeHandler.cpp#l165

[hytel]

Here are the results in the VSG shadow example super wide - NO ISSUE AT ALL, LOOKS PERFECT.

Here are the results in the vsg QT Viewer example with the LZ super wide - NO ISSUE AT ALL, LOOKS PERFECT.

I'd love the same behavior. There must be something in my code which prevents this. I'm sure by the two examples above that it's not version related. I'll have a look in the WindowResizeHandler and see if I can spot any differences in behavior.

[AnyOldName3]

Maybe try adding logging or inspecting things in a debugger to see what the old and new FoV are in the demos versus your app.

[hytel]

We'll the logic for handling this isn't in my Application, it's buried in the VSG and vsgQt libraries. I'd rather not go back to those libraries and recompile them with temporary additional logging that I'll have to remove later. It took me a long time to get VSG prerequisites working, vsgQT compile, the vsg Examples compiled, etc. I can though set break points in the WindowResizeHandler and check some of the logic, and values, but I'm not sure if I'll spot where the FOV horizontal is recomputed to compensate for the resize. I'll give it a shot.

[hytel]

Ok, I may have some idea of what is happening. To be clear, my situation is a bit different from most. I assume the majority are using the full window/screen vsg::Viewer like in the many examples. Much fewer are using a full window/screen Qt widget parent as in the Qt widget examples. But I'm not. I'm using a complex Qt form with a menu, other controls, a status bar, and a place for the vsg window widget. The problem is it's hard to compute the initial size ahead of time for the vsg window because things happen before it comes up. So, I use the rough numbers provided in the Qt designer to pass into the window traits, but even then, bad things happen. I can for example even say I want the central widget geometry at 0, 0, 100, 100 but that should still be BELOW the menu like it would be for most Qt applications. My understanding is that Qt forms with GL accelerated windows can sometimes overlap the menu bar so you need to add a content margin at the top of the layout to "push" the window down. Anyway, all that being said, I can't compute the window size ahead of time, only know that it will receive the window resize events just fine - I can see them coming in perfectly with the VSG resize handler.

The problem is with the perspective matrix transform. It computes the aspect ratio NOT from the new size of the window, but as a change from the previous aspect ratio. I'm sure there is a reason for this. Anyway, so if the aspect ratio is wrong to begin with, it will not fix itself when the window is resized and the new width/height/aspect ratio are known. It usually just gets worse. So, what I did is to make a duplicate version of the perspective matrix but change the transform so the aspect ratio is simply computed on the NEW sizing information, alone and not as a change from the old. This seems to work just fine. I'll be testing more soon. But I wanted to leave this note here now because I will not be able to work on this next week.

[robertosfield]

Well done on getting to the bottom of the issue.

When I wrote the VSG's projection resize mechanism I did it on the assumption that the initial values were valid and changing relative to this would be appropriate. It might be that we can tweak the design so that it handles you particular usage case correctly - the obvious thing to do is have a fixed vertical FOV and then compute the horizontal FOV for the current aspect ratio, but this is vsg::Projection subclass dependent but perhaps it's OK to have individual implementations.