2008/03/17(月) [n年前の日記]
#1 [iappli] ちょこっとモデリングし直し
相手先から形状のラフ画像が送られてきた。なるほど、こういう形やったんか。
と思ったが、該当画像を参考にしてモデリングを始めたら、上面図と側面図が矛盾していて悩んでしまったり。いやまあ、そもそもラフだから、正確なわけもないんだけど。
ラフに基づいてモデリングしてるうちに、なんだかシルクロード少年ユートが脳裏に浮かんだり。アレもモデリングは大変だったんだろうなあ。いや、アレは比較的よくできてるほうじゃないのかと思ってるんだけど。2Dのキャラデザイン画を注視しながらツールに向かっているうちに、「うむ、なかなかの出来栄え！」とモデリングした人は思ったんじゃないだろうか。でも、出来上がったソレは、お客さんにはギョッとされてしまうのがアレなんだけど。作業してるうちに感覚が麻痺してくるんだよな…。と素人の分際で知った風なことを書いてみるテスト。
それはさておき。形状を変えてみたら、位置や角度は変わってないのに、背景画像とパースが比較的一致してしまって愕然としたり。乗せているモデルの形状デザインに難があって、パースがおかしく見えていたのか…。今まで、途中でちょっとだけヘルプをしてくれたデザイナーさんの画を元にしてモデリングしてたんだけど。そこに根本的な問題があったとは…。
まあ、あのラフ画像をドット画におこせと言われたら、自分も途中で頭を抱えてしまうだろうから仕方ない気もするのですが。コレ、立体ではどういう形になるんだか、わからんですわな。デザイナーさんも、かなり苦労したのだろうと想像。道理で、修正を要求しても腰が重かった・小手先(?)の修正に留まってたわけで。って自分が修正を要求してたわけでもないんだけど。
余談。自分は、アニメ大好き人間なせいか、記号化された視覚情報を比較的肯定する傾向があって。パースとか陰影とかこだわってるけど見た目判りづらくなってるものと、あまり手は入れてなくても記号としては判り易くなってるものがあれば、そりゃ後者のほうがいいじゃん、ゲームに使う画像ってそういうもんじゃないの、てな考えが時々脳裏に浮かぶので、件のデザイナーさんの作った画像も「別にこれでいいじゃん。記号的画像が無い状態よりはマシだし」てな感想だったり。…まあ、パースや陰影にこだわりつつ、記号としても成立するものがベストだろうとは思うんですが。そのへん、かけた労力と得られる効果も関係してくるし。
それはそれとして、現状どこまで修正済みかを問われた時のために、バイナリを相手先に送信。「現状どうなってるの？」と万が一言われたら使ってくれ、みたいな。
昨日からずっと作業してたけど、さすがに限界。仮眠。
と思ったが、該当画像を参考にしてモデリングを始めたら、上面図と側面図が矛盾していて悩んでしまったり。いやまあ、そもそもラフだから、正確なわけもないんだけど。
ラフに基づいてモデリングしてるうちに、なんだかシルクロード少年ユートが脳裏に浮かんだり。アレもモデリングは大変だったんだろうなあ。いや、アレは比較的よくできてるほうじゃないのかと思ってるんだけど。2Dのキャラデザイン画を注視しながらツールに向かっているうちに、「うむ、なかなかの出来栄え！」とモデリングした人は思ったんじゃないだろうか。でも、出来上がったソレは、お客さんにはギョッとされてしまうのがアレなんだけど。作業してるうちに感覚が麻痺してくるんだよな…。と素人の分際で知った風なことを書いてみるテスト。
それはさておき。形状を変えてみたら、位置や角度は変わってないのに、背景画像とパースが比較的一致してしまって愕然としたり。乗せているモデルの形状デザインに難があって、パースがおかしく見えていたのか…。今まで、途中でちょっとだけヘルプをしてくれたデザイナーさんの画を元にしてモデリングしてたんだけど。そこに根本的な問題があったとは…。
まあ、あのラフ画像をドット画におこせと言われたら、自分も途中で頭を抱えてしまうだろうから仕方ない気もするのですが。コレ、立体ではどういう形になるんだか、わからんですわな。デザイナーさんも、かなり苦労したのだろうと想像。道理で、修正を要求しても腰が重かった・小手先(?)の修正に留まってたわけで。って自分が修正を要求してたわけでもないんだけど。
余談。自分は、アニメ大好き人間なせいか、記号化された視覚情報を比較的肯定する傾向があって。パースとか陰影とかこだわってるけど見た目判りづらくなってるものと、あまり手は入れてなくても記号としては判り易くなってるものがあれば、そりゃ後者のほうがいいじゃん、ゲームに使う画像ってそういうもんじゃないの、てな考えが時々脳裏に浮かぶので、件のデザイナーさんの作った画像も「別にこれでいいじゃん。記号的画像が無い状態よりはマシだし」てな感想だったり。…まあ、パースや陰影にこだわりつつ、記号としても成立するものがベストだろうとは思うんですが。そのへん、かけた労力と得られる効果も関係してくるし。
それはそれとして、現状どこまで修正済みかを問われた時のために、バイナリを相手先に送信。「現状どうなってるの？」と万が一言われたら使ってくれ、みたいな。
昨日からずっと作業してたけど、さすがに限界。仮眠。
◎ 3DCGやドローツールは積極的に使ったほうがいいような気もしてきたり。 :
「ドット打ったほうが早いやろ」「ドット打ちのほうがいいものができるぞ」等々、ファミコン時代からやってるデザイナーさんが大昔に言ってた記憶があるのだけど。パースがどうとかそういうのを要求されちゃったりする場面では、2Dゲームでも、最初から3DCGで、下絵レベルでいいから作ってみたほうがいいのかもしれないなと、なんとなくそんなことをぼんやりと。一見、二度手間、三度手間、余計な作業をしてるような感覚に陥るんだけど。何度も修正作業を要求されるよりはまだマシなのかもしれない。みたいな。
今企画のオリジナルコンテンツの使用画像を眺めていても、最初からドット打ちで画像を作ってるんじゃなくて、どうもイラストレーター等のドローツールで、キャラやロゴの制作をしてから16色画像に落としてる感が。…ん？ もしかしてそれは、後々印刷物に流用する可能性も考えてそうしてるのかしら。ドット画しか存在しないと、印刷物に使うとなったときに描き直しだし。なるほど、印刷物にもデジタルコンテンツにも同じデータを使えるという点では、最初からドローツールで画像制作をしておいたほうがいいのか。せっかくデジタルデータを作るんだから、色々と使い回しができるデータ形式で最初に用意したほうが効率がいいよな。たぶん。
3DCGゲーム全盛時代に何を言ってるのか。＞自分。
今企画のオリジナルコンテンツの使用画像を眺めていても、最初からドット打ちで画像を作ってるんじゃなくて、どうもイラストレーター等のドローツールで、キャラやロゴの制作をしてから16色画像に落としてる感が。…ん？ もしかしてそれは、後々印刷物に流用する可能性も考えてそうしてるのかしら。ドット画しか存在しないと、印刷物に使うとなったときに描き直しだし。なるほど、印刷物にもデジタルコンテンツにも同じデータを使えるという点では、最初からドローツールで画像制作をしておいたほうがいいのか。せっかくデジタルデータを作るんだから、色々と使い回しができるデータ形式で最初に用意したほうが効率がいいよな。たぶん。
3DCGゲーム全盛時代に何を言ってるのか。＞自分。
◎ パレット替えに関して実験。 :
背景の上に乗せる障害物の色をレベルに応じて変えてくれ的要求が来てるので、障害物画像のパレットデータをEDGE2を使いながら変更・増量。しかし、作業してるうちに、パレットだけ変更した画像数が、単純計算では5倍ほどになることに気づいて悩む。…パレットデータだけ持って、PalettedImage() で変更していったほうがいいか。以前そのへん実験したときは、現在のgif画像中のパレット値を取り出して、計算で変化させて書き直す、ということは機種依存の値が返ってくるからできないにしても、パレットデータのRGB値を別途持っておけば、パレット替えはなんとかできそう、てな感じだったし。
パレットデータをRGBでファイル保存しなきゃいけないわけだけど。EDGE2なら、パレットデータをcsvファイルで保存できることに今頃気がついた。ありがたや。チマチマと保存。この手の修正要求が多々上がってきた場合は、Python + PIL 等でcsv保存を自動化せんといかん予感もあるけれど。
csvを読み込んでバイナリファイル出力する Perlスクリプトも作成。
パレットデータだけで2KByteほどになってしまった。うーん。まあ、全部別画像で持つよりは、はるかに容量が少ないから、これでいいか…。
プログラムソースを変更。画像を Image() で確保するメソッドに引数を増やして、PalettedImage() で確保する処理も追加。障害物画像の表示部分も、Image() と PalettedImage() のどちらを使うかで処理を分けた。
動作確認するが、エラーが出る。…開発用モード有効時は、別の流れで動いてることを忘れてた。初期化がちゃんとされてなかった。…が、まだエラーが出る。念のために色んな場所で、障害物配置初期化をしてたのがマズかった。画像を読み込んでないのに縦横幅を取得しようとしてコケていた。そのへんも修正。
なんとかいい感じに表示できたけど。既に画像展開済みの場面でも、処理が返ってくるのが妙に遅い。何故。…画像展開済みか否かに関わらず、System.gc() を何度も呼んでたのが原因だった。スクラッチパッドから読み込む前後でも System.gc() を呼んでるんだから、画像ナンバーの一覧をループで見ていくところでは呼ばなくてもいいよな。せいぜい、ループ外の前後で呼ぶくらいで大丈夫だろう。たぶん。
パレットデータをRGBでファイル保存しなきゃいけないわけだけど。EDGE2なら、パレットデータをcsvファイルで保存できることに今頃気がついた。ありがたや。チマチマと保存。この手の修正要求が多々上がってきた場合は、Python + PIL 等でcsv保存を自動化せんといかん予感もあるけれど。
csvを読み込んでバイナリファイル出力する Perlスクリプトも作成。
パレットデータだけで2KByteほどになってしまった。うーん。まあ、全部別画像で持つよりは、はるかに容量が少ないから、これでいいか…。
プログラムソースを変更。画像を Image() で確保するメソッドに引数を増やして、PalettedImage() で確保する処理も追加。障害物画像の表示部分も、Image() と PalettedImage() のどちらを使うかで処理を分けた。
動作確認するが、エラーが出る。…開発用モード有効時は、別の流れで動いてることを忘れてた。初期化がちゃんとされてなかった。…が、まだエラーが出る。念のために色んな場所で、障害物配置初期化をしてたのがマズかった。画像を読み込んでないのに縦横幅を取得しようとしてコケていた。そのへんも修正。
なんとかいい感じに表示できたけど。既に画像展開済みの場面でも、処理が返ってくるのが妙に遅い。何故。…画像展開済みか否かに関わらず、System.gc() を何度も呼んでたのが原因だった。スクラッチパッドから読み込む前後でも System.gc() を呼んでるんだから、画像ナンバーの一覧をループで見ていくところでは呼ばなくてもいいよな。せいぜい、ループ外の前後で呼ぶくらいで大丈夫だろう。たぶん。
[ ツッコむ ]
以上です。