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

スポンサーサイト

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

レンダラ進捗20150823

進捗20150823
前回はスケルトンが影響を与える範囲のボリュームを可視化しただけだったけど
今回はそこから実際に髪の毛かどうかの判定を加えた

のだけどやっぱりうまくいかんね
まぁそんな簡単にうまくいってしまったら院生時代何やってたんだって話なんだけどさ
近づいてはきたけどここから解決策が浮かんでない部分がいくつかあるから
使えるようになるまではまだまだかかるかな……
スポンサーサイト
  1. 2015/08/23(日) 03:18:42|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

レンダラ進捗20150816

進捗20150816
とりあえずボリュームを作るところが一応出来て
そのボリュームを適当に可視化してみたというだけ
色は適当にデプス値

ようやくここまで来たけど
これでもまだスタート地点に立ったぐらいのもんだからね

思えば修論時点のアルゴリズムって
骨の繋ぎ目周辺に出るアーティファクトと
分け目がいかにもメタボールですという感じに丸まってたのを除けば
そこそこちゃんと出来てたなぁ
……とも思ったけど
逆に何ができてるって骨同士ブレンドだけだからやっぱ微妙か
  1. 2015/08/16(日) 20:10:12|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

レンダラの現在の進捗

画像がない更新って解説記事以外ではできるだけしたくないのだけど
まぁ1ヶ月広告でてしまったし
何か他に出せる画像もないので仕方なく現状を

・ポリゴンの交差判定はできた
・適当BVHも実装した
・Blender側の髪の毛のスクリプトとエクスポータはできた
・髪の毛のデータのインポート自体はできた
・髪の毛をレンダリングするときの中間データになるボリューム構造も定義はできた
・ボリュームの作成がまだ
・ボリュームを作ったあとどういい感じになるように処理するかが全く
・シェーディング……?

来月当たりにはレンダリングしたい(願望)
  1. 2015/07/31(金) 00:26:32|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

レンダラの進捗報告

何度見たかわからない恒例の法線出力
レンダラ進捗20150520
とりあえず適当BVHでまぁ一応許容範囲としたいスピードに
あと法線出力だけど一応シェーディングの処理はこの先実装するシェーダと同じ仕組で動いてるから

んでとりあえずこの先は髪の毛のレンダリングを優先して実装するつもりでいるけど
まずBlenderの方でそれ用の構造を作れるようにしないと……
と準備をしていたのだけど
どうも頂点には新しいプロパティを追加できないようで
やっぱりBoneか……
  1. 2015/05/20(水) 01:16:21|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

自作レンダラがBlenderから使えるようになった

さぁ,何個目かのレンダラ
今まではシーンデータをスクリプト画面からエクスポートスクリプトを起動して書き出して
そのあとコマンドラインからそのファイルを読むようにレンダラを起動するという方法で使ってたけど
そろそろBlender上から直接使えるようにしたいよねということで
今回はAddonを作った
レンダリング結果
まぁ結局ファイルを出力してスタンドアロンのレンダラが動くのは変わらんのだけどね

さてようやく実行できた
交点判定とかスレッド制御とか全く動かしてなかったけど
まぁ散々書いただけあってか運がよかっただけか
とりあえず特に問題なく動いてよかったわ

といってもまだこれが今実装されてる機能の全部だけどね
なんとBVHはおろかAABBすら使っていない
シェーダも存在しない
当然髪の毛のレンダリングなんて実装できていない
ここから何を優先的に実装していこうか……
  1. 2015/04/30(木) 00:19:01|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

ノンフォトな髪の毛

ノンフォトな髪の毛
ひとまず修論のやつを載せてみる
まぁ理由は1ヶ月更新してません広告出ちゃったからってだけだけど
いや確かに記事の日付1/1になってるけど更新自体は1週間以上たってたきがするだけどなぁ
このへんは向こうの都合のいいような条件設定になってる気がして非常にアレ
  1. 2014/01/31(金) 21:32:32|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

1時間で何かをレンダリングするレンダラ

メガデモ界隈でレイトレの波が来てるから合宿しようぜ
ということで企画されたレイトレ合宿に参加
といっても現地に行かないでレンダラを提出するだけのリモート参加だけどね

本当は一時間でレンダリングするものだけど
とりあえずかけられるだけ時間をかけてレンダリングしたのが下
レンダリング結果
解説というか何やってるかは上のリンクから辿れるスライドに書いた
ちなみにAA実装するの面倒臭がってもとは2560x1920でレンダリングしてる

まぁコンペの結果は正直どうでもいいとして
今回ので今まで書いた中では一番まともなレンダラができた
一応それなりに拡張できるように組んだつもりだから
これをベースに自分用のレンダラを開発していこうかなぁと

問題はノイズだけど……
まぁ正直GI使わなきゃいけないようなものレンダリングするわけじゃないし
その辺は必要なものを実装して使っていく形で
  1. 2013/08/27(火) 01:06:41|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

はじめてのフォトンマッピング

タイトルどおり
まぁ実際に実装したのはプログレッシブフォトンマッピングだけど
簡単に言うとレイトレを第1パスにしたフォトンマッピング
フォトンマッピング
まぁほぼほぼあってると思うけど
なんか怪しい気もする
  1. 2013/06/24(月) 14:18:34|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

IBLのようなもの

パストレの背景にHDR画像持ってきてIBL
イメージベースドライティング
クリエイティブ・コモンズ・ライセンス
この 作品クリエイティブ・コモンズ 表示 - 非営利 - 継承 3.0 アメリカ合衆国 ライセンスの下に提供されています。
http://www.hdrlabs.com/sibl/archive.htmlにある作品に基づいている。

とまぁIBL用のHDR画像をここから持ってきたわけなんだけど
正直CCの表示方法これであってるのかよくわからん

ここ見ながらHDR形式の画像読み込んで背景に置いただけ
なんかポリゴンが見えるのは……まぁ原因は予想はついてるんだけど
とりあえず修正が面倒なのでこのまま
レンダリングに11時間かかったよ!

ちなみにタイトルがIBLの ようなもの となってるのは
HDR画像を光源として使うの時の補正というか強さの計算がよくわかってないから
リニア化とかガンマ補正とかなんかあるらしいけど
あのへんの話ってよくわからんのよね……
  1. 2013/05/30(木) 22:36:23|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

はじめてのAO&パストレ

特に必要だったわけじゃないけど
書かなきゃいけないかなぁと思ったから書いた

そもそも
専門はCGです☆
とか言っておきながら
今回が初めてとかマジでお前今まで何やってきたの感

アンビエントオクルージョン
パストレーシング
正直正しい方法なのかちゃんとわかってないけど
一応それっぽくなってる
どっちも単純にランダムにサンプリングしてるだけ

あとはもう少しコード追加すればIBLもできるかな
そしたらlucyをレンダリング
……の前に空間分割を実装しないと一年回しても画像出てこないだろうなぁ
  1. 2013/05/28(火) 21:46:18|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

メタボールをCUDA使ってレンダリング

12月~1月は課題と研究中間発表の準備に追われて
なかなかそれ以外に時間を使えそうな気分じゃなかったけど
ようやく1,2ヶ月ぐらい研究だけで良い期間に入って余裕ができた

というわけでなんとなくメガデモとやらにでも手を出してみようかと
GPGPU使ったリアルタイムレンダリングでもしてみるかと
そんな感じで作り始めたわけですよ

メタボール
濃度関数はガウス関数
近似関数だとむしろ条件分岐入るからそのままの式を使ってる
あとはレイマーチング法で交点探索してるけど
反復回数は固定にしたいからsaturate使ってステップを調整
まぁ完璧とは言えないと思うけど一応描画できた

で,今のところ5個のメタボールを画面サイズ256x256でギリギリリアルタイム描画可能と
GPUはGTX460だから一世代前とはいえまだ産廃じゃないと思うから
最新ので走らせてもそこまで良くはならないと思う
書き直せそうな箇所はあるからそこを調整してどうなるか……

チューニングの仕方が普段書いてるのプログラムと違うから
ノウハウがねぇ……ちょっと……
  1. 2013/02/06(水) 12:15:25|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

スケルトンを使った髪の毛らしきもの

研究の一部
スケルトンベース
まぁおおよそやりたいことはできてる感じ
いんぷりしっとさーふぇす
いろいろ手法はあるけどようやく本質というか実態というか
なんかそういうものがつかめてきたような気がする

こういう関係の本ていいのないものかなぁ
CGの本って言うと感覚として
一番多いのがソフトの使い方
んでポリゴンモデルとかテクスチャとかの作り方とかがあって
プログラミング系だとDirectX、OpenGL関係とかシェーダとかあって
その後レンダリング手法だったりCG全般知識だったりもある
で、こういう陰関数曲面を扱った本って言うと……
この前一冊見つけたかな……
専門的にって言うともう壊滅的
まぁ洋書しかないっすわってことでこの前注文したけどまだ届かない

まぁ言ってもGIとかも日本語だとフォトンマッピングが一冊あるぐらいなのかな
  1. 2012/10/30(火) 04:24:34|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

さーふぇすりこんすとらくしょん2

前回とは違った手法で再構成
CSRBF法ってやつ

前回使った手法ではセルごとに関数フィッティングしてたんだけど
今回使ったのはでっかい方程式解いて一発でパラメタフィッティング的な感じ 
ソルバ書くのが結構大変でね……
まぁなんでもいいならそりゃ楽なんだけど
パフォーマンスが出なくて結構手こずった

最終的に修正コレスキー分解を自分の書いた疎行列クラスに合わせた書き方して
何とかマシな速度でできるようになった

うさぎ再構成2

右のやつは……
まぁなんというか原因はうっすらわかってるんだけど
どう処理していいかわからんのだよねぇ……
  1. 2012/09/08(土) 19:06:39|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

さーふぇすりこんすとらくしょん

いんぷりしっともでる
とかいうものにちょっと興味があって
でも球だのトーラスだの作っても面白くないから
サンプリング点からの再構成に手を出してみた

MPU法とかいうものを使って実装
参考にしたのはこの辺
Multi-level Partition of Unity Implicits
 └オリジナルの論文
色情報付き陰関数曲面モデルの生成
 └MPU法について丸っと書いてある
MPU法アルゴリズムの概要
 └ほかのページも.論文じゃわかりづらいところもわかりやすく載ってる.

結果はほい
こいつから
元の点データ
こう
うさぎさん再構成
そんでぐにゃっと
ねじれるうさぎさん
まぁこんな感じ
三番目の奴は関数で変形させてみたってもの
メッシュ形状気にしなくていいのはさすが関数モデル
いろいろ面白いことに使えそう

実は必要な関数を一個実装してなかったりする
再構成がうまくいってないところがあるのはそのせい
まぁでもちょっと試しに遊んでみるにはこれぐらいでもいいかも

あとは本気でやるならもう少しサンプリング点を増やさないといけないみたいだから
わざわざ元のデータから1/10に減らしてるこれじゃそもそも……

今回はねじるだけだったけど
関数次第ではもっと複雑な変形もいろいろできるはずだから
破壊アニメーションみたいなのに使えないかなぁとか思ったり
  1. 2012/08/01(水) 05:16:59|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

今年度のZバッファレンダラ書き直し

下は単なる画像
Zバッファレンダラ2011
2年のときに課題で作って
去年研究のためにほぼ1から書き直して
今年もさぁ書き直そうというわけですよ

2年のときに書いたものは論外で
まぁあのころレイトレの方に力を入れてたこともあって
課題の範囲でとりあえず動けばいいだけのプログラム

去年のはレイトレのほうで使ってたオブジェクトデータを使えるようにして
オブジェクト指向の考え方を少し取り入れ拡張性を高くして
コストが高い初期化をなくし高速化を意識して計算精度を……
とまぁ一応しっかりとしたものを書いたつもり

で今年はというと

去年のコードは書き直したとは言ってもアルゴリズムは一昨年と同じで
授業で習った塗りつぶしのアルゴリズムなんだけど
教えやすいようにかなにかは知らないけど実はちょっと標準から外れたものらしく
ハードウェアで実装されているものはもう少し違うものだとか
それとコードも一応高速化を意識してはいたものの今見ると無駄な計算が多い

その辺を改善しつつ
あと先輩のコードを見せてもらってアドバイスをもらって
さらに友達から色配列への直接アクセスの方法を教えてもらって
去年より高速で拡張性が高いプログラムを目指す

んで今のところの具体的な変更点は
オブジェクトのデータとプロセスを分ける
計算回数が少なくなるように計算する場所を考える
塗りつぶしアルゴリズムの変更
大きいところだとこんなもん
まぁまだ塗りつぶしだけでシェーディングもまともに作ってないからね

あとどうでもいいけどBlenderが2.5になってエクスポータも書き直すだろうから
この際だからファイル形式も変更するつもり

さていつもの更新より文書いたけど
実は単なる1ヶ月広告が出るのを回避……できてなかったか
その広告を消すのが一番の目的だったり
  1. 2011/07/25(月) 00:18:01|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

アルゴリズムメモ(視線とポリゴンの交差判定)

今回はレイトレーシングで使う視線とポリゴンの交差判定
レイトレーシングの基本的な仕組みは面倒だから書かないよ

説明は追記で
[アルゴリズムメモ(視線とポリゴンの交差判定)]の続きを読む
  1. 2010/08/30(月) 02:35:18|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

パース補正用カーブレイトレーシング

名前は適当
CGだと迫力がどうのってパースの問題が大きいんじゃね?
と思ってそれを改善するためにレンダラに機能を追加
まぁ実験的な物だけどね
レンダリングでトレースするレイを曲げてやれば
距離によってパースのかかり方を変えられるからなんかできそうという
で、結果
パース補正
うーん…
効果はあるんだけど絵として微妙…
ついでにプレビューできないから調整がかなり面倒
関数でレイを曲げる機能は実装するだろうけどこの使い方は微妙かな…

カーブレイトレについてどうでもいい追記
[パース補正用カーブレイトレーシング]の続きを読む
  1. 2010/07/21(水) 05:58:08|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

異方性反射

っていうか異方性反射も表現できるなんかよくわからないものを実装した
そもそも異方性反射って表面の小さな凸凹が影響してるんだから
それをノーマルマップで与えてやりゃいいんじゃね?というわけ
だから異方性反射っていうより表面形状のマッピングって言った方がいいかも
ただスペキュラ計算は単なるフォンの反射モデルなのでお察しくださいと

ドアノブっぽいモデルを使ってテスト
異方性反射
まぁ多分できてるんだろうけど…
法線補間してるのにカクカクに見える…
アップベクターも補間してやる必要があんのかも
それだけで綺麗になるのかどうかは知らんけど

分割が細かい球と大きなテクスチャを使ってテストした画像
左が横に筋が入ってる風、真ん中が縦に入ってる風、右が凹みがある風のテクスチャ
テスト1テスト2テスト3
ちょっとは綺麗にできてる気がする

…んだけどクソ重てえええええええええええええ

追記(20:43)
アップベクターの補間計算を追加
補間計算あり
おお綺麗になった
でもこれ頂点のUV値が合ってないところがあるとちゃんと計算されなかったり…
まぁでもそれはしょうがない
…のかなああああああああああああああ
あーもう解決方法は普通に見当付いてるし実装自体もかなり簡単なんだけど
食うメモリと初期化時の計算コストがまた増える…
でももう今更なのかな…
  1. 2010/05/29(土) 18:54:42|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

法線マップでやらかした

自分の作った法線マップの根本的な間違いを見つけた
いやー外積の取り方とか何度も変えたたけどどうりで直らないわけだ
法線マップ使った今年の研究…ってほどじゃないけどそれのアルゴリズム考えてたときに気付いた

まずはこれ
法線マップ
左がBlender内蔵でレンダリング、右が自作のレンダラでレンダリング
まぁ自作の方は相変わらず汚いけど陰やハイライトのつきかたを見ると多分ほぼ同じ
バンプが飛び出してマップがへこんでる

さて次はこれ
なんかおかしい
同じく左がBlender内蔵、右が自作のレンダラ
さーて何かがおかしいね
内蔵はそのままだけど自作の方は凹凸が逆になってる
これ何をしたかというと、ただ四角形を180度回しただけ

くるくる回してみると
くるくる
おーおーこれはひどい
なんかもう凸凹してるのは何となくわかるけど
どこが出っ張っててどこがへこんでるのかよくわからなくなってる

これの原因はこう
よくわからない図解
法線マップってなんかまずアップベクターをとって外積計算をいろいろやってくんだけど
問題はそのアップベクターの取り方(ここからは実際に直して試してないから推測)
本来ならテクスチャーの上方向にとらなきゃいけないんだと思うけど
自作のだと常にY軸+方向でやってる
これだと回転させても計算後の法線は回転前と同じで
回転させたら上向いてたところが左向いてなきゃ行けないところを上を向き続けてるっていう
現実的に考えたらあり得ないわけわからないことが起きてる

さてこいつをどうやって直せばいいかってことなんだけど
多分こんな感じで行けると思う
解決方法
テクスチャ上方向(v軸+)がアップベクターになるようにすればいいんだから
その点のuv座標と頂点のuv座標からアップベクターを頂点の座標の配分比で的な何かで…
それを3次元空間に持っていってアップベクターのxyzを求めて…まぁそんな感じ
多分その配分はuの値を見れば簡単に求められるんじゃないかなぁ

以下愚痴

[法線マップでやらかした]の続きを読む
  1. 2010/05/25(火) 08:36:25|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0

Zバッファ法修正

ついさっきの記事だけど修正したからまた更新
こうして記事数を水増し
修正版
ゴミがほぼ出なくなった
前回の画像と比べてみると差は歴然
しかも前回のはアレでもかなりマシなアングルを選んでたし

ところどころでintにしてたのをfor文も全部floatのまま回すようにして
最後の最後バッファに格納するときにintに直さなきゃいけないものだけを
キャストするようにしただけなんだけどね
後は終点部分までちゃんと回らない可能性があるからそこはあらかじめ格納しておくとか
それと全く機能がないスクロールバーを外した

まぁこのゴミに関しては学校でかなり議論して
キャスト部分がどうのとか実数でfor文回すとどうとか
線を引く順番とかその方法とかいろいろと話があったけど
とりあえずは今のやり方でゴミが出てないからこれでいいかな
  1. 2010/05/22(土) 00:47:45|
  2. 自作レンダラ
  3. | トラックバック:0
  4. | コメント:0
次のページ

プロフィール

トック

Author:トック

プロフィール(仮)

twitter:elgraiv_took
└ブログ更新情報

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

FC2カウンター

コンテンツ一覧

本棚

最近の記事

カテゴリー

月別アーカイブ

ブログ内検索

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