Viewport transformation efficiency

[white-axe]

Is your feature request related to a problem? Please describe. Luminol's shaders have a 4D viewport transformation matrix. This is totally unnecessary because all we ever do to the viewport is translate and scale it.

Describe the solution you'd like Replace the 4D viewport matrices with two vec2<f32>s: one that represents the position of the viewport and another that represents the scale along the X- and Y-axes.

Describe alternatives you've considered If we need to do more than just translations and scaling to the viewport, we can use a 3D transformation matrix instead of a 4D one. A 3D transformation matrix is enough to encode any 2D affine transformation, a 4D transformation matrix is only required for 3D affine transformations.

[Speak2Erase]

I'm honestly not sure how to solve this one?

Viewports are currently projection matrices from model space (coordinates for vertices relative to each other) to clip space (position on the screen)

The way they're currently implemented, they actually don't do a lot for us, because egui calls RenderPass::set_viewport to set the region where custom paint callbacks are drawn on the screen. This is both a curse and a blessing because it means that if we decide to draw things like events inside luminol_graphics::MapView we'll need to set the viewport ourselves, but it also means that we can effectively ditch Viewport (for events)

[white-axe]

We can still get rid of the projection matrix for Viewport though because, as far as I know, every single Viewport projection matrix we currently use is created using glam::Mat4::orthographic_rh, and that function just generates a matrix that represents some combination of translation and scaling (no rotations, shearing or other weird stuff). That can be reduced to just passing to the shader the translation as vec2<f32> and the scale as vec2<f32> instead of using a matrix.

[Speak2Erase]

I think what I'll do is split viewport into the region on the screen being drawn to (shared between things drawn in the samw region), and any transformations being applied to what's being drawn

This is how 3d usually works (there's a transformation matrix that applies rotation, scaling, and translation to an object) and a projection matrix which applies perspective and normalizes coordinates to fit in clip space