2009年6月アーカイブ

デフォでオーバーニーソックスとバックシームストッキングが入ってたので大歓喜。

まあでも成長したら服装も自動で選ばれて変わってしまったが。

女の子が欲しいなあと頑張ったら二度も男の子が生まれてしまってゲンナリしながら一気に操作するシムが4人になって忙殺されてます。Free Willで放置してても割と大丈夫っぽいのですが、赤子の世話も絡むとちょっと十分ではないかなと言う感じ。次に新規でやるなら独身でのんびりやってみますかね。ティーンズ以下だと単身で作れないのがちょっと難だけど。

CRT信者にしてEIZO信者という一部の身内に有名な私ですが、この度遂に液晶ディスプレイを購入しました。

動機は民生品SEDの発売の目処が立たないのと、現存して使用しているCRTの保護というネガティブこの上ないものからきてたりしますが。CRTである必要性のない作業までCRTを使ってると寿命が縮むし、それの代替品も入手が極めて困難だし。

世の中じゃ16:9比率が氾濫してますが、4:3のにしましたが高価ですね。16:9は映像鑑賞には良いサイズだとは思うのですが、色々作業をするには縦が短すぎるし縦に回転させると横が短すぎるというイマイチ使えない寸法だと思う。特に現在のPCのOSは4:3を前提としてインターフェイスが設計されているわけで、この辺が変わらんとどうしようにもないと思うのですが、Windows 7ではさらにタスクバーがでかくなって縦を圧迫する仕様になってるみたいじゃないですか。

で、色味に関してはEIZOなのであんまり文句言いたい部分は無いのですが、角度によって色が変わるのは思っていたよりも違和感が強いですね。色むらは殆ど見られないにも関わらず、普通に正面から見ても端の方に行くにつれて微妙に色がかわるのはいかんとも。ちょっと正面からそれるともう駄目。

さらに遅延も思ってたより感じるかなあと。16ms程度らしいのですが、職場で使ってるやつはもっと遅延してるだろうし質も低いやつだから大丈夫かなと思っていたのですが、CRTが身近だとマウスカーソルの移動がもたついてストレスを感じてしまう。数ms遅延のやつは16:9しかないし、色味が腐ってるはずなので使いたくないんですぅ＞＜

前回のを踏まえて、もうちょっとデバイスの初期化と取得できるデータの蓄積なんかを今よりもちゃんとしとかないとまずいよなということで、ゴリゴリその辺を書いてるんだがめんどくさいな。

データ取ってくるだけの処理なので誰が書いても似たような感じになるはずなのだが、その辺のサンプルレベルでやるには大袈裟な物量なので誰も公開してないが、ユーザに使って貰うには必須というのが面倒この上ない。

SDKのDirectX Caps Viewerのソースがあればリファレンス見返す頻度も減って参考になるんだろうが、こういうのに限ってソースが含まれてないしね。

で、いつものことだがそのリファレンスもリファレンスらしからぬ書き方をしてたりして萎える。D3DRTYPE_SURFACEの説明が「サーフェイス リソース。」とかね。そんな説明は定義された文字列を見りゃ誰でも分かるわけで、良くないコメントの書き方の典型すぎる。

DX10からはこの作業は無くなるわけだが、DX10とVistaなんて誰も使ってないし将来もないし、DX11はやっとプレビュー段階で対応ハードすらまだないのでどうにもならん。DX11は主流になってくれるのかは分からんが、とりあえず未だに固定機能頼りの多い個人規模だと敷居は高くなりそうだ。VSとPSはSM3.0未対応のハードを切り捨てる勢いで使ってるので主流になりそうならDX11に移ってもいいのだが、GSやらCSの使い道は未だによく分からん。

CSのテッセレーションはストリームの量減らせるとかLODが楽とからしいが、普通にハイポリモデル用意する方がアーティストにとっては楽だし意図した結果にコントロールしやすいんじゃないかと思う。パフォーマンスが犠牲になってもね。他にも色々使い道がありそうなのはいいが、普通の人が扱いこなせる範疇なんですかねえ。

GSに至っては結構出てから経過してるのに、頑張ってるなと思ったのはNVIDIAのヘアシミュくらいだしなあ。酷いはポストエフェクト用の矩形ポリ作ってるだけとか。

Larrabeeなんて固定機能とは真逆を行ってるわけで、余程下地が整っていない限りレンダラ方面の人だけが弄るだけで終わりそうな気がするんだがはてさて。

色々と機能追加しつつ高速化しつつリファクタリングしてみたので、久しぶりにノートの方で動作確認してみようとしたら見事にブルースクリーン。

以前はMSAAを使うと青画面になってたので今回は最初から切ってたのだが、それでも駄目らしい。恐らく浮動小数点テクスチャの一部のフォーマットが対応してないだろうということで、R16FとかG16R16Fとかの拡張されたやつを無難なARGB16Fに変えてみたのだが変化無し。これで前は動いてた気がするんだが。

ノートのグラフィックチップはMobile Intel 965 ExpressはShaderModel 3.0になんとか対応してるようで、最低限のスペック上での動作確認にはなかなか便利。一応最下限のターゲットにしてみようかと思っていたのだが、真面目なエラーチェックとオプションでのオン/オフを入れないと動いてくれなくなってしまったようだ。もっとも動いてくれたところでリアルタイムとは言い難い速度で動くんだろうけど。

こいつよりもデリケートな印象のあるATI系は手元に無いのでさらに心配だ。真面目にやるなら検証用のマシンも作らないとなあ。

今のところGF8x系以降が推奨レベルで、テクスチャフォーマットの対応さえとればGF7x系が速度はともかく動作可能レベルなのかなあ。ひでぇ。ShaderModel 2.xとかはバージョンが乱立しすぎてしがらみがややこしいので全部切り捨てる方向で。

きっちり対応できてるPCゲームは偉大だわ。

今更Tone Mapping作ってみたんだが、これはどうやって正しく処理が行われていることを確認すればいいんですかね。

YCrCb系だと色相が明らかに変になったので、Reinhardと同じようにXYZ系にしてみたのだがなんか合ってるような気がしない。背景のカラーをサンプリングして比較してみても色相は狂ってなくて、明度と彩度は変化してるのだが、モデルなんかはコントラスト比が変わりすぎて違和感を感じる。

そもそもLwhiteが1.0の時は0から1の線形になるはずなのだが、そうではなくて補正がかかっちゃってる時点で計算に使う値がまちがっとるんだろうか。Reinhardのソースをもっと見ろという話ではあるのだが、ごにょごにょ。Reinhardの手法を使ったと思われる他の人様のソースも見事に計算式に使う値がバラバラだったりするのは何故なんでしょう。

Reinhard以外の手法で感光シミュあたりの方が良好な結果が得られるんだろうけど、Reinhardの手法の場合は先述のようにLwhiteによって補正カーブの形状が変化してくれるはずなのがおいしいなあと思う。特に1付近の低い値のケース。補正されすぎないようにLwhiteを適度にクリッピングしておけば一番扱いやすいんじゃないか？

扱いやすいといってもアーティストの間ではトーンを自分でコントロールできないTone Mappingは不評なわけですが、個人でやる限りには自動でやってくれる方が用意するデータとパラメータが少なくてもそれなりの見栄えになるので多分楽だろう。