Name: n_n   Time: 2006/08/15  - No.38

1ヶ月くらい暇があるのでなんか作業するか、絵でも描くか

メタセコアはstation系が追加されたのでシェーダーを作り直していいんだけどアウトラインレンダーの個別のアルゴは割とどうでもいいんだけど、インターフェイスとして汎用オブジェクトリストを積んでやらないと美味しくはないと思ってるんで
そこらへんの構想がまとまってから。
でもまとまるとすぐに、メタセコアのプラグインである必要性が薄れてきて、手っ取り早く独立した方が良くなると思う。でもどうせMQOは基本的なファイル形式だろうから、ゆるい連携は確保し続けると思う
完全に独立しちゃうとモデラーを作らなきゃいけなくなるから、それが理想ではあるんだけど…

3Dブラウザは簡単ではあるけど、プロジェクションとパースペクティブの両変換をキチンと原理的に仕込んでやらないと、後々の発展性に響くと思うけど、実際には何を発展させていくか当てがないとクラスが作れない
最初に作るならテクスチャベースだろう。ラインベースははまずフィルタが揃ってない。

単純なお絵描きソフトで、DOT線とアンチペンと新水彩を試すのが楽かなぁ。解像度の3軸も導入して…
インターフェイスとか完成度を気にすると全然完成しなくなると思うので、シンプルに単純に、でもタブ補正はきちんとついてるような、そんな奴。

Name: n_n   Time: 2006/08/15  - No.39

クラスのモジュールの主従関係について。
基本的に、インクルードされるのがモジュール側で、する側が制御構造側、あるいは文脈側といってもいい。

ブラシとかストローク生成のモジュールを作るけど、アプリの環境プロパティの影響を受けるけど、環境プロパティは実働モジュールからもGUIUからも参照される。だから環境プロパティがインクルードされるべき？

個々のモジュールは他に流用されうるけど、環境プロパティはアプリ固有で、明らかに結合組織である。
環境プロパティが変更された時に、そのタイミングで各モジュールの設定値を書き換えてくればいいのだけど、どのモジュールが参照してるかわからないから、登録型のリストを作ってモジュールのコンストラクタで登録してくるようにすると、モジュールクラスは登録用処理をインクルードしながら、環境プロパティにインクルードされ呼び出される側になってしまう
なんにしても無駄な構造だと思う。

一番シンプルなのはモジュール毎にstaticな環境設定値だけを格納した構造体を作って、そのようなモジュール毎の環境設定構造体を複数集めて一つの環境プロパティにすること。
GUIがその環境設定値を直接いじってもいいんだろうけど･･･一度まとめた方が分かりやすいとは思う。

Name: n_n   Time: 2006/08/16  - No.40

取り合えず、シンプルな線画描きツールを試してみよう
ブラシはDOT、2値、アンチペンの3種、薄と矩形の消しゴムツール、回転拡大と統合した掌ツール、パン、レイヤ合成、コピーの3矩形ツール、1bitペーパーをならってワンキー保存機能、矩形切り出し書き出し保存ツールもあるといい
レイヤは3つ程度で十分、1つじゃ駄目なのはトレスアップを試せないから。

GUIはしぃを参考にシンプルに行きたいけど、ここまで機能が絞られてると全部キーショートカットでいけるかもしれない。でもつけるとしたらしぃ風。
各レイヤは1bitかアルファ付きで2bitか、グレー8、グレーＡ16のいずれか。ついでに各レイヤ毎に背景色と描画色を設定できるようにしよう。

こんだけあれば、後はタブレット補正の具合とブラシの出来でかなりの所まではいけると思う。

Name: n_n   Time: 2006/08/16  - No.41

しぃのキャンバス外の背景部分から描画が始められる奴はどうやって実現してるんだろう
hackとかで背景のイベントをすってしまうんだろうか？ どうせイベントなんかないんだから最初からそっちにイベント組み込んでviewは描画に専念？
その場合viewがマウスイベントを受け取らないようになってしまう

Name: n_n   Time: 2006/08/17  - No.42

タブレットのパケットはマウスイベントとして受け取る場合と、パケットとして受け取る場合があるんだけと、パケットとして受け取った方がレスポンスがいいそうだ
でもその場合、マウスはマウスでカーソルを持ってて、タブレットは独立したカーソルになってしまう。クリックイベントやダブルクリックイベントを生成しなきゃいけないのだけど…そのやり方は分からん。

マウスモードでもパケットがキューから複数送られてくるだけで、それでいいっちゃいいけどレスポンスがかわりはするのと、クリックの最小筆圧ってドライバ側の設定に左右される。
でもSAIみたいに自分でタブドライバ作るようなのは全然分からんぜ、何が駄目なんだろ。ワコムのドライバにはバグがあるそうだけど。


曲線補間で一番難しいのはレスポンスの問題だと思う。 基本的に前後に余分な位置情報が欲しいので、ストロークに対して一定の遅延を持つ、だから、描き始めの時に一定距離空走してからじゃないと描画されない。
それじゃ駄目だから、普段から一定サイズのキューを保持しつづけていて、クリック時にそれを使って確定させる、とすると、普段からパケットを監視してないといけない
マウスで言えばmousemoveイベント。

でこの補間処理てのは、基本的にはブラシの味を作るためではなく、タブレットの感触を自分に合わせるためにあるので、環境設定から1つだけ設定できるのがいい
ブラシごとに設定値を持たせて切り替えてもいいけど、そうするといつまで経っても手がなじんでくれないと思う。

としよう。

Name: n_n   Time: 2006/08/17  - No.43

そうじゃなくても、メインの線画ブラシは、1つにまとめてずーっと使い続けていくべきなんだろうなぁ
見栄えを変える部分はブラシのレンダリングフィルタの設定とかで誤魔化してさ。

Name: n_n   Time: 2006/08/22   PaintTime： 16’56” - No.45

Original size

APIについてちょっと考える。
チャートの書き方なんか覚えようかな…

まず基本的にAPIの目的は各部の連携を絶つ事とアプリの機能を統一的なアプローチで提供する事。
あるクラスの内部メンバがローカルな呼び出しをする場合、その結果をグローバルに反映させる為に結局グローバルな呼び出しが必要になる、に対しての対処法。パラメーターがそのローカルエリアでしか参照されない限りはAPIには関係ない。

APIが各部の連携を絶つ為には、できる限り組み込み型で処理をするようにしなきゃいけない
呼び出される側のAPIは組み込み型だけで出来ていて、内部に保持しているユーザー定義型の変数を扱えない事になる。それに対して読みと書きをするAPIXが必要になる。APIXを扱うモジュールは十分な量のヘッダーをインクルードしなきゃいけなくなる。特にAPIXで保持される型がAPIXをインクルードしようとしたりしないように注意しなきゃ。

ある汎用ではない型のオブジェクトが、ローカルとAPIXとで保持されて互いに参照する場合、複雑な関係になる。そういうのも全部含めてAPIXにしてしまうのもありだ。
もしアプリのほとんどの機能をAPIXに含めれればAPIXはその後のアプリの拡張にかなり役立つでしょう。
もしローカルなユーザー定義型とAPIX内のユーザー定義型との連携を他に影響が及ばない形で定義できたら、APIXをかなりコンパクトに捉えれるんじゃねーかとおもうんだけど

なんかそこらへんがよく分からん

Name: n_n   Time: 2006/08/22  - No.46

あーなんかめんどい
ブラシ編集のコマンドてのが、例えばこいつGUIとセットでいい筈なのにキーショートカットからも変更するかもってAPIに組み込まれちゃうんだぜ
つまり2つ以上の場所から呼ばれるならAPIで統合しようってことなんだけど、特にブラシの設定はどーもGUIとクローズドな関係だとおもうんだ

つまりキーショートカットや作業中に設定できるのはブラシの「抽象的な属性」であってこれはAPIにしていい。一方ブラシクリエーターでいじるのはブラシの「全ての具体的属性」で完全なGUIが欲しい。けどここ以外には要らない。

完全な具体性を必要とするのは、処理系、設定ファイルの読み込み書き出し部、GUIの3つのみで、これは1セットでいいと思う。
そこにAPIからの汎用的な抽象的パラメーター変更のコマンドが舞い込んでくるって具合。


逆の言い方をすると、APIが必要なのは、すべてのパラメーターをいじるよりも、いつどのタイミングからでも大雑把な設定が出来る、って利便性のためなのかもしれない。
全てといっても結局は、処理系、設定INI、GUI、キーの4つしかなくて、処理系の中には内部処理系と外部処理系からの波及があって、波及がなくてキーが有効でない時ならAPIにしなくてもいいのかもしれない。
波及てのは全く関係ないモジュールの処理の結果として設定が代わるので、全く関係ないモジュールから見える部分に設定変更関数を用意しなきゃいけないという状態。キーはいつでも変更したいという意味合いが強い。
に対してクローズドなGUIは全てのパラメーターをいじれる代わりに、そこでしかいじらないパラメーターを多数抱えていて、こういうのがAPIにしなくていいメンバ。

でもここで切り分けちゃうと、設定値毎に変更の手続きが変っちゃって面倒ではある。
ブラシクリエーターしか使わないAPIをつくるか？

GUIはAPIモジュールとAPIを読み込んで内部パラメーターに対して完全な制御をする、
その他のモジュールは汎用APIの方から大雑把な制御しかしない


あーあと、
パラメーターを書き換えたり読んだりする、パラメーターを使った変換アルゴリズムの提供、編集コマンドの実行、アプリの表示設定の切り替え、
これらは明確に区別して扱ったほうがいい。

Name: n_n   Time: 2006/09/06  - No.47

最近、ちょっと別の発想が分かりかけてきた

ライブラリィがそれなんだろうけど
処理の詳細、アルゴリズムを提供する部分と
挙動の文脈を支持する高度で抽象的な処理内容を決定する部分は、キチンと分けるべきって奴だ。

ある特殊な構造の内部メンバを保持するクラスがその内部メンバに対する処理を監視するために
内部メンバに対する制御を全部インターフェイスとして定義する

そのインターフェイスは「組み合わせればどんな処理も記述できる」な低次元の演算に留めて
高度な文脈は別の扱う側に任せるとする

そうした方がいいのだと思う。

でもループの一番中で起こる処理をとにかく早く回したい時には
どーしてもクラス関数の中で直接制御処理する必要があるとは思う。

これがクラスの隠蔽って奴なんだろう

Name: n_n   Time: 2006/09/06  - No.48

クラスの機能てのは
内部処理のブラックボックス化とあるいは隠蔽
ポリモーフィズム、それと構造体としての意義があるんだと思うけど

ブラックボックスてのはインターフェイスが開かれてるので、演算の文脈を抽象的に指示できるけど、まだ制御されてる側だ
処理を全く隠蔽して、自動的に行っても構わない
つまり使う側が演算の意味性を理解してそれを組み合わせるか、それともただ一定の手続きに従って呼ぶだけでいいのかの違いだ
あるいは呼ばなくてもいい。
staticメンバを使ってクラスオブジェクトのコレクションを作って、処理に合わせて周りのオブジェクトと同期を取ったり、そういう隠された処理をしてもいい
…のだけどそーいうことをすると演算に使える小さくて小回りの効く副作用のない処理ではなくなってしまう
だから処理の詳細を隠蔽する事と処理自体を隠蔽する事は違うのだ。

構造体としての意義は、多数のパラメーターを連動させたまま一つのオブジェクトとして扱えるというものだけど、あんまり意味がないと最近思っている。
確かにポインタや参照1つで渡せるのだけど、呼び出しの際にメモリアクセスになるので最適化かける時少し考える
それとヘッダーのインクルードがちょっと複雑になる。
もし「privateメンバでしか使わない型ならcppでインクルードできる」て仕様だったら気にしない

ポリモーフィズムは詳細を隠蔽された構造体的な統一されたオブジェクトの集合をまとめて扱う手段になるけど
使わない方がいい場合の方が多い気がしている

というのも
どうもおれがGUIの側からものを考えているので、ある程度別々のクラスであることを認識しながらそれを同一に扱いたい、としているのだけど、それがどうもポリモーフィズムって感覚とそぐわないのだ
全部の命令をbool型で宣言して、trueを返すのは処理実体がある場合だけ、みたいにすればいいんだけど、
そこまでしてポリモーフィズムの意味があるのか？みたいな…

基本型のコレクションを任意の派生型に変換して扱えればいいんだけどね
出来るけど、やった事ないので躊躇。