はじめに

　リリースノート

　2.0のレファレンス

何が変わったか

#7102：@Garima3110 が投稿した問題 #7077 に対処しました

　まず#7077から見て行きましょう。

#7077：createCamera は引き続きデフォルトのカメラとして自動的に設定されますか？

　@Vishal2002 と #7071をデバッグしていたところ、私の最初のバグレポートのコードにバグがあることに気付きました。setup で createCamera を使用してフレームバッファカメラを作成していたのですが、それが誤ってメインキャンバスのカメラに設定されてしまっていました。これは、createCamera() 呼び出しのデフォルトの動作が、新しいカメラを返すだけでなく、基本的にそのカメラに対して setCamera() も呼び出すことになっているために発生していました。これを回避するには、push/pop などの同等のメソッドで囲む必要があります。

#7071：
フレームバッファカメラで引数なしのcam.ortho()はメインキャンバスのサイズを使用します

これのデバッグの際に生じた問題を解決したようです。

#6777：@davepagurek による Documentation.js から古い形式への初期変換スクリプトを追加します

　これは、docs/data.json を古い docs/reference/data.json 形式に変換する Node.js スクリプト用の定型文を追加します。node utils/convert.js を呼び出して実行すると、出力が docs/converted.json にダンプされます。

#7179：@sproutleaf によるすべてのパラメータタイプを標準化

　まず#7178から見て行きましょう。

#7178：フレンドリーエラーシステムのパラメータ検証を刷新

　なんかフレンドリエラ―のバリデーション方法についてのなんからしいです

　FES で使用するすべてのパラメータ型を標準化しました。つまり、すべての型を大文字で始める必要があります。また、特定のオプションではなく定数が保持される現象も修正しました。

　私のエディタは保存時にファイルのスタイルを自動的に変更するため、一部に空白が追加されていました。申し訳ありません。

#7183：@sproutleaf による convert.js の修正とパラメータの標準化を完了します

　#7179 のフォローアップ: 前回の標準化で捕捉されなかったパラメータを修正しました。また、parameterData.json を生成する convert.js も変更しました。

スキーマ生成に使用されないフィールド (クラス、名前、モジュールなど) を削除しました
パラメータがオプションの場合、オプションフィールドを末尾の ? に置き換えました
データ構造をフラット化することで複雑さを軽減し、可読性を向上させました

#7186：@sproutleaf による Zod を使用して新しいパラメータ検証ツールの開発を開始します

　p5.jsにvalidate_paramsを追加します。現在、このファイルはp5と連携しておらず、完全な機能とドキュメントがまだ備わっていません。これは今後の開発の出発点として役立ちます。

#7194：@sproutleaf によるパラメータ検証とテストファイルの更新

　変更点：

実際のp5定数に対して検証する
オプションパラメータを完全に考慮する
パラメータ検証用の新しいテストファイルを追加する

#7203：[p5.js 2.0] @limzykennethによるリファクタリングとモジュールビルド

バンドルからプリロードを削除
async/await のサポートを設定
ライフサイクルフックを設定 - WebGL でのライフサイクルフックの使用には、依然としてリファクタリングが必要です
p5.prototype 配下のすべての独自プロパティとメソッドは、グローバルモードでウィンドウにアタッチされますが、名前が _ で始まるものはすべて除外されます

docsのparameterData.json
1589行目

 "image": {
      "overloads": [
        [
          "p5.Image|p5.Element|p5.Texture|p5.Framebuffer|p5.FramebufferTexture",
          "Number",
          "Number",
          "Number?",
          "Number?"
        ],
        [
          "p5.Image|p5.Element|p5.Texture|p5.Framebuffer|p5.FramebufferTexture",
          "Number",
          "Number",
          "Number",
          "Number",
          "Number",
          "Number",
          "Number?",
          "Number?",
          "CONTAIN|COVER?",
          "LEFT|RIGHT|CENTER?",
          "TOP|BOTTOM|CENTER?"
        ]
      ]
    },

2091行目

"createVector": {
      "overloads": [
        [
          "Number?",
          "Number?",
          "Number?"
        ]
      ]
    },

#7210：@davepagurek による WebGL テストのほとんどを修正

後方互換性を保つため、現時点では色のゲッターをいくつか追加しました
以前のランナーと現在のランナーの間のテスト変更をいくつか修正しました
いくつかのバグを修正しました。これらのテストがどのようにして成功していたのかは不明です
-- roll() テストは実際には tilt() をテストしていました
-- buildGeometry テストは周囲のコンテキストの塗りつぶし色を無視し、それを白と比較していましたが、それでも動作していました
テストが失敗したときにスクリーンショットを保存する機能を無効にしました。スクリーンショットはすべて空なので、無効にしました

#7251：@davepagurek による 2.0 でのビジュアルテストの実行

　これは#7210を基にしており、ビジュアルテストを再び実行できるようになります。いくつか注意点があります。

vitestリファレンスからリンクされているライブラリはNode.jsでしか動作せず、ブラウザで実際のテストを実行するのは少し面倒なので、結局使用しませんでした
Viteは既にブラウザにファイルの読み書き用のサーバーフックを提供しており、それを使用することができました。最終的には、古いビジュアルテストランナーをそれらのフックを使用できるように改造するだけにしました
あいまい一致を行うために、diffライブラリであるlikejsを追加しました。今後、このライブラリのテストと設定の調整をさらに進める必要があるでしょう
また、WebGLテストで、頂点カラーがアルファを正しくインポートしないというバグも発見しました

#7215：@lukeplowden による、他の貢献者向けに dev-2.0 ブランチを実行できるようにするための小さな修正

　余談ですが、これは1.x互換レイヤーに組み込むのが良いかもしれません。色をシェーダーユニフォームに素早く変換するため、カラーレベルや配列プロパティにアクセスしている人を見かけます。そういったことを記録するための問題を作成する必要があるかもしれません。（シェーダーに色を渡すことはそれほど珍しくないので、toNormalizedRGB() のような、より適切な名前の「本当の」APIを用意するのも良いかもしれません。）

#7257：@limzykennethによるモジュール構文変換

　
　現在、すぐに誰かが作業していないすべてのモジュール（Typography、FES、WebGLは除く）を新しいモジュール構文に変換する作業を進めています。これらのモジュールは実装者の裁量で変換できます。

　変換方法については、既に変換済みのモジュールをご覧ください。さらに説明が必要な場合はお知らせください。以下に概要を説明します。

　src/ 内の各フォルダはモジュールとみなされます（つまり、ライブラリをモジュール形式で配布する場合、これらがさらに分割される可能性は低いということです）。各モジュール内の各ファイルはサブモジュール/ライブラリファイルとみなされ、#7015 で説明されている新しいライブラリ構文を使用します。さらに、各モジュールフォルダには新しいファイル index.js が作成され、以下の形式で提供されます。

　以下略

#7266：@davepagurek によるさらなるテスト修正

テクスチャテストにpixelDensity(1)を追加しました。これにより、高dpiディスプレイでテストを実行してもテストが中断されることはなくなりました
画像差分ライブラリをよりカスタマイズされたものに置き換え、ピクセルシフトへの対応を改善しました
古くて使われていないブラウザベースのビジュアルテストランナーを削除しました

#7268：@sproutleaf によるパラメータ検証とテストファイルを更新します

パラメータバリデーターは、実際のp5オブジェクトとWeb APIオブジェクトに対して検証するようになりました
テストファイルを更新し、以前のパラメータバリデーターファイルでカバーされていたすべてのテストケースに加え、さらにいくつかのテストケース（p5外部のクラスの関数のテスト、Web APIオブジェクトのテストなど）を追加しました
パラメータバリデーターに新しいモジュール構文と依存性注入を使用しました
パラメータバリデーターは、配列型の引数を動的に処理するようになりました

#7267：@davepagurek による dev-2.0 用シェーダーフック

　これは #7149 からの分岐であり、dev-2.0 ブランチとのマージ競合を解決します。

#7291：@sproutleaf によるパラメータ検証の最終変更

paletteLerp のパラメータ検証サポートを追加しました。paletteLerp の追加については #6960 をご覧ください
zod-validation-error ライブラリを使用する代わりに、初心者向けのカスタムロジックを使用してエラーメッセージを出力し、それに応じてテストを修正しました
convert.js を更新し、1) 誤って重複した定義（createAudio で発生したものなど）を無視し、2) 同じ型のオーバーロードが存在する場合は重複を排除するようにしました
完了した未処理の TODO 項目の削除、デバッグ専用の関数 printZodSchema の削除など、コードのクリーンアップを行いました

#7276：@lukeplowden によるカスタムシェーダー属性を定義する setAttribute() 関数

これの解決のようです：

#5120：p5Shader - カスタム属性を指定する方法はありますか？

　上記の問題に対応して、グローバル setAttribute() 関数と、p5.Geometry に同じ名前のメソッドを追加しました。

　（議論の中で名前が変更されたようです）

　vertexProperty という名前を使うことで、頂点自体を置き換えたり設定したりするのではなく、頂点に何かを追加しているということが明確になります。つまり、vertexProperty という名前は適切だと思います。

#7295：@davepagurek による初期モジュールのリファクタリング

　これは、#7270 から最後の緑色のチェックまでを取得し、上流の変更をマージして、マージ可能な状態に到達することを期待します。

#7296：[p5.js 2.0] @limzykennethによるWebGLモジュール構文

p5.DataArray のようなクラスは、公開ドキュメントはあるものの、大部分が内部的なようです。公開API でしょうか？公開API でない場合は、p5 にアタッチされず、スタンドアロンクラスとして GeometryBuilder クラスと同じように扱うことができます
p5.Texture.js の MipmapTexture クラスは、新しいシステムとの互換性に問題があります。エクスポート時に、MipmapTexture が p5.Texture を拡張するために必要な p5 が利用できません。Texture クラスをファイルスコープ（つまり、新しいライブラリ構文の function(p5, fn){...) 内ではないスコープ）に移動することはできますが、Texture クラス自体は定義時に p5 への参照を必要としますが、これは新しいライブラリ構文の function 内でのみ利用可能です。また、export はルートで実行する必要があるため、ライブラリ構文の function から MipmapTexture をエクスポートすることもできません。この問題の最適な対処方法がわかりませんので、何かアイデアがあれば教えていただけると幸いです
p5.RendererGLクラス自体を動作させるには、まずp5.Textureの修正が必要になるかもしれません。この部分をリファクタリングしたいとおっしゃっていたと思います。p5.Renderer2Dもまだ変換していないので、今のところは後回しにしておきます

#7293：@sproutleaf による FES に新しいスケッチ検証ツールを追加

新しい sketch_verifier.js ファイルを .../core/friendly_errors に追加します。これにより、現在の sketch_reader.js が置き換えられます
sketch_verifier.js は、ユーザーのコードを読み取り、ユーザー定義の変数と関数を抽出できるようになりました
既存のすべての機能をカバーするテストファイルを追加します

#7256：シェーダーが何に使われるかを定義する。by @Garima3110

　これの解決：

#6759：p5.js 2.0 RFC 提案: シェーダーが何に使われるかを定義する

　
　シェーダーはp5の中で最も導入障壁が高いと言えるでしょう。シェーダーが適用されるタイミングとされないタイミングについて、混乱が生じています。この混乱を解消することで、ユーザーがシェーダーを習得し、理解しやすくなるでしょう。

　現在、p5は、塗りつぶし、ストローク、画像などにシェーダーを使用するかどうかを、それらに含まれるユニフォームや属性に基づいて判断します。これは現在、以下のようにドキュメント化されています。

　シェーダーがこれらのプロパティを必要としない場合、未使用のシェーダープロパティを最適化して削除するブラウザーもあるため、未使用のシェーダープロパティをシェーダーに追加することは信頼性の低い解決策です。

　ユーザーシェーダーを塗りとストロークのみに適用できるシナリオを簡素化することを提案します。

塗りシェーダーは、現在のテクスチャやライトの有無に関係なく適用されます
ストロークシェーダーはすべてのストロークに適用されます
どちらもimage(...)の呼び出しには影響しません。シェーダーに画像を送りたい場合は、texture(...)を呼び出すか、uniformを設定してから四角形を描画する必要があります

#7323：@davepagurek による形状テスト

　これにより、2DモードとWebGLモードのbeginShape/endShape機能の単体テストが追加され、シェイプ描画の内部をリファクタリングする際のチェックリストとして使用できます。

同一シェイプ内のベジェ曲線と二次曲線の頂点の組み合わせは、現在サポートされていないため、テストされません
WebGLモードと2DモードでcurveTightnessの扱いが異なるバグがあるようです。現時点ではテストケースはそのまま残していますが、将来的に共通の実装を使用する際に、どちらかが動作しなくなる可能性があります

#7316：@SilasVM による dom.js の内容を 4 つのファイルに分割

#7113：@Garima3110 による問題 #7059 を解決

　まず#7059を見ましょう。

#7059：画面座標を取得する関数の提案

　スクリーン関数ですね。
　メリーさんや山辺さんが欲しいとツイートで述べていたので自分が提案しました。

　screenX()、screenY()、screenZ() のような関数を Processing に実装するという提案です。

　p5.js にも画面座標を計算する関数が必要だという提案をよく見かけます。ここで提案した方法ではないにしても、そのような関数があれば良いと思いました。

　以下は、2D と WebGL の両方のコンテキストで worldToScreen 関数を示す複合スケッチです。
　demo sketch

議論の一部

ご依頼いただきありがとうございます。コードは良さそうです！

2Dと3Dのユニットテストを追加していただけますか？シンプルなケース（例えば、変換が適用されていないケース）と、手動で検証できるケース（例えば、90度回転など）の両方を追加してはどうでしょうか？
例えば、回転する正方形（3Dでは立方体）のようなケースで、各頂点の横に画面座標を描画するといったことは可能でしょうか？

無事作ってもらえたようです。

#7350：@davepagurek によるシェイプのビジュアルテストをさらに追加

　@GregStanton が #7323 で言及したように、ビジュアルテストではカバーされていないシェイプモードがいくつかあります。これにより、点、線、三角形、四角形のケースが追加されます。

#7270：p5.js 2.0 @limzykennethによるステートマシンとレンダラーのリファクタリング

　ベースクラスp5.Rendererは、push()とpop()の影響を受けるレンダラー内のすべての状態を追跡するstatesプロパティを提供します。ベースバージョンは以下のようになります。

　p5.Renderer を拡張する各レンダラーは、push() および pop() の影響を受ける場合、状態プロパティに状態を追加する必要があります（例：this.states.someState = 'someValue'）。push() および pop() の基本実装では、push() が現在の状態のコピーを配列にプッシュし、pop() が配列に最後に保存された状態をレンダラーの現在の状態に復元することで、状態が追跡されます。（詳細は以下の行のコメントを参照してください。）

　個々のレンダラーは、状態の必要な変更に応じて処理するだけでなく、push() と pop() の独自の実装で super.push() と super.pop() を呼び出す必要があります。

#7355：@davepagurek による WebGL モードのリファクタリング

　まず#7030を見ます。

#7030：画像のユニフォームはシェーダを使用して描画するたびにリセットされます

　ご指摘ありがとうございます！#5923以降、シェーダーがアンバインドされている時はテクスチャもアンバインドされます。これは、他のバグを防ぐためです（テクスチャを使用していない時、バインドされたままにしておくと、下流で多くのバグが発生します）。ただし、各描画の直後にシェーダーをアンバインドするため、最初のシェイプにのみ深度テクスチャがバインドされ、それ以降のシェイプは空のテクスチャになります。現状では、各シェイプを描画する前にユニフォームを再適用する必要があると思われます。
　p5でこの問題を修正するには、シェーダーが最後に使用された際にバインドされたテクスチャを記録しておく必要があるかもしれません。そうすれば、シェーダーを再度使用する際に、それらの値を再バインドできます。そうすれば、テクスチャは他のユニフォームと同様に機能します。

　いわゆるテクスチャのリセット問題ですね。カスタムシェーダの場合、setUniformで設定したテクスチャは描画のたびにリセットされるようです。

　ここでの私の計画は、WebGLモードの構造をリファクタリングし、貢献者にとってより理解しやすく、重複を減らすことです。概要は以下のとおりです。

RendererGLのすべてのメソッドを1つのファイルにまとめます。複数のファイルに分割されているものは、既存のGeometryBuilderクラスと同様に、自己完結的な要素にする必要があります
immediateモードとretainedモードを可能な限り統合します。どちらもp5.Geometryを使用して描画しますが、ジオメトリの作成と保存の方法が異なるため、これらのシステムを分離し、共通のレンダリングコードを残す必要があります
シェーダーとジオメトリのプロパティの場所をより明確に定義します。現時点では、レンダラーの動作に応じて、複数の場所のいずれかに配置される可能性があります

　なんか色々あったようです。

#7361：@limzykenneth による 2.0 モジュールのクリーンアップ

　主に#7270から残ったアーティファクトをクリーンアップしています。

#7368：custom_shapes.js を追加します。これは最終的に @GregStanton による vertex.js に置き換えられます

　まず#6560を見てみましょう。

#6560：頂点関数をリファクタリングして複合パスを有効にする

　この機能強化により、さまざまな状況にある個人へのアクセスが向上します。
　大規模なコードベースの経験が少ない、あるいはコードベースを操作するための自由時間が少ないボランティアにとって、頂点関連の機能への貢献は現実的になります。例えば、新しい arcVertex() 関数に対するコミュニティのサポートはありますが、現在のコードベースの複雑さが開発の妨げとなっています。
　複合シェイプを作成したいユーザーにとって、既存のp5 APIは期待通りに動作するため、混乱が少なくなります。また、複合シェイプを作成するためにネイティブのCanvas APIやSVGを学習する必要がないため、知識の壁も解消されます。

　色々便利になるようです。

　これは、以下の変更を加えた新しいファイルを作成するだけの小さなPRです。

shapes -> custom_shapes.jsを追加します。これは最終的にvertex.jsを置き換える予定です
shapes -> index.jsにアドオンを登録します
src -> app.jsを更新し、新しい機能をそこに含めます

#7369：@davepagurekによるストロークの深さの順序付けの問題を修正

　まず#6386を見てみましょう。

#6386：Chrome/Linux でラインシェーダーが動作しない

　一部のマシンで、一部のテストにおいて、WebGLの塗りつぶしの背後に線がレンダリングされるという問題が発生しました。これにより問題は解決しました。具体的な内容については、コメント欄に詳細を記載してください。

#7365：p5.js 2.0 @limzykennethによるIOリファクタリング

　とりあえずここまでとします。

おわりに

　ここまでお読みいただいてありがとうございました。