RTMの処理落ちに対抗した話
どうも。RTMでD 第三話の収録がなんとか完了してほっとしているtask58です。(この後編集しなきゃいけないんだけどね) 今回、撮影をする中で、列車が処理落ちを繰り返して尺取虫になったり、脱線したり、突如停止したり、モデルが読み込まれてなかったり...(+ect) こんな風に大惨事になることもしばしば。なお原因に気付くまで数十回無駄なRETAKEを繰り返しておりました。(突然の英語) というわけで今回は、この処理落ちに対抗します。 ※RTM2.4.23-42、fixRTM2.0.25の環境です。 で、原因を究明する中でいろいろやったんですよ。まず光源全消去。光源処理は重いのでなくしたらうまくいくかなとおもったのですが効果なし。このせいでRTMでD 第三話の池森駅は蛍光灯が設置されてませんがご了承ください() その後、試しに描画距離を8から6に下げてみました。すると処理落ちするタイミングが遅れたんですよ。この時僕は、「どこかのチャンクが"読み込まれる時"に処理落ちが発生しているのではないか」という仮説を立てました。...立てたからどうした。あの周辺のチャンクで処理落ちの原因になってそうでかつぶっ壊してもクオリティに影響を及ぼさないものなんてないぞ。どうしよ。...まてよ？"読み込まれる時"に処理落ちするなら... 処理落ちの原因になるチャンクをあらかじめ読み込んでおけばいいんじゃね？ これはピンときてしまった。物は試しだやってみよう！ 今回はチャンクローダーを追加するMODは入れてないので信号変換器(無線)のチャンクロード機能を使ってロードします。 チャンネルを5にしてるのはただの気まぐれです。今回はチャンクロードの数値を2にして保存。何度目かもうわからないリテイクを開始。そして... 無事うまくいきました！ ＼(^_^)／やったね！ ただし、この対策はおそらく、すべての処理落ちに効くわけではないと思われます。今回のケースから推測されるこの方式が効くタイプの処理落ちは... 毎回同じ地点で発生する (→特定のチャンクを読み込んだときに発生する) 描画距離を変更すると、処理落ち発生地点が変化する(→処理落ちの原因となるチャンクが読み込まれるタイミングが変化するため...