Make RenderSceneData take projection correction into account

[BastiaanOlij]

This came out of #90148 and deals with the comment made by @xcodian

We now make sure that get_cam_projection and get_view_projection return corrected projections to deal both with our reverse-z and flip-y logic.

This also adds logic to keep the flip_y state in our scene data object and remove passing this around as a parameter, in doing so it highlights there are a few other scenarios where we flip y.
The compatibility renderer has not been touched as it currently does not support compositor effects but has similar logic we'll look at as part of a planned cleanup in 4.4.

For testing, this is @jake-low's original MVP adjusted for master including fixing memory leakage and adjusting it for this change.
MVP-90148-corrected-v2.zip
Note:

• Reverse-Z means that near-depth is 1.0
• I could not reproduce the gamma issue, it's possible that this was fixed alongside the reverse-z changes
• The reported "upside down" orientation is the reality we live with. We are working on internal buffers which need this orientation. This PR embeds the needed flip in the projection matrix making it less likely mistakes are made.

(note, the cube was moved into the cone on purpose, was just testing if depth was correct here)

[BastiaanOlij]

Just double checking, @akien-mga @AThousandShips it was 4.2-stable.expected where I need to add checks for compatibility breakage? I'm not fixing the virtual functions because there is no possible scenario where someone would extend this class with GDExtension, but calling these functions from GDScript is a use case we need to catch.

[AThousandShips]

This was exposed in 4.3 AFAIK so not even sure compatibility binds are necessary

Edit: Yep, there's no RenderSceneData in 4.2, so the validation doesn't need to change (unless this is added in 4.4), but I think the compat binds are relevant still for smooth transition

[BastiaanOlij]

This was exposed in 4.3 AFAIK so not even sure compatibility binds are necessary

DOH! off course!

[BastiaanOlij]

@kebabskal would you mind checking this out as well and see if this has any effects on your project? Yours is probably the most extensive use case of compositor effects so if we're overlooking anything, hopefully we can uncover it quickly.

[clayjohn]

Is there any way that we could detect if the RenderSceneData is being used in ReflectionProbes? I would really like to remove the p_flip_y option if we can.

For starters, it will always be false in the GLES3 version of this class. So the user shouldn't have to think about that.

Perhaps we could store whether a ReflectionProbe is being used when we create the class?

Alternatively, we could overhaul the renderer so we aren't rendering upside down. As far as I can tell there has never been a benefit to rendering upside down.

[BastiaanOlij]

Just to clue everyone else in on our discussion this morning.

Our decision for now is that for 4.3 we'll try and make the logic in RenderSceneData* automatic, I'll look into the needed changes to make this possible and update this PR.

Than for 4.4 we're going to investigate removing the flip logic all together. I'll raise a proposal with the details for this.

[dsnopek]

If we could just render right side up always, in both RD and compatibility, that would be amazing! :-)

[BastiaanOlij]

This is something to investigate later, I'm pretty sure we've hardcoded the flip in the shaders used here,. I've left this comment here so we are reminded to do this as part of the planned flip-y clean-up (ditto on mobile renderer).

[kebabskal]

@kebabskal would you mind checking this out as well and see if this has any effects on your project? Yours is probably the most extensive use case of compositor effects so if we're overlooking anything, hopefully we can uncover it quickly.

As you saw, tried it on stream and it seems to work perfectly! Thanks!