返信お絵描き

Name: oga Time: 2008/10/03
PaintTime： 5’34”

湾岸MIDNIGHTが大スキー

車に興味ある訳じゃないよ
全くないといっても過言ではないよ
こんなこと言うと印象悪いけど本当にないからある振りする方が失礼なくらい興味沸かない
ゲームもそう、全然やらない
でもゲーム作ることは別
やんない人がまともに作れる訳ねーって言われるけど俺も実際まともに作れる気はなくて
自分が楽しみたいから楽しいようにやるだけだったりする
そんなのゲームじゃないと言われればその通りかもしんない
俺だって食べない人が美味しい料理作れる筈ないとは思うし、そういうと思う

とかなんとか語りいれるごっこしちゃう

でもなんかその内容に凄く感心してまいっちゃう
どうしてそんなこと知ってんの？って
ボクは命に関わるようなことしてないし絵やプログラムを仕事にしてる訳じゃないし年単位で触らなくても全く平気だし
基本的に怠惰だからすぐお手軽に済ましちゃうけど
なんか違う瞬間はあるけどそれが何なのかわかんない時に読むと変に納得できちゃう

うんでも実際は共感って言える程俺が知ってることはなくてただ流されてるだけだとは思う
作品の雰囲気に浸って酔ってるだけ
んでももう少しそっち側に行ってみたいと思っちゃうよ

わーい失敗ー

Name: oga Time: 2008/10/03 - No.684

他の人がそんなこと言ってるの聞いたことないし同意してもらえた試しもないけど
ゲルインクボールペンって感触が凄くお絵描き掲示板テイストだと思う
ちょっともたつくとすぐ汚くなって台無しになるけど
速度保てると凄く気持ち良くてその速度に耐えれるだけの供給量もあってそこがおいしい

んでももっとのんびり描きたい時もあって
紙の上に先を置いた状態で考え直したい時もあって
そういうのは出来ないせわしなさが苦しい時もある

鉛筆なんかは先っぽ置いただけじゃ全然色載らないのに滑らすと途端に黒くなるでしょ？
ああいう感覚もあったらいいなと思うんです
んでもインクの黒の力強さとコントラストも欲しいんです

別の話で絵になくて粘土に在るもので形を壊すことと作ることが同時に出来ることが粘土っていいなと思ってて
絵は絵の良さが勿論あるしそれを粘土に持ち込むのは全く不可能に思えるけど
デジ絵に関しては両立させることは出来るんじゃないかーと思ったりします
というかそこに可能性感じてるから絵も造形も程ほどにしてお絵描きソフト作りてーなんてほざいてる訳で

話戻して、粘土は壊すことと作ることが同時に出来るし
表面に指置いてもまだ何も起こらないでいてくれるんですよね
ダイレクトな感触があるのにそれを乗せる瞬間を思い通りになると言うか
急がされずに済むんです
その曖昧な所でなで続ければ勝手に表面をツルツルにもしてくれるけど
そんなのはただのテクニックで
大事なのは指置いた瞬間すぐには動かなくてもいいとこじゃないかなーと

まあ何が言いてーかっつーと
絵を描く方法って描くだけに限定しなくてもいいよね
テンポよくシャッシャと線引き続けることが全てじゃねーし
それが自覚できればもっと色んなお絵描きソフトがあってもいいと思えるさ

Name: oga Time: 2008/10/04 PaintTime： 1’24” - No.685

(8702 B)
Original size / Anime / Continue

探してた物がよーやく見つかったかもしれない。

「ホッチキス」
ある接続面と別の接続面を、ある方向から針を打って留めるように、緩く結合させる機能。

色々なやり方でこれは実現できるんだろうけど、
あえて別の空間にディスプレイスメントする方式でこのリンクを形成しちゃう
また留める相手はポリゴンの接続面同士でもいいけど、デカルマッピング用の透明な板ポリでもいいことにする
というか一方向からの投影マッピングもこれで出来るようにする

何がいいかって
UVマッピングで頭を悩ます「オブジェクト全体で面が重ならないこと」とか
「ポリゴンもUVのマッピングも連続した辺共有の接続面で出来てる単位じゃないと編集しずらい」とか
UVトランスフォームが分かり難い、分かり難いからUV空間で見ながら編集しなきゃいけない
作業中にどこかでUV展開するとか貼り付けるって作業が欲しいとか
そういう所を是正できるかもしれない

ホチキスされた接続面同士はホチキスされた点を中心にある程度の広さを持ってお互いの編集に同期しあう関係がある
だからその範囲を超えると影響しあわない、効果直径を針ごとに持ってる
接続面自体が薄いプラスチックの成型品のように弾力を持っていることにする
針は普通は三点だけど一点貼りで回転を許したり、スライドする針があってもいいことにする
針に対して針の位置をずらしたり、接続面のホスキスしてる角度をずらしたり出来るようにする
前後に二枚のゴム皮膜を被せたり、片側だけ被せて、一定の拘束力が働くようにする
この拘束力が強いと2枚の面は隙間なく重なる
また二枚の面が重なってもポリゴンの格子は重なっていないので曲げると歪な凹凸が出るけど、ゴム皮膜はそれに対して凸抱な面を作る
デカルマッピングが可能なようにゴム皮膜に対して面のテクスチャを投影することが出来る
ゴム皮膜の強度を一方を0にして一方を最大にすると、一方的に張り付くゲイザーやデカルマッピングになる事にする

何をしようとしてるかっつーと
ディスプレイスメントやテクスチャのマッピングや色んなものを一つの概念でパッケージしちゃおうとしている
お絵描きに置けるレイヤーみたいな、便利で基本的でいくらでも応用が利いて、何かしようとしてもそれをどう使うか考えれば実現できるような
多少汚くても頑張って実現できちゃうような
そんな概念を探していたのだ

でも今挙げたような条件や挙動で実際どこまで出来るのは全然分からない
何せまだ思い付いたばっかりだ
効率よく動作させたり頑張ればリアルタイムで出来るように方式を洗練していかなきゃいけない
もしかしたらどうしようもない欠点が見つかるかもしんないしリアルタイムは無理かもしんない
実際に触ってみたら面倒なだけになるかもしんない

けどなんとなく上手くいけそう
ホチキスが登録商標でさえなければなぁ

Name: oga Time: 2008/10/05 + - No.686

LO表紙画集買った読んだ見なきゃ良かった！！
なんか絵そのものの魅力もあるんだけどその他の部分で大いにブーストされてて
これ見て絵だけ誉めるのは嘘だろーみたいな
俺がLO見て惹かれてたのはこいつらのテンションだったのかみたいな
一人で発表するあても目指す夢もなく絵描いてるような俺には眩しすぎると言うか直視できないというか
そんな自分の行き詰まりが見えてイヤになった！

現実どうかは知らないけど
仕事に本気で打ち込んで楽しそうにしてる人の姿は励みになるなぁ

Name: oga Time: 2008/10/07 - No.687

物語の中のキャラクタは世界に対しての何かの役割を持っていて
物語はキャラクタがその役割を果たしたり、変質させたり受け継いでいくことで進行していく
勿論具体的な国や勢力の勃興や前線の上がり下がりやとりでの攻防戦や戦術シーンも見せ場なんだけど

そのキャラクタが持ってる世界に対しての役割って奴を保存量として扱って
そのグラフの変化を追っていく形で物語を記述する言語があってはどうだろう？

運命ってものの大きなうねりを直接記述するアウトラインプロセッサーというかね

んでもキャラクタってものに運命を結集させてるのがそもそも人間の発想なんだろうか
科学の技術史がメインだとどっかのSFみたいにワープ技術やタイムマシンが開発されることでそこから始める世界の変化を追っかけてったりしてるし

んでも根底にあるのは世界って有限のリソースがどういう風に推移していくかの様子を眺める感じなのかな
たまに予測のつかないか説明の出来ない推移が起こる時にそれを説明する力が物語のテーマになるんだけど
それを物理演算としてシミュレートすること考えると
物理法則が帰納的に推論されながら実行される仕組みになっちゃったりしないだろうかねー

Name: oga Time: 2008/10/07 - No.688

天文学のカメラのデジタル処理で
時間経過で対象の小惑星とかの明暗変化で、光源が太陽とか分かりきってれば
ある程度は対象の形が分かるらしいけど
同じようにレンダリングでも、光源やViewPortのピクセルがピクセル以下のスケールジッタリングした時に
丁度アンチエイリアスをかけたように細部を描画できるだろうけど

その何フレームかけて同じ対象を描画しつづける間、毎回スクリーンのピクセル上で前のフレームのピクセルと加算しづつけるけど
その時の加算係数と減衰係数調整すると、暗い所から出てきて目がくらむのを再現するのは容易かろうし
全体の露出調整で画面をちょっと気持ちよくするのは出来るだろう

さてふと机の上のシャーペンの換え芯のケースが目に飛び込んできた
ハイライトがやけにギラギラしてやがったからだけど
よく見ると右目にはハイライトが見えるのに左目には見えないから距離感がおかしくなっていたようである
当たり前のことだけど人間の目は左右にはなれてついてるから、スペキュラのハイライト見たいな奴だとすぐに光って見える位置がズレてそーなっちゃうわけだけど
まあモニタ上では距離感なんて表現出来ないからハイライトがズレて貰うだけにする
ハイライトをズラしたいけど目は一つならば光源二つにして重ね合わせればよい
やってみたけどあまり上手くいかない
それより落ちる影が二重になってソフトシャドウになることの方が効果的だったけど
元々両目の視差のために光源をずらしたんだけど、影の落ちる位置は変わりないんだから
ハイライトを落とす光源のジッターは影落とす光源とは独立してないといけない
でも影は影でソフトシャドウのために光源を複数個ジッタリングで扱うのはよさげに思える

今カメラは1つと仮定したけど
被写界深度というかピンとのあってる距離の表現に左右の目分のズレを表示してみるのは悪くないと思える

影、ハイライト、カメラの位置、Viewportのピクセル
全部ジッターしながら描画すると、もしかしたら
もしかしたら素敵な奥行き感のする画になるかもしんない

でも別の利点もあって
キャラクタの動きの激しさに応じてピクセル上での加算係数と減衰係数調整すると
動きが激しい時は低画質で、ちょっとでも余裕が出来たら高画質にするって言う
中々素敵なことが出来る

とりあえずそんなカメラを作りたいもんだねぇ

Name: oga Time: 2008/10/12 - No.691

メタセコは面のスムージングされた法線をドキュメントに持ってないので
再生側でそれを計算して保持する処理かかなきゃいけないんだけど
メタセコプラグインSDKにコードそのまま書いてあるけど
メンドくさいので放置

というか今のままだと単なるMQOモデルのARびゅーあーでしかなくて実用性皆無なので
もっと実用的で実践的な応用方法考えてみる
できる限り手間のかからない奴で

でもまぁ…
ARのマーカーの認識精度がそれほどたいしたものじゃないので
難しい気はする
そもそも向こう側覗きたいだけなら、おれの額か眼鏡に位置情報が分かるような無線デバイス一つついてればいいだけで
画像認識させてそこから向きまで検出する必要はないというか
実写に3DCGモデル重ねても自分の部屋の中撮ったっておもしろくないんだもん

Name: oga Time: 2008/10/13 + - No.692

ハイ削除削除

ARtoolKitのサンプルベースにしてOpenGL切り離して
ビデオ出力取り出してマーカー見つけてそのマーカーへの座標変換行列つくる所までは出来た
ちゃんと全部関数として揃ってるので順に呼び出せばよかっただけ

そして取り出した座標変換行列から、
向こう側除ける窓用のビューと射影の行列を取り出して
それを適当な３Ｄ処理系に投げればよいだけ

GLutとATLの共存のさせ方がわからなかったので切り離したので
DirectXやATLとまた絡ませても仕方ないので、
カメラのセットアップとマイフレームのマーカー検出か覗き窓行列取り出すまで関数にして
後は適当に、スクリーンとカメラの位置だとか、
覗く窓以外用のマーカー検出に切り替える処理だとかかけばいいのかな

OpenGLの初体験の印象は凄く良かったです
うちの環境だと起動に15秒程度毎回かかるとか、それほど早くはないとかあるけど
処理の書き方や扱い方は凄くすっきりサッパリしてて分かりやすかった
でもやっぱ使いたくないや
DirectXのOpenGL風ラッパとかあったら欲しい
DirectXとOpenGLを切り替えれるようにするレイヤ作ったら結局そうなるんだろうというかそうしたくなりそう

とりあえず今は覗き窓をきちんと形にしていこう

Name: oga Time: 2008/10/14 - No.694

駄目だった･･･しょげる

いや考えればわかる筈だったんだけどさ
とにかく形にしようと勢いでやってて最後まで気づかなかった

やってたのはメタセコのプラグインで視点制御で向こう側覗けるARなんですけど
カメラも接続できたしマーカーも認識できたし、ステーションプラグインでずーっとマーカー監視しつづけて見つけた時だけ視点移動して
そのままマーカーの座標渡すと凄くガタガタしたり認識出来なくて急に止まったりしてイライラするので
視点移動先のターゲットと元視点と移動中の現視点で滑らかに繋ぐとか
そういうことばっかやってて気付かなかった
メタセコじゃ駄目だ！射影行列を行列として設定できない！！
SetProjectionMatrixがあれば出来たのに！！

と言う訳でマーカーの動きに併せて視点の位置が前後するだけの
ぼやけたプラグインにしかなりませんでした･･･

上手くいくようなら
オブジェクトの移動操作と視点移動のモードを切り替えつつARで色々やれるようなの考えてたのに･･･

Name: oga Time: 2008/10/14 + - No.695

他にいくらでも行列として射影行列渡せてプラグイン使える3Dソフトあるだろうけど
なれてるメタセコアだからいいのに
それだけのレンダラ作るってほどでもないような気もするし･･･

射影行列設定は要望するとして
ARToolKitのレスポンスだと作業に使うのは無理そうな気がする
画像認識部分をもう少しチューニング、設定パラメーターとかじゃなくてもう少しフィルタ処理を細かくやってから認識してもらえないと･･･

いっそ汎用の3Dポインタに対してそれを視点位置にとって覗き窓作れるプラグインにして･･･
というかWiiリモコンがそのままPCに使えるらしいのね
どんくらいの情報やりとり出来るかはわからないけど

色んな種類のカードを認識させたりその位置関係読み取れるのが利点であって
一つの点の位置だけを取るには不向きなんだろうね
読み取った位置関係を色々計算して視点にしたり移動対象にしたりっつーのは汎用っぽい仕組みだし
子供向けにカードを地面の上に並べてフローチャート作るとそれでプログラミングできちゃいますよとか
そういうのくらいなんだろうか

RigidChipをARで組み立てるくらいは出来そうだけど、
できたからってどうなのよ、パラメーターの方が大事じゃん、ってはなりそう。

行き詰まった！
ARToolKitに対して夢が見れない！

Name: oga Time: 2008/10/14 PaintTime： 3’29” - No.696

(13532 B)
Original size / Anime / Continue

ARToolKitの利点はマーカーの数があまり制限されない所だと思う
単一のポインティングデバイスとして動きや加速度まで検出するのは不向きなかわりに
一杯並べたマーカーを順に検出して認識していけるようなのは出きるとして

でもそうなると固定したカメラの低い解像度で全部捉えるのは無理だろうし認識しずらい時もあるので
どうせならカメラを手に持って動かせるといい
カメラを動かしつつ複数のマーカーを検出して
同時に検出した複数のマーカーのセットを重ね合わせして
配置されたマーカーの全体を検出するとか
ちょっと時間と空間に広がりがある方が向いてそうな気がする

どんなものなら
複数のカードの配置で面白いことが出来るのか･･･
よく思い付かない

戦略シュミレーションゲームみたいな
勝手に周囲のユニットと戦闘始める部隊ユニット配置して
その行く末を見守るようなのがいいんだろうか

でも目の前でカードを配置してるのに首はモニタのほう向いてるのはなんか辛い

ふつーにWiiリモコンに乗り替えた方がいいんだろうか

Name: oga Time: 2008/10/17 - No.698

Original size / Continue

OpenGlのマテリアルとライトの色がどう演算されるのかわからねー
乗算とか加算とかないのかと思いながら見てても見当たらなかった
代わりにマテリアルの設定値が0～1じゃなくて-1～1の範囲だったことを発見したので
試しにマテリアルの値をとりうる範囲で設定できるよーな簡単なテストコード書いて実行してみる

・・・・・・
んーこりゃ見ながらじゃないと扱えんわ
数字からじゃ全然想像できなかった挙動してた

Name: oga Time: 2008/10/26 - No.699

動画作成ソフトが欲しい･･･
アフターエフェクト買えっつーことなのだが
体験版触ってもどーも頭に入ってこない
あんな複雑なソフト俺には扱えない

けど色々したいので
easytoonを土台に置くようなパラパラアニメ作画ソフトを考えるんだけど
まず欲しいのがマルチなタイムラインだったり、3D空間でオブジェクト回したりテクスチャだったりラグドールだったり
どうも手描きを嫌がってるとしか思えない物ばかり欲しがってる俺
でもなんとなく考えてて
最終出力がパラパラアニメなら、パラパラアニメを描けるソフトがあれば、
どんな手段で生成されたパラパラアニメに最終的には修正出来て、
最初の素材を出力する部分は単なる効率化のためのものでしかない
とか思うようになった

色々考えるけど皮肉すぎて扱いに困る
けど考えてるのは、より前向きに高機能なソフト目指しましょうってことだ
自分がやりたくない事を代わりにやってくれるソフトじゃなくて
自分のやりたいことをやらせてくれるだけのソフトじゃなくて
自分がやろうとしてることをより便利に実直に真正面から取り組む為のソフト
他のやり方ならもっと簡単になるとかそういうんでもなくて
かと言って苦労して喜ぶ為のソフトでなくて

Name: oga Time: 2008/11/12 - No.702

昔メタセコのプラグインレンダラを作り掛けてた時に漠然と思い浮かんでた
「レイヤライクなリスト構造で描画処理を記述出来たらいいな」がようやく実現出来そうな気がしてきた
もう何年目だろう

と言ってもずっとそのことだけ考えてたわけじゃなくて
スクリプトとかスタックとかサーバー＆クライアントのモデルとか触ってるうちに材料が揃ってきて
決定的だったのは実験でフォトショのレイヤでフィルタ回路みたいなもん作った時に小数点以下の値の切捨てが起こってる事を意識出来たからだ

皆がそうやってるからって考えなしに、レイヤの合成は2枚単位で行なうつー観念に囚われてたっぽくて
そうじゃなくても良いと思えるようになったら途端に
今レイヤの形で弄ってたものがレイヤじゃなくなっていく事に気付いた

あとレイヤのリスト構造でただのUIであって別にデータ構造を表現出来てる訳じゃないんだよね
って考えるとよさげな気がした
何の為にリスト構造が、どんな使い方だと効果的なのか、

そしてスクリプトで処理を記述するブラシと複数レイヤに同時に描き込みするブラシも合流したらどうなるだろう？
というのを今考えてる所
さて動くものはいつ出来るのか

しかし最近の自分のテンションの低さよ

Name: oga Time: 2008/11/12 - No.703

ところでスクリプトってそんなに普通の人は触りたくないものなんだろうか？
自分からするとレイヤだってアクションスクリプトだって扱うUIが違うだけで本質的な挙動と自由度にさして差は無い気がしてるんだけど
スクリプトでブラシカスタマイズできますーってお絵描きソフト作ってもスクリプト弄ってくれなきゃどうしようもない訳だけど

でそこでスクリプトをレイヤみたいなリスト構造や縦横のテーブルで記述できたらいいのかもと考えたりしてます
予約語とか関数名はボタンとキーショートカット登録と入力予測でどうにかして、識別子や関数名はスコープで勝手に追加するとして
タグ挿入型のHTMLエディタみたいにして入力の手間を減らしたとしても、本質的なスクリプトの挙動の読みにくさは変わりないんだけど
でも別にそういう複雑さが理解出来ないんじゃなくてただ単に文字読んだり入力したり覚えるのを嫌がられてるような気がしなくもないので
そこは丸めないつもりでいるんだけど

例えばフォトショのアクションスクリプトは普通にスクリプトをリストで記述で来てるけど
せいぜい条件分岐やループが無いってくらいで
他のことは大体上手くいってる気がする
スタックについてもレイヤのバッファをプッシュしたりポップしたりすれば頑張って出来なくないので
後は手間が減らせれさえすればどーにかなりそうな気はするんだけど

もすこしスタックとか一時バッファとかサブルーチンとかスコープとかを綺麗に表現できればどーにかならんだろうかと考えたりしてる

必要最小限の要素で構成する事に興味あるわけではないし
普通に使いやすいのは豊富に関数がパーツとして用意されてて、既存のブラシやフィルタもフリーソースなスクリプトで実現されてるような
そういう画像編集言語的なものがあればいいだけで

なんとなくそういうものを考えてる所なのだ
出来れば絵チャ並のネットワーク機能もつけてってのは望み過ぎだろうか

Name: oga Time: 2008/11/12 - No.704

上手くスクリプトをＧＵＩで記述する方法が実現できれば
ゲームエディタも作れるし、もっと皆が触ってくれるようになると思うぜ

でも俺は多分コードの方がわかりやすくて好きなんだ
だってコードって1次元なんだ
1次元なのにちゃんと多次元の構造を記述出来てるところがすげーんだと思う
書いてる途中はいくら文法間違ってても文句言われないし
文法に沿うようなエディットしか許さないとむしろ能率が落ちる気がするし
やっぱポイントは分かりやすさなんじゃねーかとかおもたり

Name: oga Time: 2008/11/12 - No.705

紙の上に定規置いて距離を設定するとそこを消失点にもう一本の定規が開いていくコンパスのような道具を思いついた
針を打って支点固定してからアームで絵をなぞると二倍三倍に拡大してくれる道具があったけど
あれを支点なしで実現すればいいだけなので、ちょっとしたクランク組めばいいだけであった

けど、それよりスマートな手が2つも思いついた
1つは幅40センチで長さが3メートルぐらいの布にパースグリッド印刷しといてそれ紙の下に敷いて使うってもの
広い机でゆったり描けるなら便利そう、何より迷う所が一つもない、問題はその大きさだけ
もひとつは多分今あるパース定規と一緒の原理で
A3くらいの紙に三角形のパースグリッド引いたら、計算した消失点までの距離にしたがって2本縦線引いて
二本分の交点を紙に写す時に間を広げるとそれで距離がN倍出来るって奴

つーても結局の所、いちいちパースグリッドを引く手間を減らせるかどうかってことにしかならなくて、そこはコンパス式の利点になるけど、
それで絵描く訳じゃねーから結局グリッドでいいのか
そういう所を強化してくれる3Dお絵描きソフトがあっていいのにね

Name: oga Time: 2008/11/12 - No.706

そうだ
コピックの調色してて思ったことだけど
濃度と見掛けの色の濃さは比例はしてないのね
二乗か三乗か10のN乗かになってるみたい
半分の色の濃さにしたい時は加える液の量は1/10とかそんな感じ
あとエアブラシで塗装してても、ずーっと薄吹きしてたのにある瞬間に突然色がつき始める感触とか
濃度と色には何か不思議な関係がある

つーてもそれがインクが光に色つける仕組みに寄ってるのか
ついた色か色がつかずに反射した色と混ざる時の比率の話なのか
人間の目の特性なのかはよくわからないが

もしお絵描きソフトでそこら辺を気にして処理作れば
本当に水彩っぽかったりマーカーっぽいソフトも作れるんだろうか？

あとインクの名前で色呼んだり、白や黒にも複数種類があったり
紙を替えるとにじみや沁みの特性がガラリと変ったりするようなのもいいな

とか考えてる所で
スクリプトや画像処理言語作って自由度求めることよりも
その自由度で作った関数やクラスオブジェクトをGUIやイベントとどう関連つけるかって部分の方が面白そうだとおもった
理解しやすい操作しやすい概念を実現できてれば、それがどんなパーツで組み上げられていてもどーでもいいのだ