-
-
Notifications
You must be signed in to change notification settings - Fork 70
Unexpected Y-axis translation when using ortho()
and resetMatrix()
#891
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
Comments
Hi @SableRaf , while giving some thoughts to this issue, I have few ideas and approaches to share and discuss here first. 1. Using Shader UniformTo ensure that shaders handle the Y-axis orientation correctly, we could declare a uniform boolean and then applying in vertex shader, followed by setting from Processing, something like- uniform bool uFlipY;
if (uFlipY) {
pos.y = -pos.y;
}
gl_Position = pos;
// In `PShader`
shader.set("uFlipY", true); 2. Using Internal Flag for Y-Axis InversionWe could declare a boolean something like - float yScale = flipYAxis ? -y : y;
float yTranslate = flipYAxis ? -ty : ty;
projection.set(x, 0, 0, tx,
0, yScale, 0, yTranslate,
0, 0, z, tz,
0, 0, 0, 1); and then a user can simply use like- g.flipYAxis = true;
ortho(0, width, 0, height);
resetMatrix(); 3. Adding a whole new method to handle thisWe could add a new method next to existing ortho(...) method - public void orthoTopDown(float left, float right, float bottom, float top) {
float x = 2.0f / (right - left);
float y = -2.0f / (top - bottom); // Flipping y here (as compared to existing method)
float z = -2.0f / (far - near);
float tx, ty, tz = (all as-is with no change)
projection.set(x, 0, 0, tx,
0, y, 0, ty,
0, 0, z, tz,
0, 0, 0, 1);
updateProjmodelview();
} Let me know your views on above. |
Hi @SableRaf and @Stefterv , after giving some more time and observations to this, I think we should use both the Approach 2 which is of using internal flag and Approach 1 using Shader Uniform. Because, In my opinion, for 2D/3D sketches with default P3D renderer, Only Approach 2 ( What you folks think of 🤔 ... |
Hi @SableRaf let me know among the methods that I have discussed above, which one would be the best suitable approach to fix this or some other concerns I should be taking care of and keep in mind to check upon before working on this. I would love to discuss feedback as well as other solutions that you think of if any. |
Hi @SableRaf and @Stefterv am I thinking in right direction as discussed in above comments:
I would be more than happy to raise a PR if you folks think that I am approaching in a correct way. Will revise the PR as per the feedback and changes as required. Thanks! |
Hi @IIITM-Jay, thanks so much for your thorough work and patience! After merging the earlier PR, we realized that—even though the current behavior is technically incorrect—many things have already been built on top of it. We’d like to fix it properly in the future, but don’t currently have the bandwidth to approach this with the care it needs. Really appreciate your effort here, and we’ll definitely revisit your suggestions when we’re ready to address it fully. |
Note
This issue is a repost of processing/processing#6175 by @usuallyannoyed, updated and edited for tone and clarity.
Description
The
ortho()
function does not behave as expected.Expected Behavior
ortho(0, width, 0, height)
with a cleared modelview matrix (resetMatrix
) should allow users to draw within the specified bounds (e.g.,0
towidth
on the x-axis and0
toheight
on the y-axis).Current Behavior
Instead, the drawing area behaves incorrectly, requiring adjustments (e.g., translating
-height
on the y-axis) to achieve the expected results. This behavior makes it unintuitive for users who expect the specified bounds to align with the visible viewport.Steps to Reproduce
Observed Result
The triangle only becomes visible when compensating for the unexpected offset by translating the y-axis.
Expected Result
The triangle should appear within the specified
ortho
bounds without additional transformations.Environment
Possible Causes / Solutions
The issue appears to stem from the following block of code in the Processing source:
processing4/core/src/processing/opengl/PGraphicsOpenGL.java
Lines 4482 to 4486 in 937f528
Despite the comment saying that
The minus sign is needed to invert the Y axis.
, this implementation does not fully invert the y-axis as intended. Instead, it flips the y-axis around zero, resulting in all the y-coordinates being offset into negative space.Suggested Fix
To invert the y-axis properly in normalized device coordinates (NDC), pre-multiply the projection matrix with a
-1
scale for the y-axis. This can be achieved by modifying the projection matrix calculation as follows:This approach ensures the y-axis behaves as expected without requiring additional transformations.
Additional comments
This behavior stems from Processing's choice to have the Y-axis increase downward, consistent with traditional computer graphics. While reasonable, the implementation relies on ad-hoc adjustments throughout the code. Centralizing it at a lower level (NDC or viewport) and exposing it as an optional flag would provide more clarity and flexibility.
The text was updated successfully, but these errors were encountered: