Name: oga
Time: 2007/06/22
PaintTime： 7’11”
なんかやる気でない
最近の進展はDirectX使ったブラシが描けるようになったこと
VS使ってばひょーんて描画できるので500*500のブラシでもスイスーいなんだけど
でも、びでおめもりの制限があるから普通に絵に使うサイズの領域なんか確保できなくてしょんぼりしてる
最初はバックバッファに直接描いて、AAも効かせてタブレットの姿勢ら合わせてブラシも回すので、ほとんど不満ない感触まで持っていけたこれはすげー。
でもバックバッファで済ませる訳にもいかないのでテクスチャにドキュメントもって行ったらAA効かなくなっててションボリした
で一度システムメモリに移してMMXでフィルタかけようかとも思って、フィルタの勉強してたらなんかプリフィルタとポストフィルタの仕組みが理解できたので
だったらPSでボケフィルタ書けば全部上手くいくんじゃねーのかな？
と思ったとこで止まっちゃった。
実際には任意サイズのドキュメントなんてシステムメモリ上に確保するしかなくて
現在のカレントレイヤーだけでもびでおめもりに納まらないかと思ったけど
いや多分今そこら辺のビデオカードなら大丈夫だけどうちは64MBしかなくて、4096*4096一枚こっきりだったりして
それはちょっと難しいなぁと言う具合だったりする。
お絵描きソフトの何が嫌って、25%とか16%で描く時に画面全体何処で描画が起こるか分らない所で
せめて画面に移ってる範囲はすぐに編集できるように展開しようとすると、
ドキュメント全体が映っちゃってたりするわけで
全くコスト感覚も何もありゃしねぇ
じゃブラシで書き込むためのテクスチャ、書き込んだテクスチャを1/4するためのテクスチャ、それをドキュメントと合成して、バックバッファとシステムメモリ上のドキュメントテクスチャを差し替えて、
て処理をブラシで描いてる間ずーっとしなきゃいけなくて
何の為にDirectX使ってるかわかんなくなってくる
最初は回転も拡大縮小もAAもついて思いのまま、その上チョー早いだったのになぁ…
でもブラシの感触は良かったからもう少し煮詰めてまともなお絵描きソフトの体裁持たせたい所ではある
Name: oga Time: 2007/06/22 - No.113
あと
少しだけ3Dゲームのベース作ってみた
ステージ読み込んでその中歩いて弾撃ってくるくらい。
オブジェクト管理がいい加減なのでそこまでだけど、うん
やっぱ駄目だわ
色が自由に制御できないとやる気出ない。
つーのも3D空間使ったお絵描きチャットを構想して
DirectXを使ったテクスチャへの書き込み、云々の可能性を探ってたんだけど
どうもそもそも3D空間でお絵描きが出来て楽しいのか？てところが疑問だったりする
マップ作成ツールとしては便利だと思う
実際にプレイヤーの視点で気になる所をペペペっと色塗れればね。
でもテクスチャ共有してる複数のオブジェクトの共通のリソースであるテクスチャに書き込むとかはちょっと変な気がしてくる
そもそもテクスチャに書き込むためだけのソフトかっつーわけで
まぁそりゃモーションとモデリングもできれば最高なんだけどね･･･
どうも頂点をいちいち動かすモデリング方を絵チャットって空間でやりたいとは思えんし
色々ある。
でもFPSで血とかのエフェクトが適応できる仕組みでもあるから、それはそれでいいと思う
Name: oga Time: 2007/06/22 - No.114
多分大事なのは、材料を目に見える形で提示することだと思う
テクスチャについてはスケッチブック形式で自分がいじる分のは持っておけばいいと思う。これは中々のアイディアだぜ
よく分からんけど、なんとなくこれ以外にはないと思う
リストやグローバルなリソースホルダーにアクセスするのはなんか違うと思う
自分が触っていい分は提示されていて、必要なら他の人のも見ることができる
自分が持っているテクスチャなら何処に貼り付けてきても自由でありたい
何より自分が持っているリソースを管理して適切に配分しようって気にさせる
だから限られた大きさであるべきなのだ
でもここから一歩先に行こうとすると何も思いつかない
世界には地面がある。多分建築物もある。それらに落書きできるのはいい。
落書きはしよう
でもそれが楽しいのかっつーと、ちょっと違う気がする。
そこが分らない
何をしたいのか、何を見て欲しいのか、何なら一目も気にせず没頭できるのか
果たしてそれはお絵描きのツールだろうか？
そこでモデリングに行くかムービーに行くか迷う
モデリングは基本的には未来ないのでムービー行きたいね。
Name: oga Time: 2007/06/26 - No.116
こっちは作ってるソフトで描いた画像。
2値で等倍でこれ描けるんだから胸張れると思う
微妙なカスレは意図したものじゃなくてDirectXのラスタライズルールによるものなので、ビデオカードで変わるかもしれないし、何より描画を全部DirectXに依存しなきゃいけなくなる
これが後々に大きく足を引っ張りそうである。
いずれはカスレ具合の制御もきちんと解析して出来るようになんないといけない
今はなんか徹夜のテンションで作ったブラシとパラメーターのおかげで出せているだけで、後で作り直してもこの感触に及ばなかった
Name: oga Time: 2007/06/26 - No.117
上の画像サムネイルになってるね、ションボリ
今度は色濃淡付きの絵
2値に比べりゃ遥かに細くてシャープな線、に見えないこともないけど
好みとしては2値の方が好き
Name: oga Time: 2007/06/26 - No.118
次は濃淡つきアンチエイリアスの線で描いた絵。
CreateRenderTagretだと現在の画面モードに関わらずマルチサンプリングを設定できるのでそのおかげ。
画面全体をマルチサンプリングにすると大きいテクスチャ使う時にやたら遅くなるって現象を回避できるようになっている
理屈は知らん
でも別のサーフェスに描画した絵をテクスチャに転送してから画面に描画するって方式のせいで速度がガクッと落ちてしまった
バックバッファに直接描くなら、400pxのブラシでもスイスイ動くのに今は40pxがせいぜい
それだけでは旨味がないので、確保するテクスチャのサイズ64pxにしてそれを使いまわすことで描画するようにして、結局速度はかわらないのだけど、ビデオメモリを温存できるようにはなった
このブラシモジュールを3D絵チャットに持ち込む場合、3D部分に大量のビデオメモリが割かれるのは間違いないのでこの方式でいい筈
でも速度遅いのはどうにかならんのかな…
Copyrectsが悪いのは分っているので、これにかわる転送方法か、転送の経路自体を見直す必要があるかも
Name: oga Time: 2007/06/26 - No.119
50%表示はDirectXの縮小フィルタで問題ない品質なのでそれで済ませている
これも画像をテクスチャとしてDirectXで描画するおかげだけど、
本当にそれが正しい選択かどうかは分らない
分ってるのは品質的にはそれが問題ないってこと。
Name: oga Time: 2007/06/26 - No.120
可能ならこんなブラシをお絵描き掲示板で使いたいんだけど
JavaでDirectX使うのは結構無理がありそうなのでこまる
なんでDirectX使うかっつーとブラシパターンを3次元回転させたパターンを取り出す為なんだけど
Javaだとそこだけでもかなりスペック食いそうで困る
フラッシュはそもそもラスタライザの品質が気にいらないからアウト。
じゃ多分C++であろうActivXで作る？
いっそSTGのハイスコアみたいに、お絵描き掲示板のCGIで受け取るけど描画はクライアントのアプリからってんでもいいかなと思ってる
アップロードありの絵掲示板ならその絵が何で描かれたかは最早問題じゃないしね
それとも「他からソース読み込んでません」てレギュレーションモードでも作る？
お絵描き掲示板である意味を考えると色々派生が出てきそう
だけど答えは出ない
Name: oga Time: 2007/06/26 - No.121
ブラシのパターンを3次元回転させるためのDirectXだけど、
用途を絞ればCPUでやるより遥かに速度は出るので期待感あるんだけど
レイヤーが10枚も20枚もとか、キャンバスのサイズが4000*6000とかになるとお手上げ
いくら縮小表示してても書き込める領域の大きさはビデオメモリの大きさまでですよ、ってルールが許容できるなら可。
あとうちのビデオカードでは、16bit以下のターゲットに対してはレンダリングできない
ただのイメージサーフェスでも生成できる一番軽いのはＡチャンネル8bitで
モノクロ線画用の2値だけど凄く大きい、とかはDirectXでは無理っつー事になる。
Name: oga Time: 2007/06/26 - No.122
線がかすれる理由は、描画すべき黒の領域がピクセルの中央を占めていないからだ
しかしどうにかして、ピクセル内の面積の比に応じてグレーがつくように実装したい
256値のグレー値を得るには、16*16のマルチサンプリングで白と黒の比を決定すればよいが、
DirectXでターゲットになる2値サーフェスなんて存在しないので、そういう発想は捨てる事にする
ぼかしPSで高速な縮小フィルタは作れそうだけどね
結局1ピクセル以下の描画は特別な方式が必要で、
個人的な感覚では多分4pxより細い線のAA部分にはそれが必要で、それ以上ではハードウェアのAAで十分だと思う
どういう仕組みだろうか。
引かれた線は必ずピクセルの中央、0.5、0.5を通り、ピクセル内を横断した時の距離と筆圧とパターンの面積からモノクロ濃度を求めてそれを書き込むようなエンジンだ
とにかく作るだけなら出来そうではあるけど
ハードウェア使って速くなるように作るっつーのは、ちょっと想像つかない
現状でカスレにそれほど困ってはいないけど
綺麗に1ピクセルで途切れないダマらないドット線作るには必要な技術だったりする
でもDirectXでドット線作りたいなら単にラインポリゴンで描画すればよかったりもするんだけどね
Name: oga Time: 2007/06/26 - No.123
自力でアンチのかかった線をLinaToするってのはどういうことかなー
てのを試しにやって見たルーチン動かしてみた画像。
1つのピクセルの色面積は1ピクセル平方、
同じ濃度同じ太さの直線を色んな角度に引くとする。
斜め45度の線と真横の線で、Ｘ長さを一緒にするとピクセルの数は一緒になる
ということはピクセルの濃度は斜め45度の線に対して真横の線は1/√2の薄さで無ければならない、となる。
これをピクセル単位の問題にすると、
あるピクセルを線分が横切った時に、そのピクセルに与えられる色の濃度は、
横切る線分の長さの2乗に比例する、となるような気がする。
てのをやって見たつもりの画像である。
何か間違っている気がしなくもない。
やってることは色の面積の収支を取っているだけなので、ぼかした時に同じ濃さの線に見えるというだけ。
今アンチエイリアスがかかっているけど、無理矢理ＡＡなくしてとにかくシャープにしたくはある。
かすれるブラシの時に誤差拡散ディザを少し調べて、そのストリーム処理の仕方が面白かったので
多分同じような誤差拡散の仕組みも導入するんじゃないかと思う
ディザじゃなくて、誤差拡散フィルタリングね。
で多分、拡散の方向が後ろのみだと気持ち悪いので、前後方向に散らすような仕組みにはするんじゃないのかな
Name: oga Time: 2007/06/26 - No.124
はて、何かおかしい
そうだ、完全にただのドット線ならプレゼンハムやらで済むし、その場合にピクセル毎の距離は一定だったりする。
今やってるのはプレゼンハムにたまに起こるmin(dx,dy)の方のジャンプでピクセルを分けることなのだけど
完全に真ん中で分かれた場合に他の部分に比べてそこは半分の濃度になってしまって
これがやたら気色の悪いものになる
これを是正するためにどっちか濃い方に色が流れ込む仕組みを作って、そうやってぼかしを作る
これは幅1ピクセルの線でも起こる現象だけど
本当に幅が1なら斜めの線はほとんど常に太さ2の領域をしめる事になって
そこに濃度が分担される。
勿論そんな風にしては線がボケボケになってしまうだけだけど
どんな線にしたいのか？どんなパラメーターで制御したいのか？
を考えないと、それを制御するアルゴリズムなど見つかる筈もない
そう、まずはドット線の太さと特性を、どう解釈するかだ
それは連続的に他の線と連なったいる筈では？
Name: oga Time: 2007/06/26 - No.125
後プレゼンハムなら同じパターンの連続だから、線の傾きから分配フィルタ作って、その数だけ線を重ねれば済むだけだったりする
でもそうじゃなくて、大事なのは補間曲線導入した時に、その線の部位ごとに色を決定するアルゴリズムであって
だったね
Name: oga Time: 2007/06/27 - No.126
まず
DirectXでならマルチサンプル利かせれるから、困らんとする
どうしても線の品質に不満がある時に自作となる
そうではなくて自作のラスタライザで処理が必要になるのは2値である。
グレスケは諦めて4倍効率悪いけどDirectXにしていいとおもう。なんかそこまでクリティカルではない気がする。
2値は少し考えるけど…
考えた所で答えは出ないと思う
2値のペイントツールなんてものは漫画描くにしか使わないわけで
必要なのは高解像度でブリブリかける速度だったりする
ブラシの感触は何とかなりそう
速度が欲しいっつーのは、例えば1200dpiの画像を平均して100dpi程度のモニタでみなから描くわけで
10%か20%、大きくてせいぜい40%で描くとして、
画面内に見えるのは200メガピクセル位になる。
2値データなのでピクセルあたり1bitで、データ量としては25MBとなる。
データ量は問題ないけど、
例えば縦に線一本引いたとして、線の幅が12ピクセル、秒に画面を3往復できる速度、72万ピクセルくらいを処理する事になる
俺にはちょっとこの速度が想像つかない
いや結局無理さ！
やってみたら出来るかも知れないけど可能性は感じない
Name: oga Time: 2007/06/27 - No.127
カスレの存在意義について。
まずカスレって何だ？
基本的には2値バッファとかモノクロ印刷とか色深度が限られた所で無理矢理中間調を再現するためのディザ拡散の、線画版と思えばいい
画像を平均化すれば元の意図したグレー画像が得られると仮定する
つまりソースの画像はグレー画像でそれにフィルタリングしたものと言う訳だ。
次にじゃどうしてカスレが線に見えるの？てことでこれは二種の原理があると思う
一方は目の解像度より細かい時で、この時は勝手にボケて平均化してくれるのでもとのグレーが再現されて多階調になる場合
一方は、明らかに2値画像の画素も境界も見えているのにそれを線だと認識する場合で、こっちはわからん、けど2つある。
次にかすれた線画の解像度っていくら？
数値的に考えれば256値のグレーをモノクロのディザで表現するには、単純には3倍の解像度があればいい
3倍以上であれば画素の配置に自由度が出て、例えば４×４ピクセルなら、全体で16bitの情報のうち階調部分は8bitだから残り8bit、256通り分の自由度がある
2つの情報が混在してるってのが大事で
例えば1200dpiのモノクロ画像は、多分150dpiか72dpi程度の階調解像度と、それ以外で出来ているような気がする
これは階調部分を低く見積もりすぎかな？階調とそれ以外で250:8て情報量比になってしまうな
んーでもそんなものの気がする
で問題なのは
今階調を取り出すのに平均化してた訳なんだけど
もし画像に対して寄って見た場合、平均化フィルタの幅が変わっちゃうので、階調対それ以外の情報の配分比は連続的に変化してしまったりする
そういうのが表現しずらいから
仕方ないからモノクロ画像も元々は同じ解像度のグレー画像と解釈して
それ上でブラシ処理やアルファ加算していきながら目的のグレーを出して、
次に「 1/何の解像度で濃淡が維持されて、且つ、線の位置情報が損なわれない自由度で、出来る限りデータを軽量化する 」ってフィルタ処理がかかると思う
位置情報が損なわれないってのは、目的の位置に色を配置したいってことで、逆に濃淡優先の時にそれが損なわれるって意味でもある
単純に考えればグレー画像をディザ拡散して２値化すれば細部はボケるけど、もし表現するグレー階調の解像度をぐっと下げれば、元々のピクセルの配置を損なわないことも出来たかもしれない
てーいってる訳で
それがかすれじゃないのかな？と思う
Name: oga Time: 2007/06/27 - No.128
出力するグレー階調の解像度てのはJpegの色情報と輝度情報みたいなものだと思えばいい
人間が鈍感な方のデータを低深度、低解像度にしてデータを軽量しようってことだ
ディザ拡散にグレー階調の目的解像度って概念つければ、こっちはどうにでもなる
問題は位置情報が損なわれるって現象をどう解釈するかだ
位置情報を大雑把に線のことだとしよう
線てのは他とつながってようやく意味が起こるので、ピクセル毎に180個のバッファを持たせて、周囲のピクセルと接続して線分を形成できる時はその角度のバッファに重みをつけるって処理を全角度に行い、そのピクセル位置の線の角度の重ね合わせた総和を求める
そのピクセルが全体としてもっている方向と強さが分るわけで、これをベクトルにする
次にこれをキャンバス全体に行うと有向面って奴が出来上がる。
でもう少し、本当は線は解像度に対して疎かであろうから、有向面の向き値てのも解像度によって平均化されてんだと思う
そうやって作った向き情報をどんくらい保持できるかな？てのが「線が損なわれる」の一応の解釈…
だけどそんなのやってられーん
と言うわけでやるならこんな感じの処理
最初に用意した高解像度のグレー画像を、まず低解像度化して、領域毎のグレー値を求める
1つの領域で見れば、そこに要求されているのは全体の白黒濃度比が指定されたグレーになるように、な訳でグレーが維持される限りは元々の画像の再現に努めればいい
で、多分画像の情報の大部分はエッジによっているわけだから、最初にエンボスフィルタかけて、それをマスクにしてから領域のグレー値に近づくようにディザ拡散をかける
するとエッジ部分は残して、けど領域全体を平均化すると指定された通りのグレーになる画像ができそうな気がする
問題があるとすれば、多分エンボスマスクは画像にどぎついシャープ掛けたようで見苦しいだろうなとは思うけど
多分それなりじゃないのかな
Name: oga Time: 2007/06/27 - No.129
でも最初に高解像度のグレーを求めている時点で処理として無駄が多いし
別にこれをやればクオリティが上がるとかってものではないので何の意味もない
ただ、思考する上でのステップね
Name: oga Time: 2007/06/27 - No.130
次にDirectXのかすれについて。
どうして起こっているかといわれれば、答えは簡単で、ラスタライズルールで蹴られたからだ
ラスタライズルールではピクセルの中央、0.5,0.5を占めるポリゴンの色がピクセル全体に反映される事になっているので、0〜0.499、0〜1.0を占めるほぼピクセル半分の線は描画されない事になる
これを解決するためのマルチサンプルで、ねしマルチサンプルの倍率を16倍、32倍、128倍とどんどん増やしていけば、最終的にはピクセル内の色面積の平均値に落ち着く事になる
今考えるのは、マルチサンプルの代替手段を考えることではなくて、どうしてかすれが起こり、どうしてそれを俺が良い線と感じるのか、だ
マルチサンプルして平均化した線を俺はいいとは思わない
作ったグレー画像を誤差拡散シャープフィルタでも掛けて16値か4値くらいまで落とせば好きになるかもしれない
ああ、つまりカスれる線のシャープネスが振り切れてるところが好きなわけか
でもそれだけじゃ説明にならないね
多分拡散アルゴをブラシに入れるのが一番早いと思う。
今のブラシで不満なのは角度によっては、線を描画させないことが出来ることで
それはタブレットの解像度がピクセルより細かくてそれを俺が制御できちゃうせいなんだけど
つまりピクセルの中央を通らないようにしていけばいつまでも線が描画されない現象が起こって
これ対策に、同じようにカスれるけど領域の平均としては一定のグレーを付加出来る、拡散ディザブラシが欲しいって訳だ。
そうでない場合の選択肢は、ディザブラシでもなくグレー階調でもないとすれば、ドット線に階調を与えることだ
マルチサンプリングと違うのは2つのピクセルを横並びに色つけてボケるって現象を起こさないことだ
こっちもやっぱ誤差拡散が欲しくて、隣のピクセルがもし描画されるなら、前後のピクセルの相応しい方に色が集まるようにしなきゃいけない
つまり最低でも2ピクセルが常に未確定な拡散グレー階調のドット線で
多分問題はないでしょう
こうなるとカスれるかどうかは、ドット線より細い線を要求するかどうか、になる。
Name: oga Time: 2007/06/27 - No.131
DirectXで作るディザブラシ
最初に線引いてマスク作る
次に一回ぼかしフィルタかけて濃淡や線の密度をグレー値にする
次にランダムノイズのテクスチャ被せて、上で求めたグレー値を敷居値にして2値化する
でできんじゃねーのかなー
ディザでも誤差拡散でもないけど
用意するノイズパターンを1次元画像にしとけば、線上に配置する限りは必ず一定面積で収支とれる訳だから
その面積分で平均化したグレー濃度で2値化すれば、在ってる筈。
Name: oga Time: 2007/06/27 - No.132
処理だけフォトショでやってみると随分薄い濃度に仕上がるのが分る
一体何故だ？
Name: oga Time: 2007/06/27 - No.133
シェーダー上で動かせる乱数発生器が見当たらない･･
つうかfloat型のレジスタしかないのに見つかるのは32bit整数の発生器ばかりだからだ
ビットマスクやら何やら頑張れば出来なくもないけど何かがおかしい…
もしかしたらDX9とか10だと普通に乱数発生器できてるのかな？
現状でやるとしたらfloatで動く乱数発生器を何とか見つけるか、テクスチャに乱数書き込んで参照するか
それ以外思いつかん。
