Clothウェブシミュレーター (cloudofoz.com) 1 ポイント 投稿者 GN⁺ 2025-04-27 | 1件のコメント | WhatsAppで共有 関連記事 Flipbook - モデルから直接ライブストリーミングされるWebサイト 6 ポイント · 3件のコメント · 2026-04-23 Three.jsベースのライトセーバーシミュレーター 17 ポイント · 10件のコメント · 2025-07-15 Streamlit - PythonコードをカスタムMLツールに簡単に変換 3 ポイント · 0件のコメント · 2020-02-11 Show HN: ブラウザで3D植物シミュレーション 3 ポイント · 1件のコメント · 2023-12-04 WebGL流体シミュレーション技術 2 ポイント · 1件のコメント · 2024-12-30 1件のコメント GN⁺ 2025-04-27 Hacker Newsの意見 ブラウザで見られる別の例: https://oimo.io/works/cloth/ こういう布のインタラクションをゲームでいつ頃見られるようになるのか気になる Marian Pekárの記事を読んでVerlet積分を理解し、自分で布シミュレーションを作れるようになった: https://pikuma.com/blog/verlet-integration-2d-cloth-physics-... 「VerletはフランスのVerlet地方で作られたものだけがVerletで、それ以外はただのスパークリングEuler」というジョークが素晴らしい Web開発、Gradle、Javaの知識から、どうやってこういうものを作る段階へ移れるのか気になる CSの学部を出ていないので、プログラミング言語をいくら学んでも、こういうものは一生理解できないのではないかと思うことがある。OPENLY、LIBGDX、GODOT、Unityを少し触ってみたことはあるが、布シミュレーションをゼロから作るとなると本当に途方に暮れる 思っているよりずっと単純。私はソフトウェアエンジニアとしてのキャリアを始める前に、このスレッドの別の場所でリンクされている「破れる布」のデモを作った ここでは基本的なVerlet積分を使っており、格子を構成する2Dベクトルを現在位置と過去位置に基づいて更新し、すぐ隣の点との一定距離を保つように制約する。その点同士の間に線を引けば布になる。物理シミュレーションに魅了されて調べていたとき、実装しやすいものの一つだったので最初に取り組み、労力に対する結果がとても良かった。もちろん、その先はずっと複雑になる 物理シミュレーションを学びたくて、同じように感じたことがある。時間がたつにつれて、物理のような知識領域と、それを実装するためのプログラミング道具は分けて考えるべきだと学んだ 特にゲーム開発から入ると、剛体、布、ばね、流体のような主要なシミュレーションごとに、自然で慣用的なプログラミング方法があるように感じる。最初は流体シミュレーションも、格子を作って時間ステップごとに更新ルールを選ぶような形で、言語の中に自然に表現できると思っていた。だが実際には、問題を数学と物理でモデル化し、それを言語と道具にマッピングする作業であり、その道具が常に慣用的に表現してくれるわけではない 粒子位置とばねに基づく布シミュレーションのように、コードへ移しやすいアルゴリズムもあるが、さらに先へ進もうとしたときには、むしろそれが誤解を生んだ。結局、物理と数値解析をより深く掘り下げてから問題をコードに移す必要があり、結果のコードは不格好でマジックナンバーが多くなることもある Web開発はJavaだけに限られず、概してコンポーネント統合の問題が支配的。構造は多いが中身は少なく、計算はライブラリに委ね、ビルド時には統合の複雑さが、実行時には分散システムの規模が問題になる 逆にシミュレーションを書く場合は計算量が多く、コードの大部分が実際の中身になる。Web開発が異質なものの組み合わせだとすれば、シミュレーションはより均質だ。問題は、秒間フレーム数が決める時間予算の中で、単一プロセスの性能に制限されること だから一つの実行環境に集中できる。配布の問題を解決してくれるブラウザを勧める。Ganja[1]はおそらく「構造ではなく中身」に近い究極のシミュレーションプロジェクトかもしれない。非常に特異で理解しづらいためメンテナンスは止まっているが、動作はする。もう少し構造化されたものとしてはD3があり、作者たちは力学ベースのグラフ[2]のような現代的な可視化／配置アルゴリズムをすでに用意している。より親しみやすい出発点はProcessing[3]系かもしれない。Javaから始まり、PythonやJavaScriptなどへ移植されている ただし布シミュレーション一つは、ゲームエンジンにたとえるとネズミ一匹の細胞一つのようなレベル。ゲームエンジンは非常に大きく、そこでも自分でシミュレーションを書くというより、多くの内部統合を行うことになる 1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js 2 - https://github.com/d3/d3-force/tree/main/src 3 - https://processing.org/ 結局、すべては数学と物理 ゲーム開発を名指しで尋ねたわけではないが、グラフィックス、数学、ライティング、物理のような知識は、だいたいその分野に広く行き渡っている。布シミュレーションのようなニッチな話題だけを個別に探そうとすると、ゲーム開発資料と結び付いていない情報を見つけるのは難しいかもしれない 今日 https://alextardif.com/LearningGraphics.html を読んだが、いろいろな方向への道しるべになり得る。https://learnopengl.com/ はVulkan、Metal、DX12のような新しいAPIがある今でも、継続して高く評価されている。ただしAPIは、解くべき問題の5%程度だと考えればいい。正直もっと少ないかもしれないが、Vulkanは聞いていた以上に重い C/C++を学びたくないならWebGLコミュニティが大きいので、関連するサブレディットやフォーラムから始めてもよい。それでもAPIとプラットフォームは、実際の物理シミュレーションという印象的で新しい部分を包む外皮に近い 出典を付け加えると、私はWeb開発／Gradle／Javaの開発者で、数年前の試みの後、余暇にまたゲームエンジンを作っている そこまで難しくはない。JavaScriptでは各点を (x,y,z) で表し、質量を与えたうえで、毎フレーム重力を適用し、必要なら少しノイズを加えればよい 粒子が動こうとするたびに、三角法で力を辺を通じて他の点へ伝え、暴走しないように少し減衰を入れる。質量は、その後、力によって各点がどれだけ影響を受けるかを決める。3Dが負担なら、まず2Dでやればよい Elden Ring の驚くべき布のデザインを分析した Polygon の動画を思い出した: https://youtu.be/wSSqx-Dh6ko 動画で十分に強調されていなかった点は、布には機能的な目的もあるということ。布は敵の形状を隠し、モデルを見分けにくくする FromSoft のゲームの最も革新的な側面とも言える精密な当たり判定と近接戦闘が中核のゲームでは、自由に流れる布のせいで、攻撃を当てるにはキャラクターをどれだけ近づけるべきか、当たらないためにはどれだけ離れるべきかを判断しにくくなる。そこに予測しにくい動きや攻撃パターンが加わると、難易度はさらに上がり、戦闘のたびに固有のものになる 現実でも布は同じ性質を持つ。ローブやマントをまとった敵は、ずっと脅威で対処しにくい ゲームプレイの反復構造のため個人的には FromSoft のゲームを楽しめないが、設計面では史上最もよく作られたビデオゲームの一部だと思う こういう布アニメーションはずっと好きだった。最初に見たのはおそらく dissimulate の Codepen の破れる布デモで、そのコードが9年前に書かれたものだとは信じがたい [1] - https://codepen.io/dissimulate/pen/eZxEBO [2] - https://github.com/Dissimulate/Tearable-Cloth 14年前に作った自分のバージョンもある: https://www.youtube.com/watch?v=G05M_Y6NQVM こういう基本構成は実装がとても単純で、結果が本当に素晴らしいという点には同意する それを作ったのは私。Codepen に投稿した元のバージョンはだいたい13年前だった 自分でも信じられないが、初めてのプログラミング職に就く前だったことを思い出すと、本当に昔のことのように感じる 2000年のビデオゲーム Hitman にも布はあったし、2008年の Mirror's Edge には破れる布があった。おそらくどちらも最初ではなかったはず こういう布シミュレーターは、いつもある程度不安定に感じる。Grid 布を生成してみると、跳ねたりランダムに動き出したりする これは IEEE 754 浮動小数点誤差が蓄積するためなのか気になる 物理シミュレーションやゲームエンジンの文脈で数値積分を調べるとよい。出発点として https://en.wikipedia.org/wiki/Numerical_methods_for_ordinary... を見られる 私の理解では、単なる浮動小数点誤差だけではなく、連続関数を単純な離散ステップで近似する性質から生じるもの。リンク先の Wikipedia 記事にも、大きなステップでは浮動小数点精度が問題になるずっと前から誤差が蓄積することを示すグラフがある 数値積分の手法ごとに異なるトレードオフがある。Euler 法、Verlet、Runge-Kutta などがあり、方式によっては全体のエネルギーが蓄積しがちで、別の方式ではエネルギーが失われがちだが、どちらも誤った挙動だ。より複雑な方式は多少うまく動く傾向があるものの、各ステップが複雑になる利点が、より単純で速いアルゴリズムをより多く反復することを上回るのかを検討する必要が出てくる 物理シミュレーションでエネルギー保存は、明示的にコーディングしない限りデフォルトでは働かない。たとえば定期的に直接補正するようなやり方が必要 丸め誤差だけでなく、時間の量子化、そして数学モデル自体に由来する他の小さな誤差も原因になる 誤差が減衰方向なら、実際のようにエネルギーが散逸して動きが最終的に止まる効果になり、加速方向ならシミュレーションが暴走する このサイトの作者に、よくできていると言いたい。外部 JavaScript なしでそのまま動き、モバイルでも動作する 最近のテキストベースのウェブサイトの大半については、こうは言いにくい 本当に印象的な仕事だ。シンプルだが見続けてしまうし、Verlet 積分が自然でそれらしい布シミュレーションを作るのにどれほど強力かをよく示している 興味があるなら、Hitman のゲームエンジンから出た Jakobsen の論文もおすすめ。古典的な資料だ こういうものがどう動いているのかについて、難しい問いを実際に投げかける姿を見るのはよい。すべてが何年にもわたって積み上がった無数の小さなステップから作られているのだと毎回感じる 数学が壁のように感じられる地点にぶつかるのか、それとも理解できるまで叩き続けるのかが気になる いくつかのパラメータと制約を設定するだけで、これほど現実的な動きが出る点がいちばん興味深い 私たちの周囲の世界も、隠れたモデルと力の集合にすぎず、私たちの仕事はそれを発見してシミュレートすることなのかもしれないと思う。美しい仕事だ
1件のコメント
Hacker Newsの意見
ブラウザで見られる別の例: https://oimo.io/works/cloth/
Marian Pekárの記事を読んでVerlet積分を理解し、自分で布シミュレーションを作れるようになった: https://pikuma.com/blog/verlet-integration-2d-cloth-physics-...
Web開発、Gradle、Javaの知識から、どうやってこういうものを作る段階へ移れるのか気になる
CSの学部を出ていないので、プログラミング言語をいくら学んでも、こういうものは一生理解できないのではないかと思うことがある。OPENLY、LIBGDX、GODOT、Unityを少し触ってみたことはあるが、布シミュレーションをゼロから作るとなると本当に途方に暮れる
ここでは基本的なVerlet積分を使っており、格子を構成する2Dベクトルを現在位置と過去位置に基づいて更新し、すぐ隣の点との一定距離を保つように制約する。その点同士の間に線を引けば布になる。物理シミュレーションに魅了されて調べていたとき、実装しやすいものの一つだったので最初に取り組み、労力に対する結果がとても良かった。もちろん、その先はずっと複雑になる
特にゲーム開発から入ると、剛体、布、ばね、流体のような主要なシミュレーションごとに、自然で慣用的なプログラミング方法があるように感じる。最初は流体シミュレーションも、格子を作って時間ステップごとに更新ルールを選ぶような形で、言語の中に自然に表現できると思っていた。だが実際には、問題を数学と物理でモデル化し、それを言語と道具にマッピングする作業であり、その道具が常に慣用的に表現してくれるわけではない
粒子位置とばねに基づく布シミュレーションのように、コードへ移しやすいアルゴリズムもあるが、さらに先へ進もうとしたときには、むしろそれが誤解を生んだ。結局、物理と数値解析をより深く掘り下げてから問題をコードに移す必要があり、結果のコードは不格好でマジックナンバーが多くなることもある
逆にシミュレーションを書く場合は計算量が多く、コードの大部分が実際の中身になる。Web開発が異質なものの組み合わせだとすれば、シミュレーションはより均質だ。問題は、秒間フレーム数が決める時間予算の中で、単一プロセスの性能に制限されること
だから一つの実行環境に集中できる。配布の問題を解決してくれるブラウザを勧める。Ganja[1]はおそらく「構造ではなく中身」に近い究極のシミュレーションプロジェクトかもしれない。非常に特異で理解しづらいためメンテナンスは止まっているが、動作はする。もう少し構造化されたものとしてはD3があり、作者たちは力学ベースのグラフ[2]のような現代的な可視化／配置アルゴリズムをすでに用意している。より親しみやすい出発点はProcessing[3]系かもしれない。Javaから始まり、PythonやJavaScriptなどへ移植されている
ただし布シミュレーション一つは、ゲームエンジンにたとえるとネズミ一匹の細胞一つのようなレベル。ゲームエンジンは非常に大きく、そこでも自分でシミュレーションを書くというより、多くの内部統合を行うことになる
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
ゲーム開発を名指しで尋ねたわけではないが、グラフィックス、数学、ライティング、物理のような知識は、だいたいその分野に広く行き渡っている。布シミュレーションのようなニッチな話題だけを個別に探そうとすると、ゲーム開発資料と結び付いていない情報を見つけるのは難しいかもしれない
今日 https://alextardif.com/LearningGraphics.html を読んだが、いろいろな方向への道しるべになり得る。https://learnopengl.com/ はVulkan、Metal、DX12のような新しいAPIがある今でも、継続して高く評価されている。ただしAPIは、解くべき問題の5%程度だと考えればいい。正直もっと少ないかもしれないが、Vulkanは聞いていた以上に重い
C/C++を学びたくないならWebGLコミュニティが大きいので、関連するサブレディットやフォーラムから始めてもよい。それでもAPIとプラットフォームは、実際の物理シミュレーションという印象的で新しい部分を包む外皮に近い
出典を付け加えると、私はWeb開発／Gradle／Javaの開発者で、数年前の試みの後、余暇にまたゲームエンジンを作っている
粒子が動こうとするたびに、三角法で力を辺を通じて他の点へ伝え、暴走しないように少し減衰を入れる。質量は、その後、力によって各点がどれだけ影響を受けるかを決める。3Dが負担なら、まず2Dでやればよい
Elden Ring の驚くべき布のデザインを分析した Polygon の動画を思い出した: https://youtu.be/wSSqx-Dh6ko
FromSoft のゲームの最も革新的な側面とも言える精密な当たり判定と近接戦闘が中核のゲームでは、自由に流れる布のせいで、攻撃を当てるにはキャラクターをどれだけ近づけるべきか、当たらないためにはどれだけ離れるべきかを判断しにくくなる。そこに予測しにくい動きや攻撃パターンが加わると、難易度はさらに上がり、戦闘のたびに固有のものになる
現実でも布は同じ性質を持つ。ローブやマントをまとった敵は、ずっと脅威で対処しにくい
ゲームプレイの反復構造のため個人的には FromSoft のゲームを楽しめないが、設計面では史上最もよく作られたビデオゲームの一部だと思う
こういう布アニメーションはずっと好きだった。最初に見たのはおそらく dissimulate の Codepen の破れる布デモで、そのコードが9年前に書かれたものだとは信じがたい
[1] - https://codepen.io/dissimulate/pen/eZxEBO
[2] - https://github.com/Dissimulate/Tearable-Cloth
こういう基本構成は実装がとても単純で、結果が本当に素晴らしいという点には同意する
自分でも信じられないが、初めてのプログラミング職に就く前だったことを思い出すと、本当に昔のことのように感じる
こういう布シミュレーターは、いつもある程度不安定に感じる。Grid 布を生成してみると、跳ねたりランダムに動き出したりする
これは IEEE 754 浮動小数点誤差が蓄積するためなのか気になる
私の理解では、単なる浮動小数点誤差だけではなく、連続関数を単純な離散ステップで近似する性質から生じるもの。リンク先の Wikipedia 記事にも、大きなステップでは浮動小数点精度が問題になるずっと前から誤差が蓄積することを示すグラフがある
数値積分の手法ごとに異なるトレードオフがある。Euler 法、Verlet、Runge-Kutta などがあり、方式によっては全体のエネルギーが蓄積しがちで、別の方式ではエネルギーが失われがちだが、どちらも誤った挙動だ。より複雑な方式は多少うまく動く傾向があるものの、各ステップが複雑になる利点が、より単純で速いアルゴリズムをより多く反復することを上回るのかを検討する必要が出てくる
丸め誤差だけでなく、時間の量子化、そして数学モデル自体に由来する他の小さな誤差も原因になる
誤差が減衰方向なら、実際のようにエネルギーが散逸して動きが最終的に止まる効果になり、加速方向ならシミュレーションが暴走する
このサイトの作者に、よくできていると言いたい。外部 JavaScript なしでそのまま動き、モバイルでも動作する
最近のテキストベースのウェブサイトの大半については、こうは言いにくい
本当に印象的な仕事だ。シンプルだが見続けてしまうし、Verlet 積分が自然でそれらしい布シミュレーションを作るのにどれほど強力かをよく示している
興味があるなら、Hitman のゲームエンジンから出た Jakobsen の論文もおすすめ。古典的な資料だ
こういうものがどう動いているのかについて、難しい問いを実際に投げかける姿を見るのはよい。すべてが何年にもわたって積み上がった無数の小さなステップから作られているのだと毎回感じる
数学が壁のように感じられる地点にぶつかるのか、それとも理解できるまで叩き続けるのかが気になる
いくつかのパラメータと制約を設定するだけで、これほど現実的な動きが出る点がいちばん興味深い
私たちの周囲の世界も、隠れたモデルと力の集合にすぎず、私たちの仕事はそれを発見してシミュレートすることなのかもしれないと思う。美しい仕事だ