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

スポンサーサイト

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

久々のZバッファ法

Zバッファ
上は単なるスクショ
ポリ数1万超でも去年作ったやつよりは動きがマシになった
ってもできる限り処理を軽くしたつもりだけどやっぱりかなりカクカク
まぁ去年のは三角形数枚で今よりひどかったからそれに比べたらかなりの進歩

データの構造やファイルのインポート部分はレンダラからの流用だから
オリジナル形式ではあるけどちゃんと使用可能
まぁ使えるパラメータは限られてるけどね

うーん…
多分ループ回すときのキャストで値に誤差が出るのか結構汚いなぁ…
1ピクセル分になるかどうかの小さなポリゴンがあるのも原因ではあると思うけど
その辺の処理もちゃんとやってこそだよね…

ちなみに下の方のスクロールバーは動かしても全く反応しない
カメラ回転とか今は画面ドラッグでするようにしてある
  1. 2010/05/22(土) 00:28:30|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

今日の夜中やったこと

・基本的なクラスの宣言
・可変長配列の実装
・配列、行列系の構造体定義
・頂点、面のメンバ宣言

うん、ほとんどやってない
いやまぁ可変長配列の実装でまたいろいろと言語的な壁に……
vector?うーん……
さらっと調べたけど自分で書いた方がいろいろ応用が利きそうでね

また今日実家帰るけどソースは持っていくから進める
…かどうかはわからん
いつも持ってくだけ持っていってやらないし
  1. 2010/03/25(木) 07:17:17|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

ようやく書き直し始めた

今までC++の勝手がよく分からなかったから全然進めてなかったけど
今日ようやく書き始めた
今まで
class A{
B b;
}
class B{
A a;
}
的な構造すらどう書けばいいかわからなかったから
そこで結構躓いてたのよね
Javaはホントに楽だったよ……
上のでコンパイラ通るんだからね……
ファイル分けても修正する必要ないし……

いやーそれにしてもどこから手を付けていいかわからんね
いろいろと弄ってきたから全く使われてない無駄なコードが各所にあったり
コメントもほとんどつけない上に変数名も略しまくって読み辛かったり
なんでこんな書き方したのか理解できないところがあったり
今はちゃんとコメントつけながら書いてるよ
クラス名変数名もちゃんとわかる程度にはしてるし

そもそもコードの量がそれなりにあるからね…っても数千行だけど
まぁ考えながらとはいえ基本的な部分だけでも詰めて3ヶ月位はかかって書いたものだし
そんな一日二日で移植できるもんじゃないけどさ

うーん……
やっぱ書いたところで機能が増えるわけじゃないから
モチベーション保つのがむずかしいなぁ
  1. 2010/03/24(水) 23:40:54|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

またメモ

無駄機能を追加してる過程で気付いたことをちょっとメモ

まず影の計算方法がおかしい
今ソース見られないからはっきりとは言えないけど記憶をたどって推測すると
どうやらバッファに書き込むときと最終的な計算時の2か所でおかしなかとやってるみたい
あとポリゴンの裏面の扱いが結構怪しい
たぶん影の計算にもこいつが絡んでるような気がする

それとミップマップ的なものをどうしようか考えてたけど
バッファにUVを書き込んでおけば近傍ピクセルのUVとの差分が分かるから
それをもとにサンプリングすれば何とかいけそう

どっちも結局前に書いたバッファの改良をしないことにはどうしようもないから
今すぐどうのってのはできなさそうだなぁ

まぁ今のうちにわかる範囲でいろんな問題点を見つけておくってのもありはありか
言い訳っぽいけどね
だってC++よくわからんのだもん……
  1. 2010/03/21(日) 01:06:23|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

バッファを小さくする

軽くメモ
今まで全ピクセルのディフューズ、スペキュラ、影などなど求めてから全部をバッファに入れてたけど
交差判定だけしておいてフェイスのIDと交点の座標とフラグをいくつかだけバッファに格納して
領域分けをした後に輝度の計算した方がメモリの容量は少なくて済むし多分今までと同じことができる
シェーダ別に必要な情報が違えばそれに応じていろいろな情報をとることもできるから
バッファの容量を増やさずにできる処理は増えるはず

まぁ実装はいつするかわからないけど
だからメモ
  1. 2010/01/28(木) 17:05:58|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

シェーダ管理の修正

前回のやつを見直してさすがにあれじゃ頭悪すぎるだろうということで修正
値を持たせるわけでもなく関数ポインタみたいに使うとかいっておいて全部newするとかないわな
というわけで書き直し
public class ShaderControl {
public static ShaderPri getShader(String name){
ShaderName sn=ShaderName.COMMON;
try{
sn=ShaderName.valueOf(name);
}catch(IllegalArgumentException e){}

return sn.GetShader();
}
}
public enum ShaderName {
COMMON(new ComSh()),
SKIN(new SkinSh()),
HAIR(new HairSh());

private ShaderPri sh;
ShaderName(ShaderPri pr){
sh=pr;
}
public ShaderPri GetShader(){
return sh;
}
}

これで少しはマシになったはず
  1. 2009/12/19(土) 21:42:48|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

球状レンダリング

というのかどうかわからないけど
背景とかに使うようなぐるっと見たような感じのあれ
球状
モデルデータは学校で使おうと思ってるやつ

プログラム自体はほとんど今までのを流用というかそのまま使って
スタートのところを変えただけ
  1. 2009/12/17(木) 09:10:53|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

そろそろシェーディングの部分を

作ろうかと思うけどその前にプログラムの構造を少し考えようと
んでまぁ肌、髪の毛、その他でいろいろとシェーディングの仕方を変えようとしたときに
シェーディング用のインターフェイスを作ってそれを実装したクラスを作れば管理が楽じゃないかと
まぁ友達が同じようなことやってたけど考え方の元は
先生にCでのメモリ管理について聞きにいったときにちらっと話してた
Javaでも関数ポインタと同じようなことができるんだよ的な話
これ知らなかった時期は毎回if文やswitch文で分けてたよ…
もっとも今回のプログラムはそう頻繁に呼ぶわけじゃないから真価は発揮しないと思うけどね
今回は少し実際のコード的なところも触れていこうかと
理由はないよ!本当だよ!
かなり長いから追記で

それと注意
・クラス名や変数名はかなり適当(基本略しまくり,スペルミス上等)だけど突っ込まない
・実際に使う状態で動かしてないからちゃんと思った通りになってるかはわからない(コンパイラには通るレベル
・Javaの解説の間違いは許せないレベルじゃない限りスルーしてくれるとうれしい

[そろそろシェーディングの部分を]の続きを読む
  1. 2009/12/09(水) 22:14:44|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

C++で書き直す

今までJavaで書いてたけどやっぱりC++で書き直そうかと
まぁ書き直したところでスピードが出るかどうかはわからないけど
Javaだと不便なところもいろいろとあって…

ただ移植するのに障害もいろいろとあってね…
やっぱりJavaのAPIってのは便利なのがそろってるから…
  1. 2009/11/25(水) 01:29:40|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

エッジ判定のゆとり

とりあえず画像を見てもらった方が早いかなと
改良
赤で○をつけたところが主な直ったところ
さぁこれでホントにエッジ描画に関しては一段落かな?
あぁいや一応手描き風に見せる為に線にムラを出すようにしようかとかも考えてたんだっけ
まぁそれでもとりあえずは一段落か
  1. 2009/11/16(月) 00:14:26|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

エッジ描画速度向上

改良
エッジ描画が少し早くなった
改良前:43秒→改良後:26秒
ただこれはものによるかなぁ…
状況によっては前の方法より時間がかかる可能性がある
それと相変わらず結構いい加減な方法使ってるから少し不安
ここから早くするにはまず言語を変えるとか…
ただそうすると画像IOと表示関係が面倒だし
やったとしてもJNIを使ってみる位かなぁ…
それで早くなるのかはわからんけど

追記
まぁちょっといろいろ試してみたけど細かいところにJNI使っても変数の参照が大変で逆に遅い
ただ配列を作る→それを元に計算の流れを繰り返しさせたらC++の方が早かったからやっぱり差はある
プログラムの中は配列操作ばっかりやってるから全体的に書き直せばもしかしたら早くなるかも
もっとも配列使わないのが一番いいんだけどね…
んー…てことは起動部分と描画部分とファイルIO部分をJavaで書いて
後の部分をC++で書き直してJNI使えば少しは早くなるのかな?
まぁアルゴリズムを見直した方がいいのはわかるし
Javaもいいわけに使えるほど遅いわけじゃないんだけども
やっぱりC++使えた方が便利なんだよねいろいろと
  1. 2009/11/06(金) 07:33:57|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

ようやく修正完了

修正の記録
1:前回のやつからまたアルファの合成式を修正
 結局まだ間違ってたのよ…
2:1のやつにエッジがぴったり重なってる所をはじくようにしたもの
 こうしないと重なってるところが変に濃くなる
 もとから作るつもりだったんだけどなくてもいいかなと思ったらそんなことなかった
3:2の判定が間違ってたからそこを修正
 うん、ちょっと勘違いしてただけ
4:判定をするの順番と言うか場所を変えた
 3のキャノピーのあたりがおかしくなってたんだけど
 A(交差判定の結果描かない、重なり判定でBと重なる:描く)
 B(交差判定の結果描く、重なり判定でAと重なる:描かない)
 があったとすると(2点はかなり近いけど微妙に位置が違う)
 今までは重なり判定→交差判定の順でやってて上の例だと何も描かないことになるんだけど
 普通に考えたら描くのが本当だろうと
 まぁ多分上の例では理解できないと思うけどそんなこんなでそこを修正

んでだ、ここまではよかった
割とスムーズに解決できた
問題はこの後
4を見るとわかるけどやっぱり線がおかしい
これがどうしてもわからなくてねぇ…
あるピクセルのところでいろんな数値を出力させて原因を探ったわけさ
そしたらなんかよくわからんNaNが大量に出てて
さらにエッジの持つ頂点の中の数値まで見たら
どうもIDは違うんだけど座標が全く同じ点が大量にあって…
そのせいで長さ0のエッジができてそれが原因らしいと
で結局何が悪かったかというともとのモデルデータの頂点のマージをしてなかったことが…
まぁそれをはじかないのも問題っちゃ問題なんだけども
モデルデータを修正したらいけた

そしてその成果がこれ
今回の成果
よし、これで大丈夫かな
と言いたいんだけどまだちょっと気になるところあるんだよねぇ…
羽の付け根とか…
弄るところは目星ついてるからどうでもいいんだけど

ちなみにモデルデータを修正しただけでエッジの描画時間が約860秒から約30秒に縮んだ
要するに極端に時間がかかってたのもそれが原因だったと…
そうだよなぁ…さすがにキャラの数十倍かかるとかなんかおかしいとは思ったんだよ…
  1. 2009/10/28(水) 03:06:02|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

もはや何がなんだかわからない

前回弄ったところを元に戻して時間計測もかねてレンダリングしてみたんだけど
え…?
いやもう何がなんだかさっぱりだよ
え?なになんでこんなことになってんの?
これ下手したら前回のやつのがまだマシじゃね?
どこ確認すりゃいいんだろうなぁ…

ちなみに描画時間はエッジだけで862秒
まぁ1時間コースだったノーパソよりマシだけどさすがにないわ
  1. 2009/10/27(火) 20:55:47|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

また速度を上げるためのなんたら

前回完成したエッジ描画何だけども…
やっぱり遅すぎて使い物にならない
ということが判明しまして…

もっともアルゴリズム考えてる段階である程度は覚悟してたわけで
まぁ自分が使うのに問題ないレベルなら少し位遅かろうがかまわなかったんだけども…
例
なつかしいね
これを描画するのに約8分
内エッジ描画にかかる時間約5分
まぁ2コアのノートPCでやったからってのもあるけど
さすがにこれはヤバいだろうと…

いろいろと判定を改良したてエッジ描画部分を3分未満に縮めてみたんだが
どうしてこうなった
え…?いや、なんっつーか意味わからん
変えた方法ってのは過去に仮として使ってた方法を使って
あらかじめ描く必要のない辺をはじいてから前回の方法で描く
というだけで描画する部分は一切弄ってないはずなんだが…
んー…過去のところで頂点座標を直接触ってるところがあるのか?
ただ一部はちゃんと描けてるってのも怪しいよなぁ…

ちなみに二番目の画像のやつ
前回の方法でノーパソで描こうとしたら一時間以上かかりそうな勢いだったから途中でやめた
今回の+いつも使ってるMacで24秒(エッジ部分は12秒)
モデルも微妙に違うし方法ももちろん差があるんだけど
それにしたって思ったよりスペック差ってでかいなぁ…
  1. 2009/10/27(火) 11:54:46|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

エッジのアルファブレンディング修正

修正
なんてことはない
ただ単に最後もとの画像と合成する時にアルファを余計にかけてただけだった
これで今のところエッジの方は一時完成と見てもいいかな
個別に色指定、幅指定するにはエクスポーターから書き直さなきゃいけないし

いよいよシェーディングか…
塗り分けのシステムは途中まではできてるから問題はどうやって値を使うかだな
単に輝度のしきい値で二値化するだけならわざわざ自作しようと思わないし
分けた領域内での輝度の分散やら偏差やらをとって…統計苦手なんだよなぁ…
陰と影は別に計算した方がよくて環境光がは…んー…
肌、髪、その他でやり方を分けるのも手か…?
まぁぶっちゃけこの辺はリアル系と違うから何でもありっちゃありなんだけどね
  1. 2009/10/21(水) 16:20:06|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

エッジの角

角のところ
角度によって丸くするか尖らせるか決められるようにした
というか前回の段階で実装してたつもりだったんだけど
判定とか普通に間違っててできてなかった

しかしエッジは時間かかったなぁ
まずアルゴリズムを考えるのにかなり苦労した
そんでもってそれをコードに直すが思ってたより大変で
書き終わっても途中で部分部分のチェックができなかったからバグだらけ
その間違い探しをするのにまたこう…
文字列出力を使ってそこに到達してるか、変数の値はどうなってるかをチェック
そんでおかしいところを見つけて直すと
他にも間違いあることが発覚してまたチェックの繰り返し
画面全体がエッジで真っ黒になったときはどうしようかと思った

まぁまだアルファ合成の部分の修正してないんだけど

そういえば今回のと前回のはわかりやすいようにシェーディングは切ってるよ一応
  1. 2009/10/20(火) 09:15:43|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

久々のレンダラ

エッジを描画する部分がようやく形になった
エッジ描画
太さももちろん調節できるし
アンチエイリアスも…んー…
どうもアルファ合成がうまくいってないな…
  1. 2009/10/20(火) 06:42:58|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

エッジがおかしい

高頻度の更新が少し続いた後しばらく音沙汰なしはいつものこと
今回は別なことをいろいろやってたのよ

それはさておき
Blenderの方でもアニメーション用のエクスポーターを書いて
ようやくアニメーションの出力ができるようになったんだけども
試しにレンダリングしてみたものでトラブル発生
黒い線が…
いや、ポーズがださいとかそういうことじゃないよ?
なんか黒い線が入るんだよね…
ちなみにあと背景が黄色いのは見やすいように編集しただけ

アニメーションだから他のコマも見てみたけど、こうなるのには条件があるみたいで…
このシーンを別の角度から見てみると
シーン
こうなってるんだけども(アクティブになってるのがカメラね
どうやら右下のドローン(初代)がカメラの横に来たときになるらしい
んでどうやらこれはドローンのエッジらしいんだが…
確かにエッジの座標変換が怪しいのはあるんだけど
さすがにこのレベルは確実にどこかおかしい

というわけで原因を探ったんだけど…
どうやらこういうことらしい
図解
んでまぁちょっとその部分を弄ったらまぁなおりましたと
オチはないよ

ただ一応直ったのはのはいいんだけども
今回に近い状態でちゃんとレンダリングできるようになったのかは怪しいかな
  1. 2009/08/11(火) 05:49:08|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

アニメーションをレンダリングできるようになったよ!

サムネクリックで拡大して再生
アニメーション
連番ファイルを読み込んで連番画像を出力してるだけだから
バッチ処理みたいなもんなんだけどね
あとはこれに合わせてエクスポータ書かないと…
  1. 2009/08/06(木) 06:13:36|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

ボーン入れたのをレンダリング

ボーンのウェイトとかちゃんと正しく計算できてるかのチェック
って言ってもレンダラというよりエクスポータのテストだけど
比較用に右側が内蔵レンダラで普通にレンダリングしたもの
自作の方内蔵レンダラ
カーブは書き出せないから坊主
前のやつはちゃんとメッシュに直してたのよ
とりあえず合ってるんじゃないかな
CopyLocationとかもそのままで大丈夫みたいだし

ちゃんと服着せたよ!
テクスチャ貼っただけだけどな!
でもこれだけでずいぶん違う不思議

うーん…
Blender内蔵の方なんだけど
どうもアルファ値付きのテクスチャ貼ったときに
透明の部分は元のマテリアルの色が見えるんだけども
その不透明と透明の境界部分が変になってるんだよなぁ…
  1. 2009/08/06(木) 01:10:38|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0
前のページ 次のページ

プロフィール

トック

Author:トック

プロフィール(仮)

twitter:elgraiv_took
└ブログ更新情報

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

FC2カウンター

コンテンツ一覧

本棚

最近の記事

カテゴリー

月別アーカイブ

ブログ内検索

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