Difference between revisions of "Category:LSL 天気"
Mako Nozaki (talk | contribs) |
Mako Nozaki (talk | contribs) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
{{Multi-lang|Category:LSL | {{Multi-lang|Category:LSL Weather|/ja}} | ||
{{LSL Header{{#var:lang}}|ml=*}}{{LSLC{{#var:lang}}|}} | {{LSL Header{{#var:lang}}|ml=*}}{{LSLC{{#var:lang}}|}} | ||
{{LSLC{{#var:lang}}|Region}} | {{LSLC{{#var:lang}}|Region}} | ||
Line 9: | Line 9: | ||
{{Box|1={{User|Andrew Linden}}: [http://forums.secondlife.com/showthread.php?p=889095#post889095 2/10/06] 抜粋{{Footnote|handle=lost}}|2=サーバサイドの雲はグリッド上のセル・オートマトン・アルゴリズムで生成されます。それは一番近くの仲間の値を使って、少数の状態 (たとえば、快晴、晴天、曇り、雨) の中から遷移する先を生成するものです。それぞれの SIM には 18x18 グリッドの雲のセルがあります。雲のグリッドの境界線の値は隣の SIM に送信され、グリッドの 1 番目と 18 番目の行/列がそれに基づいて設定されます。SL では雨が降りませんが、'raining' 状態はこれから 'clear' になるということを示すために使用されます。水蒸気の配分はクライアントに送信され、その地域の中の雲のパーティクルを配分するのに使用されます。クライアント側で、雲がパーティクルとして描画されます。 | {{Box|1={{User|Andrew Linden}}: [http://forums.secondlife.com/showthread.php?p=889095#post889095 2/10/06] 抜粋{{Footnote|handle=lost}}|2=サーバサイドの雲はグリッド上のセル・オートマトン・アルゴリズムで生成されます。それは一番近くの仲間の値を使って、少数の状態 (たとえば、快晴、晴天、曇り、雨) の中から遷移する先を生成するものです。それぞれの SIM には 18x18 グリッドの雲のセルがあります。雲のグリッドの境界線の値は隣の SIM に送信され、グリッドの 1 番目と 18 番目の行/列がそれに基づいて設定されます。SL では雨が降りませんが、'raining' 状態はこれから 'clear' になるということを示すために使用されます。水蒸気の配分はクライアントに送信され、その地域の中の雲のパーティクルを配分するのに使用されます。クライアント側で、雲がパーティクルとして描画されます。 | ||
}} | }} | ||
{{Box|1={{User|Andrew Linden}}: [http://forums.secondlife.com/showpost.php?p=1340727&postcount=3 11/22/06] 抜粋{{Footnote| | {{Box|1={{User|Andrew Linden}}: [http://forums.secondlife.com/showpost.php?p=1340727&postcount=3 11/22/06] 抜粋{{Footnote|ここに記載されているのは抜粋ですが、引用元には完全な文書があります。}}|2=<!--I know I answered this before, but I couldn't find the link. It's lost!--> | ||
風は Siggraph 1999 Proceedings の中の Jos Stam の記事で説明されている 2D の Stable Fluid メソッドに基づいています。それぞれの地域は自分で非圧縮性シミュレーションを行っていますが、境界条件を隣り合った地域とやりとりしているため、ある地域が他の地域に影響を及ぼすことができるようになっています。この結果、風が形成できる最も大きなコヒーレント渦は 1 つの地域の大きさになりますが、地域をはみだした風は他の地域にねじこまれるため、風の構造によっては単独の SIM を超えることもあります。 | |||
それには擬安定というカオス魔法が注入されていて、それを沸騰させ続けています。そして、カオスは太陽の位置に比例します。そのため、環境行動は 1 日のスケジュールで変化します。小さなオフセットが入っていて、日の出と日没あたりでグローバルな風の平均値を太陽とずらすようになっていると思いますが、長い間コードを見てません。 | |||
以前は風と情報をやりとり (してこき使う) 方法がありましたが、開発者の一人が 2003 年 1 月の稼働以降のどこかの時点でこっそりその機能を無効化してしまいました。そして私にはそれを元に戻す時間的余裕がありませんでした。 | |||
もともとは、私たちは風がどのぐらいの CPU サイクルを使ってしまうかとても気をもんでいたため、1 秒間に数ステップしかない極めて低い解像度 (16x16) のシミュレーションに下げてしまいました。いつの日か再び風のシミュレーションのコードと向き合って拡張できればいいなと思いますが、忙しいスケジュールを鑑みると、少なくとも 1 年か 2 年先になりそうです。}} | |||
{{Footnotes}} | {{Footnotes}} |
Latest revision as of 06:41, 16 April 2010
LSL ポータル | 関数 | イベント | 型 | 演算子 | 定数 | 実行制御 | スクリプトライブラリ | カテゴリ別スクリプトライブラリ | チュートリアル |
Andrew Linden: 11/22/05 抜粋[1]
現在のお天気システムは単純なランダムな雲の発生/成長/消失アルゴリズム(基本的にセル・オートマトンの小さいグリッド) です。これは、ゼロ発散過程("flawed implementation of a Jos Stam fluid simulation" の中のお気に入りの言葉です)の固有な偽不安定によって引き起こされる、早くて解像度の低い (16x16) 2D の流体シミュレーションからヒントを得たものです。
天気の将来構想はというと... 昔は (アルファ版?ベータ版?) 雨のエフェクトが存在していましたが、当時は雨粒の衝突判定をするにはかなりコストをかけないといけなかったので、雨はまっすぐに家の屋根を突き抜けて動くものとなってしまいました。ほとんどの人がそれをうざったく非現実的なものと思ったので、私たちはそれをやめました。もっと正確な雨や霧のエフェクトを出すには、クライアントに物理衝突のアルゴリズムを埋め込まなければならないでしょう。良い点は、このようなエフェクトはまさしく私たちがやりたいと思っていることです。悪い点は、そのようなプロジェクトの予定は少なくとも 1 年先になるということです。
Andrew Linden: 2/10/06 抜粋[1]
サーバサイドの雲はグリッド上のセル・オートマトン・アルゴリズムで生成されます。それは一番近くの仲間の値を使って、少数の状態 (たとえば、快晴、晴天、曇り、雨) の中から遷移する先を生成するものです。それぞれの SIM には 18x18 グリッドの雲のセルがあります。雲のグリッドの境界線の値は隣の SIM に送信され、グリッドの 1 番目と 18 番目の行/列がそれに基づいて設定されます。SL では雨が降りませんが、'raining' 状態はこれから 'clear' になるということを示すために使用されます。水蒸気の配分はクライアントに送信され、その地域の中の雲のパーティクルを配分するのに使用されます。クライアント側で、雲がパーティクルとして描画されます。
Andrew Linden: 11/22/06 抜粋[2]
風は Siggraph 1999 Proceedings の中の Jos Stam の記事で説明されている 2D の Stable Fluid メソッドに基づいています。それぞれの地域は自分で非圧縮性シミュレーションを行っていますが、境界条件を隣り合った地域とやりとりしているため、ある地域が他の地域に影響を及ぼすことができるようになっています。この結果、風が形成できる最も大きなコヒーレント渦は 1 つの地域の大きさになりますが、地域をはみだした風は他の地域にねじこまれるため、風の構造によっては単独の SIM を超えることもあります。
それには擬安定というカオス魔法が注入されていて、それを沸騰させ続けています。そして、カオスは太陽の位置に比例します。そのため、環境行動は 1 日のスケジュールで変化します。小さなオフセットが入っていて、日の出と日没あたりでグローバルな風の平均値を太陽とずらすようになっていると思いますが、長い間コードを見てません。
以前は風と情報をやりとり (してこき使う) 方法がありましたが、開発者の一人が 2003 年 1 月の稼働以降のどこかの時点でこっそりその機能を無効化してしまいました。そして私にはそれを元に戻す時間的余裕がありませんでした。
もともとは、私たちは風がどのぐらいの CPU サイクルを使ってしまうかとても気をもんでいたため、1 秒間に数ステップしかない極めて低い解像度 (16x16) のシミュレーションに下げてしまいました。いつの日か再び風のシミュレーションのコードと向き合って拡張できればいいなと思いますが、忙しいスケジュールを鑑みると、少なくとも 1 年か 2 年先になりそうです。
This category currently contains no pages or media.