LogicoolのG9 Laser Mouseを愛用している。
ゲーミング向けとはなっているが普通に使う分にも非常に扱いやすい。
が、専用ソフトウェアのSetPoint・・・こいつだけは常に不安定だ。
ある日突然挙動がおかしくなる。
先ず、サイドボタンどちらかを押すとマウス制御不能に陥る。
また、ハード側でプロファイルを切り替えても同じ症状。
一時的な解決手段はPC再起動。
アンインストールしようとするものの正規ルートではアンインストール不可能。
そこで強制アンインストールソフトで対処。
再度インストールするものの症状は改善されず。
少し強めのレジストリクリーンソフトでクリーン。
するとサイドボタンの不具合は解消するがプロファイルでの問題は依然残る。
SetPointIIを起動すると、どうやら認識されていない。
※G9はコントロールセンター側では認識されないのは正常
Google先生で調べられる範囲の解決方法はすべて有効ではなかった。
この時の状態は下記。
(1) デバイスマネージャ側ではLogicool HID-compliant G9 Laser Mouseと表示
正常動作となっている
(2) SetpointII.exeでは認識されていない
(3) サイドボタンのプリセットは機能している
で、解決した方法は・・・
コントロールパネル→ハードウェアとサウンド→デバイスとプリンタの表示→デバイス
ここにLogicool(R)G9 Laser Mouseがあるので右クリックでコンテキストメニュー表示。
トラブルシューティングに警告マークが付いていたのでクリックすると修復開始。
今回はこれで問題が解決した・・・。
2012年5月12日土曜日
2012年3月27日火曜日
スキニング
思い返せばGPUでスキニングなんてまともにやったことがない事実。
LightwaveのCPUスキニングくらいしか記憶にない。
分業化の弊害というかやる気がなかっただけというか。
初心に帰ってやってみることにした。

左:行列パレット使用
中:行列パレット使用(途中の過程はSQT)
右:SQT
どれもこれも結果は同じのベーシックな手法。
結局、頂点ブレンドしてる限り潰れることには変わりなし。
サンプルはGitHubのSimpleSkinningSample。
一応、最近の流行というか主流な手法にも目を通してみた。
・spherical blend skinning
・skinning with dual quaternions
前者が主流で後者が割りと最近の手法とのこと。
変形結果を見る限りでは前者が自然な気がする。
計算コスト的には後者が優れている(対数空間で乗算を加算にするとか)。
LightwaveのCPUスキニングくらいしか記憶にない。
分業化の弊害というかやる気がなかっただけというか。
初心に帰ってやってみることにした。

左:行列パレット使用
中:行列パレット使用(途中の過程はSQT)
右:SQT
どれもこれも結果は同じのベーシックな手法。
結局、頂点ブレンドしてる限り潰れることには変わりなし。
サンプルはGitHubのSimpleSkinningSample。
一応、最近の流行というか主流な手法にも目を通してみた。
・spherical blend skinning
・skinning with dual quaternions
前者が主流で後者が割りと最近の手法とのこと。
変形結果を見る限りでは前者が自然な気がする。
計算コスト的には後者が優れている(対数空間で乗算を加算にするとか)。
2012年3月26日月曜日
GLSLあれこれ
HLSLの場合はDirectXがコンパイル。
GLSLの場合はグラフィックカードのドライバでコンパイル。
という認識なので、誤認識でなければドライバが悪さしているということになる。
GLSLに限らずシェーダ言語はベクトル演算が得意なのは百も承知なんだ。
それでも最適化を意識しない段階ではスカラー演算で済ませてしまうこともある。
とある実装で内積演算をスカラー演算で済ませている箇所で問題が発生した。
ベクトル演算に直すと意図した結果になった・・・めでたしめでたし。
では済まない。
C++でのアルゴリズムから演算部分、シェーダの記述を全て見直して、
該当箇所をなんとはなしに変更して見ると、実はベクトル演算でなかった結果、
問題が発生していたのだ。
仮にデバッガがあったとしても、気付き難いレベルだぞっと・・・。
一応ドライバ(nVidia Geforce7800用)は最新なんだけどなぁ。
あとは以前発生していたリンクエラーの問題。
vertex/fragment共にエラーはないのにリンク時に失敗するケース。
失敗時は通常エラーログを取得できるのだができない。
つまり何が起きているのかさっぱり分からない。
glGetShaderiv(program, GL_INFO_LOG_LENGTH, &bufSize);
で返ってくるバッファサイズが負になっていたんだが、無理やり適当なサイズに変更した。
するとエラーログが取得できた。
GLSLのおかげでやりたいことが一向に進まないジレンマ。
GLSLの場合はグラフィックカードのドライバでコンパイル。
という認識なので、誤認識でなければドライバが悪さしているということになる。
GLSLに限らずシェーダ言語はベクトル演算が得意なのは百も承知なんだ。
それでも最適化を意識しない段階ではスカラー演算で済ませてしまうこともある。
とある実装で内積演算をスカラー演算で済ませている箇所で問題が発生した。
ベクトル演算に直すと意図した結果になった・・・めでたしめでたし。
では済まない。
C++でのアルゴリズムから演算部分、シェーダの記述を全て見直して、
該当箇所をなんとはなしに変更して見ると、実はベクトル演算でなかった結果、
問題が発生していたのだ。
仮にデバッガがあったとしても、気付き難いレベルだぞっと・・・。
一応ドライバ(nVidia Geforce7800用)は最新なんだけどなぁ。
あとは以前発生していたリンクエラーの問題。
vertex/fragment共にエラーはないのにリンク時に失敗するケース。
失敗時は通常エラーログを取得できるのだができない。
つまり何が起きているのかさっぱり分からない。
glGetShaderiv(program, GL_INFO_LOG_LENGTH, &bufSize);
で返ってくるバッファサイズが負になっていたんだが、無理やり適当なサイズに変更した。
するとエラーログが取得できた。
おいこらnVidiaの担当者ちょっと出て来い。
GLSLのおかげでやりたいことが一向に進まないジレンマ。
登録:
投稿
(
Atom
)