（動画リンクは下にあります。）
添付されたプロジェクト ファイルは次のように開きます。
The project file contains all the JSL files and some other bits and pieces like a credits slide.プロジェクト ファイルには、すべての JSL ファイルとクレジット スライドのようなその他の小片が含まれています。
私は自己完結型のプロジェクトが好きです。それらには短い学習曲線があり、JSLファイル（灰色のディスクアイコン、左上から5番目）を保存すると、プロジェクトのアーカイブファイルではなく、プロジェクトが開かれた一時的な場所に保存されることを理解したら、すべてが理にかなっています。 もう 1 つの奇妙に見えるアイコン (左から 4 番目) は、保存されていない JSL ファイルを一時的な場所に保存してから、プロジェクト アーカイブを再構築/保存します。 プロジェクトには独自の名前空間があります。私が気づいたことは何も漏れません。 プロジェクトのログ ウィンドウを右側にドッキングしました。
プロジェクトをのぞいてみる、または実行しようとする場合は、ここに私がどのように使用したかの概要を示します。 まず、Rain Drop Manager は (1 枚の写真につき 300 行 x 32768 枚の写真) 行の巨大なテーブルを作成します。 これは数時間で完了し、フレームからフレームへと 300 個の雨滴の位置を追跡するため、順次実行する必要があります。 次に、Number Server が開始されます。 別のタブで GUI ウィンドウを開き、Linux マシンのファームを管理します。 Number Server は、実際には、各ファーム マシンがシーケンス内の異なる画像で動作するようにする Web サーバーを実行する Python プログラムです。 3 番目に、GUI はファーム プロセスを起動し、Generate Images の JSL を使用して画像を作成します。
かなり複雑なセットアップですが、かなり堅牢であることがわかりました。 少なくとも 3 回実行され、毎回約 55 時間かかりました。 うまくいくことがわかったのは、NFSを使用せず、代わりにWindows共有フォルダーを使用することです。 VirtualBox で Windows を実行します。 VBoxManage を使用して Windows を起動および停止します。 Windows の起動ディレクトリを使用して JMP を起動します。 もう一度実行する場合に GUI に追加すること: ワーカーが終了してシャットダウンしたことを示す「青」の状態。
55 時間後のファーム内のマシン間の作業の分散:
Several classes of hardware in this Beowulf Cluster.この Beowulf クラスター内のいくつかのクラスのハードウェア。
カウントは、各マシンが作成したイメージの数を表します。 マシンがイメージを終了するたびに、次にどのイメージを処理するかをナンバー サーバーに問い合わせます。 雨滴の位置は事前に計算され、ズーム レベルは画像番号によって決定されるため、農場のすべての労働者は独立して作業でき、完成した画像を共有フォルダーに押し込んで、ビデオが組み立てられるときに名前で並べ替えられます。 コードは現在、イメージを逆ビット順序で作成するように設定されており、中間のイメージ、次に 1/4 のイメージ、次に 1/8 のイメージ... という順序で生成されます。 27 時間の時点で、1 つおきの画像が作成されているため、概要を簡単に確認できます。 (悲しいことに、3 回目の 55 時間の実行が必要な問題は、隣接する画像でしか見られませんでした...時々...ちらつきの雨滴!)
4K 60FPSの動画をアップしました。 私のハードウェアでは、4K 30FPS または 2K 60FPS のいずれかを使用できるため、両方を同時に見たことはありません。 1 つだけを選択する場合は、60 FPS を選択してください。非常にスムーズです。
ダウンロード後に .zip 拡張子を削除すると、JMP 16 で開きます。 それを機能させるには、多くの微調整が必要になります。
