Format   W x H      Animation
No.193

  (10699 B)
Original size / Anime / Continue

Name: oga   Time: 2007/11/16
PaintTime: 7’32”

SAIのS補正が、少しおもしろい。
基本的には遅くてカーソルの動きについて来れない補正なんだけど
(SAIの補正はカーソルの動き自体にかかる場合と、カーソルと描線が分離して描線画遅れる場合とある)
最後の抜きを思いっきり払った時に、遅延してる箇所から抜きが始まるのが面白い
普通に単にカーソルの動きをバッファして処理の関係で遅延してるだけならそうはしない筈なのに、どうしてそんなことしてるんだろう?

意図はわからないけど
俺はなんとなくつけペンのペン先がビョンってはねた感触を思い出してちょっとうれしくなった
それ以外のほとんどの局面では、分離してる描線とカーソルにイライラがつのってるんだけど、最後のハネるのだけは許せそうである

そういう目線で思い出せばカーソルの動き自体が重くなる一部の補正も、ある意味では何かしらの感触を感じさせるものではあったかもしれない
俺は凄く重く感じるよ、水飴をガラス棒でかき回してるみたいに感じる

問題はこの挙動も感触も全く理屈に叶ってないってことだ
つまり、制御方式としては能率ダウンで情報も劣化してるし応答速度も悪いし品質も落ちている筈だし、一度この方式採用してしまうと他に応用できなさそうである
だけど、本来在り得ないタブレットから手へのフィードバックがあったと感じてしまった所が特筆というか
ある意味で1つの方向性を指し示してしまったように思う

絵掲のドット線がモニタ上で見る描線に対して、割りと低い位置に1つの正解を提示してしまったように。


ここまで言うと、
このコンセプト大事にしてコンパクトで低級志向なお絵かきソフトを1つ完成させるべきだ
てー話にも聞こえなくもない


後別件だけど
SAIの線に対してちょっとしたイライラがあって
ペンの入り抜きで抜く時に、ちょっと離れるのが早い気がする
ストロークペンで粘らすのがいいんだけど
補正として抜きにだけ粘りいれれないだろうかね
線つないだつもりで繋がってないのでイライラします、かなりイライラします。

Name: oga   Time: 2007/11/16  - No.194

特殊な感触のお絵描きソフト作った時、大事なのはサポートが切れて対応OSがなくなるまで何年使えるかだと思う
そういうマルチプラットフォームなは思想もノウハウも俺にはない訳だけど
特殊な感触ゆえに、それを使い込む時間に見合う分くらいは安定して使えなきゃ困る

ペン入れ専用ソフトって物のインターフェイスがどんなモノになるかは分らないけど
何かそういうアイディアは必要なのかも

windowsのメッセージのやり取りで、別々のプロセスで起動したペン入れツールと原稿用紙ツールと定規ツールを組み合わせて使用てのは出来なくないだろうけど
一番大事であろう、スレッド間の連携に手間取りそうで意味がなさそう

やりたいのは、タブレットやモニターやファイルやキャンバスやレイヤの仕様や挙動から、
カーソルが動いて線を描く動作を如何に切り離すかで
そこを維持した状態でどんくらい他の部分を簡素に、あるいは機能的に作れるか…

Name: oga   Time: 2007/11/17  - No.198

同人誌の方がどうにも形が見えないのでこっちの方が作業したくなってしまう
そんな折に今日の占い
「形に残らないことに力を入れて、損をしているように感じられても、実は幸運な日のようです。見栄を張るために行動することはやめましょう。」

アハハハ
笑えねーよ

Name: oga   Time: 2007/12/01  - No.258

えーと
ペン、フィーリング、M、Lてのが出来るかどうか…
タブレットからの入力をストロークとして抽象化して、
抽象的なストロークに対して、描かれる描線を記述する
というのが出来るかどうか

基本的にはペン持ってるんだから、ペン先の位置と速度と時刻と3角度、それに筆圧があればそれでストロークなのかな
WinTab規格で十分なんだけど、時刻や曲線に繋ぐ補間式までは含めていないから、そういうのもあわせて一連の「ストローク」てものにする

ペンはペン先の形状とインクの出方と出たインクが紙の上でどう挙動するかの3つ

形状は、鉛筆、シャープペン、マーカー、ウレタンニブ、ボールペン、付けペンの6種、これにインクが出る部分のマッピングと応力に対して変形具合をスプリングやボーンで指定できるように

インクの出方は、補充量と紙への吸われ方とペン先のどの部分にどんくらい供給されるか、それと溜まり方

紙に出た後は表面張力と粘りが大事、あとは紙の上でどんな濃淡出すか


というのを記述できればいいのかな?

Name: oga   Time: 2007/12/02  - No.267

レイヤの枚数の話。

俺っチて別に色を重ねてったりフィルタリングしたり色を差し替える為にレイヤ分けしてる訳じゃなくて
単にいちいち塗りの時にマスキングを切り替える手間を惜しんでレイヤに分けているだけで
実際には無数のアルファチャンネルと1枚のレイヤ(+線画で2枚)があればいいんだけど
でキチンと順序だてて行えば、予め色分けされた領域と色マスク機能と2枚のレイヤでコピーと結合繰り返せば実現できる訳だけど

本来やりたいのが選択チャンネルの切り替えを、レイヤの切り替えに摩り替えた上に更にそれを2枚のレイヤと作業工程の順序で置き換えた訳だけど
あんまりにもやり方が決まりきってるのでスクリプトやアクションにすればいいんだけど

今興味あるのはその、複数枚のレイヤ使うことを順序と重なり型を限定して2枚に置き換えるってアルゴリズムと、選択チャンネルの切り替えと色マスクの連携て部分なんだな
別にレイヤ数を抑える事に興味がある訳じゃなくて、多分他にも色々あるであろう「作業の順序を限定すればもっと少ないリソースで処理できること」に普遍的に適応できるアルゴに興味ある

といっても、興味があるだけで今のところそれ以上の切り口が思いつかない

色マスクとチャンネルの切り替えは、
しぃに色選択があれば1枚の色分けされたレイヤをソースにしていくらでもきりかえれたのに…て部分に8byteの選択チャンネルとは別にニーズを見出したかったりする
個別のアルファが必要ならレイヤの透明度保護が一番ですよ
選択範囲の濃度では筆を重ねる度にどんどん濃くなってしまいますから

Res

No.224

  (21716 B)
Original size / Anime / Continue

Name: oga   Time: 2007/11/24
PaintTime: 21’7”

GIF透過配置ツールの先に想定してるwebアプリ「なんとかダンサー」
振り付けデータを投稿して再生したりコメントつけたり出来る
3Dを使ったアプレットの掲示板で、多分ログイン制のエチャにも出来る

基本的には鯖上にあるモデルとマップのリソースを、スレッド掲示板のスレッド立てる感覚で配置して
次にスレッドにレスをつける感覚で、ポーズかコメントを投稿する
ビュウワアプレットでスレッドを読み込んで、上から順番にレスを適応していくと、アニメーションになっているって仕組み
コメントの場合はフキダシとして描画される

基本的にはこれだけだけど
拡張として、モデルデータや新規テクスチャの投稿や差し替えが出来るようにして
レスでオブジェクトの追加配置が出来ると遊び方が広がりそう
コメントにもななしのモブコメントとキャラにフキダシつけて喋らせる台詞コメントがありそう

モデルデータとアップロードもつけば、鯖にどんどん新しいモデルデータを追加出来て遊び方も広がるでしょう

ポーズデータは基本的にはテキストで、理解出来る形式で手打ちも出来ると便利だけど
再生はどうせアプレットだから、アプレット上でポーズつけてそのデータを投稿してもよい

モデリング機能は想定しない方がいいだろう、一気に複雑になる。


ボーン構造は、基本的に人型のベース構造があって、それの部分構造と一部カスタマイズでバリエーションを増やし、派生の構造のポーズデータでも無理矢理基本人型データにコンバートして他の派生型にも適応出来ると素晴らしい
手足を等価に扱って交換できるIKが欲しい
ポーズつけの為のIKハンドルも使いやすいものが望まれる
シチュエーションによって下半身や上半身の姿勢制御をオートとマニュアルの比率で制御して、カーソルのトレース機能とかもあるといい
簡単な物理演算処理も入れて地面の上を歩くとかジャンプするとか、そういうのも出来るといい

あそうだ、カメラ制御も必要な筈。

チャットモードにする時は、しいエチャみたいにPC上に立ち上げれるといい
ただ、リソースが複雑になるので、出来ればベースとなる掲示板のリソースデータを読み込んでチャットにする動作がいいとおもう
掲示板がドキュメントの格納庫として凄く重要になる訳だ
勿論チャットから掲示板への直接出力もあって欲しい

あとは動画として吐き出してニコニコ動画みたいなとこに流せれば…

Name: oga   Time: 2007/11/24  - No.225

スレッドは最低1つ以上のキャラクタとステージで構成され、1つのタイムラインと1つのカメラを持つ。
スレッドを組み合わせたりインスタンスやシンボルとして描画出来るのはいいと思うけど
現在編集中のスレッドは1つであるべきって気がする。

掲示板のリソースを使ってエチャ立ち上げるとそのスレッドがチャット中とマークされ、編集不可になる
スレッドにログインして鯖からチャットのアドレスを受け取って参加すれば良い
チャットが終った時や、オーナーが書き出しした時に掲示版に反映される
エチャを非公開スレッドとして立ち上げてもいいと思うけどね

エチャにした時大変なのは
各ユーザーがどの時間軸のどのオブジェクトを編集中か、イメージしにくいことだろう
キャラクタ自体を自分が編集中ってことでロックしたくなったり、時刻違うのを分担して作業したり
色々あるだろうから、何種類かのロック機構が欲しいとは思う

荒らしが湧いた時の被害が甚大だから
掲示板の投稿データは全部保存していつでもロールバック出来るように
エチャにログインする時も設定すれば掲示板のログイン認証と組み合わせて登録ユーザーのみにも出来ると便利

投稿するドキュメントには、再生用のコンパイル済みデータと編集用のドキュメントデータをセットにするといいと思う
クライアントとホストでどこかで線引きしなきゃいけないのだけど
コンパイル済みデータで共同作業性が落ちても嫌だし、ドキュメントデータをいちいち鯖で処理させて負荷かけて再生するのも嫌だし、バランス取るための妥協ライン探すのも難しいでしょう
だったら両方載せとくのが吉

基本的に今言ってるのってwebで運用するツールとしての外見上の機能の話で
直接作業性に関わるツールの出来の良しあしの話はしてないし、まだ想定していない
簡単手軽に的確にそれでいてカッコよくポーズ付けが出来て、絵を描いている感覚を忘れないツール…
てのはちょっとすぐには思いつかない


人形が1つあって、それをどう動かすかという部分を、如何にネット上で皆が参加しやすい形で実現するか
それがテーマな気がするよ

Name: oga   Time: 2007/11/24  - No.226

多分、あんまり細かい所気にするよりさっさと掲示板とエチャとシステム全体作って見て
アプレット部分は最後に作り込んでった方がいい気がする
最初はモデルデータ固定でテクスチャもなし、カメラも固定でいい、投稿出来るのもポーズとコメントだけで
後々コンバーターで処理する骨格だけ作っといて
ポーズも最初はIKの逆の…なんだっけ、親子座標系をただ回せるだけにして
それでいいと思う

Name: oga   Time: 2007/11/24  - No.230

1つのモーションを1スレッドで作るとする。
まず最初にスレ立て主がモデルとボーンを定義して、初期状態として立ちポーズとリンクしとく
次に、最初追記処理としてレスが順番に投稿されて、一通りの動きが完成してから
次に修正として時刻とポーズでモーションが改訂されて行く
無数にある改訂版のどれが良いかはわからないから、編集された順番は維持するけど、最新ほど正しいとは言えない訳だ
どれを選ぶんだろう?

修正付加の追記モードだとリレー漫画を描いてるようなノリになって、これは1つの使い方だと思う

それとは別にある目的があってその為のモーションを一つ作りたい場合、例えばタイムラインの全長とかはスレ主が決めちゃっていいんだろうか?
この場合、最初にキーとなる大まかなポーズを配置してから、少しずつ全体を煮詰めていく感じになって、その変遷を見るにはコメント数×モーション時間の分だけ再生しつづけなければならない、凄く長い。
多分、基本的に投稿された修正レスをシークエンスにまとめたリストが1つあって、レスの一つ一つにはIDがついてて、同時に自分が修正したつもりのドキュメントに今までどのIDが適応されていたか、逆に言えば自分より前に適応された修正でも除外して修正しちゃうことが出来るとして、
だから1つの修正レスを選択すると、それより以前のレスの中で適応されなかったものはグレーアウトされるとする
あるいは、基本的には自分より以前の修正は全部適応されているのが前提だけど、明示的にそれを除外した場合、その時点でバリエーションに分岐が起こって、系統図表示モードになる、とする。
基本的にはこの系統図は分かれる一方でもう交わることはないんだけど、他の系統でいい修正が入った時にそれを取り込む動作も在り得る訳で、修正IDの参照リストがそれを実現してはくれる

この系統樹は時間が進むほど全体としての修正度は上がるけど、何かの素材として出力する時は、樹のどの部分かを指定して出力する。それは修正IDを指定すれば、その修正と適応先の参照リストの組み合わせで、バージョンが特定できる

一本の系統であれば、5段飛ばしとか10段飛ばしで再生しても修正は蓄積してくだけで問題ないけど、樹が分れた時は別々に表示する事になると思う
分かれた瞬間じゃ1つの修正しかないから無駄なので、枝が分かれる最後のバージョンか、枝分かれしないうちに何個の修正が累積したかで、修正の利き具合を指定出来るようになるかな。

一番良いのはこの樹を見てバージョンを確認するよりも、別にあるコメントリストを見て誰がどの修正をどんな目的でやって、結果的にどんくらいの出来になったか、クチコミの評価を当てにして選ぶのが良くて、確認したい人は全部確認してみればいいとなる。
どうせ自分で修正する時は、自分が修正する箇所は何度も何度も繰り返し再生してみて繋がり確かめる訳だから、その近辺に関しては保証できるといい

逆に、保証してない範囲をマスキング出来るのもいいのかな。修正した範囲が被ってなければ、それは合成して構わない訳だし、1つの修正に関してそれの適応前と適応後を比較するのは大事な事だし。


で今言った話は、どのバージョンのモーションを採用するかの話にも関わる
最初に言った「スレ立て主がモデルとボーンを定義して、初期状態として立ちポーズとリンクしとく」の立ちポーズに複数のバージョンがあってより後の修正がこれが改定された場合は…となる。
参照リストも後で書き直せる権限がどこかにはある訳だ。
書き直せる権限というよりは、後で修正可能なリストとして参照元を指定してて、暗黙でそれに従いつつも必要ならそれを再指定したり、バージョンアップでリストが更新されたり…と言うことである。


ここら辺の動作を少し良く考えて欲しい

Name: oga   Time: 2007/11/26  - No.245

まずお勉強。
基本的に俺が知ってるjavaアプレットの運用例はしいエチャでこいつは多分6年か7年前であるけど
今の所需要は満たせているのでお手本にするとして…

アプレットが大事なのはブラウザ上で実行できてプログラムの配信やアップデートとコンテンツの提供を一緒に出来る事だ
一方でローカルファイルへの保存や参照を好き勝手には出来ない仕組みがあるらしいんだけど、署名をすれば大丈夫らしい
ActiveXと一緒なのかな
そうでなくても普通にjavaアプリ組むのとアプレット組むのは少しずつ違いが出る

それに対してJavaWebStartてアプローチが普通に組んだJavaアプリを、ブラウザで配布、アップデート、起動が出来る仕組み提供してるらしい
やろうとしているのは、絵掲示板、エチャ、ローカルアプリの3種類の使い方が如何に簡単に出来るか
出来ないとすればどれを切り捨てるかでいうと
結構いいバランスなんだろうか?

とは別にFlashて選択肢もあるでしょう
こっちはまるっきりアプレットでしかないけど、Javaより強力な動画再生能力があることとそれ使ってプログラムが凄く簡単そうって所
3Dエンジンやフリーのコンパイラもあるんだけどタブレットから筆圧を読み込めるのだろうか?


でこれらじゃなくて普通のローカルアプリをC++で作るとなるとどうなるんだろ
プログラムの配布とアップデートは、まぁアプレットじゃなくてもいいし、
掲示板との連携もできなくはない
エチャやるにしても3Dやるにしても、何よりパフォーマンス叩き出すのには便利
Windows限定になるけど、この場合は仕方ないのだろうか

じゃアプレット使う意味ってなんだろ?
専用アプリ入れないと閲覧も出来ませんよって言った時に見てさえくれない大多数の人が相手なんだろうか
それともちゃんと使い方覚えて使いこなしてくれる一部の人向けなのだろうか…

さてエチャはどっちだったんだろ

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