トックのCG部屋-トップ別室へ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

もう少し早くするために…

前回のモデルをレンダリングするのにかる時間
47秒強
まぁ一枚の画像を奇麗に仕上げるってんなら最終的な作画に1時間かかろうとかまわないんだよ
でもアニメーションをレンダリングしようと思ったらそうはいかない
レンダリングするのに1秒かかるものと5秒かかるもの
まぁ一枚だけレンダリングするだけだったら大した違いはない
あーいや、気分的にはそうでもないかもしれないけど…
でも作業に影響するほどの差はでない
が、これを使って60fpsで1秒分のアニメーションを作るとする
そうすると前者は1分、後者は5分かかる
まだこれくらいならいいかもしれないが1分分作るとするとその差は4時間にもなる

とまぁこんなくだらない前振りをだらだらとやって何が言いたいかって言うと
もう少しスピード上げなきゃなぁ…とそれだけ

んでコードを見直して速くできそうなところを探してみようと
まず速くできそうなのがfor文
下は特に意味もないけど配列に値を代入するだけのしょりを二通りの書き方で書いたもの

for(int i=0;i<3;i++){
   a[i]=i;
}

a[0]=0;
a[1]=1;
a[2]=2;

上の二つの実行結果は全く同じ
でもこれ何万回かループさせて時間を計るとわかるけどかかる時間が倍位違う
下は何もなくただ配列の三カ所に1つずつ代入するだけだけど
上は一回値を入れるたびに変数のインクリメントと条件の判定をしてる
まぁfor文の中でいろいろ処理してるんならそこまで差はでないだろうし並べて書くのも大変、
ループ回数がとんでもなく多かったり、そもそも変数で回数がかわったりしたら並べては書けない
そういうときは素直にfor分使えばいいんだけど上みたいなのとかは並べて書いた方がいい
それが何回も呼ばれる可能性があるならなおさら
んで、これ結構使っちゃってるんだよねぇ…
RGBそれぞれに同じ値かけたり、XYZそれぞれを足したり
そんなのが頻繁にあって全部上みたいなfor文使ってるわけだ

後は配列の初期化
これが普通に重い
メモリ食って頻繁にガベコレするからさらに重い
これもたくさん使ってるんだけど…
これをなくすのは結構難しいんだよなぁ…
for文は楽だから使ってるのが多いんだけど
こっちは必要だから作ってるのがほとんどだからなぁ

と、とりあえず上の二つをどうにかして少なくしようというわけで
まずどこを改良するのが一番効果的か
そりゃまぁ一番多く呼ばれてるところを改良するのが一番だわな
そうすると結局行き着くのが交差判定をするメソッド
んでそこをよく見たら無駄なfor文、配列の初期化の二つを併せ持つメソッドを4回も呼んでた
これは二点からベクトルを作るメソッドなんだけども
交差判定するには
視点→視線到達点、視点→頂点1、頂点1→頂点2、頂点1→頂点3
の4つのベクトルが必要
どれも消すわけにはいかない…
とりあえずfor文だけを書き直したら47秒強→45秒強と約2秒縮まった
あとはどうにかして配列の初期化を減らせないか…と考えてふと気づいた
上の4つのベクトル
全部メソッドが呼ばれるたびに作ってたけど
よく考えたら視点→視線到達点はどのポリゴンと判定しようとかわらないし
頂点1→頂点2、頂点1→頂点3も視点がかわろうとかわることはない
つまりその3つを先に計算しておけばこのメソッドで作らなきゃいけないのは
視点→頂点1のベクトルだけということになる
まぁ計算した値をずっと持ってる分メモリは食うだろうけど
そんな感じで改良した結果36秒台まで縮まり
他のところも頻繁に呼ばれてるfor文を削ったりした結果
最終的に34秒強まで縮めることができた
やっぱり見直してみるもんだね…
ちなみにVMの設定変えたりして試したときのモデルは11秒でできたよ

さて3割近く早くできたとはいえまだまだ時間がかかってるわけで
あとはどこを改良すればいいかね…
といってもレンダリング時間の大半を交差判定にかけてる以上
それとは関係ないところを改良しても大した効果は見込めないだろうなぁ…
スポンサーサイト
  1. 2009/06/30(火) 07:44:54|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

エクスポーター仮完成

一応Blenderからレンダラに移せるものについては全部書いた
ただBlenderじゃ定義されてないパラメータもあるから
今の段階だとまだ仮としか言えない
一応完成
具体的に今回書いたのはWorldのところと光源の影設定

さて、問題はここからだ
Blenderで定義されてるけどレンダラの方では使わないパラメータは
書き出さなきゃいいだけだから全く問題ない
ただその逆はどうしよう…
スムースグループやらこれからいろいろ追加するだろうパラメータは
Blenderで定義されてないものも多くなってくる
それをどうやってBlenderで書き出すか
一応テキストファイルで出力されるからそれを直接弄ることもできなくはないけど
果たして3つ頂点IDから目的のポリゴンを見つけることができるか…
それができたとして数千数万あるポリゴンすべてについてやる気力があるかどうか…
まず考えられるのが使わないパラメータの利用
アルファの合成方法の切り替えなんかはZTranspの値使ってもいいかなぁとか思ってる
ただ後はBlenderのコード弄るしかないだろうなぁ…
smoothの値もAPIを見ると"0以外なら頂点の法線を平均する"ってなってるけど
今のところ任意の値は設定できないし
Faceに新しいパラメータととEditingの画面に独自設定用のパネル追加して
そこで自由に弄れるようにするのが理想的
ってもビルドすらしたことないんだけどね…
てかパラメータ追加したらBlender標準の保存にも影響するじゃん
さすがに無謀すぎるか
もっとも保存に関してだけ言えばインポータ書いて独自形式使えばだけなんだけども
あとはスクリプトで値を変更して変更はそれ用のファイルに書き込み
それをエクスポート時もしくはレンダラインポート時に読み込んで使う
作るのも使うのも面倒だけどこれが一番現実的ではあるかな
ま、今すぐ必要になるわけじゃないしまた後で考えるか

そういえばレンダラ自体の設定はまだ書き出せるようにしてないんだよねぇ
サイズ、最大再帰回数、分割数、スレッド数などなど
あれstaticで設定してるから今はまだ関係ないけど
アニメーションをレンダリングできるようにしたとき
ファイル毎に設定が変えられると不都合が出てくる
んで、最終的なファイルの読み込み方を
レンダリング用ファイル:レンダリングの設定とフレーム毎のシーンファイルのパス
シーンファイル:オブジェクトやマテリアルなどなどの設定
でレンダリング用ファイルを読み込むようにするつもりだから
アニメーションを書き出せるようにしたときに一緒にやろうかなと
んでそのアニメーションは2.5から設定が今までのと互換性がなくなるという噂があって…
まぁフレーム毎に全部書き出すこれにはあんまり関係ないとは思うけど
2.5になってから書こうかなと思ってるから…
要するに後回し
  1. 2009/06/30(火) 02:41:12|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

1行文を追加しただけでスピードが3倍になった

前回のモデルを条件を変えてレンダリングしてみた
バウンディングボックスの判定とVMの設定を変えて
スレッド数は全部8、アンチエイリアスはなしでやった結果…
ボックス判定VM設定CPU使用率時間
なしデフォルト48%500s
なしモメリ増71%265s
ありデフォルト44%60s
ありメモリ増70%19s
これは…
最短と最長の差が25倍以上…
一番上なんてまだスレッド数が8でこれだからシングルスレッドだったらと思うと…
どうも初期設定だとメモリが小さくて頻繁にガベコレしてたみたいで
ヒープ領域増やしたらその頻度が大幅に減ったらしく2~3倍早くなった
CPUの使用率が全然あがんないなぁと思ってたけどこれが原因だったとは…
レンダリングするのにデフォルトのヒープじゃいくら何でも小さすぎか
てか初期2MB最大64MBって…思ってたよりずっと小さかったわ…
まぁVMってもその中でOS走らせてごちゃごちゃやるわけじゃないもんなぁ…

結構記事がたまってきたからレンダラはカテゴリ分けるかな
  1. 2009/06/28(日) 19:18:17|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その21

スクリプトを修正して四角形ポリゴンを三角形に2つに分割して書き出せるようにした
スクリプト修正
なんとなく前作ったものをレンダリング
やっぱりアンチエイリアスがなぁ…
でもまぁ見比べてみたけど角度によって違う気がする
てかスクリプト完成とか言ってレンダラ自体の設定とWorldの書き出し部分まだ作ってないや

さて、なんか無理矢理一段落したということにしてこれからの方針でも
というか今回はどっちかって言うとこっちの方が書きたかったこと
これを今後どういうものにしたいかと言うことなんだけど
簡単に言うとアニメに特化したレンダラ作りたい
トゥーン独特の違和感がないような感じのやつを
あとは髪の毛の手前に目を描く機能とかつけたりして
影響させる光源を決められたりすると顔と体の陰影のつき方の違いも解決できそう
とまぁいろいろと方法も含めて考えてみたんだけど
髪の毛の手前に目をかく機能:特別なパラメータ持たせてソート時に判定すればいいだけ
影響させる光源を決める:ポリゴンにそのリスト持たせるだけ
この辺は割と簡単にできそうだけど
線やシェーディングはレイトレよりむしろZバッファの方がやりやすい気がしてきた
レイトレは1ピクセル毎に計算してくから
となりのピクセルの影響を受けてどうとかって処理がやりにくいんだよねぇ…
フィルタとかの後処理だと限界が…
んで、じゃあピクセルバッファ使ってポリゴンのIDやらZ値やら透過の過程やら全部記録して
後からそれをもとにいろんな処理をしていけばいいじゃん!とか考えたけど…
メモリが…
縦×横×サンプリング数×最大再帰回数×バッファ一つ分
個人的にHD出力までできてほしいから縦横は1920×1080
最大再帰回数はそのシーンの半透明物体や鏡の個数にもよるけど最大だと最低5回は欲しい
バッファ一つ分はintが4バイト、doubleがその倍で持たせるものを考えると32位は…
となるとアンチエイリアスをかけなかったとしても
1920×1080×1×5×32B≒320MB
さんびゃく…にじゅう…めが…ばい…と……だと…?
2×2でアンチエイリアスかけたらギガ単位じゃないか
てか書いてる途中で勘違いに気づいたけど
最初メガの存在を完全に忘れて考えてたから300ギガかと思ってかなり焦った
まぁ300MBでも十分でかすぎるんだけどね
VMの設定ちゃんとやらないとこれだけで確実に飛ぶし
ポインタのサイズ考えてないから実際はもっとでかいし
やっぱり現実的じゃないのかなぁ…
でもZバッファでやるにしてもアルファブレンディングとかしようと思ったら
結局でかいバッファ持たなきゃいけないだろうからどっちもどっちなんかなぁ
エッジの描画に関してはZバッファの方が良さそうな気はするけどね
レイトレ→Zバッファでエッジの描画→全部のバッファをもとに処理
って流れが良さそうかなぁ
やるかどうかはまだちょっとわからないけどね

それにしても本当にあの違和感って何なんだろう
某休日朝のアニメ見てると2D作画と3D作画の違いがよくわかる
一番は服のシワや髪の毛の陰影ハイライトあたりか?
後はアニメ絵独特の空気感というかなんというか…
その辺をうまく改善できるようなレンダラが作りたいなぁ
まぁレンダリングの前に勢いのある動きでも全く歪まないモデルとか
無駄に細かく動くモーションなんかも原因ではあるとは思うんだけど…
あーいやそれがほとんどなのかなぁ…

てかあのアニメは教育上どうなのよ…
いや、何とは言わんが…
  1. 2009/06/28(日) 03:25:57|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その20

法線マップの式を修正
スレッドの制御をExecutorを使うように修正
バウンディングボックスでの交差判定を追加
修正
バウンディングボックスでの判定を追加したおかげでスピードは倍に
さらにExecutorを使ったおかげで分割数>最大スレッド数でも処理が重くならなくなった
時間がかかってるのはほとんど球体の周辺
もう少しポリゴン単位とかで判定したいんだけどあんまり式複雑にしたら意味ないし…
はじめに透視変換しておくと再帰が使えなくなるし…
Javaだからとか言い訳したところでどうしようもないしなぁ
JOGLにGPGPU…よりはまだ先にやることがあるわな
なにか考えるか…

ちなみに今回はアンチエイリアスをかけて…
あれ…?
これ…かけてるんだけど……あれ……?
方式見直すかな…
  1. 2009/06/27(土) 01:13:33|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その19

エクスポート用スクリプト完成
前回同様ちゃんとかけてるかどうかのチェック
チェック
どっちもフォトショで縮小済み
とりあえずエクスポートはうまくいってる
が…今度は本体の方の問題がいろいろと出てきた
まずノーマルマップの式がまだ間違ってる
次に多分間違ってるわけじゃないんだけどやり方の関係でスムースが奇麗にできてない
最後に一番問題なのがレンダリングの速度
そりゃ自分の作ったプログラムだし遅いのは覚悟してたが
まさか上のやつで2分以上かかかるとかもうね
多分交差判定の部分なんだよなぁ…
バウンディングボックスでの判定なんて必要ないだろとか思ってたけどそんなことなかったわ
  1. 2009/06/24(水) 20:29:29|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

3周年で4年目突入、そして成人

さて何となく始めたこのブログももう4年目に突入ですよ
この1年は…
壮大な黒歴史を晒したこと位でその他は平常運転
いろいろ手をつけては投げ出して
といっても今までよりはまともになったかなぁ
まぁ一応記事を作ってはみたけど特に書くこともないです

あとは毎年のごとく昨日誕生日でしたと
20歳ですよ、成人ですよ
ほんとは喜ばなきゃいけないんだろうけど
どちらかというとすごい鬱ですわ
関係ないことなんでそれについては書きませんけどね

そういえば初めて自分で酒買って飲んだけど…
あんまりおいしいもんじゃないね、ジュースの方がいいや
  1. 2009/06/22(月) 00:20:35|
  2. お知らせ・管理など
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その18

めんどくさくて今まで後回しにしてきたところにようやく手を付けました
他のソフトとのデータのやり取りです
まぁ他のソフトと言っても要するにBlenderなんですけどね

既存のファイル形式だと面倒だったり変数の過不足があったりするんでまたオリジナル形式
仕様を決めてそれに合わせてインポートするためのメソッド書いて
Blenderの方ではAPIを見ながらエクスポート用のpythonスクリプトを書くと
いやーJava…というかEclipseの偉大さを痛感するわ
そんな感じで書いた成果がこれ
比較
重ねて見るとほとんど違いがわからない
もっともわからないような設定にしてるんだけど
オーバーサンプリングをオンにしたら全然違うし
光源の減衰とかまだ実装できてないのもいろいろあるからね
とりあえずデータの移動がちゃんとできてるかどうか見るだけ
そもそも最終的に同じだったら自作する意味なんて全くないわけで…
  1. 2009/06/21(日) 03:46:52|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その17

マルチスレッド化
マルチスレッド
Blenderの内蔵レンダラのように縦横の分割とスレッド数を決められるようにした

んだが…
あんまり早くならないなぁ…
というかCPUの使用率見てもスレッド数増やした効果があまり見られない…
いや、一応分割数とスレッド数を合わせると4割位早くはなるんだけどもさ
  1. 2009/06/16(火) 22:37:16|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

カイエントークン

遊戯王関係

どうやったって公式のカイエントークンは存在しない
だったら自作で満足するしかねぇ
その自作で出来のいいものを作って満足しようぜ!

---追記(10/9/26)---
そういえば公式のカイエントークンできたね
ってもあれじゃやっぱり手に入らないけど
---追記ここまで---

てかマジでトークンパック的なもの作れよ
羊も綿毛もプロモだし効果やステータスみたいな説明はないし

まぁそんなわけでイラストから描いた
冥府の使者カイエン
がんばって描ける人風に描いたよ!
でもほぼ正面から+光源どこよ?+その他諸々で典型的な描けない人の絵

カード化は追記の方で

[カイエントークン]の続きを読む
  1. 2009/06/14(日) 10:53:26|
  2. 二次元
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その16

全反射を実装
全反射…?
…できたのかなぁ…
屈折の式から不正な値が出た場合を全反射として書いてみたけど…

てかそれよりもソースが完全にスパゲッティ…
もうヤバいって
コメント書いてどうにかなる問題じゃないって

あとはあれだなぁ
変に新しいオブジェクト定義しないで素直にポリゴンで実装すりゃよかったなと
いや、まぁ後々こっちの方がやりやすいことも出てくるとは思うんだけどね…
  1. 2009/06/10(水) 09:13:57|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その15

前回追加した機能を拡張
濃さで色を変えるようにした
濃度で色変え
これで何がしたかったのかというとビームやらライトセイバーやらの表現
炎や煙とかもこれ使えばできそう
Haloの実装どうしようかと思ってたけどこれあればいらないかもなぁ
  1. 2009/06/09(火) 18:39:18|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その14

ポリヘドロンモデル(仮…以下略)にアルファ値を持たせてみたりとか
後はアルファの合成方法と連動して影の落ち方も切り替え可能にした
アルファとか
なんかゼリーっぽい
これまだ光源とか全然意識してないんだよねぇ…
こいつが光源の影響を受けるようにしようとすると
屈折とかの関係上フォトンマップ的なことをやらなきゃいけないわけで…
しかもそれやるにしても中身が受けた影響を持たせるバッファとか馬鹿にならないし…
なんか考えなきゃ…

影の切り替えの方はアレだよ
色付きの煙でも影には色つかないでしょ?ってこと
…ん?あれ?あってるよね?
まぁ違ったらまた変数増やして指定できるようにするだけだよ

つーかこのポリヘドロンモデル(仮)ってなんていうんだろ
ソリッドモデルの一種だとは思うんだけど名前ないのかなぁ
  1. 2009/06/08(月) 13:21:31|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その13

屈折の式直したよ…
修正
何が間違っていたかというと
・屈折の式で絶対値でなければいけないところがあってそこがおかしかった
・屈折の式で出てくるのはベクトルなのにそれをそのまま次の点にしていた(オフセット無視)
・判定ミスでスムージングしないはずのところまですべて滑らかにしようとしていた
後なんかまだあったような気がするけどこんなところ
いやーまぁなんと言うか…うん…

それと上を修正した後でた問題
こいつで今回結構手間取った…
最後の難所
どうも二回に一回屈折できてない…わけじゃないんだがなんかおかしくなるみたいで
なぜか表面にスムージングかけると何ともない
なんでかなぁと結構悩んだんだけど
屈折の式で法線を見るとき、裏側からのときは法線をひっくり返して渡さなきゃいけなくて
そのために法線の値にマイナスをかけてたんだけど…
あれだよ、Javaでは隠されてるけど意識しなきゃいけないあれ
ポインタ
参照型と値型の違いが…ね…
法線は面クラス内の法線を計算するメソッドからもらってくるんだけど
スムージングしないときは面の法線をそのままもらってくるようになっていて
そのとき値型の様な代入の仕方をしてその法線配列のポインタをそのまま返し
屈折するたびに法線がクルックルひっくり返っていたと…
はぁ…
配列をあっちこっち渡してるから結構気をつけてはいたんだけどなぁ…
  1. 2009/06/06(土) 23:37:09|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その12

今回は結構大規模改装
前回ちょっと言ってたポリヘドロンモデル(仮…というかあるんだろうけど名前知らない)の実装
そしてその実装のためにRenderableインターフェイスを作成
さらにそれに合わせて+屈折、反射を再帰的に計算できるようにメソッドをいろいろ変更

その結果がこれ
いろいろ変更
なんか屈折が表現できてる風
風…というのもこれオブジェクト置いたところが歪んで屈折してるように見えるんだけど
何となくそう見えてるだけでいろいろとおかしい
あの屈折してるように見えるところにあるオブジェクト、屈折率は背景と一緒
つまり屈折して見えるわけないのにしてるように見えてるというわけ
原因は十中八九屈折を計算してるメソッド
ネットで見つけた数式を実装してみたんだけど…
あ、あれ…?なんかデジャビュ…
前のもそうだけど式が間違ってるんじゃなくて実装の仕方が間違ってるんだとは思うが…
まぁあれだ、やっぱり自分が理解してない数式を使っちゃだめってことだね、うん
  1. 2009/06/06(土) 19:39:52|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その11

アンチエイリアスを実装
アンチエイリアス
保存時のアルファとは未だ格闘中
背景とオブジェクトの境目が白っぽいのもその影響

後やっぱり半透明がどうしても…
半透明のものを考えるときに問題になるのがその中身
不透明なものは中が見えないから表面だけ表せれば全く問題ないけど
半透明なものは中が見える
ただポリゴンモデルだと面しか表せない上にぺらぺらの物体すら作れてしまう
そうなると4面体を1つの単位としたポリヘドロンモデル的なものを定義した方がいいのかもしれないなぁ
そうすればペラペラな物体が作られることもないし
uvにwでも加えれば内部に立体テクスチャを使うこともできる
まぁデータ量がばかでかくなる上に計算時間がかかって
それに見合うだけの結果が出てくるかどうかはかなり怪しいけど
  1. 2009/06/05(金) 16:25:47|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その10

アンビエントを実装
アルファの計算方法、影を落とすかどうか、影が落ちるかどうかを
マテリアル毎に切り替え可能に
細かいところを実装
全体的に青っぽいのはアンビエントの影響
アルファの合成方法を切り替えられるようにしたのは
ビームやスモークみたいなものを半透明のオブジェクトで表現できるようにするため
そういや同じ半透明でもいろいろあったんだっけなぁ
  1. 2009/06/05(金) 06:04:08|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その9

いろいろ悩んだ末とりあえずアルファ関係を修正
さらに修正
結局のところRGBAだけで半透明をリアルに表現しようなんてのがそもそもの間違いで…
多分RGBそれぞれに反射、吸収、透過のパラメータを持たせればそれなりにうまくいくんだろうけど
そんなことしたら今度はなかなか思った色を作れないだろうし…

んでまぁ今回どういう仕様にしたかというと
アルファ=光を反射吸収する割合
RGB値とアルファ値からRGBそれぞれの光の透過率を計算
それをもとにRGBごとに合成
という感じ
赤でアルファ値が66%の場合
赤い光だけを完全に透過して
黒い背景の前では黒くて見えず
白い背景の前では真っ赤
と、普通のソフトとはちょっと違った感じになる(設定次第だとは思うけど
っても現実ではこっちの方が近い気がするんだけどねぇ
赤いセロファン通して青いもの見たら紫に見えるか?って話
まぁ切り替えられるならそれにこしたことはないんだけど

ちなみに出力の方のアルファは相変わらず
やっぱりアルファはRGB毎にあるべきだと思うんだよなぁ…
  1. 2009/06/04(木) 07:35:22|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その8

アプレットからJavaアプリケーションに変更
レンダリング結果を保存できるようにした

のはどうだっていいよもう
それよりもかなり致命的な問題を発見
透明度
この赤い半透明の面と緑色の面
設定では全く同じ色なんだよね…
なんでこんな問題が起こったかというと
あの透明度の計算方法を変更したのが原因で…
もともとアレは光源からの光に対してのものだったんだけど
それをちょっと応用すれば視点でも使えるかもと思ったのが間違いだったのかなぁ

追記
というわけで修正
修正
多分これで大丈夫なはず
――さらに追記――
やっぱり大丈夫じゃなかったあああああああああ
あぁもうどうすりゃいいんだよ…
――追記ここまで――
ちなみに奥の左側にある面の色とか中央のオブジェクトの色とかが違うのは
設定変えてるだけだから今回の問題とは全く関係ないよ
と一応書いておく

ついでにファイルの保存
アルファも書き出すようになってるけど
半透明のものは二重にアルファをかけたようになってちゃんと色が出せなかったりする

あぁ…
やっぱり透明度っていろいろめんどくさい…
  1. 2009/06/04(木) 05:08:11|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラ その7

かげのでき方がおかしくなる場合があったので改良
かげ改良
影を出さないときは問題なかったんだけど
影を出したとき光源の位置や面によって陰がおかしなことになってた
右側がどういうことになってるかを説明すると
イメージ図
また雑でわかりにくい図だけど…
赤がスムージング後の面のイメージで、黒が実際の面、黄色が光
スムージングしたところで実際に形が変わるわけではないので
光が当たらなきゃいけないところと実際にあたるところが合わなくなるというわけ
そもそもこんな鋭い角スムージングしようとするなという感じもするけど
鈍い角でも目立たないにしても起こりうることだと思うから一応ね

んでどうやって直したかというと
単純に点を共有してる面同士は影を落とさないように変えた
これで完全に回避できるかどうかは怪しいけど今までのよりはマシなはず
ちなみに
今度は影できなきゃいけないところに影できなくなるんじゃね?
というのは多分大丈夫
まぁ駄目だったら元に戻すだけだよ
  1. 2009/06/03(水) 08:48:01|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0
次のページ

プロフィール

トック

Author:トック

プロフィール(仮)

twitter:elgraiv_took
└ブログ更新情報

twitter:elgraiv_take
└無駄な日常つぶやき用

FC2カウンター

コンテンツ一覧

本棚

最近の記事

カテゴリー

月別アーカイブ

ブログ内検索

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。