VRM入道

http://gray.ap.teacup.com/ghost/にて欧州行脚2009公開中

 
この記事にはコメントを投稿できません
コメントは新しいものから表示されます。
コメント本文中とURL欄にURLを記入すると、自動的にリンクされます。
投稿者:KSMaster
とりあえず掲載しておきました〜。
BBSの方、了解です〜。

http://ksmaster.sblo.jp/
投稿者:ghost
さんくす。
http://8719.teacup.com/vrmovies/bbs にも、いくつか既に放流してるので、適当にサルベージよろ。>KSMaster殿
投稿者:KSMaster
とりあえず上げておきました。
http://kinokuni-station.com/ptatrain/ptEF65-akatsuki.lzh
第5号は明日届くのでまだオープンしていないので未掲載ですが。

http://ksmaster.sblo.jp/
投稿者:ghost
なるほど、参考になりました。ありがとう。>ちびて殿

VRM環境でどうかは実験するのが一番だと思うので、後日やってみることにします。他諸兄も、我こそはと思う方は何某かの実験をやってレポートしてくださいませ。>ALL
投稿者:ちびて
少なくとも、RailSimでは、起動時にテクスチャなどをメモリに読み込ませるらしいので、テクスチャの枚数やサイズが小さいほどPCに優しいようです。
VRMがいつテクスチャを読み込ませてるか知りませんけど、多分面積比だと思います。
画質とパフォーマンスのバランスを考えると256四方辺りが妥当じゃないでしょうか?

とか言いつつ、RailSimのプラグインは軽く1024x256とか使ってますが。
投稿者:ghost
おぉ!

いや、その説明で多分あってる。というか、今、すごく納得がいった。

ところで、教えて君で申し訳ないんだけれども、ついでにご教示願いたいんですが。元テクスチャのサイズが大きくなることによって、それを収蔵するオブジェクト(VRMの場合はレイアウト・編成ファイル)のサイズが大きくなるのは止む無しとして、レンダリングエンジンの負荷に対する影響は、単純に面積比と考えてもいいんでしょうか?

然るべくアンチエイリアシングさえしてやれば、画像リソースのサイズが大きければ大きいほど、近接視点での見栄えがよくなるワケですが、思うにI.MAGiCが128x128の画像を敢えてサンプルに選んでいるのは、やはりパフォーマンスへの影響があるからなんではないかと。

ここまでの話からすると、RSでもそこらへんについて何か気をつかわねばならんところがあるんじゃないか、と想像してみるワケですが、何か知見をお持ちであればお願いします。>ちびて殿
投稿者:ちびて
比で記録されていると思います、多分。
サイズが2の累乗なのは、PC内部で画像を2の累乗に修正してからレンダリングするので、最初から2の累乗であれば修正する手間が無くなるとか…。
記憶が曖昧なので、違うこと言ってるかもしれませんが。
投稿者:ghost
レンダリング時=実際に画像をモニタ上に吐く時点はそれで理解できるんだけども、その元ネタになる画像のサイズまで可変なものなんですかね?

つまり、ポリゴン面と対応するテクスチャの領域は、元テクスチャの絶対座標ではなく、元テクスチャのサイズに対する比で記録されている、って理解で正しいですか?>ちびて殿

元テクスチャの縦横サイズが2の乗数ってのは、多分、レンダリング時の計算を高速化するために、それを前提とした精度でしか計算してない、って考えると納得はいくんですが。

このへんはボクも専門ではないので、教えを乞いたいところです。
投稿者:ちびて
画像リソースは、テクスチャとして車両の方向幕などの面に合わせてマッピングされるので画像の大きさについては大きかろうが関係ないかと。
この辺は多分LightWaveだろうとメタセコだろうと関係ないと思いますが。

実験的代物

CSS無効化 ここで知った方法を使ってます

真・世界征服新着情報

今月のお勤め

2009年
← December →
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

ブログサービス

Powered by

teacup.ブログ
RSS
Powered by teacup.ブログ “AutoPage”