昨日の続き。

MBCS で CProgressCtrl::SetMarquee() と同等の振舞いをさせるには以下のようにする。

1. PBM_SETMARQUEE を SendMessage する
　　CProgressCtrl* pWnd;
　　pWnd->SendMessage( PBM_SETMRQUEE, ... );

2. Windows XP ビジュアルスタイルに変更する(*)
　　http://www.microsoft.com/japan/msdn/windows/windowsxp/xptheming.aspx を参照



* ... MBCS でコンパイルするとXPスタイルを使用する manifest ファイルを自動生成してくれない
　　　 UNICODE 時は XPスタイルを含んだ manifest ファイルを自動生成する

UNICODE 定義時にしか使えません。 ...なんでやねんorz

http://markezine.jp/article/detail/4822

MarkeZineのRSS見てたら、変なのが引っかかった・・・

豊川ヴォイスが気になってしょうがないので本屋さんで見つけたら買ってみようと思う。

CWnd を派生させた自作クラスに template class を使いたくて、使い方を調べました。

MSDNでヒットしたので、そちらを参考にしました。

 

ふむ。

BEGIN_MESSAGE_MAP() を BEGIN_TEMPLATE_MESSAGE_MAP() にするだけでいいのか。

 

ふむふむ。

 

っで、作ってみたわけですが。

 

 

template class 内の関数宣言のところで右クリックすると確実にフリーズします。(VC8)

---

template<typename T>

class Hoge : public CWnd

{

        void hage();   // ←ここで右クリック

};

 

#include "hogeImpl.cpp"  // 定義部はcppに記述

---

フリーズというか、カーソルのアイコンが砂時計になったまま戻ってこないです。

私の場合、[右クリック → 定義へ移動] を多用するので、癖で右クリックしてしまってよく固めちゃいます。

この現象にあわれた方いらっしゃいませんか？

対処法をググってみたんですが、見つけられず。

 

追記(6/23 14:45)

F12 キーでも固まりました。

どうやらジャンプ先が見つけられず永遠と検索しているような感じです。

あれです。

なんのヒネリもなく、パックマンもいません。

だってパックマン描くの面倒くさかったのｗ

(Project : VS2008 Professional [C#])

 

気が向いた時に時間があれば何か機能追加します。

気が向かなかったり、時間が無ければ尻つっついてくださいｗ

[3ds max][plugin]外部参照オブジェクトの外部参照コントローラのみをシーン合成する　の続報です。

前回、

> っが正直なところ、これくらいは maxscript で対応してくれてもよさそうです。

> 手元にある max2008 の maxscriptリファレンスを見ても、対応してませんでした。

> max2009 はどうなんでしょうね・・

と書きましたが、トライアル版のmax2009をインストールして調べてみました。

結果、#mergeControllers はありませんでした。

残念です。

 

 

ついでに、max2009 を起動して気付いたのがビューポートの変化。

Autodesk DWF Viewerで見たことのあるView Cubeがデフォルトでついていました。これ、社内の人には不評でした。

おそらく開発ではほぼ「デフォルトでOFF」状態になりそうな機能です。

ただし、操作が直感的なのでmaxの操作に慣れていないディレクター等の品質チェックのみを行う人なんかにはアリかも、という感じでした。

max8では正常動作していたスクリプトをmax9で走らせると一部不具合が判明した。

不具合があった箇所というのは、複数のmaxファイルを外部参照オブジェクトとして読み込み、Offset, Rotation, Scaleを

予め用意しておいた数値でアニメーションキーを自動的に打つ部分。

max9では新たなアトリビュートとして「外部参照コントローラ」なるものが用意されていた。

コントローラも外部参照として扱われているので、シーン内でそのオブジェクトに新規にキーを打つことができない状態になっていた。

では、外部参照コントローラだけをシーン合成行うにはスクリプトでどうすればいいか調べてみたところ・・・

・

・

・

結論から言うと、スクリプトのみでは方法が「ない」んです。

maxscriptで外部参照オブジェクトに関して操作する場合、objXRefMgrインタフェースを使用します。

+ MAXScript 言語リファレンス
　+ 3ds Max オブジェクト
　　+ インタフェース
　　　+ コア インタフェース
　　　　+ コア インタフェースのドキュメント
　　　　　+ インタフェース: objXRefMgr
maxscriptリファレンスの上記ツリーを確認してみると、

---

<Interface>AddXRefItemsFromFile <filename>fileName promptObjNames:<bool> objNames:<string array> xrefOptions:<&enum array>
 promptObjNames default value:false
 objNames default value: #()
 xrefOptions enums:{#asProxy|#xrefModifiers|#dropModifiers|#mergeModifiers|#mergeManipulators|#selectNodes|#mergeMaterials}
 xrefOptions default value: #()
 xrefOptions は In パラメータです
指定されたレコードに名前の配列を追加します。

---

とあります。この xrefOptions で本来であれば存在していなければならない #mergeControllers がありません。

つまり max9 においてスクリプトレベルでの制御は不可能ということです。

 

仕方がないので外部参照オブジェクトを読み込むルーチンのみをプラグインで書き、

スクリプト側からプラグインの関数を呼び出すようにしました。

以下はそのソース。

---

#include <Maxscrpt/Maxscrpt.h>
#include <maxscrpt/Strings.h>
#include <maxscrpt/arrays.h>
#include <maxscrpt/numbers.h>
#include <maxscrpt/maxobj.h>
#include <maxscrpt/definsfn.h>

#include <XRef/iXrefObjMgr8.h>

def_visible_primitive( MergeXRefControllersFromFile, "MergeXRefControllersFromFile" );
Value* MergeXRefControllersFromFile_cf(Value** arg_list, int count)
{
 
 check_arg_count_with_keys(MergeXRefControllersFromFile, 2, count);

 type_check(arg_list[0], String, "第１引数は外部参照オブジェクト先のmaxファイルパスじゃないとダメ");
 type_check(arg_list[1], Array , "第２引数は読み込むノード名配列");

 try
 {
  char* full_path_filename = arg_list[0]->to_string();
  Array* node_names_array = static_cast<Array*>(arg_list[1]);
  
  Tab<char*> tab_node;
  char** node_names = new char*[node_names_array->size];
  for( int i=0; i<node_names_array->size; ++i ) {
   node_names[i] = node_names_array->data[i]->to_string();
  }
  tab_node.Append(node_names_array->size, node_names);
  IObjXRefManager8* xref_manager = IObjXRefManager8::GetInstance();
  IObjXRefRecord* ixrRecord = xref_manager->AddXRefItemsFromFile(full_path_filename, false, &tab_node, XREF_MERGE_CONTROLLERS);

  delete[] node_names;
 }
 catch(...)
 {
  return new Integer(-1);
 }
 return new Integer(0);
}

---

 

これで、スクリプト側から
MergeXRefControllersFromFile "C:\\hoge.max" #("node1", "node2")
のような感じで呼び出せます。

とりあえず、上記対策を行って正常動作することは確認しました。

 

っが正直なところ、これくらいは maxscript で対応してくれてもよさそうです。

手元にある max2008 の maxscriptリファレンスを見ても、対応してませんでした。

max2009 はどうなんでしょうね・・

コカ・コーラ、振らなきゃ飲めない炭酸飲料発売

 

炭酸飲料で振らなきゃ飲めないって斬新。

強炭酸だと爆発しかねないので炭酸は弱めになっているんでしょうね。

あれ？ファンタって結構炭酸キツかったような・・

頂点カラーのアニメーション作成に頂点ペイントモディファイヤを使用し、そいつを export させようと企んでいます。

 

で。

 

以下のコードを書いてみました。

 

boost::optional<int, int> CheckVertexPaint(INode* in_node)
{
 Object* max_obj = in_node->GetObjectRef();
 while( max_obj && max_obj->SuperClassID() == GEN_DERIVOB_CLASS_ID ) {
  IDerivedObject* dobj = static_cast(max_obj);
  const int num_modifier = dobj->NumModifiers();
  for( int modifier_cnt = 0; modifier_cnt < num_modifier; ++modifier_cnt ) {
   Modifier* mod = dobj->GetModifier(modifier_cnt);
   if( mod && mod->ClassID() == PAINTLAYERMOD_CLASS_ID ) {
    /// キーフレームの取得
    int lc_min_frame = INT_MAX;
    int lc_max_frame = INT_MIN;
    
    const int num_ref = mod->NumRefs();
    for( int ref_cnt = 0; ref_cnt < num_ref; ++ref_cnt ) {
     RefTargetHandle ref = mod->GetReference(ref_cnt);
     // max 9 では頂点ペイントモディファイヤでアニメート可能なパラメータは1つのみ
     Animatable* IAnim = ref->SubAnim(0); /// レイヤーの不透明度
     Tab key_frames;
     IAnim->GetKeyTimes(key_frames, FOREVER, 1);
     if( key_frames.Count() > 0 ) {
      if( key_frames[0] < lc_min_frame ) {
       lc_min_frame = key_frames[0];
      }
      if( key_frames[key_frames.Count() - 1] > lc_max_frame ) {
       lc_max_frame = key_frames[key_frames.Count() - 1];
      }
     }
    }
    
    if( lc_min_frame == INT_MAX ) {
     continue;
    }
    
    /// キーフレームの範囲が取得できたので取得した値を返却する
    return boost::optional<int, int>(std::make_pair(lc_min_frame, lc_max_frame));
   }
  }
  // 次の referenced object を検索
  max_obj = dobj->GetObjRef();
 }

 /// 取得できなかったのでこのノードには Vertex Paint モディファイヤは存在しない
 return boost::optional<int, int>();
}

 

 

頂点ペイントモディファイヤでレイヤーの不透明度にキーフレームが存在する場合、始点キーフレームと終点キーフレームを

std::pair<>に詰め込んで返す関数になってます。

 

最初、Modifier クラスから派生していない IVertexPaint クラスからどうやってアニメーションキーフレーム取るのか悩んでこのエントリーで愚痴ろうかとしていました。

エントリー書いている途中で閃いて無事キーフレーム取得できました。息抜きって必要ですね。

max 9では頂点ペイントモディファイヤで、アニメート可能なパラメータは1つしか存在しないので

　　Animatable* IAnim = ref->SubAnim(0);  /// レイヤーの不透明度

とSubAnim の引数を0で決めうちしています。

 

再利用される方はご注意を。

 

#あ、こんなネタ再利用するの私くらいかｗ

3ds Max 2009 の Press Release が発表されました。

http://pressreleases.autodesk.com/index.php?s=press_releases&item=383%3C%2Ftd%3E

英語版リリースは2008年春に予定と、3ds Max 2008がリリースされてまだ4ヶ月程しか経っていないのに

もう次バージョンを発表ですか、と驚いております。

 

3ds Max 2008の評価もほとんど出来てない状態だったので、もうこれは2009出るまで待っとけという神のおつげなんでしょうね・・・

詳細はこちら。

AGEIAといえばPhysXを開発している事でゲーム業界では有名（なはず）な企業。

GDC2006へ行った時もPhysXのセッションを覗きに行きました。

 

ただし、PhysXを導入する敷居は非常に高い。

なぜかと言うと、専用のチップ(PhysX SDK対応の物理演算用GPU)が必要なため。

PhysX - Wikipediaを参照

 

NVIDIAがPhysXのテクノロジをどう活かしてくるのか楽しみです。

Paint.NET では、デフォルトでPSDファイルを読み込むことは出来ない。

しかし、プラグインを導入することで様々な形式のフォーマットに対応することが出来る。

プラグインは自分で作ることもできるし、フリーで公開されているプラグインを使用することも出来る。

 

そこで公開されているPSDファイル読み込み用のプラグインを導入してみた。

大抵のPSDファイルは正常に読み込むことができ、編集も出来た。

しかし、一部のファイルで読み込み中に「メモリ不足のためイメージを読み込めません。」というエラーが発生した。

 

エラーの原因を調べてみると、どうやら Paint.NET はレイヤー毎に全てのピクセル情報を内部で持っているらしく

レイヤーの数を60, サイズを2000x3000の画像ファイルを読み込もうとすると以下の計算になる。

2000 * 3000 * 4(RGBA) * 60(layer) ≒ 1.34GByte

 

つまり、このようなPSDファイル1つを開くだけで約1.34GByteものメモリを食いつぶすことになる。

実際にはもう少しレイヤーの数が多いPSDファイルを読み込もうとしていたため、プロセス単位で扱えるメモリを全て使い果たし

結果読み込みエラーが発生したと推測する。

 

各レイヤーにおいて、透明色以外で塗ってあるピクセルの情報のみをメモリに保持しておく機構にすれば、かなりのメモリ節約になると思うのだが、なぜかそうはしていない模様。

 

※上記エラーはPSDファイルが原因ではなく、コアの実装に依存しているので別フォーマット読み込みでも発生する

私は今まで BitArray を使用したことがなく、今回少しハマったのでメモ。

---

Array リテラル
　#( <value>, <value>, ... )

+ MAXScript言語リファレンス
　　+ コレクション
　　　　+ コレクションのタイプ
　　　　　　+ 配列の値

 

---

BitArray リテラル
　#{ <selection> }
 
　<selection> は、カンマで区切られた次のリスト
　　　<integer>
　　　<integer> .. <integer>

+ MAXScript言語リファレンス
　　+ コレクション
　　　　+ コレクションのタイプ
　　　　　　+ BitArray値

 

---

■Array と BitArray の違いは何ですか。
 MAXScript の配列には任意の数の要素が格納でき、各要素は、整数、浮動小数点、文字列、Point3 値、カラー、あるいは他の配列のどれでもかまいません。

 一方 BitArray に格納できるのは、1 つのタイプの情報のみです。名は体を表すというように、このタイプとは単一のビット、
 すなわちバイナリ ディジットのことです。ビットは(1, true) に設定されるか、(0, false)に設定されないかのどちらかです。
 つまり、BitArray に保存できるのは、バイナリ情報、すなわち true または false 値を表す任意の数のビットだけです。
 bitArray は 1 バイト内に 8 つの値を保存できるので非常にメモリ効率が高いのですが、通常の配列の場合、1 つの要素が
 1 つの値を保存するために数バイトが必要になります。

 選択状態などの面のプロパティを取得および設定する場合には、bitArray が非常に有用です。

 bitArray を Array に変換したり、true および false 値しか格納していない Array を bitArray に変換することが可能です。

+ MAXScriptに関する質問と回答
　　+ MAXScriptの構文と用語
　　　　+ Array と BitArray の違いはなんですか。

---

 

つまり、
a = #(5, 10, 15, 20)
b = #{5, 10, 15, 20}
は全く別物であり、インデクサでアクセスした際の返り値も以下のように違う結果が返ってくる
a[1] → 5
b[1] → false

 

# ()と{},小さいフォントだと分かり辛くて小一時間悩みました

私に足りないものは一体なんだろう？

そう思ってやってみた。（パクリです）

 

 

むむ。確かに肉体美には憧れています。

#肉体改造計画を既に実施中

遅まきながら iKnow! に登録しました。

English の listen は feeling でなんとなく理解できますが speak や write は全然ダメです。

とりあえずの目標は、初級レベルを全制覇目指していこうと思います。

 

#ちょこっとやってみましたが、気楽にできて面白いですね

3ds maxで製作したシーンデータをエクスポートするプラグインを作っています。
最近頂点アルファを設定したデータに対応させました。
ところが、早速ツッコミが入りました。
「設定した頂点とは違う場所にアルファが入っている」と。
エクスポートされた該当ファイルを確認すると、確かに違う場所にアルファが入っている。

これは明らかにプログラムのミスと判断し、調査を始めたのが一昨日。
原因究明の為、頂点アルファ・頂点カラーについてのリファレンスを引いてみると以下の説明文がヒットした。(※1)

 A.テクスチャおよびカラー頂点の数はメッシュ頂点の数と、異なる場合がある。
 B.メッシュ面の数は、テクスチャおよびカラー面の数と常にまったく同じである。

 以上を踏まえた上で、対応する頂点を検出する方法を次に示す。
 
 1.メッシュ頂点のインデックスを取得します。
 2.対象とする面のインデックスを参照している面を検出します。
 3.各面の内部の頂点の番号(1番目、2番目、3番目 - .x、.y、または.z)を確認します。
 4.頂点を参照している各面について、同じインデックスのついたテクスチャ面を取得します。
 5.それぞれのテクスチャ頂点のインデックスを面から取得します(1番目、2番目、3番目 / .x、.y、または.z)。
 6.取得した頂点は作業開始したメッシュ頂点と対応しています。
 7.検出された全ての面について、手順3 ～ 6 を繰り返します。

なるほど。
つまり、予め Face (面)単位で頂点データを管理しておけばテクスチャ座標でも頂点カラーでも1対1の関係が必ず成り立つ。
(但し Face に関連付けられているのは各々の実データへのインデックス値であることに注意)

では、上記方法に作り直そうとソースを見ると、既にこの方法で書いてありました。
よく考えるとそりゃそうだよな。と思うところがあります。
以前からテクスチャ座標や頂点カラーはエクスポート対象としてサポートしていました。
そこに「頂点アルファ」を新たにサポートしただけでした。
もしリファレンス通りの方法で管理していないと頂点アルファ以前にテクスチャ座標や頂点カラーのデータも化けるわけで･･･。

ハマリました。
何故、頂点アルファのデータのみ化けるのか？の原因が不明になりました。

そこで、ごく簡単なテストシーンデータ（数ポリゴンの平面メッシュに1つの頂点に頂点カラー・頂点アルファを設定）
を作成し、エクスポートすると意図したデータが出力された。

あれ？意図したデータが出てくれると逆に困るんですが･･･と内心思いつつ、一つの案が浮かびました。

「この現象は、エクスポータプラグインのプログラムに原因があるのではなく、
　頂点アルファの設定を行うオペレーション手順に問題があるのでは？」と。

問題のあるシーンデータと、テストシーンデータを比較してもシーン内の最終結果はポリゴン数の差しか違いがありません。
違いがあるとすれば、製作途中のオペレーションの違いしか無いと考えたわけです。

該当シーンデータを製作された担当者さんにオペレーション内容を伺おうと思いましたが、
本日は別所に行かれている様子で社内にはいませんでした。

原因究明は後日ということで、とりあえず正常なデータが出力できないものかと色々いじっていたら出来ました。
問題のあるシーンデータのノードに頂点ペイントモディファイヤを追加して、アルファ成分を選択状態にした状態で集約後
エクスポートを実行すると意図するデータが出力されました。
謎です。

私の環境では問題ないことが確認とれたので、担当者さんのフォルダを覗きに行くと

既に問題のないデータがアップロードされていました

(;'口')<ェェエエエ工工工

(※1) MAXScript リファレンス 9.0 の以下のツリーを参照
MAXScript 言語リファレンス
　+ 3ds Max オブジェクト
　　　+ 編集可能メッシュ、スプライン、パッチ、およびポリゴン
　　　　　+ Editable_Mesh および TriMesh
　　　　　　　+ テクスチャ座標と頂点カラーについて

明けましておめでとうございます。

 

PCにさしっぱにし続けたUSBを、いざ抜こうとしたら全く抜けない人がいました。

こちら。

>パソコンの背面を窓際に向けておいてたりすると、冬とかに結露
>して、そこから錆びたりする場合があります。

えーっと・・・非常に稀有な現象だと思うのですが、これはあるあるネタなんでしょうか。

非常に気になります。

今日で仕事納めでした。

17:00から部内での納会で酔っ払ってるkeichanです。こんにちは。

 

さて、明日からインターネット環境の無い実家へ1週間程引き篭もりますのでネット活動も本年はこれで終了になります。

今年は非常に刺激的な1年でした。

 

来年は今年と同じか、それ以上の刺激を受けることができるか楽しみです。

では、皆様良いお年を。

なんかまた面白そうなサービスが始まりました。

こえ部 声で遊ぶコミュニティ

お家に帰ってから弄ってみたいと思います

プレイステーション2ゲーム『ICO』にGPL違反発覚

こんな事件(?)あったんですね。

同僚から聞いてビックリしました。

私も今GPL絡みのブツを扱っているので気をつけたいと思います。