loadImage(...) and createGraphics(..., P2D) have different y-coordinates
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- java
- Lĩnh vực
- computer-graphics
Hướng nghiên cứu
Tái hiện sketch được cung cấp và so sánh hành vi của tọa độ texture của loadImage(...) với createGraphics(..., P2D), bao gồm cả đường dẫn BufferedImage và đầu ra của shader. Bắt đầu từ các entry point này và PGraphics, sau đó xác định xem quy ước tọa độ có thể được làm cho nhất quán hay không; hoàn tất khi cả hai nguồn ảnh tạo ra cùng một hướng y dưới shader.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Most appropriate sub-area of Processing 4?
OpenGL
Processing version
4.4.4
Operating system
MacOSX
Steps to reproduce this
PShader texCoordShader;
PGraphics pgP2D, pgDefault;
void setup() {
size(800, 400, P2D);
String fragShader =
"#ifdef GL_ES\n" +
"precision mediump float;\n" +
"#endif\n" +
"varying vec4 vertTexCoord;\n" +
"void main() {\n" +
" gl_FragColor = vec4(vertTexCoord.st, 0.0, 1.0);\n" +
"}";
saveStrings("frag.glsl", split(fragShader, "\n"));
texCoordShader = loadShader("frag.glsl");//, "vert.glsl");
pgP2D = createGraphics(400, 400, P2D);
pgDefault = createGraphics(400, 400); // Default JAVA2D renderer
pgP2D.beginDraw();
pgP2D.endDraw();
pgDefault.beginDraw();
pgDefault.endDraw();
}
void draw() {
background(0);
shader(texCoordShader);
image(pgP2D, 0, 0);
image(pgDefault, 400, 0);
}
Additional context
I'm working on a keystone library that is using a shader.
Because a image has different coordinates then a graphics created with P2D I need to know what the user is giving.
Not only that, it complicates the shader math way more then I would like.
To give an example:
The difference between those is P2D and default renderer (both in a sketch that is P2D).
Notice that the text is correct in both cases!!!
This does not just apply for PGraphics, using loadImage is different as well (cause also baked by a BufferedImage).
Having a mix of both of them really complicate things.
Complaining is easy however. I will dig into seeing if I can find a solution.
Would you like to work on the issue?
Trying...
- Ngôn ngữ chính
- Java
- Star
- 497
- Fork
- 183
- Merge trung bình
- 4 giờ 39 phút
- Pull request đã merge (30 ngày)
- 3
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của processing/processing4
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
processing/processing4#1554 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
processing/processing4#1515 · 1 reaction ·
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
processing/processing4#1573 ·
-
startup error Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
processing/processing4#1569 · 7 bình luận ·
-
Binaries under bin directory lack executable permissions for the snap and .deb packages for Linux Đang mởbug
processing/processing4#1567 · 3 bình luận · 1 reaction · 1 người được giao ·
Tất cả issue của processing/processing4
Issue tương tự
-
certification
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 80/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Đang mởbug ecr
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Needs: Triage Type: Feature request
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
github/copilot-sdk#2760 ·