目安箱 †
意見・質問等はこちらにお願いします。
過去の要望・意見はこちら
注意:ここに乗せた機能全てを実装するとは限りません。また、検討・テストした結果不可能と判断した物は実装予定としていても実装しないこともあります。
※エフェクト、入出力プラグインに関しては、プラグインのページにてお願いします。
OpenGLでブレンドモード †
vroad? (2009-02-07 (土) 23:44:06)
こっちはどうでしょう?
加算合成と減算合成はシェーダー無しですぐできそうです。
現在拡張2Dでしかブレンドモードの指定は出来ないようですが。
- glAccumで加算・減算はできるみたいですが、オンボードや古いグラボだと自前で合成したほうが速いみたいですね。 この部分は前から考えてはいたのですが、現在シェーダで誤魔化しているアルファブレンドの問題と同じ問題を抱えているので、ちょっと様子見です。 -- うp主?
- glBlendFuncは?減算は出来ないかと思いましたがglBlendEquationEXT(GL_FUNC_REVERSE_SUBTRACT_EXT)という手もあるようです。
glBlendFuncだけでも色反転→加算→色反転すれば出来るみたいですが、重そうです。 -- vroad?
テクスチャ転送時に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?
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が同じように扱えるかどうかとか、既存のプラグインをどうするかとか、うp主の気持ちとかです・・ -- 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を使い分けるような処理系があったら怖いですw
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での1キー呼び出しみたいに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)
コンポジションAで作ったパーティクルを、
コンポジションBに移すとリセットにキーフレームが打たれていなくても、
リセットした最初からの状態になってしまいます。
仕様かバグか分かりませんが、可能でしたら対応お願いします。
- プラグインに関する質問は、プラグインのページにてお願いします。 パーティクルの発射した粒子に関する情報は、コピー時、またはプロジェクト保存時には保存されず、貼り付け先などには反映されません。これは、NiVEでの貼り付け処理に関する部分の仕様となっています。 -- うp主?
- 本体の標準エフェクトと勘違いしていました。すみません。仕様との事、了解しました。 -- 167?
エクスプレッションの無効化について †
金の髭? (2008-10-30 (木) 20:19:55)
要望というほどのものではないですが、なんらかの形でエクスプレッションの有効・無効を切り替えるようなことはできるでしょうか。
例えば、起動時に
「このプロジェクトにはエクスプレッションが含まれています。エクスプレッションを有効にしますか?」
といった警告を出して有効・無効を選ぶとか。
エクスプレッションに関する知識が浅いので変なことを言ってるかもしれませんが、
比較的無制限にプログラムが書けると聞いたので、悪意あるプログラムへの対処の1つとして有効かなと思いました。
もっとも、問題ないかどうか調べるには、無効にして開いた上でエクスプレッションのソースをチェックして判断する力が必要なわけですが。
- ここのプロジェクトで有効・無効を設定するのは結構面倒なので、環境設定から有効・無効の設定、エクスプレッションのアセンブリにはファイルアクセスやらレジストリのパーミッションでも付けてみようかと。 -- うp主?
- おお、なるほどそういうこともできるのですね。危険なことをする人はまずいないとは思うのですが、一応案の1つとして書いてみました。実装項目の1つとしてご検討いただければ幸いです。 -- 金の髭?
用語集とテキストアニメーションのページ作成について †
金の髭? (2008-10-26 (日) 21:43:08)
うp主様へ
NiVE愛用者スレにも書きましたが、
「NiVE関連用語集」
「テキストアニメーションプリセット」
の2つのページをWiki内に試作してみました。
内容をご判断いただき、もし差し支えなければメニューのほうに追加していただければ幸いです。
プリセットの配布などについては、こんな感じでどうだろうということでまとめてみましたが、
他になにかお考えになっていたことがあれば破棄していただいて構いません。
あと、確認をとらずに進めてしまいましたが、プリセットを公開する場合、素材アプロダのほうを使わせていただいても問題ないでしょうか?
- 追加しました〜 -- うp主?
- 素材あぷろだはその名の通り素材なら何でも(他者の権利を侵害しない限り)うpしていいので、どんどん使ってやってください。 -- うp主?
- 対応ありがとうございます。それではありがたく使わせていただきます。 -- 金の髭?
動画を毎回幅をピッタリにするのが相当面倒なんで・・・ †
トイタッツ? (2008-10-26 (日) 19:33:22)
質問箱に書いたほうがよかったかな・・・?
動画を読み込んだ後、ほとんど512*384に合ってなく、毎回タイムラインでマテリアルからサイズを縦横の余白をなくし、ピッタリ合わせようとしているんですが、縦横の余白と限度のところが全部黒なので相当わかりにくく、さらに動画をタイムラインに読み込む度にそのかなり面倒な作業をしないといけないのはとても嫌です。
なので、縦横の余白を自動でなくし、縦横がピッタリ512*384に合うようなのを是非追加してください。
もし既にあったら方法を教えてください。お願いします
- どういう素材動画を使っているのかわかりませんが、コンポジションや動画のサイズを把握していれば、画面を見ながらサイズをあわせる必要はなく、座標やスケールを計算してあわせればすむはずです。基本的なところに勘違いがあるような気がします。マテリアルの各パラメータの意味を考えながら作業を進めてみましょう。あと、もしかしてコンポジション作成時にレンダラとして「OpenGL」を選択していますか?OpenGLは動画を3次元的に扱うためやや複雑になるので、最初は「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いつも使わせてもらってます。
タイミング計ったようにちょうど1ヶ月ですがお休みを邪魔する意図はないですw
現状、プレビューウインドウの動画外の部分は真っ黒ですが、ここの部分の色を環境設定で弄れるようにしていただくことは可能ですか? 背景色を透明で作業することが多いのですが、この場合背景色が黒に見える状態なので動画自体、プロジェクト自体との境が目で確認できません。背景色を一時的に透明でなく黒でない色に変更することで対処していますが、この要望を取り入れていただくとその手間がなくなりより効率的に作業できるようになります。
どうか御一考ください。
- プレビューウインドウの背景色を変更することは可能ですが、間に透明部分の塗りつぶし等の処理が必要になるため、少し重くなると思われますがよろしいでしょうか? -- うp主?
- 「透明部分の塗りつぶし等の処理」を見て不安に思ったので確認させてください。現在「透明」を選択した場合の色を黒から変えることはできる、動画の枠の外のあまりの黒い部分を変えることはできない、ということでしょうか。また、いずれにせよ、重くなるのは設定で黒から変更した場合のみでデフォルトのままなら重くはならない、ということはないでしょうか? -- コーヒー?
- すいません、言葉が足りませんでした orz 塗りつぶすのはレンダリング後のイメージの透明部分で、プレビューウインドウの背景色は変更可能です。また、レンダラが透明色、プレビューウインドウが黒以外の時のみこの処理を行う、というようなことは可能です。 -- うp主?
- 謝られると逆に罪悪感がw 確認取っただけですw デフォルト時は処理をはさまない、重くならないということなら取り入れていただくとうれしいです。 -- コーヒー?
- ver1.73での実装ありがとうございます。スレでは早とちりしてましたが、どうもレンダラ、プレビューウインドウの背景色ともにデフォルトの状態で起動してからプレビューウインドウの背景色を変えると動画の透明部分も一緒に塗りつぶされてしまうようです。その後レンダラ側を透明に設定しなおしたりすればイメージどおりでした。ありがとうございます。 -- コーヒー?
- たしかに塗りつぶされますが、フレーム再描画すれば大丈夫みたいですね。自分も一瞬あれ?って思ったw --
- おおぅ、色変更直後は透明部分が塗りつぶされませんね。修正します orz -- うp主?
- よろしくおねがいしますw -- コーヒー?
- もう遅いかもですが、一番下に派手な色のカラーイメージ置けば区別付きますよ --