« 2005年10月 | メイン | 2005年12月 »
2005年11月30日
Firefox 1.5 [ 雑記 ]
FirefoxのMacOSX版には、複数の動画Flashがあるページを開くとものすごく重くなる（ひどいときはハングする）っていう問題があったんだけど、たしかそれが解消されてるはず。以前Flashでハングしたサイトがいますぐは思いだせないんで未確認。あと、ブックマークバー等のメインウィンドウ内から出るメニューの表示フォントが変わって読みやすくなった。前は「歯」が「■」にしか見えなかったのが、ちゃんと読める。
投稿者 ヒロツ : 16:20 | コメント (0) | トラックバック (0)
2005年11月29日
MTDとShaderTree [ finalRender Stage-2 ]
◆MTD
非常にわかりやすいfinalRenderならではの例、Micro Triangle Displacement、いわゆるマイクロポリゴンディスプレースメント。Advanced RenderのSPDと似てるが、こっちのほうがずっと強力というか制約が少ない。
レンダリングされてるポリゴン数は「faces 473376」とあるので約47万ポリゴン。これがGI込みで4分（2CPU）でレンダリングできてしまう。使用メモリもメインマシンのほうがシステム全体で400MB程度、ネットワークスレーブのほうはCINEMA 4D本体が立ち上がっていないのでシステム全体で200MBにしかならない。ジオメトリの動的メモリ管理がマニュアルにはあったけど実際のインターフェイスには出てなくて（未実装？）結局使ってないんだが、実メモリだけでもこのぐらいのポリゴン数なら問題ないようだ（メモリが足りなくてもMTDをかけたオブジェクトがレンダリングされないだけで、CINEMA 4Dが落ちたりはしないようだ）。なんつうか、レンダラーそのものの地力の違いを感じる。
◆Shader Treeと日本語モード
英語モードで使ってれば何の問題もないが、日本語モードの場合ちょっと厄介なことがある。Shader TreeはXpressoのインターフェイスをそのまま使ってるらしく、日本語モードではfinalRenderが英語版であっても出力ポートのデフォルト名称は日本語で「カラー」になる。ところが、Shader Treeの出力ポートとfR Materialの入力ポートはポート名の文字列で接続が認識されるため、シェーダの「カラー」出力とマテリアルの「Color」入力では繋がらないのだ。
試しにfR Materialを作ってShader TreeでPhongシェーダノードをつなげてみる。シェーダノードのプレビューではDiffuse Colorに設定した緑色が反映されているが、マテリアルのほうには反映されていない。エディタビューにもレンダリングにも反映されない。
ポート名はデフォルトで非表示になっているので、右クリックメニューの「Ports / Show Names」で表示させると、日本語で「カラー」となっている。これはたぶんXpressoの出力ポートのひとつである「カラー Color」を流用してfR Materialに繋いでいるからだ。
出力ポートの右クリックメニューに「Rename Port（ポート名変更）」というのがあるので、これで「Color」と変更してやる。
すると、無事にShader TreeとfR Materialが繋がって、シェーダがマテリアルに反映される。
この件はCebasのフォーラムでドイツの人もポストしていた。ドイツ製のプラグインなのにドイツ語では支障があるというのはどうなんだCebas。
また、Displacementのチュートリアルにも書いてあるが、fRのMTDを使うには新規で「Color」として作成した出力ポートの名前を「Displacement」と変えてやる必要がある。日本語モードで使っている場合は「カラー」から「Displacement」に。
MTDっていえば、fR Displacement Tagをオブジェクトに適用しても効いてないっぽい。これもなんか怪しい。
投稿者 ヒロツ : 20:16 | コメント (1) | トラックバック (0)
finalRender-Imageモード [ finalRender Stage-2 ]
もう一つのGIモード、finalRender-Imageでフロをレンダリングしてみた。fR-IモードはCINEMA 4DのAdvanced Renderの発展型といえるモードで、設定もわりとARのGIに似ている。ただし、こっちは最適化がかなり進んでいて、いじれるオプションもものすごく多くなっている。
レンダリング所要時間は全くの偶然で先のAQMC+LightMapとほとんど同じになった。全体的なクオリティも似たり寄ったりだが、引っ込んでるところの影がスポっと途切れるようなアーティファクトはない。LightMapよりも結果が読みやすいので、こういうタイプの手ごわい静止画ではこっちを使うほうがよさそうだ。
fR-IはGIのEdge Detection（エッジ検出）オプションで落ちたり、Decay（減衰）の基準距離としてStartと表示されてるやつが実はEndだったり、微妙に詰めの甘いところがある感じはする。
GIとは関係なしに気になるのはアンチエイリアスの品質。CINEMA 4Dはオブジェクトエッジでは16x16でサンプリングするのでアンチエイリアスが恐ろしくきれいなのだが、fRはオブジェクトエッジもコントラスト差もあまり変わらないようだ。それと、輝度が１を超えているところとの境界はアンチエイリアスがうまくいっていない。これは輝度が１を超えているレイと通常の輝度のレイを単純に平均化してるせいで、アンチエイリアスがかかった後でも当該ピクセルの輝度が１を超えてしまうため。こういうとこをインチキして飛ばないようにするレンダラもあるんだけど、fRはそうじゃないようなので、アンチエイリアスにジッタをかけるとかして逃げるしかないかも。
投稿者 ヒロツ : 01:54 | コメント (2) | トラックバック (0)
2005年11月28日
R9.52 [ CINEMA 4D R9.5 ]
R9.5のアップデートR9.52が出ましたね。
バグフィックスの詳しい内容は出てないようですが、コンテンツブラウザとかテクスチャベイクとかの新機能でバグ取ったりちょっと改良したりされてると思います。特にテクスチャベイクはいろいろ挙動不審なとこがあったんですが、おおむね直ってるようです。
あとChanLumが標準装備になりました。元はCoffeeプラグインだったのがC++プラグインになって速度も向上しているらしいです。
同時にフリーダウンロードのライブラリも公開されてますね。これは僕も未チェックですが、ファブリックのマテリアルは自分で作ると面倒なんで結構いいかもしれません。
投稿者 ヒロツ : 21:46 | コメント (0) | トラックバック (0)
機動戦士ＺガンダムⅡ−恋人たち− [ アニメ ]
今回は劇場に行って観た。
副題どおり、やたらといちゃいちゃしてる奴が多い。戦闘＞いちゃいちゃ＞戦闘＞いちゃいちゃ＞移動＞いちゃいちゃ＞陰謀＞いちゃいちゃ＞ハマーン様＞続く、って感じ。特にカミーユ、調子に乗るんじゃない。
女性陣では、僕としてはフォウ・ムラサメが最重要ポイントだったのだが、意外とあっさりしていた。第二部はあっさりひいておいて、第三部でドスンとくるんだろうか。CVゆかなは特にどうということもなし。ちょっと軽かったかなあ。サラ・ザビアロフの声優が池脇千鶴に代わってて、これはなかなかよかった。一筋縄で行かない問題女子をうまく演じてた。カツｶﾜｲｿｽ。
男性陣では、カミーユ調子にのんな。あとエウーゴのおっさんたち面白すぎです。
メカ関係は、種類が多すぎてよくわかんねえよ。旧世代MSと新世代MSというか、中にヘビーメタルかモーターヘッドが混じってるというか、それがかえってMS文化の多彩さを演出してて面白かったが。サイコガンダムは怪獣映画みたいだった。MAや変形MSの戦闘は動きが速すぎて何がどうなってるのかわからんのと、人型である必然性を否定するのは諸刃の剣だと思った。そこらへんと比べると黒い三連星とか牧歌的だよな。戦艦は3Dになってたけど、第一部のアッシマーとかも3Dだったんだろうか？ あの精度の絵を手で描いてる人がいるとしたらすごいな。
相変わらず新旧の作画のばらつきが目に付くのが惜しい。線の精度、絵そのものの巧拙のほかに、旧作カットだとキャラが途端に「北爪顔」になっちゃうのもスゲエ気になる。あ〜もったいねえ。
第三部は結末がどうなるのか気になるところ。カミーユが心神喪失しちゃうオチはまあ変わるとして、それ以外はどうするんだろ。実はZガンダムというのは、僕がテレビアニメを見るのをやめるきっかけになった作品だったので（以後エヴァまでほとんど何も見なかった）、御大にはちゃんとオトシマエつけていただきたいですよ。
投稿者 ヒロツ : 21:34 | コメント (0) | トラックバック (0)
AQMCとLightmap [ finalRender Stage-2 ]
手持ちの風呂シーンをfinalRender Stage-2でレンダリング。
CGTalkのfRスレッドなんかで3分だの5分だのというレンダリング時間を見てると、これの2時間42分（2CPUで）というのはすごく遅く感じてしまうが、室内に光源のない閉じたシーン、オブジェクトの大半が鏡面反射アリ、さらに直線的なV字型のミゾやら極細オブジェクトやらがあるという悪条件なので、それなりのクオリティを出すとこのぐらいになってしまう。それでもAdvanced Renderよりはだいぶ速い。
よく見ると、細長いミゾや段差で陰影が不規則になっている。これはどうもSecondery Bounceで使用しているLightMapのアーティファクトを拾っているようだ。
LgihtMapはチェックのためレンダリングで表示させることができる。こういうものだ。こわっ サイレントヒルかと思った。なお、上の完成画像とは設定が異なり、表示のレンダリング時間もプレパス再使用のため非常に短い。
ここで描かれている丸いパターンはLightMapの個々のサンプルの明るさを表わしていて、本番のレンダリングでは、Secondery Bounce（カメラからサーフェスにぶつかったGIレイのそれ以降の反射）が拾うのはこのLightMapをスムージングした輝度になる。当然LgihtMapにはぼんやりした陰影しかないわけだが、GIの二回目以降の反射では多数のレイの輝度が平均化されるため、大抵はこれで間に合ってしまう。サンプルが粗いのでGIの反射回数が増えても計算の負担はあまり大きくならない。このへんはフォトンマップ+パストレーシングによるファイナルギャザリングと同じだ。
LighMapで問題が生じるのはサーフェスが引っ込んでいる部分。引っ込んだところはGIのレイが拡散しにくいため、直近のLightMapサンプルしか参照できず、LgihtMapの陰影の偏りを平均化しにくい。付近にLightMapのギャップが存在すると、その偏った陰影をそのまま拾ってしまう。完成画像の細長いミゾで陰影が波打ったようになっている部分では、Primary Bounceのサンプル精度をいくら上げても改善されないので、おそらくその直上にLightMapのギャップがあるのだと考えられる。試しにSecondery BounceのLgihtMapの精度を上げてみたが、それをやるとレンダリング時間がドカンと伸びるようで、あまり効率は良くなさそうだ。
こういう引っ込んだディテールのあるシーンでは、AQMC+LightMapよりもfR-imageのほうが向いているのかもしれない。次はfR-imageを試してみよう。fR-imageはAdvanced RenderのGIの発展型なのであまり有り難みがなく（笑）、まだ試していなかったのだが、ARと比べると大幅に機能向上しているようなので、実は期待できるのかもしれない。
投稿者 ヒロツ : 16:58 | コメント (4) | トラックバック (0)
2005年11月23日
Sky PortalとLight Portal [ finalRender Stage-2 ]
つづき。Sky Portalは開口部を通じて背景へのGIレイを導くもの、Light PortalはオブジェクトへのGIレイを導くもの。ではこのシーンのように、開口の外は半分が空、半分が地面というような場合はどうすればいいのか？ なんのことはない、同じ位置にSky PortalとLight Portalを重ねて置いてもかまわないらしい。
両方置いたら一段と光が入るようになった。
なにやらレンダリング時間も延びているが、たぶんLight Portalを追加したぶん、そこから発射されるGIレイの数が多くなってるんではないかと思う。
トンネルの出口が飛びすぎなので、OpenEXRで出して露出を落としてみた。こうすると、飛んでた壁面も、空も地面もちゃんと見える。
よく見るとトンネル出口付近で地面に明暗の境界ができている。そこはちょうどLight Portalがはまっている箇所なので、Light Portalより内側だけが明るくなってるのではないかと思う。
マニュアルによるとSky PortalもLight PortalもRectanglar Area Lightのみとか書いてあるので、単純な四角い窓でない開口部がある場合は問題になるかもしれない。
このギザギザトンネルはGIに重い負荷をかけるにはいいんだけど、絵的には面白くないのでこのへんでやめにする。以後はもうちょっとマシなシーンで。
投稿者 ヒロツ : 23:23 | コメント (4) | トラックバック (0)
finalRender到着 [ finalRender Stage-2 ]
finalRender Stage-2 for CINEMA 4D到着。国内代理店のTMS経由なので、オンラインでなくメディアで送られてきた。物理的にはキーコードが印刷された書類とCD-Rで、CD-Rには日本語のインストール手順ドキュメントも入ってた。その他のインストール等の注意事項は既にネットで情報収集済だったので（DLLが１つ足りないとか、RenderStationはウィンドウモードでないとダメとか）、特にトラブルも無く導入完了。finalRender自体のマニュアルは生のHTMLで、コンパイルされたHTMLヘルプではなかった。もちろん英語。
◆ぎざぎざトンネルをレンダリング
とりあえずこないだのARのストカスティックモードのテストで使ったギザギザトンネルシーンをレンダリングしてみた。
GI的に非常に厳しいシーンなので結構てこずったが、レンダリング時間1時間ちょっと（2CPUで）でどうにか許容範囲の絵になった。Advanced Renderでは似たようなクオリティの絵が1CPUで21時間かかっているので、乱暴に言うとfinalRenderのほうが10倍速いということになる。ええっ
finalRender Stage-2にはGIのモードが3つあるのだが、これで使ってるのはStage-2から実装されたAdaptive QMCというモード。ベタなパストレにアンダーサンプリングやライトマップ併用の２パスGIなど最適化アルゴリズムを組み込んで高速化した、最も汎用性が高いイチオシのモードらしい。まあ最新だからね。
もうひとつ、Sky Portalという機能を使っている。これをジオメトリの開口部にセットすると、全てのGIサンプルポイントが必ずその開口部を参照するようになり、開口部の小さなシーンでも効率的に天空光を取りこめるというもの。短時間でこれだけトンネル内が明るくなるのはSky Portalの貢献が大きいようだ。絵ヅラをこないだのARのと比べてみるとこっちはカラーブリードがすごく少ないが（ARのほうはむしろ多すぎだけど）、Sky Portalから入る光はいきなり空／背景まで行ってしまって地面の光を拾わないので、そのせいかもしれない。
◆Distributed Render
fRにはDistributed Renderというネットワークレンダリング機能があって、複数マシンで一枚の画像をレンダリングできる。Shadeには昔からある機能なので大したこと無いかと思いきや、コレができるレンダラーはそんなに多くない。CINEMA 4D本体もできない。
レンダリング中はこんな具合。
緑と赤のドットはAQMCのプレパスで、黄色と赤のカコミが現在レンダリング中のバケット。黄色はこのCINEMA 4Dが動いてるPCで、赤はネットワーク上のスレーブのもの。GIを使った時間のかかるレンダリングではバケットの送受信の間隔が長いので、ネットワークによるオーバーヘッドは感じられない。うちの場合はメインが2.4GHz*1、スレーブが2.0GHz*1の2台なんだけど、体感的にはデュアルCPUと同じ。GIを使った重いシーンのテストレンダリングこそ速く片づけたいものなので、そういう使い方ならDistributed Renderが活きてくる。安いPC買ってスレーブ増やそうかと真剣に考え中。fR2は1ライセンスで10CPUまでDistributed Renderで使用可能だそうなので、予算と電力の許す限り増やしてもライセンス的には十分な感じだ。逆にスタンドアロンのNet Renderには追加ライセンスが必要という、なんか微妙なライセンス形態になっている。
投稿者 ヒロツ : 18:18 | コメント (5) | トラックバック (0)
2005年11月21日
機動戦士Zガンダム−星を継ぐ者− [ アニメ ]
劇場公開は近所でやってなかったので観そびれてしまい、DVDでようやく観た。
テレビシリーズを劇場映画3本に圧縮というのはファーストガンダムと同じなはずなんだけど、ファーストガンダムの劇場版よりずっと展開が早いというか駆け足になってた感じがする。Zはファーストより贅肉が少なかったってことなんだろうか。どうでもいい合体シーンとかククルス・ドアンの島とかないしな。テレビシリーズと比べるとカミーユよりクワトロのほうにだいぶ比重がいってるような印象も。観客はオッサンが多そうだからそれはそれでよさげ。
新作部分の作画がスゲエ良くてびっくり。単に絵が上手いっていうだけじゃなくて、カミーユがアーガマのラウンジで両親の死を嘆く場面の演技とか、ちょっとアニメではあり得ないような芝居の細かさで、マジで度肝を抜かれましたハイ。逆に旧作部分で明らかに絵がヘタクソなとこがあったりするのがなんとももったいなかった。新旧のギャップはエージング処理して馴染ませたりしてるそうだけど、それ以前に作画レベルが違いすぎるところがあるのはどうにもならん。ヘタクソなとこは全部描き直しちゃったほうが良かったんではないのかと思うんだけど、どうなんだろ。予算的な事情なのか、それなりに旧作部分を残すことに特別な意味があるってことなのか。はて。
声優陣はもう結構な歳のはずなんだけど、ぜんぜん違和感ないのはすごいね。もう20年も経ってるのに。化け物かおまえら。声優っていえばフォウ・ムラサメ役でイロイロあったらしいけど、イロイロの部分は関係者や業界に反省してもらうってことで、第2部以降も作品自体には期待してる。「恋人たち」はちゃんと劇場に観に行こうっと。
投稿者 ヒロツ : 02:07 | コメント (0) | トラックバック (0)
コープス・ブライド [ 映画 ]
ストップ・モーションがどうとかいう以前にティム・バートン好きなので無条件にOKな感じです。ナイトメアビフォアクリスマスはだいぶ子供っぽいとこがあったんだけど、コープス・ブライドは実にティム・バートン的なストーリーで、大人社会の欺瞞を告発したりナイーヴな若者が土壇場で内面の強さを見せたり、そういうやつ。型通りといえばそうなんだけど、そもそもストーリーというものには必然的な型があるもんだからね。
人形のキャラクターは顔のデリケートな表情もきっちり出ていて魅力があった。ストーリー的に人物の心理を描写できないと駄目な内容なので、このへんは必然なんだろうな。セットも隅々まで作り込まれてて素晴らしい。なにしろ全部人の手で作るわけだから、その都度必然性を考えてけばちゃんとこういうのができるのかもしれない。
ストップ・モーションのアニメーションにはミニチュアセットや人形の持つ制約があるわけなんだが、絵の道具というのはだいたい何でも制約があるもんで、長い時間かけてその制約の中で限界まで表現力を引き出せるようになると、そこにスタイルが確立されるんではないかと思う。この「長い時間かけて」っていうのがミソで、3DCGみたくめまぐるしく技術が移り変わっていって、なおかつオペレーションしている人間のほうも自分自身の手を繰り返し動かして技を培っていくようなことができてない場合、単に道具に流されてるだけのがちゃがちゃしたものになってしまって、スタイルなんか確立される暇もないなんてことになりがち。3DCGできちんとしたスタイルを確立するためには、全体をコントロールする人間に明確な美意識があるっていうことと、オペレーションする人間に体でものにした技術があるっていうこと、あと、そういう人たちがちゃんとした仕事ができるような環境、そういうのが必要なんじゃないかと思う。
投稿者 ヒロツ : 01:46 | コメント (2) | トラックバック (0)
エウレカセブン 第27〜31話 [ アニメ ]
またオープニングとエンディングが変わった。
オープニングは……ビートパンク！？ 楽曲と絵の動きがうまくかみ合ってるとこはいいんだけど、画面全体がずっと黒っぽいまんまでパッとしない。あと、なんつってもキャラ絵がヘタクソすぎる。レントンとエウレカは動きはいいけど顔違うし、アネモネとドミニクは本編でいちばんひどかったときでもここまでひどくなかったつうぐらいでもう見てられんし、最後の止め絵も、止め絵でコレってどういうことよという出来だし。1クールごとにオープニングエンディング作り直しなんてやってられっかっていうスタッフ陣の逆ギレなのかと思った。
エンディングは非常に好み。止め絵プラスアルファ程度の枚数だけど、絵ヅラの面白さでちゃんと持たせてる。と思ったら絵コンテ渡辺信一郎か。画面がモノクロで衣裳も本編と違うので、誰だかはっきりしない人物もいるがまあそれはそれで。曲もけっこういいのでアーティストのサイトを見に行ったらなんか、ディスコグラフィーは頭悪そうな感じの曲が多くないですか。要するにプロデューサーとソングライター次第ってことか。テレビ版とストリーミング版でミックスが違うように聴こえるんだけど、はて？
27・28話
ビームス夫妻はレントンの「覚悟」の節目をつくる存在としては良かったと思うんだけど、エウレカを敵視してる事情については説得力のある描写がなかったんで、元SOF＝頭おかしくて死にたがり、っていう印象になってしまった。ホランドのほうもそのへんは同様だし。あと、レイの腕とれたのはやりすぎじゃないかなあ。
29・30話
エウレカの正体が明らかに！ っていうか予想通りすぎです。このへんでバラしておかないと話が先に進まないというか、前後半の折り返しまで無理矢理引っ張ったというか、そんな感じ。でも単にエキセントリックなところがなくなっちゃっただけじゃタダの内気で不運な女の子でしかないので、いままでと違う見せ方でエウレカらしさを出して欲しいと思った。どうも、話作ってるほうの人たちがエウレカの変化というのが何なのかつかめてないような感じがする。
じじいサーストンとドミニクの話はとても良かった。ドミニクが土壇場でデューイから離反する伏線だろうか？ あとタルホがイメチェンしてたけど、なんで突然イデオン風になったんだろう。その服どっから出してきたんだ？
女博士がそのものズバリ赤木リツコなのは笑った。
31話
みどころ満載。チュー未遂とか、ババア賢人の萌えリアクションとか、凶悪少女部隊とか、あっけなく表に出てきたコーラリアンとか。エウレカとニルヴァーシュの関係はもうちょっとうまく表現できるんじゃないのかなあ。暴れてたニルヴァーシュがエウレカが近づくと大人しくなるとかさ。ひさびさにアネモネ出てきたけどなんか地味。
前半2クールでは意図的に情報を隠してたのが逆効果で非常に歯切れの悪い展開になっちゃってたとこがあったんだけど、3クールに入ったら途端に勢いが出てきた。ストーリーのSF的な側面も見えてきたし。でも政府とか軍隊とかの社会的な側面は相変わらず薄っぺらくて、オシャレなオタクが背伸びしてもこんなもんかという限界を露呈してる感じ。
投稿者 ヒロツ : 01:26 | コメント (2) | トラックバック (0)
2005年11月16日
ストカスティックモード（２） [ CINEMA 4D R9.5 ]
つづき。今度はトンネル状のシーン。球体を挟んで手前と奥に開口アリ。
標準、ストカスティックともに拡散反射回数5／サンプル数600。光量が足りないのでレンダリング時にグローバルの露出を上げて、それでもまだ足りないのでOpenEXR保存したのをPhotoshop読み込み時に補正。
標準モードのほうはサンプル解像度をかなり高くしたのでレンダリング時間がストカスティックモードよりも長くなってしまった。640*480で21時間（P4/2.0GHz）は全く話にならない速度だが、それでもなおトンネル表面のミゾにはアーティファクトが見られ、完璧な結果とは言えない。
ストカスティックモードのほうは15時間かけてもまだまだノイズが目立つ。サンプル数600でこれだとすると、仮にサンプル数を倍の1200にしたら結構ノイズが取れるかもしれないが、その場合レンダリング時間が2^5=32倍になるんだろうか？ 予想はしていたが、こちらも実用には程遠い速度。
一応また「差の絶対値」でチェックしてみる。これも入力レベルを詰めて強調した画像。ストカスティックモードのノイズが画面全体で見られ、トンネルの入り口付近は広い範囲で差が生じている。
カラーサンプラーツールでチェックすると、トンネルの入り口付近は標準モードのほうが明るめになっている。GIサンプルの中に極端に明るいサンプルが混じっていると、標準モードでは補間によって周囲に拡がるので、ピクセル単位でしかノイズが出ないストカスティックモードよりも影響が現われやすいのかもしれない。
総合的に見て、ストカスティックモードはやはり「使えない」シロモノだと思う。
アウトドアではそこそこノイズのない結果が得られるが、標準モードに比べて特に何かメリットがあるわけでもない。結果には普通に視認できる程の差は生じていないので、標準モードで生じる問題がストカスティックモードでは回避できるというような状況はほとんどないだろう。速度的にも大きく劣る。
インドアは標準モードでもかなり苦戦しているが、ストカスティックモードにもメリットはない。だいたい、パストレーシングのセカンダリ以降をそのまま倍々で計算してるならインテリアで実用速度にならないのはあたりまえのことだ。
アニメーションでのフリッカーを避ける目的でストカスティックモードが使えるようなことが言われてるが、全く現実的でないと思う。ストカスティックモードを使うぐらいなら標準モードやカメラアニメーションモードでGIの精度を高くするほうが効率が良いし、可能ならGIをベイクすれば速度も桁違いに速い。
画質対時間比でいうと、ARのストカスティックモードよりもMaxwellのほうがずっと優っているように思う（Maxwellは1.0からはセカンダリ以降のサンプリングで何かサンプル間での輝度差を小さくするような細工をしてノイズを軽減してるんじゃないだろうか）。Maxwellのほうは他にもリアルDOFや真性のコースティクスのような、ARにない付加価値があるので、トータルでは全く勝負にならない。本来ベタなパストレをやるものでないARの「一応つけてみた」程度のストカスティックモードと、最初からベタなパストレで攻めるMaxwellのようなレンダラとで勝負にならないのは、まあ当たり前といえば当たり前なんだけど。
投稿者 ヒロツ : 21:15 | コメント (7) | トラックバック (0)
2005年11月14日
ストカスティックモード（１） [ CINEMA 4D R9.5 ]
そういえばストカスティックモードって使ったことなかったなあ、と思って、標準モードとどのぐらい違うのかテストしてみた。
まず簡単そうな屋外のから。空と太陽光線はSkyで。標準モードは拡散反射回数3／サンプル数100、ストカスティックモードは拡散反射回数3／サンプル数128。
レンダリング時間が3倍強違う以外はまるっきり同じ。念のため「差の絶対値」を取って調べてみたけど、ノイズ／アーティファクトの部分で最大30/256程度の差があるのみ。
これは「差の絶対値」の画像を、わかりやすいようにレベル補正して入力レベルの最大値を36まで詰めて強調したもの。
パストレーシングのジャリジャリしたノイズとGIサンプルのモヤモヤしたアーティファクトが確認できるほか、エリアシャドウの境界とぼけた鏡面反射にも差があるのがわかる。
この方法では「絶対値」しかわからないので、カラーサンプラーツールを使って詳しく調べてみると、大きな明度差は標準モードのアーティファクトによるもののようだ。ストカスティックモードに比べて明るくなっているところもあれば暗くなっているところもある。ストカスティックモードは全体的にノイズは出ているものの、サンプルのばらつきは標準モードほど大きくない。もっともレンダリング時間が3倍以上かかっているので精度が高くて当然ともいえる。
次にトンネルみたいに閉じた状態にしてみたんだけど、こっちは設定を厳しくしないといかんものでレンダリングに時間がかかる。NET Renderにぶんなげて放置中。続きはまた明日⊂￣ェ￣⊃ノ
投稿者 ヒロツ : 23:38 | コメント (2) | トラックバック (0)
2005年11月05日
Realforce 91U [ 雑記 ]
Realforce91UをShopUの通販で買った。HHKと並べてみると結構デカイ。普通のフルキーボードからテンキーを取っ払ったつうだけで、コンパクトキーボードとは呼べない感じ。
で、何よりもまず、うちのMacでまともに使えるようにしなくてはいかん。楽チンそうなのはWinKだったが、とりあえずタダでできる方法ってことで、ココのページのいちばん下に書いてあるJISキーボードリソースを入力スクリプトに読ませる方法と、uControlで修飾キーをスワップする方法でやってみることにした。このへんはTigerだとシステム自体でできるらしい（コレやってるMacはまだPanther）。
さしあたりこのエントリを書くぐらいの作業は普通にできた。Realforceのキータッチは噂通り非常に良い具合。軽くてスコスコとスムーズに打てるので高速にタイプしても右手の指と左手の指の打鍵順が逆になったりしない。キー配列がUSからJISになったせいでHTMLを書いてるとき " とか = とか _ とかが変わっててちょっとイライラした。いっそのことキートップの印字は無視してUS配列のまま使うという考え方もなくはないが、なんかそれはそれで使いにくそうだしなあ。
どうせJIS配列を使うんであれば入力スクリプトは「英数」「かな」キーで切り替えられたほうがCommand+Spaceのトグルより楽なので、WinKも試してみたい気はするが、現状だとWinKではCaps LockをControlにコンバートできないようなので微妙。uControlと併用できればいいのかもしれんけどどうなのかな。ひとまずこのままJIS配列に慣れてみて、後のことは後で考えよう。たしかPhotoshopのショートカットにはJIS配列だと効かないのが多かったような気がするので、そっちのカスタマイズがめんどくさそうな予感。
投稿者 ヒロツ : 20:56 | コメント (3) | トラックバック (0)