-
-
Notifications
You must be signed in to change notification settings - Fork 23.7k
Ensure Projection's getters have uniform behavior with y_flip and reverse_z
#108250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
2f671b3 to
ddffe0d
Compare
|
For reference, here is the complete list of getters inconsistencies across all possible combinations of Doctest log |
ddffe0d to
27cadb6
Compare
|
I wonder if an easier solution would be preferable. Personally, I am unhappy that we have exposed the transformed projection directly, we should have exposed it as an array of floats or something to make it clear that it is just for passing to the GPU. Therefore, I would suggest the following:
The goal with this approach is to discourage users from using the getters at all. If needed, we can expose z_far and z_near directly through |
This PR partially solves #106312 and #107383 by ensuring that
Projection's getters return the same values even wheny_flipand/orreverse_zare applied.However I couldn't find a way to support
remap_zwithout disruption, which makes this PR of little help with Vulkan-style matrices Z ∈ [0; 1] (for instance with Forward+).The fundamental issue is that #100209 only supports OpenGL-style matrices (negative Z-facing, Z ∈ [-1; 1], and Y upwards), which seemed reasonable considering all user-facing code follows this standard. This is not necessarily true in the buffers though, nor inside the callbacks of the Compositor.
I leave this PR in draft state so that whoever can take a look and share ideas.
At this stage I'm thinking of another approach :
Projection's getters only support OpenGL-style matricesset_depth_correction)Of course this is under the assumption that we do not want to revert #100209, which is also an option although it is mathematically accurate (only more restrictive in terms of assumptions, which allows aggressive simplification).