UVの重なりを検出(その後)

MayaAPIにバウンディングボックスの判定オブジェクトがあることに気付いたので、早速頼ってみることに。

そして上記とは一切関係ないけれど、前回のShell単位の検出をface単位にしておくことで後段の交差判定の対象を絞り込めることに気付く。これでようやく現実的な速度で動きそうな気配..

また、単にface単位に判定するのではなくて、あくまでもshell単位での分類も持つことで同じshell同士の判定は避けることも行う。(これは単に判定回数を減らすだけではなく “同一shellのfaceが隣接する場合” を重なり検出の対象から省くためでもある。)

【備考】
 このままだとポリゴン数が増えた場合に、38行目のpolyListComponentConversionがボトルネックになる..
 10万ポリゴン単位のデータを処理させるには、MayaAPIを叩く処理に変更する必要が出てくる。

【備考2】
 ..辺が重なる場合の対応は必要だったので、上記のままだと辺の重なったものが判定できない。
 その場合の実装追加も必要。。

アトリビュートのタイプ取得

何故か、よく忘れる…
※attributeInfoでも、attributeQueryでもない。

つか、もうgetAttributeTypeってコマンドが欲しい!

コンパウンドアトリビュートをスカラー要素に展開したい

例えば “locator1.translate”は、アトリビュートのタイプは “double3″。
そのままだと、特にMELで面倒。スカラーで値を取らないと、getした後に分解とか、setの際に結合とかどうすんの..ってことになるので..

要素一括では、こうやればいけるけど..
実装ではdouble3向けの実装として用意しないといけないので意外と面倒。

最初からスカラー要素で扱えるなら、その方が実装が汎用的なので、できたら冗長でもまずはスカラーが欲しいなぁ..と。
かんたんに考えると、以下みたいになる。

Pythonの場合はtranslate, rotate, scale などコンパウンドの値はタプル(tuple)型で取得設定できるので、MELのように分けて考える理由がなくて便利。
※タプル型というのは、内容が固定の値で変更できない以外はリスト型と似たような扱いができるオブジェクト。『(1,2,3)』みたいな表記で扱われているもの。リストの方は『[1,2,3]』て表記。

実際にsetAttrする時は、タプルやリストの中身をスカラー要素に展開して指定しないといけない。
その点だけ忘れないようにしとく感じ。
※タプルやリストの要素の展開は、頭に『*』を付加する。

展開部分を手で書いたら、以下のようになる。

コンパウンド要素を展開したり云々したり..みたいな話は、MEL How-To #75に書かれている。

コンパウンド/マルチ要素のアトリビュートのアクセスに関して

rampノードを例にとって、colorEntryListで管理されるアトリビュートの情報取得方法メモ。

例)登録要素を最初の一個だけにしたり、色設定を変更したり。

選択ノード(transform/joint)の状態保存/復元をする

ざっくりツールっぽく書いてみたけど、使えるかどうか不明。

【使い方】

  •  ノードを選択して saveボタンを押すと、選択ノードのkeyableアトリビュートを記憶。
  •  (saveした後に)loadボタンを押すと、記憶したアトリビュートの値をカレントフレームに復元(キーを作成)。
    ※復元時は、ノードの存在とアトリビュートのsettableのチェックを行うので、設定できないアトリビュートは復元されません。

【注意点】

  •  saveしたデータは、namespace名, ノード名が同じものにしか設定できない。
    (その場合、loadしてもなにも起きない)
  •  saveする際は、
    ポーズの再現に必要なノード群をくまなく選択しておかなくては load時に再現されない。
  • ポーズの再現に必要なノード群のload対象のアトリビュートに更に入力がある場合には
    対応していない。

ジンバルロック、フリップ、オイラーフィルター関連のメモ

ジンバルロック、フリップ、オイラーフィルター関連の情報を調べてみた。

検索でヒットする備忘録を読むと、180又は360度以上の回転を範囲内に収めてくれる、という記述が多いが、何故フリップ解消に繋がるのか説明しているページは見当たらない。

マニュアルによると—

 『ジンバル・ロックやフリップが発生した場合は、オイラー・フィルタを使用して動作を修正できることもあります。
たとえば、オイラー・フィルタ(Euler Filter)を使用して、壊れたモーション・キャプチャのアニメーション・データから不連続な回転カーブを正規化することができます。』

—のように書かれていて、不連続なカーブや正規化が、どういう意味合いで使われているのか数学苦手くんにしてみると誠に不親切で、正直いって全く理解できない解説です…
(数学的に、ジンバル・ロックやフリップを理解している人になら、意味が通じているのかもしれませんが)

MAYA 2008のオイラーフィルター問題
ジンバルロックを気にしない
Quick Trick: Gimbal Lock… Just Ignore It ! ( with a little help from Maya )

細かいことを抜きにすれば..
フリップの問題は、1件目の日本語サイトの対処方法で。
ジンバルロックの問題は、英語サイトに書かれている要領で解消できるはず。

ただ、自分としてはオイラーフィルターを自前で実装する為の情報が欲しいところ。。
と思って探していたら、1件疑似オイラーフィルター処理について書かれた記事を見つけた。
※基本的にやっていることは、フリップ対応時の処理と同じなので、まずはこの実装を試してみるべきか。

MAYA 2008のオイラーフィルター問題 (抜粋)
そもそもオイラーフィルターというのはなんなの? ていうと、角度でアニメーションをつ けているとY90度近辺でXZが暴れだし、気づいたらフリップ していたよ! という状態を解決してくれます。手動で直すときはXとZを+(又はマイナス)180度シフト【+=180】、Yに-1を掛けてから 【*=-1】、180度シフト【+=180】します。昔は全部手でやっていたのですが、今はコマンド一発で解決できるので楽ですね。まぁ、こういう時に一 気に無力化しないように覚えておいて損はないです。

続きを読む ジンバルロック、フリップ、オイラーフィルター関連のメモ

UVの向き(表裏)の判別

UVの表裏を考慮しないとバンプマップなどが反転適用されちゃうってことで、裏返っているfaceを判定してみる実験。

not のふしぎ

というか、演算子定義的な話ですけど。
is や in に notを使う場合、専用演算子 is not や not in があります。

if not 変数 is None:

とは書かかずに、

if 変数 is not None:

と書けます。

notは and, orに次いで評価優先度が低いので『if not 変数 is None:』と書いても間違いじゃないようです..
英語的に正しい構文になるようにということなのでしょうけど、突然出てくると返って混乱します。

UVの重なりを検出

ググってみると出てきたので、コードを読んだ時のメモ。

で、線分の交差判定もググって追加してみたらこんなことに..
続きを読む UVの重なりを検出

『if 変数 is None:』は、いつ使うのか?

掲題の疑問があったのですが、最近ようやく意味が分かりました..

というか、単に数値の 0 も Noneも ”(空文字)も すべて評価的には Falseになる値なんですね。
数値が 0 の時とNoneの時を別けて考えるような処理も書いたことがないほど、限定的なスクリプトばかり書いていたので、全然気づかなかったというか。考えてなかったというか..orz

Noneであることを厳密に判定しないといけない場面があれば使う。

これだけなんですよね。(ソリャソーダ

 

あと、Pythonで Noneを判定する時は、掲題のように is None を使うのはお約束です。
PythonではNoneの比較は==ではなくisを使う

対義語

【展開】

  • 圧縮ファイルの場合:展開(伸長)⇔圧縮
  • 状態として拡がる(膨れる)場合:展開(拡大)⇔縮小、展開(膨張)⇔収縮
  • 数学的なら:展開⇔収束
  • GUIのインターフェースで中身を開いたり閉じたりする場合:展開⇔折り畳み

【外注】

  • 外注(out-source)⇔内製(in-house)

【凸型/凹型】

  • 凸型(とつがた:convex)⇔凹型(おうがた:concave)

【感情/理性】

  • 感情(かんじょう:emotion)⇔理性(りせい:reason)

【明示/暗黙】

  • 明示(めいじ)⇔暗黙(あんもく)

__doc__ について

Pythonのオブジェクトには、デフォルトでいろいろとメンバ変数が詰まっている。

で、__doc__ にはそのオブジェクトの説明が書かれている。
Pythonの組み込み関数などに使うと効果テキメンです。

迷った時に使ってみると、意外に光明が差すかも。
…ただ説明は英文です(^^;