processing / processing/processing4
loadImage(...) and createGraphics(..., P2D) have different y-coordinates
まだ誰も着手していません。
- 主要言語
- Java
- スター
- 494
- フォーク
- 183
- 平均マージ
- 4時間 39分
- マージ済み PR(30日)
- 3
説明
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...
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
提供されたスケッチを再現し、loadImage(...) と createGraphics(..., P2D) のテクスチャ座標の挙動を、BufferedImage の経路とシェーダー出力も含めて比較します。これらのエントリーポイントと PGraphics から始めて、座標規約を一貫させられるかどうかを確認します。シェーダーの下で両方の画像ソースが同じ y 方向を生成すれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- computer-graphics
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100