feat(rendering): Add OrthographicCamera component

[mkuritsu]

Description

Added OrthographicCamera component to update the Camera with a orthographic projetion.

One thing I'm not sure if its the best approach is the size parameter added, I put it as a multiplier to the viewport the camera is drawing to. Would it be better to leave it like that or change it to be values to represent the plane size, something like a vec2{800, 600}?

Checklist

• Self-review changes.
• Update render main sample.
• Add entry to the changelog's unreleased section.

[github-actions]

PR Preview Action v1.4.8
🚀 Deployed preview to https://GameDevTecnico.github.io/cubos/preview/pr-1335/
on branch gh-pages at 2024-09-29 14:24 UTC

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 34 lines in your changes missing coverage. Please review.

Project coverage is 42.45%. Comparing base (f19856a) to head (3ecdf2d).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
engine/src/render/camera/plugin.cpp	0.00%	20 Missing ⚠️
engine/src/render/camera/orthographic.cpp	0.00%	12 Missing ⚠️
engine/src/render/split_screen/plugin.cpp	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1335      +/-   ##
==========================================
- Coverage   42.49%   42.45%   -0.05%     
==========================================
  Files         409      410       +1     
  Lines       29229    29260      +31     
==========================================
  Hits        12421    12421              
- Misses      16808    16839      +31     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kuukitenshi]

LGTM 👍🏻

[tomas7770]

One thing I'm not sure if its the best approach is the size parameter added, I put it as a multiplier to the viewport the camera is drawing to. Would it be better to leave it like that or change it to be values to represent the plane size, something like a vec2{800, 600}?

With the multiplier approach, does the visible area become smaller/larger depending on the viewport size? It doesn't seem right that different players see more or less of the game world just because their display resolution is different, atleast not by default. There is a lot of variance in display resolution/size combinations, ranging from things like 800x600 (usually windowed) all the way to 4K/8K, and small laptop displays to large TVs, which could result in very different experiences.

[mkuritsu]

One thing I'm not sure if its the best approach is the size parameter added, I put it as a multiplier to the viewport the camera is drawing to. Would it be better to leave it like that or change it to be values to represent the plane size, something like a vec2{800, 600}?

With the multiplier approach, does the visible area become smaller/larger depending on the viewport size? It doesn't seem right that different players see more or less of the game world just because their display resolution is different, atleast not by default. There is a lot of variance in display resolution/size combinations, ranging from things like 800x600 (usually windowed) all the way to 4K/8K, and small laptop displays to large TVs, which could result in very different experiences.

Ok yes true, wasn't thinking in that way, my mistake I will change and commit with the other approach.

[RiscadoA]

One thing I'm not sure if its the best approach is the size parameter added, I put it as a multiplier to the viewport the camera is drawing to. Would it be better to leave it like that or change it to be values to represent the plane size, something like a vec2{800, 600}?

With the multiplier approach, does the visible area become smaller/larger depending on the viewport size? It doesn't seem right that different players see more or less of the game world just because their display resolution is different, atleast not by default. There is a lot of variance in display resolution/size combinations, ranging from things like 800x600 (usually windowed) all the way to 4K/8K, and small laptop displays to large TVs, which could result in very different experiences.

Ok yes true, wasn't thinking in that way, my mistake I will change and commit with the other approach.

I guess we have four options here:

a) User specifies the final ortographic projection size - we simply don't take into account the target and viewport in the projection matrix math; leads to stretching but the user might want this in some cases I guess? I'm not sure

b) Multiply user specified size by the target*viewport size (what you have right now); AR is correct among all possible viewport configs, but users will be able to see a larger region of the world (in all directions) when rendering at higher resolutions.

c) User specifies the width of the projection matrix, and the height is calculated by multiplying the width by the aspect ratio of the target+viewport. AR is also correct on all possible configs, but users with higher display resolutions won't be able to view more of the world. Instead, users with weird aspect ratios might get to see more or less than what they should, but only in the vertical direction.

d) Same as above, but user specifies the height of the projection matrix instead of the width. I think this is more fitting than c), as in the previous options, users with extra wide displays would have their 'vertical view' very reduced. By specifying the height, we get the opposite. Users with extra wide displays get a larger 'horizontal view' but the 'vertical view' remains constant.

In my opinion, options c) and d) are the most useful, and we should probably allow the user to opt between them.
Maybe keep a float size; + an enum or boolean specifying which axis is being specified. What do you think?

[RiscadoA]

Thanks for working on this! Pointed out some nitpicks + check out my comment above

[tomas7770]

In my opinion, options c) and d) are the most useful, and we should probably allow the user to opt between them.
Maybe keep a float size; + an enum or boolean specifying which axis is being specified. What do you think?

Looks good. I think the perspective camera basically follows d)? Alternatively we could have a) and let a separate plugin manage the size, but that might be adding unneeded complexity.

[mkuritsu]

In my opinion, options c) and d) are the most useful, and we should probably allow the user to opt between them.
Maybe keep a float size; + an enum or boolean specifying which axis is being specified. What do you think?

Yes seems good, I was already making the d) option but I will add the enum to also allow for c) then.

[RiscadoA]

Just noticed this, don't use uppercase in the first letter of the commit messages; it should be: feat(scope): hey, not feat(scope): Hey

[RiscadoA]

Added my last two comments, after resolving my comments it should be good to go.
Don't forget to remove the _camera suffix from the files!

[mkuritsu]

Added my last two comments, after resolving my comments it should be good to go. Don't forget to remove the _camera suffix from the files!

ok I think all should be fixed sorry for the small mistakes

[RiscadoA]

Added my last two comments, after resolving my comments it should be good to go. Don't forget to remove the _camera suffix from the files!

ok I think all should be fixed sorry for the small mistakes

Dw about it, sorry for being so picky!

[tomas7770]

LGTM!