Format   W x H      Animation
No.85

Name: n   Time: 2006/12/29

絵チャだけど、
実はパラパラマンガ機能を作ろうと画策している。
通常キャンバスと他にもう一枚Αつきのテクスチャキャンバスを用意して、それをフレーム毎にポリゴン使って呼び出せば、とりあえず実現できるはず。
どうせ自分はWinアプリしか作れないんだから、DirectXのみで作っても問題ないのだけど、なんにしても3D関係の処理を3Dアクセラレーター使わないといけない気がする。
単純な３角ポリゴンをテクスチャつきで描画出来ればいいんだけどね。


この2dと3Dの組み合わせが、色々と自由度があって
どんなバランスでどんな組み合わせ方するかで、いくらでもバリエーションがあるみたい
考えただけでも4つ6つくらいは別々の用途がありそう

射影変換とローカル座標とリグ構造、これが使いこなせれば色々と応用が広がる

Name: n   Time: 2006/12/29  - No.86

ここら辺の仕組みと塩梅は大体テキストにまとめてしまったのでここで今更書くものでもない

あーそうだ
えーとテクスチャを描きながら3次元のモデルに反映されていく時と、3次元のモデルの上に筆を這わせてテクスチャを書き換える時と
モデル的には対称な2つの同一のアルゴで順逆として示せる、のだけど…
サンプリングの時にノイズはどうしても発生するので、それをなくすにはどうすればいいのかな？と考える。

いやサンプリングについては割と手詰まりで、テクスチャかポリゴンかどっちか解像度の高い方でドキュメントを保存するしかない
本当に欲しいのは、そんなアルゴではなくて1対1の解像度でどうやってロスを抑えるかの話だと思う
基本的には四角窓とか円形窓とかそういう話になるとは思うけど、ポリゴンに貼り付けるテクスチャにそんなフィルタが施せる訳ではないので微妙だったりする

それとは別に、使う人間が混乱しないようにするにはどうするかってのも考えるけどまぁこれは
同じ挙動のブラシでも常に二種類あって、一方はソースがテクスチャで一方はポリゴン側にソースがあるって具合になると思う
チェックボタン一つで切り替えるのが妥当なのだけど、もっとツールの上の階層で分けた方がよろしいと思う

なのにブラシの中身は共通だったりすると、バカっぽくていい
なんか斬新じゃん？

Name: oga   Time: 2007/09/08  - No.143

絵チャ
楽しい絵チャを満喫してるとどうしても「ああこのメンバーでもっと新しい絵チャがしたい」と思ってしまって絵に身が入らなくなる
病気か言い訳か
とりあえずパラパラ漫画絵チャが結構タスクの上に居る。

3D絵チャの場合、テクスチャリソースの管理をユーザーに見せるか見せないかの問題で
見せる場合には、パラパラ漫画絵チャとほとんど同じGUI構成になる

少し違うのは、3D絵チャは空間に対してのテクスチャの投影、つまりUV値の再設定があって
パラパラ漫画絵チャにはその代りに平面上へのポリゴン配置がある。
実際には投影の仕方決めるにしても一枚のポリゴンと視点位置との投影で投げるしかないので
この2つの絵チャはほとんど同じモジュールで出来ている。

違うとすれば、キャンバスVIEWに表示される視野が3Dか2Dかくらい
そして可能なら3D絵チャにもアニメーション要素を取り入れて欲しいのだ
なぜかっつーと3Dに絵が描ける絵チャよりアニメが作れる絵チャの方が遊べるから
あとニコニコ動画が流行ってるのも少し追い風

という訳で方向性はパラパラ漫画絵チャットに絞られている

Name: oga   Time: 2007/09/08  - No.144

ほとんどの部分の動作は大体想定出来ているので、実際に作る作業して完成に至るかどうかだったりする
本当にそうかな？
いや結構頑張ったよ、大体想定出来ているよ

基本的には多人数でフラッシュアニメ作っているような絵チャだと思いねぇ
トゥイーンは難しいから、ポリゴンアニメを平面的に行う仕組みにしている
ユーザー一人一人がキャラを定義するとキャラのローカルタイムラインが生成されて
そこにキーフレームを配置して、キャラクターシンボルを背景となるステージに配置して
それを再生するとアニメーションする、て具合

今まで作ったアルゴだと、タブレット周りの通信いろは、DirectX使ったDOT線、DirectX使った描画と、回路逆転してテクスチャに書き込むアルゴリズムとかは想定できてる
絵チャットのログと通信ネットワーク関係は未経験なので全然分からん
どっちにしてもコマンドをシリアライズしてストリームにして管理するだけだろうから
大して難しくはないと思う
ネットワークのパフォーマンスとか安定性は素人に期待するだけ無駄でしょう。

Name: oga   Time: 2007/09/08  - No.145

パラパラ漫画絵チャてのはしっくり来ないから動画絵チャとでも言えばいいのか
MoVチャ？

成功の鍵は2つで、
如何に直感的な簡潔なワークフローを実現するか、これは俺の実力次第。
も一つは時流や使う人の共感呼べるかどうか、要は話題性。

しい絵チャやってて常々思ってたのは矩形ツールで画像の書き出しが出来れば楽なのに、てのとログファイルがとにかく扱いにくいことかな
動画の場合絵チャのように書き捨てていくのは勿体無いので、1つのドキュメントがかなり長い間参照され続けるから、しい絵チャのような具合では芳しくない。
矩形ツールによるログ書き出しは、キャンバス上に動画書出し用の矩形フレームをいくつでも配置できてそれをローカルに出力できることかな？
可能であればflvコーデック使えれば、ニコニコ動画とかに直接上げることが出来る

チャットしてる画面をアップして自慢しようとかじゃなくて
動画作成ツールとして実用できないかっつーこと

テクスチャ上に絵を描いてそれをポリゴンに貼りつけてステージに配置できて、それをタイムラインでアニメーション出来るとして、
それだけでは使いずらいモノでしかないだろう
だからステージ上からそのポリゴンに対して絵が描けてそれがテクスチャに反映する回路がどうしても必要だと思う

それさえ出来れば、後はポリゴン使って、テクスチャを差し換えるか変形するかしてアニメーションさせる
変形アニメーションの方がAF的でいい気がする
将来性感じる

後はパラパラ漫画描く時の利便性をどこまで追及できるかかな
ウェイト方式のタイムラインであるとか、フレームに名前つけて参照呼出しが出来るとか、シンボルだからインスタンスとして何個でも配置できるとか、その手の話。


皆で絵チャットで作るワイワイ感出すために、作業は主に共通のワークスペース上で行う
ワークスペースは背景画像+αくらいの大きさだけど、領域外にもある程度の広さはある事にする
絵チャットのキャンバスと違って、背景画像領域の外には描画は出来ない
その代り生成したポリゴンキャラクタのインスタンスを配置すればそれには書き込める
要は場所が狭くなった時は外の方に並べて作業しましょうってこと。

背景画像の全体かその一角に、動画書き出し用のフレームを用意する。これはみんなに見えてる
ここに動画作るから映したいものがあったらここに配置しとくれってなる。

ワークスペースのタイムフレームとは別にキャクラタ毎のローカルタイムフレームがあって、キャラを編集してる人は主にこちらで作業してて、多分ワークスペースで何が起こっているかは見えない
これは仕方ない

更にテクスチャ空間レイヤーてのがあって共有リソースであるテクスチャ上に皆が所狭しと画像を配置している
ホントにキッツキッツに配置する。
テクスチャを贅沢に使ったパラパラ漫画は嫌われる恐れするある
でも仕方ない

DirectX使って一番辛いのはビデオカード毎に固有サイズのビデオメモリで
それを仮定できないからだ。
128MBはみんなあるだろうか？256MBでも動画を一つ作るのに足りないんだよ実際には

Name: oga   Time: 2007/09/08  - No.146

実際のとこ、機能があらかた実現したとしても、バランスの取り方でかなり調整が必要だと思う
運用してみたらメモリ食い過ぎで5人も参加すればアップアップてなるかもしれないし
それでメモリ節約の為に変形アニメーションに方向性をシフトするかもしれない。

元々変形アニメを手軽に作れるソフトが欲しいから模索してるジャンルではあるんだけどね。

後はドキュメントの寿命に付いて。絵チャだとせいぜい4時間だけど
動画で4時間で一本作るのは辛いかな…

前回のドキュメントデータをログとして読み込んで全員に配信するのはトラフィック的に結構な負荷だと思う
かといってネットペインタみたいに事前に渡すのはもっと大変なのだけど
絵チャットサーバーとログリソース配信サーバーは分けて欲しい
可能なら参加者の誰か、光回線で上り帯域が余ってる人にログホストを立ち上げてもらって
絵チャットホストとログホストが連携してチャットを運営できるとよい
負荷がかかるのは新しいメンバーが入室した時だけだけどね。

ドキュメントデータの読み込みを基本とするんなら、
予め素材として、背景やテクスチャやポリゴンをある程度配置していてもよくなる
出来れば、誰からでもそれが出来るといい
つまり2つのドキュメントの間でシンボルやリソースの受け渡しをする手段が欲しい
これは難しい
元々有限のリソースでキチキチで頑張るつもりだったから、誰からでもリソースの追加が出来るっつーのはかなり無理がある
最低でもホストさんの管理の元に事前に素材を全部くっつけたドキュメントを作ってもらっといてから…

なんてことが能動的に運営してる絵チャで出来る訳がないから
やっぱ何か欲しい

キャラクタ単位でパッケージしたファイルをZip圧縮してホストやログサーバーに渡して開いてもらうと…
て感じで。
実際にはかなり難しい
そもそもテクスチャ空間は有限で、既に他の絵が展開されている訳だから、
ある程度配置に調整が必要になるし、その調整を施すまでの待ち時間てのもある
自分のデータなのにホストさんに作業してもらうのも心苦しい

それともう一つ
絵チャでキャンバスが狭い時絵が描けなくて手持ち無沙汰なので、ローカルキャンバスというスケッチブックを各人が勝手に持てる事にしよう
絵チャットという仕組みに逆行してるけど、こんなのがあってもいいんじゃないかなと

つまり
ローカルスケッチブックキャンバスに、送信したいデータを展開して、そこからドキュメントテクスチャに自分で配置すると
そのデータがホストに渡って少し時間たってから全員に反映される…

なーんて仕組みが実現できれば素晴らしいのになぁ

Res
No.136

Name: oga   Time: 2007/07/17

変なのが思いついたので記しておこう
前からアニメの作画作業を能率的に進める為に、動きと色と形をセットにした何かの概念が欲しいと思ってた
なんとなく画素にたいして動素とか名前付けてあれこれ想像してたんだけど、有向面的な何か程度の漠然として考えしか思いつかなかった


今ちょっと考え方が変って、別のものになった
モブゴンと仮に名前付けているそれは、ちょっと別のルートから発生してきた別の概念である

着想の第一は、例えばFPSゲームのログデータとテクスチャを使って、既存の映画やエロビデオをエンコードしたらどうなる？
てモノで、エンコードの方法論は皆目見当がつかないけど、圧縮されたあとのデータとその再生方法は極ありふれていてリーズナブルな方式になれると思う
データ的にも処理能力的にも

でまた別の角度から別の状況
今の動画圧縮技術てのは、基本的にはベタなラスターのベタフレームな未圧縮動画があった上で、それをエンコードする方式で成り立っている
ゲームで行われている、ポリゴンとテクスチャを作ってモーションを作って再生するアプローチとは、全然別ものだ

でも少し考えてみて欲しい
今映像をコンテンツを作ろうとした時に3DCGの扱いやすさを無視していいんだろうか？
つまり今ある動画が作れる3DCGソフトてのは、ポリゴンとテクスチャとモーションを使って一度ベタラスタベタフレームな動画を生成するもので
そのベタラスタベタフレームな動画をも一度エンコード変換することで圧縮された動画になる訳だけど、
そのベタラスタベタフレームな動画の状態を省いたものが、ゲームとかのログ再生方式で
それって凄くリーズナブルじゃないかってことだ

でも本当はもう一つバリエーションがある
DirectXやOpenGLのような手続き型の映像記述言語を直接制御することで、ゲームとかの描画処理は成り立ってて、
その手続きと使用するリソースをそのままストリームにするとログ再生的な映像方式ができる
その逆で、圧縮された動画のストリームの各文節を吐き出す映像記述言語ってのも、なくはないだろう？
てことはそれを直接操作するコンテンツ編集用のアプリケーションだってあってもいいだろう？


基本的には一つのモノの話をしているつもりなんだけど
そいつが真価を発揮するには二つの条件を満たさなきゃいけなくて
それが「圧縮済みのストリームを直接編集して生成できること」と「編集ソフトと再生ソフトが同じ方式でパラメトリックに記述されていること」となる
同じこといってるつもりだ

でもなんか今あるコンテンツ編集ソフトはベタラスタベタフレームな動画を吐き出すまでを領分として
動画圧縮の規格はベタラスタベタフレームな動画を圧縮することを領分としていて
編集と再生が行える映像保存方式は、それぞれの狭い分野の中にチラホラと見掛けるだけな気がする

つまりモブゴンてのは
コンテンツの編集者にとって理解しやすい直感的な概念であり操作単位でありながら、
圧縮再生処理やログストリーム内においても同じく映像の基本単位になり得る概念
となる。

Name: oga   Time: 2007/07/17  - No.137

基本的にそういう体験をいくつかしている
スクリプトで作業が全部記録できるペインタ―がまず最初の体験だった気がする
もしかしたらファミコンのセーブデータだったかもしれない
イラレやフラッシュや絵チャ、それにFPSやSTGのログリプレイデータ
どれも編集と再生がセットになった1つの統一的な概念で理解できるモブゴンだ
一方でどれも自分の領分とする狭い範囲に留まってそれを理解して編集出来るようになるには、職人的な「理解」が欲しい気もする
何か根本的な原因があればいいのかもしれないけど、第一には「自分の領分だけならそれを実現することは容易い」てことだ

そうでなくても
3DCGで映像を作ってるなら、そのデータをそのまま渡して再生した方が劣化がなくて軽くて良いに決まってる
ベタラスタベタフレームな動画を挟む理由は「自分ではコーデックを作れないから」以外の理由がない気がする

ビデオカメラで映像撮って圧縮するのは全く話が違って
エンコードの際の画像や動体認識が欲しくなってきて
それは俺には全然わからない

俺がわかるのは
自分の分かる概念を自分のわかる範囲内で編集して映像作るのなら10年修行すれば誰でもものに出来るってことだけだ

Name: oga   Time: 2007/07/17  - No.138

圧縮済みのデータストリームを吐き出す映像記述言語だけど、応用範囲は結構広い気がする

それを解釈して再生するモニターがあれば、汎用性は凄く狭いけど、渡すデータ量はぐっと少なくなる気がするし、何よりリフレッシュレートがモニタ側でいくらでも水増しできる
ちょっと目に優しい

まぁすぐにはそんな素晴らしいものは思いつかないので
まずは既存のコーデックに従ってそれを直接編集するツールを造ってみたらどかなって思う
まず最初はJpegの量子化された矩形や色を直接書き換えれるお絵描きソフトだ

それの動画版になってはじめてモブゴンっていえるけどまずはそんな所だ


mpeg4の規格にその手のアプローチがないのかなーと思ったら
今のmpeg4は単なる動画圧縮形式ではなくて、文字やベクタや3DCGの各要素を含むことが出来て再生には3DCGレンダラを使う統一的な映像記述環境になっているのね

だったらもう少しじゃね？

Res
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23, 
No.   Pass   画像のみ削除    
POTI-board v1.32   Web Style by Limited_C   OriginalScript - futaba.php (gazou.php custom)
OekakiApplet - PaintBBS  ShiPainter  UseFunction - HTML template, DynamicPalette  -- Admin