気持ち早めに帰着。
そういや、flashで使用するswfってフォーマット公開
されていたようなと思って調べてみたり。仕様はAdobeのサイト
からゲットできる模様(署名が必要)。それを独自に表示する
ツールとか、SVGに変換するツールなんかもいくつか存在
するみたい。SVGにはアニメーションやボタンなどのコントロールの
定義は無いので、swfに比べてイマイチなのかしら。
AdobeのSVGデモを見てみると、意外と色々できそうな予感もしてみたり。
気持ち早めに帰着。
SVG(Scalable Vector Graphics)について少し調べてみたり。
InkscapeやSodipodiのセーブデータがこの形式だったりするの
ですが、XMLで記述されたテキストフォーマットで、仕様はフリー
らしい。ベクター描画ライブラリのCairoでは、SVGを直接
読み込む関数もあるっぽい。Webブラウザで直接表示できるように
FireFoxなんかは対応が進んでいるもよう。IEはAdobeのSVGViewer
(無料)をプラグインとして表示できるようになるみたい。
Flashのようにアニメーションに対応しているのかどうかは不明
ですが、スケーラブルなグラフィカルボタンを作成できるなんて
メリットがあるのかも。でも、SVGを使ってこんなに
便利!って具体的な例は見つからず。コントロールの割り当て
までが統合されているFlashの方が良いのかも。
早めに帰着。眠さで死亡。
TV東京でやってる「ROCK FUJIYAMA」という音楽番組。
ロックとは全く無縁のTANEなのですが、気が付くと何気に観てる
という感じ。結構前から見ている気がするのですが、何気に
人気があるのかしら?
昼ごろ起床。
会社の研修の宿題が後半にいくほど難しくなって〆切ピーンチ(^^;
昼ごろ起床。
Inkscapeを少し使ってみたり。癖が強い感はありますが、一通り
の機能は揃っているので、それなりには使える模様。でも結構落ちるかも。
複数の描画オブジェクトは「統合」や「差分」で図形演算を行えるようで、
消しゴム的な動きは後者の差分を利用する方が、パスをちまちまいじる
よりも簡単かも。
Flashと違って勝手に描画オブジェクトが合成されたりしないので、作画中の
部分修正はInkscapeの方が良いかもと思う反面、勝手に描画領域合成される
事で実現される消しゴムのような動作は図形演算を使ってひねりを効かせる
必要があり、使い勝手としては一長一短という所でしょうか。
ピクセル画像からのベクタライズが意外と良い感じ。ぼかし描画なんて
のもできます。特にぼかしやグラデーションなんかは、GIMPなどのピクセル
系ツールよりも、動的調節が簡単なように思いました。
ところで、フリーのドロー系ツールの一つに
Sodipodiてのが
ありますが、InkscapeはSodipodiからの派生(というか意見相違の分離)した
ものらしい(参考)。
SodipodiはGIMPと同じくウインドがちらかる感がありましたが、
Inkscapeは一枚板の為、TANE的にはInkscapeの方が勝手が良いように感じました。
TANEがSodipodiを試したのは
1年半前だったりするのですが、
その時以降も更新が無い様子。とは言え、Inkscapeも半年に1回の更新頻度
のようなので、頻繁という感じではないようですが。
気持ち早めに帰着。
何気にWebをさまよっていた所、
Inkscapeなる
ドロー系ソフトの存在を知ったり。
ペンツールがタブレット筆圧対応されている点、良い感じが
したのですが、癖は強い模様。
あまりの眠さに早めに寝たり。
気持ち早めに帰着。
溜池観たり。第25回「野沢雅子特集」前編って事で、声優に疎い
TANEでも判るドラゴンボールの孫悟空の声の人。「オスッ!オラ悟空」
がアドリブから生まれたとか、へぇへぇ言いまくりでした。
気持ち早めに帰着。
TV観てたらいつの間にか寝てたり。
気持ち早めに帰着。
昨日のnVIDIAのSDKサイトの周りをぐるぐると探索して
置いてあるドキュメントなんかを眺めてみたり。思いのほか
揃っているなぁと思ったり。とは言っても英語なので殆ど
読めませんが(^^;
GPUを演算に使うってのも、表示機能のついたベクトルプロセッサだと
考えれば、あまり変な事をやってる訳では無いのかも。とは言え、
GPUによるところもあるかと思いますので、特定のGPUベンダー依存
ベッタリにコーディングしてしまうと、メガデモの様にマニアック
なものと捉えられがちになってしまうのが残念にも思えます。
気持ち早めに帰着。
何気にnVIDIAのサイトから
SDKをダウンロードしてみたり。OpenGLやDirectXを使ったデモが
入っていたり。DirectXの方はRuntimeをフルインストールしないと
実行できなかったりしましたが、概ね正しく動く模様。OpenGLとDirectX
との違いは、タスクマネージャーで見ていると、DirectXの方は常に
ユーザCPUとカーネルCPUが使われっぱなしという点。OpenGLとDirectX
とで同じ絵を出すデモは無いのですが、何故にDirectXのデモはこれほど
CPUパワーを必要としているのかよく判らなかったり。
割と普通に起きたり。
TV見たりWeb巡回してぐうたら過ごしたり。
「東京ゲーム図鑑」なる番組の存在を知ったり。
ちょろりコーディング。と言っても今日は式を立てるだけで終了。
くわがたツマミのDVD化。
朝普通に目覚めるものの、二度寝したら昼過ぎ。
そういや、Wings3Dの掲示板を眺めていたら、nVIDIAのドライバを
最新版にしたらWingsの動作がスゲー重くなったというような
話が出ていたり。恐らくうちで
起こったのと同じ
話なのかも。結局、glPolygonOffset()が遅いとか、そういう所の
話題までは到達していなさそう。でも、うちもうっかりボードに
添付のドライバが最新だったりすると、ハードを変えても解決
しないという結論に至っていたでしょうから、こういう環境
に依存しているように見える不具合というのは切り分けが難しい
のかも。
ちょろりコーディング。
気持ち早めに帰着。
昨日の続き。エラーしたら手で実行を何度か繰り返したり。
その中で、std/c/windows/com.dのコンパイルで何故かエラー。
コンパイラだけが付ける事のできる内部ラベルが見つからない
とかそんな感じのエラーだったりしたので、オプティマイズ
レベルを試しに下げてみたらコンパイルできたり。うーむ、
4.1.x系はやっぱダメかなぁと思いながら進めて、とりあえず
ビルド完了。
手持ちのソースをいくつかビルドしてみたものの、正常に
動作する実行ファイルが生成できず。ダメだこれ。という訳で
結局4.0.3ベースに戻したり。ちぇっ。
ゲゲゲの鬼太郎の実写映画って......
気持ち早めに帰着。
gcc-4.1.2が出ていたので gdc-0.22をビルドしてみたり。
gcc本体コンパイルの途中で何故かエラー。真面目に調べてみた所、
何もエラーせずに.oファイルが生成できない謎現象にハマって
いる模様。以前、
環境変数TMPを変更すると、解決したのですが、それでもダメ
な場合があるっぽい。何でだ? -pipeオプションを付けて、
コマンドライン実行するとOKだったり。仕方無いので、
configure実行時にCFLAGSに「-O2 -pipe」などと指定してみる事に。
取り合えずオプションが効いて、突っかかっていた場所は
通過できてみたり。と思ったらやっぱりダメ。仕方ないので
突っかかる度にそのモジュールだけ手でコンパイルしては
make実行。思ったよりも手がかからずにビルド成功。
cygwinビルドだったのでmingwビルドを行ってみたり。
....てかこちらはエラーでひっかかりまくり。
遅めに帰着。
コーディング。なんか全然関係無い所が気に入らなくなって
書き換えたり。
遅めに帰着。
どっかで聞いたことあるなぁと思っていたら、WingsにExportプラグ
があったのを思い出し、何気に
toxicを試してみたり。
WingsのExportプラグはそれなりに安定している模様。でも、
povなんかよりは少しレンダリング時間がかかる気も。レンダリング
過程が絵で出てこない為かも知れませんが。1.0のalpha-5で止まった
ままになってるのは何故かしら?
昼ごろ起床。
ボンヤリ「ザ・ワイド」などをBGVにしながらWebをさまよっていた
のですが、
相変わらずナレーションが噛み噛みなのが気になってしかたない
です。いいけど。
GEGLをFedoraの方でビルドしてみたり。bablという外付けパッケージ
が必要だったので、それをまず入れて、GEGLをビルド。とりあえず
エラー無くビルドできたのですが、デモの実行はmake installしないと
ダメっぽい。とりあえずデモは実行できたのですが、なんか遅い気が。
よく判らないFractalレイヤーという奴が足を引っ張っている感じが
しなくはありませんが、良くわからず。因みに、実行はリモートマシン
(PentiumIII 550MHz)で行って、画面をWindowsXPマシンに飛ばしている
のですが、同様の方法でGIMPを使う分には何も問題無いレベルなので、
ディスプレイ描画が遅いのでは無く、内部処理が遅いものと思われます。
何気にFedoraの方のGIMPで環境設定の項目を見ていたら、使用するCPU数
なんて設定があるのに気づいたり。え?マルチプロセッサ対応入ってるの?
と思い、Windows版で同じ項目を見てみた所、こちらにはそのような
メニューが出てこなかったり。むーん。
Pixieの新しいのが出てたり。Ver2になったもよう。マルチスレッド
に対応されたようで、特に指定しなくても100% CPUを使うように
動くみたい。Ver1.xの最後の奴とかは何故か大量にメモリを消費して、
とあるファイルではメモリが足りなくてレンダリング不能だったり
したのですが、そこんところは少しマシになった感じ。でも、POVとか
よりは全然消費メモリが多くて、なんで?って感じ。
Pixieのレンダリングテストの際にWingsでRIB出力してテストしていた
のですが、気づくと何故かSubdivisionMeshで出力されていたり。
以前SubdivisionMeshを
食わせると赤○白×でrndrがずっこけたのと、RIB出力プラグが
ハードエッジを効かせた出力を正しくできなかった不具合があった
ので、RIBプラグを改造したのですが、何故かPointPolygon出力に
どうやっても切り替わっていない予感。なんで?
プラグインのソースを少し眺めてみたところ、PointPolygonと
SubdivMeshの切り替えスイッチが付いているものの、
レンダラによってどちらのメッシュで出すのかを決めているところ
があり、以前はBMRTやAqusisなどを入れていたりしていた都合で、
たまたまPointPolygonが出ていただけの模様。現在はPixieしか
入ってないので、そこん所を書き換えてやるとPointPolygon出力
になってみたり。また、メモリが大量に消費されるのは、
SubdivisionMeshを使用していた為のようで、法線付きのPointPolygon
であればレンダリング時の消費メモリも時間も大幅に縮小されました。
タブレット描画の実験。の前に、キャンバスを大きくすると追従が
遅くなるので、タイル型のメモリ管理機構をコーディングしてみる
事にしたり。んー、結構面倒臭いぞ?
ついにCygwinも Windows95/98/MeのEOL(End Of Life)宣言がされた
模様。次期バージョン(1.7.x?)からはサポート対象とならない予感。
まぁ、64bit対応など、やることは他にも沢山あるでしょうし、
普通にCygwinを使う人がWin98系でいつまでも使うとも思えない
し(TANEの場合、プロバイダ夜逃げ事件が無ければ今でもWin98を
使っていた可能性が大なのですが(^^;)、MicrosoftはWin98のサポートを
とっくに打ち切ってる事を考えると、EOLだと言うのは
まぁ妥当といったところでしょう。
朝割りと普通に起きたり。でも昼間に眠くなったりして微妙。
コーディング。DrawingAreaタイプにしてタブレット筆圧が取れる
ようになったり、Pixbufを貼り付けてみたり。でも、バッファを
大きくすると、DrawingAreaに転送するだけでパワーを使って
いるような。部分書き換えにして転送量を減らすとかしないとダメ
っぽい予感も。
なんとなくWeb検索をかけていたら
FilmバージョンGIMP
なんてものの存在を知ったり。いわゆる16bit版GIMPという奴らしく、
GIMP-2.0開発前のドラフト的な文書が載っていたり。
新しいグラフィックライブラリとしてGEGLとか出てきますが、
結局、全然移行できていないというのが現状らしい。
確かにフィルム系でのCGは 8bit/1チャンネル の24bit/RGBでは足りて
いないようで、16bit/1チャンネルとか、32bit/1チャンネルと
いうのは必要な世界のようです(攻殻機動隊の映画 イノセンスのコメンタリー
でもそういう話をしてたような)。
でも、現状一般で使用されるPCの出力は24bit/RGBなので、
どうしても必然性が無いという辺りが、一般の理解をまだ得られない
理由の一つだったりするのかも知れません(液晶表示だとなおさら
実効色数も少なかったりするし)。逆に、ディスプレイ表示
の方じゃなくて、高精度な印刷の方での用途があれば、必要と思う
人も多くなるんじゃないかなぁとも思うのですが、そういう話は
聞いた事無いしなぁ。
起きたら夕方。寝すぎ。
ちょろりコーディング。ただのコンテナでタブレットの筆圧を取るような
コードを書いたのですが、デバイスが認識できず。DrawingAreaのタイプ
じゃないと取れないのか?
久しぶりに日付け越え。
あまりの眠さに死亡。
気持ち早めに帰着。
昨日のgdcビルドは何故かlibc++のビルドで失敗。その後何度か
configure実行し直してみるも同じ所でエラーする模様。てゆーか、
一回ビルドできたのはなんで?
結局、gcc-4.0.3を使用したり。こちらならば全くエラー無く終了。
まぁ、gcc-4.1.xはppcクロスコンパイラをクリーンビルドできなかった
りしたので、なんか具合の良くない所があるのかも。
gdc-0.22でDuitを使用したコードをコンパイル。特に問題は無さげ。
0.22はdmdの1.004ベースの様ですが、1.00から殆ど変わって無いだろう
からまぁ。
モーションイベント内でタブレットの筆圧を取得するコードを
探ってみたり。少しDuitのコードも修正しましたが、なんとなく
うまく筆圧を取れている予感。
早くもなく遅くもなく。
先日のgdcビルドエラーの続き。libphobosのビルドで何もエラー
無しのまま、オブジェクトファイルが生成されなくてエラーだったり。
以前、同じような症状が出て、
-pipeオプションを付けるとか色々やったけど、今回は何度か手動で
実行するとオブジェクトファイルが生成できる時があるというのを
二回繰り返したらとりあえずビルド完了してみたり。でも、0.21の
時はこの問題は出ること無くビルドできたので、cygwinのDLLに問題が
あったのかも?
とDLLを調べた所、何故か2006年の12月頃の日付になっていたので、
最新のスナップショットでビルドしたままになっていたcygwinのDLL
を入れてみて、再度ビルドテストを行ってみたり。
結局終わりそうにないのでほっぽらかし。
気持ち遅めに帰着。
gdc-0.22が出てたり。遂にgcc-4.1.x対応キター。
gdc-0.22をビルドしながら先日のタブレットコードを確認したり。
GdkDevice構造体のメンバーが一つ足りなくて、
本来デバイス名へのポインタが入っている所、全く違うメンバーを
デバイス名へのポインタとして使用した結果、妙な文字列が出た
という感じ。Segfaultしなかったのは、たまたまラッキーという
感じだったのかも。でも、構造体メンバーを直接指定してたり
するのが良くない感じ。元々GdkDevice構造体はメンバーが定義
されていなかった事もあり、Deviceクラスを使用しても、
デバイス名を取り出すメソッドが無かったりする、つまり実装が
完全では無いというのが根本的な問題なのかも知れませんが。
gdcのビルドはエラー。んー、なんだ?
気持ち遅めに帰着。
Duitでタブレットイベントを取る話。GTKのテストコード見る感じ、
g_signal_conntct() で結びつける事で、関数の引数に指定される
イベント構造体内の変数 device に色々情報が入ってくるらしい。
でも、Duitでは イベント構造体内の変数 deviceや axes に
それっぽい物が入ってこない。うーむ。また、変数deviceはGdkDevice
構造体なのですが、これもまたメンバー変数が一つも定義されて
いなかったりもするので、ここん所はまだ実装されていない感じなのかなぁ。
もう少しGTKチュートリアルのXInputの項をよく眺めてみた所、
拡張デバイス情報を有効にするというおまじない(gtk_widget_set_extension_events())
の実行が必要な点が抜けていたり。
そのおまじないを入れた所、なんとなく筆圧を取れているような予感。
でも、デバイス名は変な文字列しか取れなかったり。謎。
割と普通に起きたり。
GTKのタブレットサポートについて調べてみたり。でも、GIMPでの
タブレット対応がイマイチという話題以外の事をWebから探し出す
事ができなかったり。そんな中、GTKのチュートリアルを読んでみると、
タブレットの筆圧やら傾きやらを取得する説明があったので、
説明で出てくる関数名を頼りにGTKのソースをgrepして探ってみたところ、
tests/testinput.c が
そのものズバリ、タブレット入力を利用した簡単な描画サンプルだったり。
Duitで書くにはどうすれば?と少し見てみたのですが、
Cベースのコードもボタンを押した時とモーション時とでは少し
違っていて、モーション時はバッファに溜まったイベントを
一気に吐き出すようなコードにする必要があるらしい。
GTKの関数を直使用すれば良さそうな感じがしなくもありませんが、
具体的なコードはまだ書けず。一応、GTKソースのテストコードは
コンパイルできてWindowsネイティブで動作したので、
どうにかすれば動くのは確からしい。たぶん(^^;
そういや今頃気づいたのですが、DuitはDUITではなくDuitが正しい
っぽい。
先日のAtelierはベクター保持ではなさげ。手ブレ補正が付いている
のですが、その補正の動きがイメージ的にSAIのそれとダブったのと、
元々cairoの描画について探してて、全然関係無い流れで見つけた
のですが、間の検索過程をすっとばして、ベクターだと勝手に思い込んで
しまった気がします。
描画自体は2値のビットマップで保持されており、プレビューなんかでの
「レンダリングしています」はビットマップのアンチエリアス付きの
縮小処理の事を指しているものと思われたり。そんな感じ。
「オタ絵」という単語について。2chやCG掲示板なんかで
ちょいちょい発生する「良い絵/悪い絵 論」の流れの中に出てくる事の
ある「オタ絵(orヲタ絵)」という単語ですが、話の流れから勝手に察すると、
概ね、アニメ美少女系&エロ という括りにかかるタイプの作画の事を
指しているように思います。でも実際の所どうなんだっけ?と思い、
Googleでひっかけてみた所、特に正確な定義がある訳ではなく、
アニメ絵を指して言ってる場合もあれば、いわゆる萌え系美少女
(これもまた萌えがよく判らないとどういう範囲なのか難しいですが)
という少し範囲を絞って指している場合もあるようですし、
また描き手が女性だと、男だらけに描くのを指してオタ絵と言う事も
あるようです。結局の所、大いに主観を含んでいる為、「オタ絵」
という単語が出てくる前後の文章を読まないと、その人がどういう物を
指しているのかは判らないという感じみたいです。
なのですが、いきなり「オタ絵は...」という
文言を出してくる人が居て、これだけでは微妙なニュアンスが全く無いので、
結局どういうのを指しているのかが読み手主観に委ねられ、そして
高い確率で指しているものが食い違っていて、それで話が噛み合わず、
最後は発散するという流れとなるみたい。
で、どういう条件を満たせばオタ絵になるのか?と考えて
みました。大枠で言うと リアルデッサンかアニメデッサンかに
二分し、もう一次元、厚塗りかアニメ塗りかという描画方法の違いを
加えてみました。
[モチーフが人の場合] ┌────┬────┐ │リアル │アニメ │ │デッサン│デッサン│ ┌─────┼────┼────┤ │ 厚塗り│非オタ系│ オタ系│ │アニメ塗り│非オタ系│ オタ系│ └─────┴────┴────┘
起きたら夕方。寝すぎ。
cairoの続き。あーだこーだといじり回して反応を見た結果、
考え違いをしていたという事が判明。ワールド座標に対して、
rotateするとローカル「座標系」が回転されるのですが、translate
はローカル座標系を基準にして行われる為、ワールド座標で見ると
妙な位置に移動しているように見えるだけでした。OpenGLでも
同じような事で思い通りの位置に物体を動かせなかった記憶
がよみがえってきたりする所がダメな感じ。
そういや、JSTに直してみようとした所、何故かstd.date.UTCtoLocalTime()
とか使っても変換できず。全然関係無いですが、GMTとUTCの
言い方の違い。
こういう関係ってのは知らなかったです。
cairoのアーカイブ内docにはチュートリアルの項目があるものの、
中身が書かれていなかったので、本当にそういうの無いのかなぁと
Webをさまよっていた所、全く関係無いところから
Atelier
なるマンガ描きソフトの存在を知ってみたり。ベクター描画の
線画ツールで、コミックスタジオとかそういう感じに近いっぽい。
それよりも、HSPで書かれているらしい
のに驚いたかも。円定規とかピンとか良くできてると思いましたが、
ツールとしての完成度はあんま高くは無いかも。
ファミ通WaveDVD観たり。「天誅 千乱」の連続人殺のやり込みスゲー。
SAIの新しいのが出ていたり。
気持ち早めに帰着。ひさしぶりに千と千尋の神隠しを観たり。
cairoで文字を回転する話。どうも回転軸を移動できていない予感。
んー、何か考え違いをしてるのか?
あまりの眠さに早々に死亡。
気持ち早めに帰着。
cairoで文字列を表示することはできたのですが、文字列の
幅や高さを調べるのはどうすれば?と探してみたけどよく判らず。
cairoでは描画対象のアフィン変換はOpenGLのそれのように、
行列スタックを積んでいく形になってるようです。
で、文字列の真ん中に軸を置いて回転させたい場合、幅や
高さが判らないとどうにもならないので、求める方法が知りたい
と。
で、cairoのテストソースを眺めていたらそれっぽいものを見つけて
みたり。cairo_text_extents()で得られる
cairo_text_extents_tという構造体の中にwidthやheightという
メンバー変数があり、それで文字列の幅や高さが得られそう
だったので、早速DUITで探ってみたところ、何故か
構造体 cairo_text_extents_t にメンバー変数が定義されて
なくてエラー。てか、何故?
しかたなくメンバー変数を定義してみたり。とりあえずそれっぽい
値が得られるようになったのですが、なんか思い通りの位置
に文字表示できなかったり。むーん。