目安箱 †
意見・質問等はこちらにお願いします。
過去の要望・意見はこちら
注意:ここに乗せた機能全てを実装するとは限りません。また、検討・テストした結果不可能と判断した物は実装予定としていても実装しないこともあります。
※エフェクト、入出力プラグインに関しては、プラグインのページにてお願いします。
膨張のサイズについて †
金の髭? (2009-04-04 (土) 18:48:24)
膨張エフェクトの「サイズ」に負の値を入れて、
縮小された影が作れるようにするのは難しいでしょうか。
１．キーイングで抜いたキャラの境界部分がやや荒れ気味
２．膨張サイズに負の値を入れて作った縮小影(範囲のみ表示)を
トラックマットとして使って荒れてる部分を消す
みたいな使い方ができると便利かな〜と思いました。
他の用途としては影を徐々に縮小(拡大)してキャラの形にそった
グラデーションワイプ的な感じで使えないかな〜と。
OpenGLでプレビュー時にGDIを使わない †
vroad? (2009-03-28 (土) 23:06:37)
プレビュー時はGDI使ってるらしいですが
OpenGLのコンポジションに切り替えたときにWinFormsのコントロールを差し替えてOpenGLのみで描画する事は出来ないでしょうか？
- GDIもWinFormsが内部で使ってるだけだったり、プレビューの背景色を塗りつぶすときに使ってたりするだけなのですが、プレビューとタイムライン、アイテム、ヒストリーはそれぞれがほぼ完全に独立しているので、レンダーターゲットをプレビューウインドウにするなどの自分以外を操作するようなことは出来ません。 -- うp主?
- いや、Bitmapに読み出して描画しているかと思ったんです・・違ったようですいませんでした。 -- vroad?
バッチ処理書き出し †
July? (2009-03-27 (金) 22:58:56)
書き出しに時間がかかる場合や、プロジェクトファイルがたくさんある場合、バッチ処理などができると非常に助かるんですが、実装は難しいものなんでしょうか。
要望としては、引数でエフェクトを指定して〜とかではなくて、すでに完成されたプロジェクトファイルに対して圧縮方法とファイル名を指定する"書き出しのみ"の処理ができればいいなと思っています。
- 現在の仕様だと、出力時の設定を本体が取得することは出来ず、バッチとして処理をまとめることが出来ないのでちょっと厳しいです。 -- うp主?
コンポジションを読み込んだ場合のマテリアルプロパティのコピー †
金の髭? (2009-03-12 (木) 08:49:45)
別のコンポジションをタイムラインに追加した場合、例えば「マテリアル→イメージ→位置」を「エクスプレッションにコピー」すると、
「位置」ではなく「イメージ」というプロパティ名でコピーされてしまい、実際にエクスプレッションで使うためには
"イメージ"を"位置"に書き直してやる必要がありますが、「位置」などを直接コピーできるようにするのは難しいでしょうか？
- 確認しました。これはどちらかというとバグの部類ですね orz 修正します。 -- うp主?
キーフレームのドラッグについて †
コーヒー? (2009-03-10 (火) 17:13:12)
NiVEにはお世話になっております。
どこかのバージョンからキーフレームを１フレーム目より手前にもドロップできるようになったと思うのですが、これは１フレーム目より手前には持っていけないという制限があったほうがありがたいと思うのですがどうでしょう。誤って手前まで持っていってしまってCtrl+Zで復帰、という操作をすることが多いもので・・・。
また、アイテム位置の移動の際には可能なように、キーフレームのドラッグの際にも画面端まで行ったら自動で前後にスクロールするようになると長距離の移動の際にうれしいです。現状ではホイールのショートカットで縮小→移動→拡大→微調整 とやってて、それはそれで効率的な移動法ではあるのですけども。
- スパムが無くなったのはいいけど、投稿ミスが多くなった orz 1フレーム目より手前に持って行ってしまってCtrl+Z、ということはあまりないのであまり邪魔には思わないのですが、確かに頻度的には1フレーム目より手前に持って行くことの方が少ないですね。ちょっと検討してみます。 キーフレーム移動時のスクロールに関してですが、こちらの方はインターフェースの定義の変更が必要なので、現在はちょっと厳しいです。 -- うp主?
- スパム対策お疲れさまです。こういう変なとこに労力かけざるを得ない状況ってのはう〜む、と思いますよねえ。１フレーム目より手前の件を検討していただけることと、スクロールに関しては仕様上難しいとのこと了解しました。よろしくお願いします。 -- コーヒー?
- ver1.82にて実装していただいたのを確認しました。ありがとうございます！ -- コーヒー?
OpenGLでブレンドモード †
vroad? (2009-02-07 (土) 23:44:06)
こっちはどうでしょう？
加算合成と減算合成はシェーダー無しですぐできそうです。
現在拡張2Dでしかブレンドモードの指定は出来ないようですが。
- glAccumで加算・減算はできるみたいですが、オンボードや古いグラボだと自前で合成したほうが速いみたいですね。 この部分は前から考えてはいたのですが、現在シェーダで誤魔化しているアルファブレンドの問題と同じ問題を抱えているので、ちょっと様子見です。 -- うp主?
- glBlendFuncは？減算は出来ないかと思いましたがglBlendEquationEXT(GL_FUNC_REVERSE_SUBTRACT_EXT)という手もあるようです。
glBlendFuncだけでも色反転→加算→色反転すれば出来るみたいですが、重そうです。 -- vroad?
- glBlendFuncやglAccumだと、レンダリングされた部分しか合成できず、後ろにあるトラックの合成が出来ない(これがシェーダでごまかしている部分)ので単純に実装するとかなり汚くなります。 -- うp主?
- 追記:レンダリングされた部分というのはZバッファ上で手前に位置する部分です。 -- うp主?
- ・・・Zバッファの書き込みを無効にするとか、そんな簡単な問題じゃなさそうですね -- vroad?
- 単純にZバッファを切るだけだと、本来別のトラックに隠れて描画されない部分まで描画されてしまうので、根本的な解決にはならないです。 -- うp主?
- 書き込みは無効で深度テストが有効は？（他のトラックは先に描画しておく必要がありますが・・） -- vroad?
- AEなんかだと、X軸に対して+10ﾟ、0ﾟ、-10ﾟの順で回転させたトラックを並べ、0ﾟのものに加算を設定すると、描画順序は-10ﾟ、0ﾟ、+10ﾟの順で描画されますが、+10ﾟ、-10ﾟの回転して0ﾟのトラックより後ろに行った部分は0ﾟのものと加算合成されます。こんな感じに。
さらに、もっと複雑な交差に対してもしっかりブレンドモードが働いているので、単純にZバッファのみ更新したり、シェーダでごまかす、というわけにはいかないみたいです。
現在のアルファブレンドのごまかし方なんかは結構汚いのでどうにかしたいところですが… -- うp主?
- 加算合成は手前から描画しようが奥から描画しようが一緒だと思っていました・・
パーティクルはZ書き込み無効を搭載しても問題なくないですか？ -- vroad?
- ちょっと話が飛んでてわからないのですが、パーティクルはレンダリングとは関係ないレベル(エフェクト)にあるので、そこは実装するひとの裁量によるでしょう。 -- うp主?
- プラグインの要望はプラグインのページでするんでしたっけ。そっちでする事にします -- vroad?
- http://hak.wablog.com/62.html
半透明合成はここにヒントがあるかもです。 -- vroad?
- 上のリンクでは「Aバッファ/Rバッファのハードウェア実装」という項目に書いてあることがやりたいことに近いですね。ただ、やるとするならアルファブレンドのみではなくてほかのブレンドモードもOpenGL1.5未満で実現したいので、ソフトウエア実装になると思われます。 -- うp主?
- 上のページのコメント欄に書いてある、プリミティブ単位で分割するときにソートというのはどうですか。 -- vroad?
- プリミティブ単位でのソートでやる場合は、ポリゴンのサイズを1px以下にする必要があり、さらにテクスチャをトラックの分だけレンダリングが完了するまで保持する必要がある(テクスチャの更新速度的に)のでVRAM的にもCPU的にも厳しいでしょう。ゲームとは違っていかに上手く誤魔化すかではなく、いかに正しく描画できるかが重要なので、ピクセル単位で正しく前後関係が扱える方が望ましいです。 -- うp主?
- 無理そうですね・・。諦めるしかない・・？ -- vroad?
- 現時点でやろうとすると、
1トラックずつレンダリング→カラーバッファとデプスバッファを取り出し→それぞれのトラックを1px単位で深度順にソート→ブレンディング
となるので、速度的に現実的ではないかもしれません -- うp主?
テクスチャ転送時にPBOを使用 †
vroad? (2009-02-04 (水) 13:53:15)
長くなってきたので別項目に。
考えてみたら、Bitmapを全てPBOにしなくても
Bitmapからテクスチャへの転送、FBOからBitmapへの転送時に
PBOを通すようにすれば、大きな変更なしで高速化できるのではないでしょうか。現在一切PBO使っていないみたいなので。
- インターフェースの仕様変更が必要なのでメジャーバージョンアップ級の変更は必要ですが、テストしてみたところ特に速度に変化は見られませんでした。英語は読めないのでよくわかりませんが、下のトピックの最後にあったリンクの内容的にはバッファを使い回す&PBOを複数用いてテクスチャ転送のディレイをを隠蔽する、というのが目的ではないでしょうか? IViolateEffectでバッファサイズを変更したり、フレームの先読みがない場合は特に速度的に変化はないものと思われます。フレームの先読みについては、下にも書いたとおり、エフェクトの処理時間が大きな割合を占めているため、特に実装する利点はないと思います。 -- うp主?
- ＞速度に変化は見られませんでした
DirectShowを使ってGLのテクスチャに書き込むプログラムを使って
glTexSubImage2Dの時間を計って見ましたが(QueryPerformanceCounterで）
PBO→テクスチャ:0.13msぐらい
メインメモリ→4msぐらい
で、確かに効果はあるはず何ですが・・・条件が微妙に違ったんでしょうか。
usageはGL_STREAM_DRAW,glMapBuffer呼ぶ前にglBufferData呼ぶのと、ダブルバッファリングはしています
＞メジャーバージョンアップ級の変更
↑に書いてあるのは
インターフェースの引数の変更は諦めて、テクスチャへ転送（またはFBOから転送）するとき必ずPBOを通すようにする
という事なんですが・・書き方が悪かったでしょうか
-- vroad?
- こちらでテストした際は、Textureクラスを改造、PBOを経由してglSubTexImage2Dしてます。改造前はそのままglTexImage2D(IViolateEffectによるリサイズ対策)してます。更新毎にglBufferData(..., GL_STATIC_DRAW,..)したり、一度glBufferData(..., GL_DYNAMIC_DRAW,..)した後にglMapBufferのみで更新したりしましたが、特に変化はありませんでした。PBO→テクスチャの速度はかなり出るみたいですが、メインメモリ→PBOの速度はどの程度でしょうか? -- うp主?
- 測定条件が不公平でしたorz
PBO→テクスチャは1msもかからずに出来ます。しかしglMapBuffer→書き込み→glUnMapBufferに結構時間がかかります。 それでもPBOを使わないと比べると若干早いという結果が出ました。
＞メインメモリ→PBOの速度
以下はメインメモリ→PBOとPBO→テクスチャを足した時間です・・・
PBO使用:2.32ms PBOなし:4.71ms(1400フレームぐらいの平均値)
半分ぐらいに短縮されているように思えます。&brl ソースは720x480のMPEG2の1400フレームぐらいの映像、デコーダーはffdshowです。 動画のサイズがでかくなればなるほど差が開きます。
＞更新毎にglBufferData
うちの環境では、これをやらないとPBO使わないほうがマシなぐらいの遅さになってしまいました。一方
ダブルバッファリングを使った場合/使わない場合の速度の変化はよく分かりませんでした。
usageは・・・DYNAMICの方が少し早いような・・・そうでもないような・・
＞glTexImage2D
glTexSubImage2Dのみで済むならそっちの方がよさそうですね。 -- vroad?
- 1フレーム2msも違うなら1〜2fps分速くなってもいいはずなのですが、こちらの環境ではそうならずにむしろ事前処理改良版glTexImage2Dの方が速いという結果に… もうちょっとテストしてみます -- うp主?
- 自分が作ったプログラムのソースをうｐした方がいいでしょうか･･･ -- vroad?
- GL_UNSIGNED_INT_8_8_8_8_REVを使うとGL_UNSINGNED_BYTEに比べて遅くなります。って、普通使わないかこれは・・ -- vroad?
- いろいろ試してみましたが、速度は変わらないか少し遅くなる程度で特に変化はないみたいです。 こちらで試したところ、glBufferDataで直接データを渡す方が速くなりました。これは、glMapBufferでデータを渡す場合、ポインタ同士で直接データのコピーをするメソッドがないために一旦byte配列にデータをコピーする必要があるためにそのオーバーヘッドを受けているためではないかと思われます。 -- うp主?
- 確かにC#だとIntPtrからIntPtrへのコピーがないですね・・・
http://gurizuri0505.halfmoon.jp/develop/csharp/csharp_memcpy2
ここに書かれているような方法は？（unsafeはなるべく使わない方針でしたが)Win32APIを使うのも反則？ -- vroad?
- Marshal.CopyからRtlMoveMemoryに変更してみましたが、glTexImage2Dと同じ速度になるだけでPBOの方が速くなる、という結果は得られませんでした。グラボはGeForce9600GTでバス幅も256bitあるので転送がネックになっているとは思えないんですけどね… -- うp主?
- ちゃんとC#で動くのを作ってから出直してきます -- vroad?
- http://uproda.2ch-library.com/src/lib105627.zip.shtml
コピー処理はTexture.csとPBOTexture.csを見てください。このコードだとPBOを使った場合の速度のほうが速いです。たぶんプログラムにおかしなところは無い（コピー処理だけに関しては・・）、PBOを使わなかった場合の速度が遅すぎる気がします。
PBOの使用/不使用はSimpleTriangle.csの109行目で変えられます。 -- vroad?
- 試させていただきました。が、PBO使用時と未使用時ではAvgは0.5程度(msかな?)しか違わず、3.09〜3.6でした(2000フレーム程度を数回)。Usageをいろいろ変えたりしましたが、特に変化はありませんでした。 -- うp主?
- あれー？サイズを増やしたりして負荷を増大させるともうちょっと変わるかもしれません。この場合はglBufferDataをコメントアウトすると動作が遅くなりました。NiVEに導入するほどではない高速化でしょうか？デメリットは無さそうなのであってもいいと思うんですが・・。うちのグラボはRADEON HD 2600XTなので多分うｐ主のより遅いです。 -- vroad?
- 持っているのがGeForce系のみしかないので、RADEON系だとどうなのかはわかりませんが、最近のもの、もしくはGeForce系だと大して差はないのかもしれません。 -- うp主?
- テクスチャサイズでかくしてもあまり差なし・・・？
今度はフレームバッファからPBOへの読み出しの速度を検証するプログラムを作ってみます。 -- vroad?
- グラボのドライバを新しいバージョンに変えたら、glTexSubImage2Dの動作が改良されたのかPBOの方が遅くなりました・・。上のほうで出ていた「DirectShowを使ってGLのテクスチャに書き込むプログラム」（C++製）でも、若干PBO非使用が速くなっています。それでもPBOのほうが少し速いのはテクスチャ書き込みが別スレッドだからだったのでしょうか・・。 -- vroad?
- 今回作ったプログラムではGLレンダラで1回3D変形を使った場合を想定しています。入力プラグインがBitmapを複製→Bitmapをテクスチャに書き込みしてFBOにGLで描画、BitmapにglReadPixels→Bitmapをテクスチャに書き込んでマテリアルの処理を行う で150FPSぐらいです。もうプログラムあげなくてもいいかな・・ -- vroad?
- 上のプログラムを実家の方に持ち帰り忘れたので、改造Textureクラスでテストしたところ、PBO版の方は1〜0.5fpsほど速くなっているっぽいです。環境はC2D E7200、GeForce7600GSです。2、3環境程度では実際に速くなるかどうかはちょっと判定できなくなってきましたね… -- うp主?
- そうですか・・・。うちには他にテストできそうなPCがありません・・。
http://iroiro.zapto.org/cmn/jb2/jb.cgi?mode=dlkey&id=1041
今回作ったサンプルプログラムです。3D変形というか、テクスチャを貼った立方体が表示されます。デフォルトではPBOはオフです。最初のBitmapの複製でRtlMoveMemoryを使っても見ましたが、速くなるどころか遅くなりました。
元画像のサイズは512x512、ウィンドウサイズは512x384です。上に書いたような処理で、NiVEと処理の手順は同じになっているでしょうか？ -- vroad?
- DLキー忘れてました！！pboです。 -- vroad?
- 実家の環境でテストしてみました。PBO不使用時よりもPBO使用時の方がFPSは高くなりましたが、FBOに対してReadPixelしたときの速度はPBO使用時の方が遅いようです。 -- うp主?
- レス遅れてすいません・・&br環境によっては速くなるんだったら、レンダラ設定でON/OFF出来てもいいのではないでしょうか。
＞FBOに対してReadPixelしたときの速度はPBO使用時の方が遅いようです。
垂直同期をONにすると、両方ともReadFBOの時間が増えますが、使用時の方が1〜2msぐらい速くなっています。FPSが減るのが関係している・・？ -- vroad?
- NiVEでこのプログラムと同じようなことすると、23〜24fpsぐらいしか出ませんが・・、このプログラムで出るFPSから考えるとBitmapをClone〜マテリアルの描画処理が5msなので、そのほかの処理が15ms（もっとかかる？）としても50FPSぐらい出ないんでしょうか？ -- vroad?
- いろいろ試してみたのですが、単一のテクスチャのみでレンダリングする場合はPBO使用時の方が速いのですが、それぞれ異なるサイズのテクスチャを使用すると、TexSubImageの方が速いみたいです。
>50FPSぐらい出ない
これは、バグ報告の氏の投稿22fpsの壁 その他にて回答済みですが、ファイル出力時にはカラーイメージ1枚のみだとファイルアクセスなしで100fps程度は出るようです。 -- うp主?
- 確実な効果は得られなそうですね・・採用は見送りますか。
＞ファイル出力時
実はよく分かっていません・・ ファイル出力時はFPS調整で待機しないから速くなるんですか？ -- vroad?
- >FPS調整で待機しないから速くなる
そういうことになります。ただし、実際は書き出しなどのファイルアクセスによって出力速度は遅くなります。 -- うp主?
PixelBufferObject †
vroad? (2009-01-27 (火) 14:50:12)
OpenGL使用時に
入力プラグインから、Bitmapではなく直接PixelBufferObjectに書き込むようにできませんか？
- 今のところ入力側からなんらかのレンダラの操作ができるようにする予定はありません。また、OpenGLレンダラではPBOは使用していません。 -- うp主?
- 特定のレンダラに依存する機能を用意するのはダメということでしょうか？"INiVEBitmap"みたいな名前のインターフェースを用意して、GDIのときはBitmapを使ったクラス、GLのときはPBOを使ったクラスを渡せばプラグイン製作者はレンダラを意識する必要はないと思います・・・でも引数を変えたら、現在のプラグインをどうしたらいいかわからないし、やっぱりだめか・・ -- vroad?
- PBOに対応してほしい理由はglTexSubImage2Dとか、フレームバッファの内容を読み出すときの転送時間が短くなり、高速化につながると考えたからです。また、パーティクルをフラグメントシェーダを使って大量に、高速に処理できます。↑で書いたようにインターフェースを用意するのは、複数のレンダラを持つ3Dエンジンではよく行われています。問題は、PBOとBitmapが同じように扱えるかどうかとか、既存のプラグインをどうするかとか、うｐ主の気持ちとかです・・ -- vroad?
- OpenGL使用時もGDI使用時もエフェクトを掛ける段階ではイメージはBitmapとして扱っており、エフェクトをかけ終わった後に各レンダラにイメージを渡すようになっています。OpenGLレンダラの場合はこの段階でイメージをテクスチャとしてセットしているので、エフェクトをかける段階ではPBOやFBOなどには一切触れていません。
入力からPBOを用いて各エフェクトをシェーダで回すようにしたとしても、シェーダ切り替えのコストや、API呼び出しの際のP/Invoke、マーシャリングのコストもバカにならないですし、開発者側はシェーダとマネージドコードの両方を書かなければいけなくなります。インターフェースを通してbyte配列で受け取れるようにして、マネージドコードのみでも処理できるようにたとしても、OpenGL使用時にはGPU・CPU間の転送コスト、マーシャリングでのコストが半端無いことになってしまいます。 -- うp主?
- ・・・unsafeのコードは使えませんか？BitmapData.Scan0とglMapBufferARBを使い分けすればいいとか、そんな安直な考えを持っていたんですが -- vroad?
- unsafeのコードは絶対に使わない方針なんでしょうか？サンプルもそうなっていますし・・ -- vroad?
- glMapBufferARBを使用するとしても、glMapBufferARB使用時にVRAMからメインメモリへの転送が入りますし、シェーダを使う際にはglUnmapBufferARBしなければならないのでまたそこで転送が入ってしまいます。また、GLSLのシェーダ切り替えはHLSLと違い、切り替え時にシェーダプログラムのコンパイルが入るため非常に遅く、いくつかの切り替えが入るだけでかなり遅くなります。さらに、仮に実装できたとしても、IViolateEffectでイメージのサイズ変更がされた場合はバッファの再確保も必要になってしまいます。
>unsafeのコードは絶対に使わない方針
絶対にというわけではありませんが、極力使わない方向で行こうと思っています。unsafe使うくらいならコア部分を最初からCで書いた方が速くなりますし、せっかくポインタを隠蔽してくれてるのにわざわざそれを表に出す必要も無いんじゃないかなとw -- うp主?
- >glMapBufferARBを使用するとしても、glMapBufferARB使用時にVRAMからメインメモリへの転送が入りますし、
全然知りませんでした。（直接VRAMに書き込めると思っていた）だってそんなこと何処にも書いてないし・・。「クライアントのメモリにマップする」とかしか書かれていません。もしよければ情報ソース教えてください
>切り替え時にシェーダプログラムのコンパイルが入る
そんなバナナ ATI RenderMonkeyのサンプルで8パス、40952ポリゴン使うHDRシェーダーで80FPSぐらい出ますよ。コンパイルはglCompileProgram、切り替えはglUseProgramで別の命令なのでは。＞せっかくポインタを隠蔽してくれてるのにわざわざそれを表に出す必要も無いんじゃないかなとw
うーん・・・C#でポインタぐらい使えたっていいじゃん、とつい思ってしまいますね・・・ -- vroad?
- フラグメントシェーダでパーティクルを処理して、頂点配列に設定して描画するという使い道はどうなんでしょう？
＞IViolateEffect
・・どうすりゃいいのか。エフェクトプラグインに変更したサイズのPBOを用意させれば再確保はサイズが変わったときだけで済みますが・・。トランスフォームでズームイン/アウトしたりしなければ大丈夫！ -- vroad?
- >「クライアントのメモリにマップする」とかしか書かれていません。
まさにそれです。メモリにマップすると言うことは、クライアントのメインメモリにコピーしてその先頭アドレスを返すと言うことです。同じポインタなのに内部で勝手にメインメモリとVRAMを使い分けるような処理系があったら怖いですw
>glCompileProgram
GLSLを使えるようにするときにまとめてUseProgramメソッドとして固めてしまったのですっかり失念してましたw
>ポインタ
C/C++をメインで使ってる友人がよく言ってますw C#をメインで使ってる身としては、ポインタはあくまでもCOMなどのネイティブAPIなどを呼び出すための方法(これもほとんどIntPtrで解決しますが)という感じなので、サンプルなどでポインタ使ってるのをみるのはあんまり気分よくないですねw
>パーティクル
一応簡単なパーティクルエフェクトは作ってみましたが、よっぽど高度な物理演算でもやらなければCPUに座標計算させても問題なさそうでした。座標計算よりも描画処理の方が重たいのでそっちをどうにかすべきなのですが、それは普通にポリゴンを描画するだけなので特に問題はないかと。
>トランスフォームでズームイン/アウトしたりしなければ大丈夫！
元々ちょん切れてる上に変形できないんじゃ使い物になりませんがなw -- うp主?
- >同じポインタなのに内部で勝手にメインメモリとVRAMを使い分けるような処理系があったら怖いですｗ
http://www.opengl.org/sdk/docs/man/xhtml/glMapBuffer.xml
"The data can then be directly read and/or written"とか書いてあるし、
http://ja.wikipedia.org/wiki/メモリマップドI/O
と同じかと思ったので・・違うんですね。
http://www.stevestreeting.com/2007/03/17/glmapbuffer-vs-glbuffersubdata-the-return/
英語でよく分かりませんが、32KBを超えたらglBufferSubDataよりglMapBufferの方が速いそうです。
-- vroad?
- glMapBuffer使うとしたら、IntPtr.ToPointerしてunsafe使いまくらないといけなくなりますしね・・・
そういえばトランスフォームは元のサイズよりでかくすると切れるし、*が名前の後ろについていないので
IViolateEffectではないんですね。こんな風にするのは？
・画像入力プラグインは、PBOを2つ保持
PBO1は元画像用、PBO2は他のプラグインに書き換えさせるためのもの
GetFrameを呼ばれたらPBO1からPBO2にコピーして返す
・動画入力プラグインはPBOを1つ保持
元画像は(DSInputなら)DirectShowが持っているのでPBOに置けない
・IViolateEffectは新たにPBOを用意
エフェクトの初期化時にglGenBuffersでPBOを1つ用意。
エフェクトのプロパティが変更され、再確保が必要になったら
glBufferData（NULLで呼ぶ？）で現在のデータを捨てる。
もしエフェクトが全てシェーダー化されるようなことがあれば、PBOは用なしですね。
描画結果がすぐテクスチャに入るFBOの方がいいです。いや、元から使う価値梨ですかね -- vroad?
- 正直そこまでするくらいならはじめからCUDAとかOpenCL(まだ出てないけど)使った方が早いような…w -- うp主?
- http://www.songho.ca/opengl/gl_pbo.html
glTex(Sub)Image2Dの速度はやっぱり上がるようです。OpenGLレンダラがGDIレンダラと比べて 遅いのってメモリからテクスチャへの転送を待たされているからでは？
実装してみる価値があるとは・・思いませんか？
IViolateImageEffectで、すぐに捨てられるようなデータを確保するときは glBufferDataのusageにSTREAMを指定したほうがいいかも。
3D変形もIViolateImageEffectですが、コンポジションと同じサイズで1回確保すればOKなんでしょうか。 >CUDAとかOpenCL GPGPUは情勢？が不安定なようなので・・・様子見を
-- vroad?
DirectShow入力プラグインについて †
momo? (2008-12-31 (水) 14:57:55)
恐れ入りますが、DirectShow入力プラグインの再導入はまだでしょうか？
- このページの左上のメニューからプラグインページにいけば普通に落とせますよ。古いほうのWikiのプラグインページを見ていたのではありませんか？ --
エクスプレッションの単独表示 †
コーヒー? (2008-11-28 (金) 09:56:46)
開発お疲れ様です。
verup毎に使いやすくなって助かります。
非常に細かな部分なのですが、現状エクスプレッション使用の際にはエフェクト、マテリアル内部にあるため位置、スケール等についての各タイムライン（キーフレームを打つ行）が表示されてしまうのですが、実際エクスプレッション使用の際は最初のプロパティ取得の際ぐらいしかその行を見る必要はないので、表示・非表示が選択できると縦のスペースが有効に使えてさらに効率よく書き込めるようになると思います。
マテリアルのA,P,S,Rでの１キー呼び出しみたいにEキーでエクスプレッション部だけ表示、のようなやり方でもいいかもしれません。
ほんと細かくて恐縮ですが、ご検討ください。
- 確かにパラメータがたくさんあると結構邪魔ですね。 プロパティコントロールの関係上、コンテキストメニューによる対応になりますがいいでしょうか? -- うp主?
- はい。是非それでお願いしますです。 -- コーヒー?
- ver1.77での実装ありがとうございます！ -- コーヒー?
ソーステキスト設定ダイアログのGUIについて †
ルーチェ? (2008-11-24 (月) 08:16:14)
ソーステキスト設定ダイアログに付いている[OK]ボタンの Control.Text を
"&OK" にして頂けると、キーボードでの文字列入力後に、マウスカーソルを
動かさずにAlt＋Oキーで入力確定できて便利だなぁと思いました。
また、[キャンセル]ボタンはダイアログの Form.CancelButton プロパティに
設定して頂けると、こちらもESCキーでキャンセルできて便利ではないかと。
まぁ、その後は結局マウスカーソルを動かして他の操作をするわけですが、
動画にセリフ等を一定間隔で入れるような単純作業では、マウスの操作量が
極力少ない方が能率が上がるので…。
細かい要望で恐縮ですが、問題なければ対応して頂けるとありがたいです。
- 現在NiVEで表示される設定ダイアログは、EnterでOK、Escでキャンセルができるようにしてありますが、これ以外にもニーモニックキーを設定した方がいいということでしょうか? -- うp主?
- 確かにプロジェクト設定ダイアログ等はそうなっているようですが、テキストタイムラインのテキスト→ソーステキストの編集ダイアログだとEscでキャンセルできないので…（Enterは当然ながら改行入力になる。Tabでフォーカスを移せばいけますが…）。 -- ルーチェ?
- 「ソーステキスト設定ダイアログ」という書き方がまずかったかなorz 私はテキストタイムラインをよく使うので、その文字列設定でいちいちマウスカーソルを動かしてOKボタンを押すのに煩わしさを感じてしまって…。でもよく考えたら上述したようにTabでフォーカスをボタンに移せばEnterキーで押せますね。当面はこの操作でいくことにします。 -- ルーチェ?
- orz そっちはテキストの改行をできるようにするためにEnterでOKできないようになってました。そっちの方にはニーモニックキー付けときます。 -- うp主?
- 1.76での対応ありがとうございました。 -- ルーチェ?
パーティクルの仕様について †
167? (2008-11-21 (金) 21:03:29)
コンポジションＡで作ったパーティクルを、
コンポジションＢに移すとリセットにキーフレームが打たれていなくても、
リセットした最初からの状態になってしまいます。
仕様かバグか分かりませんが、可能でしたら対応お願いします。
- プラグインに関する質問は、プラグインのページにてお願いします。 パーティクルの発射した粒子に関する情報は、コピー時、またはプロジェクト保存時には保存されず、貼り付け先などには反映されません。これは、NiVEでの貼り付け処理に関する部分の仕様となっています。 -- うp主?
- 本体の標準エフェクトと勘違いしていました。すみません。仕様との事、了解しました。 -- 167?
エクスプレッションの無効化について †
金の髭? (2008-10-30 (木) 20:19:55)
要望というほどのものではないですが、なんらかの形でエクスプレッションの有効・無効を切り替えるようなことはできるでしょうか。
例えば、起動時に
「このプロジェクトにはエクスプレッションが含まれています。エクスプレッションを有効にしますか？」
といった警告を出して有効・無効を選ぶとか。
エクスプレッションに関する知識が浅いので変なことを言ってるかもしれませんが、
比較的無制限にプログラムが書けると聞いたので、悪意あるプログラムへの対処の１つとして有効かなと思いました。
もっとも、問題ないかどうか調べるには、無効にして開いた上でエクスプレッションのソースをチェックして判断する力が必要なわけですが。
- ここのプロジェクトで有効・無効を設定するのは結構面倒なので、環境設定から有効・無効の設定、エクスプレッションのアセンブリにはファイルアクセスやらレジストリのパーミッションでも付けてみようかと。 -- うp主?
- おお、なるほどそういうこともできるのですね。危険なことをする人はまずいないとは思うのですが、一応案の１つとして書いてみました。実装項目の１つとしてご検討いただければ幸いです。 -- 金の髭?
用語集とテキストアニメーションのページ作成について †
金の髭? (2008-10-26 (日) 21:43:08)
うｐ主様へ
NiVE愛用者スレにも書きましたが、
「NiVE関連用語集」
「テキストアニメーションプリセット」
の２つのページをWiki内に試作してみました。
内容をご判断いただき、もし差し支えなければメニューのほうに追加していただければ幸いです。
プリセットの配布などについては、こんな感じでどうだろうということでまとめてみましたが、
他になにかお考えになっていたことがあれば破棄していただいて構いません。
あと、確認をとらずに進めてしまいましたが、プリセットを公開する場合、素材アプロダのほうを使わせていただいても問題ないでしょうか？
- 追加しました〜 -- うp主?
- 素材あぷろだはその名の通り素材なら何でも(他者の権利を侵害しない限り)うpしていいので、どんどん使ってやってください。 -- うp主?
- 対応ありがとうございます。それではありがたく使わせていただきます。 -- 金の髭?
動画を毎回幅をピッタリにするのが相当面倒なんで・・・ †
トイタッツ? (2008-10-26 (日) 19:33:22)
質問箱に書いたほうがよかったかな・・・？
動画を読み込んだ後、ほとんど512*384に合ってなく、毎回タイムラインでマテリアルからサイズを縦横の余白をなくし、ピッタリ合わせようとしているんですが、縦横の余白と限度のところが全部黒なので相当わかりにくく、さらに動画をタイムラインに読み込む度にそのかなり面倒な作業をしないといけないのはとても嫌です。
なので、縦横の余白を自動でなくし、縦横がピッタリ512*384に合うようなのを是非追加してください。
もし既にあったら方法を教えてください。お願いします
- どういう素材動画を使っているのかわかりませんが、コンポジションや動画のサイズを把握していれば、画面を見ながらサイズをあわせる必要はなく、座標やスケールを計算してあわせればすむはずです。基本的なところに勘違いがあるような気がします。マテリアルの各パラメータの意味を考えながら作業を進めてみましょう。あと、もしかしてコンポジション作成時にレンダラとして「OpenGL」を選択していますか？OpenGLは動画を３次元的に扱うためやや複雑になるので、最初は「GDI」を選択して色々練習して基本概念を学ぶと良いと思います。なお、余白の色を変える機能については、まさにこのページの一番下のコメントで要望が出ており、NiVE v1.73で実装されています。そちらのコメントも読んで下さい。プレビューウィンドウの右クリックメニューから「背景色の変更」を選べばその機能が使えます。 -- 金の髭?
- 度々ありがとうございます！！ 一応、GDIでやっていました。しかし、初期の読み込んでタイムラインに移動した時は、左上に来て、動画サイズが動画そのものが320*240だったりするとできなくなるのです。 計算で求めると512÷320と384÷240ということですね。 それと、背景色の変更で位置がものすごくわかりやすくなりました。ありがとうございます！！ これで作業もはかどるかと思います。 -- トイタッツ?
objファイルの読み込み †
ussy? (2008-10-25 (土) 00:19:02)
既出だったらすみません。
objファイルの読み込みはできるようになりませんでしょうか？
さらに贅沢を言わせてもらえれば、
メタセコイアのmqoが使えるととても嬉しいんですが・・・
- gekkao氏により「PluginAx.Irrlicht」というプラグインがリリースされています。今のところこれがNiVEで3Dモデルを扱う唯一の手段だと思われます。こちらのプラグイン一覧表から作者さんのHPに飛べますので見てみて下さい。プラグインの説明動画はこちら。作者さんのHPに詳しい説明もあります。そこのFAQを見るとmqoファイルも使えるように見えます。私は3Dモデルを扱ったことがないので間違ってるかもしれませんが・・・。 -- 金の髭?
- あったんですね。ありがとうございました -- ussy?
プレビューウインドウ枠の色 †
コーヒー? (2008-10-15 (水) 01:44:42)
NiVEいつも使わせてもらってます。
タイミング計ったようにちょうど１ヶ月ですがお休みを邪魔する意図はないですｗ
現状、プレビューウインドウの動画外の部分は真っ黒ですが、ここの部分の色を環境設定で弄れるようにしていただくことは可能ですか？ 背景色を透明で作業することが多いのですが、この場合背景色が黒に見える状態なので動画自体、プロジェクト自体との境が目で確認できません。背景色を一時的に透明でなく黒でない色に変更することで対処していますが、この要望を取り入れていただくとその手間がなくなりより効率的に作業できるようになります。
どうか御一考ください。
- プレビューウインドウの背景色を変更することは可能ですが、間に透明部分の塗りつぶし等の処理が必要になるため、少し重くなると思われますがよろしいでしょうか? -- うp主?
- 「透明部分の塗りつぶし等の処理」を見て不安に思ったので確認させてください。現在「透明」を選択した場合の色を黒から変えることはできる、動画の枠の外のあまりの黒い部分を変えることはできない、ということでしょうか。また、いずれにせよ、重くなるのは設定で黒から変更した場合のみでデフォルトのままなら重くはならない、ということはないでしょうか？ -- コーヒー?
- すいません、言葉が足りませんでした orz 塗りつぶすのはレンダリング後のイメージの透明部分で、プレビューウインドウの背景色は変更可能です。また、レンダラが透明色、プレビューウインドウが黒以外の時のみこの処理を行う、というようなことは可能です。 -- うp主?
- 謝られると逆に罪悪感がｗ 確認取っただけですｗ デフォルト時は処理をはさまない、重くならないということなら取り入れていただくとうれしいです。 -- コーヒー?
- ver1.73での実装ありがとうございます。スレでは早とちりしてましたが、どうもレンダラ、プレビューウインドウの背景色ともにデフォルトの状態で起動してからプレビューウインドウの背景色を変えると動画の透明部分も一緒に塗りつぶされてしまうようです。その後レンダラ側を透明に設定しなおしたりすればイメージどおりでした。ありがとうございます。 -- コーヒー?
- たしかに塗りつぶされますが、フレーム再描画すれば大丈夫みたいですね。自分も一瞬あれ？って思ったｗ --
- おおぅ、色変更直後は透明部分が塗りつぶされませんね。修正します orz -- うp主?
- よろしくおねがいしますｗ -- コーヒー?
- もう遅いかもですが、一番下に派手な色のカラーイメージ置けば区別付きますよ --
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
