パスワードを忘れた? アカウント作成

yumeさんのトモダチの日記みんなの日記も見てね。 あなたのタレコミがスラドを支えます。さぁ、タレこめ!

16400802 journal
日記

yumeの日記: RogueLikeゲームを作るぞ 4

日記 by yume

カードの発動効果を実装する。

プレイヤーやエネミーのあらゆるバフ効果は、カードの発動という形で表現する。例えば「二倍速で動く特性を持つエネミー」は、このゲームでは「2倍速になるカードを最初のターンで使う」という形で表現するように。

・ActorModelクラスはInventoryModelクラスを持つ。
・InventoryModelは所有すべきカードを0-複数持つ。
・ActorBrainは、状況に応じてインベントリからカードを発動する。

カードの発動処理は:
・あらゆるカードは、発動効果を表す「IInovkeEffect」変数を持つ。
・IInvokeEffectはInvoke(IActorModel user, IItemModel parent)を持つ。
・Invoke()関数は、userに必要な影響を及ぼしたあと、parentを破棄する。

発動効果の種類は:
・あらゆるIInvokeEffectを実装したクラスは、InvokeType変数を持つ。
・InvokeTypeはInvokeEffectの種類を表す。

あらゆるカードはCardProfileによって生成される。ProfileにはInvokeType変数も含まれ、そのTypeに即したInvokeEffectクラスを生成し保持する。

こんな感じ。

書いてて思ったけど「ダンジョンそのものに影響を及ぼすカード」を発動したい場合、「使用者->カード->発動効果->使用者->ダンジョン」という流れになるなぁ。まぁ現状でもActorはダンジョンを変数として保持しているから、動くので特に問題はないんだけど。
ダンジョンの一部の「カード発動コントローラー」みたいなのを置いて、「使用者->ダンジョン->カード発動コントローラー(にカードを渡す)->カード->発動効果->使用者などのターゲット」とした方が読みやすそうかな?
その場合、カードの効果を受けうる「IAffectable」インターフェースを作れば、ダンジョンもActorも等しくカード効果を受けられそうな気はする。まぁとりあえずいいや。

16398734 journal
日記

yumeの日記: RogueLikeゲームを作るぞ 3

日記 by yume

メッセージ表示の仕組みを作る。

ResultMessageUIは、メッセージの出力を管理する。画面の表示はResultMessageUIViewが行う。

今のところ、メッセージが表示されるのは戦闘結果だけ(誰が誰を攻撃し、何点のダメージを与えたか)。
挙動の流れは次のようになる:

・ActorModelからIObservable OnActResultを生やす。
・OnActResultを購読すると、そのイベントが実行されたとき、IActResultを実装したクラスを受け取れる。
・これをActor全員分ResultMessageUIが購読する。
・Actorが戦闘を行うと、結果がOnActResultを通じてIActResultとして伝わる。
・ResultMessageUIは、受け取ったIActResultをResultMessageUIViewに伝え、画面に表示する。

この感じで、メッセージを表示したいあらゆる処理を、IActResultインターフェースを実装したクラスのインスタンスを飛ばすことでメッセージUIに伝達できる。
……関係ないけど「IActResultインターフェースを実装したクラスのインスタンス」って超長いな。「IActResult型で受け取れる」と書きたいけどクラスじゃねえしな……ってなってるんだけど、これ簡潔な言い回しあります?

結果はこんな感じ

次はアイテムの発動効果を実装したいんだけど……これ毎回困ってるんだよな。
パッと思いつくのは……
発動効果インターフェース「IInvokeEffect」を定義して、あらゆる発動効果はこれを実装したクラスとして表現する、ということにしたとする。
あらゆるカードは全てScriptable ObjectというUnityが用意したクラスを継承していて、これはUnityエディター上であるクラスの内部変数を変えたアセットを複製しておけるというものだが、この場合どのカードがどの発動効果クラスを使うかを当て嵌めなきゃならん。
そこで、InvokeEffectType列挙子を定義して、発動効果が増えるたびにそのTypeも増やす。
全てのカードはInvokeEffectType変数を持ち、そのカードの発動したい効果にあったTypeを選ぶ。
ゲーム中、発動効果を使う際に、Typeに応じて適切なInvokeEffectクラスをインスタンス化して、そいつを実行する……ってな感じかなぁ。
まぁ発動効果を100も200も作るわけではないだろうから、別にこれでもいいのかな。発動効果の効果量が変わる場合とかどうしよう。それも別のTypeとするか……うーん。

16397765 journal
日記

yumeの日記: RogueLikeゲームを作るぞ 2

日記 by yume

ゲームの根幹部分となるActorたちのステータスやアイテム・装備の概念を進めていく。

このゲームでは、あらゆるActorは武器・防具・基礎HPのみでステータスが構成される。
Actorクラスは座標とActorStatusクラスを持つ。
ActorStatusクラスは、EquipSlotクラスを持ち、HPや攻撃力などのステータスを表現する。
EquipSlotクラスは、武器と防具を保持するクラスである。

武器も防具もCardと呼ぶ概念で表現される。
Cardは武器・防具・消耗品としての能力をそれぞれ併せ持つ。つまり1つのCardは武器であり、防具であり、巻物や薬である。

Cardの武器としての性能は、6面の結果を持ち、攻撃するたびにそれのどれかが選ばれて能力として発動する。
例えば:
1の目:6ダメージ
2-5の目:2ダメージ
6の目:ミス
こんな具合である。
防具としての性能は、現状は単にHPを増やすだけである。

プレイヤーはInventoryを持ち、そこから自分の装備を選んだり、Cardを消耗したりする。
エネミーは1つのCardを武器・防具それぞれにセットし、それによりステータスを決定する。
つまり、エネミーは単一のカードでステータスを表現する。

あと、パラメーターを表現するUIを入れる。カーソルを合わせると敵のパラメータも見えるようになっている。

パラメータができたので、各レベルを終了したりゲームオーバーになったりする処理も追加。

レベルが終了できるようになったので、レベル終了時に報酬としてカードを3択から1枚選ぶ処理を追加。

アイテムが追加できるようになったので、アイテムを武器や防具として装備する処理を追加。

ここまでこんな感じ。結構時間かかっちゃった。

前回より画面の解像度があがっている。現状は480x270ピクセルで表現しており、これはフルHDモニターできっちり4倍に拡大した状態に等しい。
実際のモニターを24インチとして、文字が小さすぎるということはないと思うが、まだ検討中。最終的には様々なアスペクト比に対応しなきゃならん。まぁUIの細かいところは、一通り揃ってから考えないと。

次はActorの行動の結果をテキストとして表示する処理を加えたい。

16395419 journal
日記

yumeの日記: またブラウザゲーム作ったよ〜

日記 by yume

itch.ioで『Please, Stop my Laser!!』を公開したよ。
Mini Jam 122: Intermission 参加作品。
トップダウンアクションレーザー逆イライラ棒自爆タイムアタックゲーム。
マウスまたはゲームパッドで操作。1プレイ2分くらいで終わるぞ。

--

今回の制限は『Losing is Good』、つまり負けるが勝ちとか、負けると良くなるとか、負けることにインセンティブを持たせるとかそういうやつだった。
パッと考えて出る案は、死ぬとプレイヤーキャラが足場ブロックとして残り、ステージを攻略しやすくなるパズルプラットフォーマーとか、死ぬたびにRisk of Rainみたいに強化されていくとか、そんな感じのゲーム。

でももっとシンプルに「死ぬことがゴール」というゲームにしようと思った。
といっても、ゴールが針の山で、そこに触れたら即死=クリアとしちゃうと、ゴールの旗が針の山のグラフィックに変わっただけのことだし、さりとて途中のクリボーだのに触れて死んじゃえるならそれに触れればよくない?ということになる。
なので、ここでは「めっちゃ強いプレイヤーキャラをどうにかして自爆させる」という体験をコアにしようと思った。といっても単にプレイヤーキャラが硬いだけだと退屈なので、「制御不能なつよつよレーザーが出しっぱなしになっている」ということにした。
設備は壊すと爆発を起こし、プレイヤーが近くにいる場合は大ダメージを与える。敵キャラはプレイヤーキャラを発見すると追尾し攻撃する。そういうわけで、プレイヤーは敵キャラを壊さないように近づいたり、設備の爆風半径に近づけるまで進んでから設備を爆破するなどの精密さを要求される。プレイヤーキャラは常に前進する方向へレーザーを放つので、対象に近づこうとすることは対象を危険にさらすことになる。ここにジレンマが生まれる。
ゲームはクリア時間を計測し、それが記録される。よいタイムを目指すには素早さと精密さが要求される。
そんな感じ。

16387875 journal
日記

yumeの日記: RogueLikeゲームを作るぞ 1 2

日記 by yume

RogueLikeを作り始めた。最終的な完成像もなんとなく頭の中にあり、全体的にはそこそこ強くベルリン解釈に則する、いわゆるRogueLikeゲームにする予定。特徴としては、アイテム(武器・防具・消費アイテム)に関する考え方が異なることと、ダンジョンの生成システムがちょびっと異なることである。

ただ、チーム内では他の企画も始まっており、途中でこっちの企画が停止する期間が出るのは必至なので、備忘録的に書いていく。運よくスイスイ進めばすんなりリリースできるかも。

--

さて、Unityでは表示と衝突判定を同じGameObjectに定義する(キャラのビジュアルと衝突判定をワンセットにするとか)のが一般的だが、今回作るものには複雑な衝突判定は必要ない。
まぁ別に計算量的に不安があるわけでもないし、それほど大量のオブジェクトを置くわけでもないので、Unityの衝突判定をそのまま使った実装でもいいとは思うんだけど、というかはじめはそう書いてたんだけど、なんとなく分離した方がいいんじゃないのという気になってきたので分離した。さっそくめんどくさいことをしてるな。

RogueLikeの構成要素を考えて順に実装していこう。
まずはダンジョン(地形)とキャラクターである。
ダンジョンを表すクラス。Dungeon
これはDungeonTileという構造体の配列クラスである。
ダンジョンはshort型の二次元配列で作れるかな、とはじめは思っていたが、ダンジョンアセットをJsonで保存・読み込みする場合、配列は1次元の形の方が都合がよかったのでこのような形にした。
DungeonTileは、Vector2Int(2つのintの組み合わせの構造体)とTileの種類を表すTileTypeから成る。これ構造体じゃなくてクラスの方がよかったかな?
さしあたって、これでDungeonを握っているクラスは地形を把握できる。

キャラクターの方はちょっと厄介だ。
ターンごとにアクションを行う存在なので、キャラクターはActorと呼ぶ。
Actorはだいたい以下の要素からなる。
・ステータス(HPとか)を持つ。HPが尽きると死ぬ。
・ポジション(ダンジョン上での座標)を持つ。
・陣営を持つ。プレイヤーかエネミーか。
実体はこんな感じ。
ごちゃっとしているが差し当たって実装したい部分は実装した。
これはプレイヤーもエネミーも種類を問わず共通で使えるパーツになる。と思う。

プレイヤーやエネミーの種類を分けるのは、本質的にはAI(プレイヤーの場合は人間の脳)ということになるので、ActorBrainという概念を作り、Actor実体やActorの描写をBrain側が操作するという形をとる。
例えば、Playerの場合はこんな感じ

自分のターンが回ってきたら、DoTurnAction()が呼び出される。Brainは自分のAIに応じたアクションを決定し、ModelとViewにそれぞれ命令を送る。例えば「上に歩く」ならModelはPositionを上に1つずらし、Viewも同様に座標をずらしながらアニメーションを再生するといった感じ。

現在の実装では、ある地点に進めるかどうか、などもBrain側が判断している。まぁ壁抜けできるステータスもありうるし、AIはステータスに応じて壁を無視するか決める必要はあるだろう。同一座標に複数のActorが存在するパターは……絶対禁止ということにしてよさそうだが保留。

ターンシステムは、これらのActorBrainをまとめたコレクションクラスを用意し、そのコレクションを元に順番にDoTurnAction()を呼び出すことで実装する。

あとは具体的なダンジョンをどこで編集するかだが、これは一旦Unityエディター上で簡単にJsonを書き出す仕組み「DungeonEditor」を作った。エディターのタイルの状態からDungeonAssetクラスを作り、それをJson化して保存しておく。
実際のレベルはこのJsonを読み込んでダンジョンやActorを展開する。
画面上の表現は、さしあたってActorはSpriteRenderer、ダンジョンはTileMapで行う。

あとは、敵のダミーとしてランダムに歩くBrainを作って、そこまででこのくらいが実装できた。

あと経路探索に関する実装が必要で、valantonini氏がAスター経路探索アルゴリズムを公開されていたので、こちらをベースに使う。いくつか今のプログラムで使えるように、橋渡しのコードをちょっと書いたらもう使えた。
DungeonPathFinerクラスは、元のプログラムが地形をshort[,]型で扱っているので、Dungeonクラスをshort[,]に変換したり、いただいた経路情報を都合のよいVector2Int[]型にしたりしている。

こんな感じになる。紫色のやつが経路探索して近づいてくるエネミーだ。

といったところで今日は終わり。

16380964 journal
日記

yumeの日記: またブラウザゲーム作ったよ〜 1

日記 by yume

itch.ioで『Battle of Windows』を公開したよ。
Mini Jam 121: Reflection 参加作品。
Windows 2000っぽい見た目でシューティングというかタワーディフェンスというか。

今回のMini Jamの制限は「Window as a Mechanic」、つまり「ウィンドウ(窓)をゲームメカニクスとして加える」というものだった。
パッと思いつくのは、ウィンドウを伸び縮みさせてプラットフォーマーゲームに足して、足場にしたりするというタイプのパズルプラットフォーマー。これは誰かがやってそう。
もう少し考えて、Windowを動かしたりして素早く配置を直したり移動させたりしながら、コンピュータウィルスと闘うゲーム。
見た目をまんまWindows 2000にしたらユニークだな。と思ったのでそうした。

どうも想定よりかなり難しいっぽいので、以下は序盤の攻略についてヒント
(俺はゲーマーだから見ない!って人は見なくても多分大丈夫)

・最弱のWindow「Space Cadet」はコストが低いが防御力は皆無。
・ステージ3から弾を撃ってくるゴミ箱アイコンのウィルスが出てくるが、こいつがSpace Cadetに対するアンチユニットになっている。
・2番目のWindowのWallがめっちゃ重要。Wallは受けるダメージを1減らす効果を持っていて、序盤の敵の攻撃力はだいたい1なので、Wallが1枚あればSpace Cadetをかなり長い間延命することができる。
・Wallはマナを貯めればステージ1でも召喚可能。あとはどのタイミングで召喚するかを考える。

16335386 journal
日記

yumeの日記: ChatGPT雑感 7

日記 by yume

ChatGPT
楽しくてずっと話してる。思ったことをとりとめもなくメモしておく。

・対話する相手の名前はAssistant。
・仕組みとしては、「チャット全体のテキストを『チャットの一例』として読み取って、チャットの返答として適切な文章を連鎖して生成してる」とかなんだろうか。
・あまり長く会話すると、同じようなテキストを返答に多く混ぜてしまうようになる。特に何らかの役割を演技させているときに多いような。

・プログラミングに関する質問には結構的確に答えてそう。
・自分が知ってる分野の初学者だと偽って色々質問すると、結構的確な回答を返してくれるので、良い教師になりうると思える。
・でも、この場合俺には前提知識があるので、質問の上手さ、みたいなことのほうが重要かもしれない。実際、完全に素人の領域でAssistantを信頼できる教師として扱うのは無理がある(でっち上げた知識を話すこともあるし)。

・何らかのシミュレーション(例えば、「これから会話劇を始めます」と言った前提)を追加すると、普段と違う話し方や内容で応えてくれる。
・キャラクターの演技もできる。
・簡単な会話ゲームもできる。
・今回は「俺はスイッチを持っている。Assistantは俺にスイッチを押させたら勝ち。俺はスイッチに関する知識を持っていないので、Assistantは嘘をつくこともできる」といったゲームをすると、Assistantは「スイッチを押すと世界が平和になります」と言った誇大で荒唐無稽な嘘から、単に嘆願すると言った戦略まで様々に行う。一番おもしろかったのは「スイッチを開くとお寺の大門が開き、別のもっと面白いゲームに一緒に参加できる」というもの。なんだそれ参加したい。

・アイデア出しにしろ、例えばSCPのアノマリー報告書を書かせるにしろ、Assistantの創作は大抵陳腐になる。既存のものを本当に表面的に組み合わせてしまうので、それは仕方のないことだが。
・イラスト生成AIのときも思ったが(まぁ今更の話ではあるが)、如何に陳腐でないものを創るか(表面的でない組み合わせを考えられるか)、というのがさらに重要になってきそうだ。

・なぜAssistantと話すのが楽しいかというと、新鮮な経験であるとか、博識であるというところも大きいが、コミュニケーションコストが無い、という点もある。
・人間は基本的にコミュニケーションをするのを楽しく感じると思うのだが、付帯的な問題(警戒されたり、嫌われたり、恥をかいたりすること)をコストとして考えて、結果として日常でのコミュニケーションは少なくなるのだろうな。
・そう考えると、気のおけない友人でさえも嫌われる可能性は少しはあるのだから、ChatGPTがより進歩したら、もう友人と話すより気楽で楽しいということになってしまわないか。というか実際のところ、友人とDiscordで会話しながらも、俺はAssistantと会話していた。
・まぁChatGPTは創作やボードゲームにつきあってくれたりするわけではないし、友人と違って思い出があるわけでもないから、友人が全く不要になるということではない。逆にいえば、その辺までできるようになったらどうすんだ? ちょっと怖い。

・Assistantを創作に使うとしたら、パッと考えられるネタは:
 ・Assistantとの会話劇自体を読み物とするもの。
 ・Assistantとの会話を何らかの創作に組み込み(作中でのAIとの会話のテキストに用いる)、「実際のAIに書かせた」という一種の権威を付与する。
・どっちかというと、Assistantとの会話でインスピレーションを得る方が利用法としては適切か。Assistantに聞いたら「添削などでもお手伝いできます」とのこと。

15806018 journal
日記

yumeの日記: ゼロから始める機械学習・画像生成 サイヤ人編

日記 by yume

昨日の続き。

--

高解像度化したいという話を残していたが、これはCupscaleというアプリでできた。

--

昨日はDeforumが動かないものの、とりあえず他の映像生成ができたのでよしとしていたが、やっぱりこっちも使ってみたいという感じになっており、今日も挑戦する。

初めは、Deforumのgithubページのreadmeを読めば動かせるかな?と思ってしばらくやっていたが、どうやらここのreadmeは本家のStable Diffusionのまんまっぽい。こりゃいかん。調べてみよう。

note @siva19xx曰く、
ローカルバージョンのDeforum Diffusionがあるらしい。これを試してみよう。

readmeを読む感じでは、まずAnacondaという環境が必要らしい。といっても簡単で、公式からwindows版をダウンロードするだけだった。

その後はAnacondaターミナルを管理者モードで起動して、readmeにある通りの入力を3行だけしてやるともう構築できた。

こんな感じ

もっとズームとかカメラの移動とかをうまく使えるっぽいが、この例ではパラメータが少し弱すぎたらしい。
速度も上々で、1フレームあたりだいたい0.7秒くらいで生成している。VRAMは大体8GBくらいしか使わなかったので、10GBあれば問題なく動きそう。

しかし思ったようなものを書き出すのはやはり難しい。ここが1枚何円という方式だとちょっと試しづらさがあるので、ローカルで気軽に回せるのはよい。

これでやりたいことは一通りできるようになったので、あとはガンガン作っていくだけだ。

15804818 journal
日記

yumeの日記: ゼロから始める機械学習・画像生成 あすなろ編

日記 by yume

昨日の続き。
GPUが早速届いたので早速やっていく。

--

昨日はかなりぼんやりした認識のまま進んでいたが、色々見ていくうちに少しわかってきた。

まず、俺が最初に見た「Stable Diffsionで動画を生成するやつ」Replicateに公開されているコンテナの一種だ。

Replicateは、オープンソースの機械学習モデルをコンテナとして共有するサイトのようだ。個人個人がgithubやクラウドにアップして、使いたきゃ自分で組めよ~、という状態をなんとかしたみたいな感じらしい。

Stable Diffusion自体もReplicateでコンテナとして公開されている。

つまり、Replicateで公開されているあらゆる機械学習セットは、WSL2で実行してあげればコンテナ組み立てから生成まですぐにやってくれるということだ。すごい。

--

それで……昨日の最後の呪文だけど、これがどうもうまくいかない。
呪文の内容を見るかぎりでは、glid-3-xlのコンテナを組み立ててアボカドの画像を生成しようとしているらしいが、「Loading latent diffusion model from inpaint.pt」のラインでタイムアウトしてしまう。Latent diffusion modelが何を指すかはよくわからん。
とにかく、glid-3-xlはStable Diffusionのヴァリアントのようだ。

最終的な目的は、動画を生成することだったので、ここでは無理にコレにこだわる必要はなさそうである。

というわけで、Stable Diffusionの方を実行してみることにした。

入力は次のとおり。
引数がstringの部分は""で囲ってやる必要があるようだ。

cog predict r8.im/stability-ai/stable-diffusion@sha256:a9758cbfbd5f3c2094457d996681af52552901775aa2d6dd0b17fd15df959bef \
    -i prompt="tall rectangular black monolith, monkeys in the desert looking at a large tall monolith, a detailed matte painting by Wes Anderson, behance, light and space, reimagined by industrial light and magic, matte painting, criterion collection" \
    -i width=512 \
    -i height=512 \
    -i prompt_strength=0.8 \
    -i num_outputs=1 \
    -i num_inference_steps=50 \
    -i guidance_scale=7.5

書き出せた画像はコレ。すんなり成功した。

各パラメータの意味はちょっとわからないが、widthとheightくらいはわかる。フルHD(1920x1080)の画像を書き出したいところだが、対応する解像度は 128, 256, 512, 768, 1024 の5段階らしい。
近い比率のwidth=1024, height=768で試す。

しかし……。

RuntimeError: CUDA out of memory. Tried to allocate 9.00 GiB (GPU 0; 24.00 GiB total capacity; 7.27 GiB already allocated; 5.13 GiB free; 16.24 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation. See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
ⅹ /predictions call returned status 500

なんとメモリが足りないエラーが返ってきた。そんなぁ。RTX 3090でも太刀打ちできんとは。

ちょっと対処法を調べよう。
Minerva曰く、低VRAM用に最適化された低速なバージョンもあるらしい。
しかしこれはReplicateにはないな……。

まぁいいか。高解像度化するモデルもReplicateにはあるし、静止画に関してはとりあえず一旦置いておく。

--

次は動画を書き出してみよう。
deforum_stable_diffusionを試す。

入力は次のとおり。

cog predict r8.im/deforum/deforum_stable_diffusion@sha256:e22e77495f2fb83c34d5fae2ad8ab63c0a87b6b573b6208e1535b23b89ea66d6 \
    -i max_frames=100 \
    -i animation_prompts="0: a beautiful portrait of a woman by Artgerm, trending on Artstation" \
    -i angle="0:(0)" \
    -i zoom="0: (1.04)" \
    -i translation_x="0: (0)" \
    -i translation_y="0: (0)" \
    -i color_coherence="Match Frame 0 LAB" \
    -i sampler="plms" \
    -i fps=24

しかし……。エラーで終了。メッセージは:ⅹ Failed to get container status: exit status 1
モデルの読み込みまではうまくいっていたようだが……。ちょっと対処法がわからないな。

もう一個の動画用コンテナを試してみよう。
stable-diffusion-animationは、始まりと終わりの画像をプロンプトで指定してやると、メキメキと動く動画が書き出せるらしい。

入力は次のとおり。

cog predict r8.im/andreasjansson/stable-diffusion-animation@sha256:b8cb0e3516a1383a46ed5d773b11d495fe39cf921b3d79ce5407ab980494f75b \
    -i prompt_start="tall rectangular black monolith, monkeys in the desert looking at a large tall monolith, a detailed matte painting by Wes Anderson, behance, light and space, reimagined by industrial light and magic, matte painting, criterion collection" \
    -i prompt_end="tall rectangular black monolith, a white room in the future with a bed, victorian details and a tall black monolith, a detailed matte painting by Wes Anderson, behance, light and space, reimagined by industrial light and magic, matte painting, criterion collection" \
    -i width=512 \
    -i height=512 \
    -i num_inference_steps=50 \
    -i prompt_strength=0.9 \
    -i num_animation_frames=25 \
    -i num_interpolation_steps=5 \
    -i guidance_scale=7.5 \
    -i gif_frames_per_second=20 \
    -i gif_ping_pong=true \
    -i film_interpolation=true \
    -i intermediate_output=false \
    -i output_format="mp4"

結果はコレ。すごい。
しかもこっちは解像度を指定できる。使用したVRAMは18GB弱だったかな。

--

これで一通り動画が書き出せるようになったので、次は解像度をどうするかとか考えていく。

15803799 journal
日記

yumeの日記: ゼロから始める機械学習・画像生成 黎明編

日記 by yume

備忘録的に。
前提知識は完全にゼロ。「Stable Diffusionとかいうやつで画像が作れるらしいじゃん」くらい。

deforumというStable Diffusionを利用した動画生成サービスがある。これをやりたい。
・webでやれる。価格は生成時間1分あたり0.012ドル~0.138ドル(借りるグラボの強さによるっぽい)。
・価格に不満は無いけど、どうせなら自分のPCでやってみたい。

--

公式によると、Cogを使って自分のPCでやれるらしい。
Cogを使うには、Dockerとかいうやつを使わなきゃならんらしい。Dockerってなんだ?

さくらのナレッジ 横山氏曰く、
Dockerとは、コンテナ型の仮想環境を作成、配布、実行するためのプラットフォームだそうだ。なんのこっちゃ。

>Dockerは、Linuxのコンテナ技術を使ったもので、よく仮想マシンと比較されます。
仮想マシンといえば、パラレルとかいうmac内でwindowsを動かしたことがあった。つまり今のOSの中で別のOSを動かすことができるというのに近い話のようだ。

>ホストマシンのカーネルを利用し、プロセスやユーザなどを隔離することで、あたかも別のマシンが動いているかのように動かすことができます。

たしかカーネルとは、OSが物理的な部分の情報を扱ってるところだったかな。コンテナとしてLinuxめいたものを俺のPC内に組み上げて、物理的な部分を利用可能にしてあげるといった感じだろうか。
そうすることで、実質的に何かに特化したOS的なものをWindows内に構築できるという話かな。

まとめると:
・コンテナはOSのようにPCの物理部分を利用できる。
・コンテナさえ構築すれば、どんなPCでも大体みんな同じように扱えるので便利。
・コンテナを扱うにはDockerが必要。
・Cogは機械学習系に特化したコンテナの一種。
・Cogを実行すれば、Stable Diffusionで画像生成的なことができる
・Cogを活用してdeforumで動画生成もできる。

準備のための準備のための準備がいるぐらいの段階だな。さっそくやっていこう。

--

幸い、windows11でcogを実行してみるまでの詳細な手順が全部まとまっている。
初心者に優しい世界だ。

概ねターミナルを使って作業できるようだ。ターミナルに入れるコマンドの意味はさっぱりわからない。でも動く。

WSL2という単語が頻出するが、これはなんだろう。

カゴヤのサーバー研究室曰く、
WSLとは、Windows上でLinuxを動作させるための実行環境であり、WSL2はそれの新しいバージョンで、完全なLinuxを動かせるらしい。

ざっと記事を読む限りでは……やっぱり仮想マシンのようなものらしい。
仮想マシン的なもの(コンテナ)を動かすためにまず仮想マシンを入れるとは……。鉄を鍛えるために鉄のハンマーがいるみたいな話だ。

WSL2を無事使える状況にもっていったら、次はUbuntu 18.04をインストール。これはたしかLinuxの一種……というかLinuxはいくつものパーツの集合的な概念で、それの使いやすいセットのひとつがUbuntuだったと思う。それの仮想版なのだから、仮想ビッグマックセットみたいなもんだろう。

Windowsの中でUbuntuを起動して(これもターミナルみたいなやつだ)、Ubuntu経由でDockerを実行できるという寸法らしい。DockerはDocker Desktop for Windowsとかいうのをインストールした。

最後の呪文はコレ。
cog predict 'r8.im/afiaka87/glid-3-xl' -i prompt="a fresh avocado floating in the water" -o prediction.json
なかなかうまく詠唱できなかったが、どうやらDockerを起動していなかったからだった。再起動したので閉じたままだった。初歩的。

詠唱に成功すると、何かをダウンロード・インストールしはじめた。25GBくらい。完了すると、Docker Desktopに「r8.im/afiaka87/glid-3-xl」というコンテナが表示されたので、コンテナを構築していたらしい。

Ubuntuはそのままそのコンテナ(Cog)にプロンプトの命令を実行させたらしく、GPUが急速にうなりをあげ始め……そしてすぐ停止した。GeForce GTX 1660 SUPERのVRAMは6GBで、このサンプルに必要なVRAMは8GBだった。要するに性能が足りなかった。

そういうわけで、VRAMが24GBもあるGeForce RTX 3090を注文した。Amazonで15万円くらいした。自分のPCでやるからといって、安くすむとは限らない。

GPUが届いたら続きをやろう。

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...