WIP: Improve Camera Controls

[sturnclaw]

This is a draft PR encapsulating my work on #4818 and some bugs fixed along the way.

2020-07-06:
Fixed the top/bottom directional indicators pointing the wrong way, removed the need to have an active camera frame during pigui code, made WorldView::shipView a pointer instead of a value in the class (why did I do it that way in the first place?), and made target indicator drawing more accurate when the camera is outside the ship.

2020-07-10:
Moved the old debug display code from WorldView to the PiGui debug code, cleaned up the last of the newUI references in WorldView, moved it to a PiGuiView base instead of UIView, and removed two signals from Pi that were used for almost nothing.

I'm getting closer to achieving the original goal, but I want a good understanding of the intricacies of WorldView first. Dropping 200 lines from the file is a good side-goal too!

[sturnclaw]

...I'm still working on this I promise, github just won't let you have an open PR without commits attached.

[sturnclaw]

Some fun things are happening on my WIP branches. I've got nothing worth pushing yet, but there are exciting possibilities on the horizon once I figure out how to tie everything together...

2021-05-09.18-13-31.mp4

[bszlrd]

Cool!
How those displays are done? Rendered to texture, and one could select which parts to display with the UV?
Asking because if this stuff goes live, I need to finish up the default cockpit replacement. And for future cockpits as well.

[sturnclaw]

Cool!
How those displays are done? Rendered to texture, and one could select which parts to display with the UV?
Asking because if this stuff goes live, I need to finish up the default cockpit replacement. And for future cockpits as well.

I am aiming to have it directly render the imgui primitives (triangles) superimposed above the surface in the world, to avoid the need for a costly mipmap generation step and to generally produce far more crisp results. There are some issues with that however (lack of clip rect support for one, lack of renderer API features for several more) so for right now it's drawn to a low-res render target (300px square) and the render target's texture is mapped to the screen.

For right now, I'd suggest setting up all screens in the cockpit so that each one is a single plane with its own material, covering the 0..1 UV space. It's extremely cheap (at low resolutions and right now) to actually render to the screen so I don't think we need worry about atlasing. It also makes it a lot easier to then select specific atlas regions via push constants (uniforms) rather than trying to manually pack the screens into UV space during creation.

[bszlrd]

I've started a work issue for the default cockpit rework over at the overhaul repo/project.
I've also included the model there for you to play with.
And here are some preliminary layout work for the current UI elements: