Troika: 機能：文字/単語/行のインデックス属性をテキストジオメトリに追加します

また多分： wordIndex 、 lineIndex ...？

単語と行は、 https：//greensock.com/splittext/のように、行ごとおよび単語ごとのアニメーションで有効になります（これは、この変更によって有効になる良い例と見なすことができます）

これにより、フラグメントシェーダーでトークンごと（char、word、line）の変更も可能になると思いますか？

これにより、フラグメントシェーダーでトークンごと（char、word、line）の変更も可能になると思いますか？

頂点からフラグメントに変化として渡す必要がありますが、そうです。 :)

うさぎの穴を下りて行きます...

次のすべてのインデックスの用途と、それぞれの合計数を考えることができます。

• charIndex、totalChars
• wordIndex、totalWords
• lineIndex、totalLines
• charInWordIndex、totalCharsInWord
• charInLineIndex、totalCharsInLine
• wordInLineIndex、totalWordsInLine

これらすべてをオプトインし、スマートパッキングを実行して、導入する新しいglsl属性の数を最小限に抑えたいと考えています。 このためのAPIについてもっと考える必要があります。

ユーザーにフラグを付けてそれらすべてを選択させることができるので、

{{
分割：{単語：true、文字：true、行：true}
}

スマートパッキングを行う

これを拡張する気ですか？ 私は興味があります👐

ユーザーに分割を選択させるというアイデアが好きです。

パックするということは、12個の新しいattribute float foo宣言を追加したくないということです。そうしないと、制限に達します（webglでは合計16個の属性だと思います）が、それらを最大3個の新しいものにパックできます。 attribute vec4 foo宣言を作成し、シェーダー内の見栄えの良いfloat変数に解凍します。

そうそう、とても理にかなっています、ありがとう！

charIndexは、増分に空白を含める必要がありますか？ または、表示されているグリフをインクリメントするだけですか？ 目に見えるグリフだけに傾いています。

空白を数えると、インデックスでアニメーション化するときに奇妙なよろめきが作成されるので、私も目に見える方向に傾くでしょう

実行するクリーンアップはたくさんありますが、上記のカウントの初期POCがあります。 フラグメントシェーダーで色を変更するためにさまざまなインデックス/合計ペアを使用する例を次に示します。

charIndex / totalChars：

charInWordIndex / totalCharsInWord：

charInLineIndex / totalCharsInLine：

wordIndex / totalWords:(この例のcharIndex/totalCharsと非常によく似ていますが、微妙な違いがあります）

wordInLineIndex / totalWordsInLine：

lineIndex / totalLines：

私はすべてのデータを最大3つのユニフォーム+2つの属性に入れることができました。これはかなり良いことです。 私はまだそれらをオプションにしたいです。

すばらしい！ テストバージョンの準備ができたらお知らせください😄

私はこれが対処できる機能を実行することを探していました。 球の周りに配置する3文字のラベルがたくさんあります。 ビューマトリックスまたはモデリングマトリックスに適用されるスケーリングに関係なく、画面上で常に同じサイズになるように、常にビューアに面して調整を行います。
現在、ラベルごとに1つのTextオブジェクトを作成し、変換を適用しています。
すべてのラベルを1つのテキストにパックし、頂点シェーダーで正しい変換を行うために各ラベルの球上の位置を持つ属性を持つことで、はるかに優れたパフォーマンスを得ることができると考えていました。
@lojjicカスタムシェーダーを作成する方法を文書化できますか？ BufferGeometryの既存のメソッドsetAttributeが行うように、属性を追加することは難しくないと思います。

私が検討していた他のオプションは、すべてのラベルが3文字であるため、インスタンス化されたレンダリングです。 しかし、それには確かにWebGL 2が必要であり、少なくとも最初は複雑すぎて価値がない可能性があります。

@FunMilesあなたが正しいと思います、これはその種のことを容易にするかもしれません。 私がそれを正しく理解している場合、最適化には2つの部分が含まれる可能性があります。

1. 回転/スケーリングロジックをCPU側のJSからGPU側の頂点シェーダーロジックに移動する
2. その_plus_は複数のテキストを1つの描画呼び出しに結合します

1については、このコメントを見てください。これは、実際にはすでにニーズに十分である可能性があります。 これは、カスタムシェーダーを適用する方法の良いデモンストレーションでもあり、基本的にはmaterialとして割り当てるだけです。 そこでTroikaのcreateDerivedMaterialユーティリティを使用しましたが、同様に、任意のShaderMaterialまたは独自のonBeforeCompile変更を加えたマテリアルを渡すことができます。

2の場合、1つのテキストをレンダリングしてから、_some_属性を使用して、球の周りの個々の文字を移動できるのは正しいと思います。 この号で説明されている新しいchar/wordインデックス属性は役立つかもしれませんが、それらが必要かどうかさえわかりません。 おそらく、これらの変位を新しいInstancedBufferAttributeにエンコードすることができます。ここで、各ベクトルは1つの文字の変位を保持します（テキストのジオメトリは、各グリフに対してインスタンス化される単純なクワッドであるため、追加のInstancedBufferAttributesは各グリフに対してステップスルーされます）。

これをやって運が良かったかどうか興味があります！

@lojjicあなたは正しく理解しました。 そして、あなたがリンクしたコードは、私が必要とするものの90％を実行します（1）。 あなたのデモは私のユースケースと不気味に一致しています。
私の理解を正すように頼むかもしれませんが、これがあなたがしていることを私がどのように見るかです：

• mvPositionは、モデルビュー空間の参照点の位置で初期化されます。 その基準点がアンカーポイントだと思います。 そうですか？
• positionはその参照点からのオフセットであり、xとyの非ゼロ座標しかないと思います。 （これにより、スケールのzコンポーネントの計算をスキップできると思いますか？）（PS：インスタンス化されたレンダリング頂点シェーダーコードを見ると、テキストを回転できるようです。この場合、zコンポーネントはゼロになりません）
• 各方向のスケールは、3x3ブロックにスケーリングと回転の構成のみが含まれていると仮定して復元されます。
• スケーリングされpositionが追加され、zコンポーネントがゼロの場合、この寄与により、投影平面に平行な平面内の位置が維持されます。

（1）を実行するためのこのコードへの変更は、テキストが私が持っている球の外側にとどまるように、主にスケーリングとわずかな座標シフトにあります。

あなたは2も理解しました。 ただし、コードを読むときに少し混乱します。 テキストレンダリングがすでにインスタンスレンダリングであることに気づいていませんでした。 私を混乱させているのは、 InstancedBufferAttributeから派生した$ GlyphsGeometryがありますが、 TextはMeshのサブクラスであり、 InstancedMeshではないということです。 私はThree.jsをもっと深く掘り下げる必要があると思います。
それ以外の場合、各文字がインスタンス化されているとすると、各グリフインスタンスのpositionをオフセットするためのベクトルを持つ属性だけが必要になります。 そうですか？

私はこれから少し離れなければなりませんでしたが、ここに簡単なステータスの更新があります：

PR＃109は、さまざまなカウントを収集して公開するという点でかなり堅実に感じています。 私は彼らをオプトインさせたいのですが、そうでなければ私はそれがどこにあるかに満足しています。

ただし、シェーダーベースのアニメーションには、これらの新しいカウントだけでなく、次のような他のデータへのアクセスも必要になるという強い予感があります。

• 現在のグリフのクワッドバウンド
• 全体的なブロック境界
• クワッドから推測できないベースライン/アセンダー/ディセンダーなどのフォントメトリック情報
• 他の？

これらのいくつかはすでにシェーダーに技術的に存在していますが、ユーザーがそれらに依存する場合は、わかりやすい名前で公開し、信頼できる契約として文書化する必要があります。

誰かがそのPRブランチで遊んで、いくつかのシェーダーアニメーションを実装してみて、不足している情報を教えてくれるなら、それは大きな助けになるでしょう。

@lojjicこの機能に興味を示したいだけです😺

ここで最新のマスターとのマージの競合を解決しました： https ：//github.com/canadaduane/troika/tree/char-indices

まだテストする機会はありませんが、数日中にテストする予定です。

私は長い間この議論から離れていました。 しかし、私はそれをもう一度見たいと思ったことを思い出しました。
この投稿の最後に、 createDerivedMaterialを使用して行った例を示します。
ただし、現在、ラベルごとに1つのメッシュがあり、ラベルの数が非常に多くなると、ローエンドの電話ではレンダリングが非常にぎくしゃくします。 各ラベルのCPU呼び出しが原因だと思います。 これに対処するために、複数のメッシュをすべてのラベルが付いた単一のメッシュに置き換え、残りの処理には改良された頂点シェーダーを使用したいと思います。

@lojjicが言ったように、私は言葉にいくつかの限界が必要だと思います。 または、少なくとも、私の使用では、各単語の中心です。
それ以外の方法でそれを行う方法やそのセンターを取得する方法に関する他の提案はありますか？

https://flightlog-beta.vercel.app/circles?route=BRU-HER-ATH-IST-AMM-CAI-TUN-CMN-RAK-MAD-LIS-ZRH-GVA-NCE-CDG-DUS-FRA- MUC-LHR-LCY-LGW-DUB-HBA-SYD-MEL-CNS-KTM-DEL-BLR-COK-MAA-CMB-MLE-HKG-HND-NRT-KIX-ICN-GMP-MNL-DPS-JOG- CGK-SIN-KUL-PEN-LGK-BKK-SGN-HAN-LPQ-CNX-DOH-AUH-DXB-JNB-CPT-LVI-ZNZ-JRO-DAR-SSH-BUD-OTP-IPC-SCL-PMC- GRU-EZE-GIG-BSB-LIM-LPB-BOG-PTY-SJO-SJU-CUN-ACA-MEX-MTY-JFK-BOS-PHL-DCA-IAD-BWI-CLT-ATL-MSP-MIA-DFW- DTW-ORD-IAH-COS-DEN-PHX-SAN-LAX-SJC-SFO-SEA-PDX-YVR-YYZ-YUL-LGA-EWR-ASP-BNE-AKL-CHC-ZQN-VIE-SJJ-VCE- MXP-FCO-BCN-PEK-PVG-HNL-OGG-KOA-HIJ-RGN-PBH-TIP-AMS-CPH-SLC-CVG-GSP-TPE-ULN-PNH-VTE-ABQ-BUF-MCO-HKT- MDL-