« 2011年11月 | トップページ | 2012年1月 »

2011年12月

2011年12月31日 (土)

宴フライヤー2011。

先日の XSI男忘年会(略称)の時に会場に貼り出していたフライヤーです。
記念にここに載せておきます。
みなさん、あまり気にもせず、スルーしていたみたいですが orz


F01

F02

F03


F05

F06







2011年終わりますね。
激震の年でした。
毎年 「激動の年だった」 とか言っている気がするけど、2011はそれどころじゃない。
もちろん、311の地震も激震だった。
それと同時に、俺のCG人生的にも、全く未知の体験をしました。まさに激震でした。っていうか、今まだその激震のさなかにいる気分です。
必ずしも望んではいなかったこの激震。
でもしようがない。揺れに身を任せつつも、そこからどう立ち上がるかが重要なこの激震。

来年はこの揺れを力ずくでねじ伏せて収束させたいです。
暗い話はもう嫌だ。
明るい気分になりたい。
俺は正しい道を歩んでいると確信したい。
俺を激震のど真ん中に放り込んでくれた人たちに、恨みはないが、ちと悔しいくらいには思わせたい。
すべては俺次第。


とかなんとかいう個人的な話はさておき、2011年もこの変態ブログを通じて、色々楽しいことが起きました。ひたすら感謝します。 毎年言ってますね。 今年俺と一緒に仕事をしてくれたり、一緒に酒を呑んでくれたりした皆様に、心から感謝を申し上げます。いやほんとですってばよ。マジで感謝しているんです。





どうか来年もよろしくお願いします。

Ue

| | コメント (0) | トラックバック (0)

2011年12月27日 (火)

May the Legacy Forces be with you。

抽選の記事を書いたら、コメント欄で m4g さんからタレコミがあり、成り行きでちょっとだけ実験してみました。







ICETree の中で、昔ながらのフォース、つまり非ICEなフォースを使うという。



やってみたら、わっ ほんとにできたっ

Legacyforces


クリックするとでかい画像。


↓シーンファイル (XSI 2012)。
ダウンロード LegacyForces.zip (416.9K)




全然知らなかったですよ。


マニュアルに書いてありますか?

書いてありますた orz


ICE の Force のところに、しっかりとページを割いて書いてありますた。。。。




最近は訪れる客もなく、すっかりさびれてコケが生えてしまった Simulate モジュールに行き、普通にメニューから Get > Forces でどれでも取り出して、Explorer から ICETree にドラッグし、接続します。 普通に、昔ながらに、効きました。


メニューからゲットできるフォースは全部試しましたが、全部効きました。


マニュアルによると、フォースを全部ぶち込んだ Group を作り、Group を ICETree にドラッグし、かつ Get Array Sum を挟んでつなげてやれば、フォース1個1個を接続する必要はなく、追加や削除はこの Group への追加・削除にすればいいと書いてあります。 なるほど。



ただしこのレガシーフォースくん達、ICETree の中ではコンパウンドとして機能するわけではなく、それ以上展開できない完結したノードとして出てきますので、一切のカスタマイズはできなさそうです。 ノードを接続するインプットすら受け付けてくれません。 まあ、そりゃそうですわね。 昔からフォースのカスタマイズなんて出来なかったわけで、ゼロから自分で組み立てることによってそういうカスタマイズを実現しようというのが ICE ですからね。


あと、サイズですね。 パーティクルのサイズを小さくしたらレガシーフォースくん達がさっぱり効かなくなりました。 おそらく、元からパーティクルのサイズに影響されるように書かれているのでしょうね。 

これが ICE のコンパウンドだったら、サイズが影響して都合が悪ければコンパウンドの中に潜ってってサイズの影響をなくせばいいだけです。 Drag Force なんかでは俺はいつもやります。 でもレガシーフォースくん達はコンパウンドのように中に潜れず、いわば全ての機能がハードコーディングされているわけなので、サイズを変えたいけどパーティクルの動きに影響を与えたくないなんていう身勝手はできないわけです。

なので、この例の場合は、サイズはそのままに、Set Particle Scale で小さくしました。挙動に関係なく、見た目上の大きさを小さくした、ということですね。




このように、融通の利かないレガシーフォースくん達ですが、昔ながらの操作感でやりたいだとか、パパっとお手軽にやりたい時なんかは、かなり便利な気がしますね。  フォースアイコンをスケールするとそのまま影響範囲やら強さやらが変わるってのも分かり易いですしね。  Toric なんて、あんな複雑なフォースは、ICE で自作しようと思ってもなかなか作れなさそうだし。


あっ

今気付いたっ


Toric ってフォースは前からありましたね。

トーラスみたいな形のフォースです。

Toric
↑ これですよ。

で、Torus の複数形が Tori だと先日知ったばかり。

つまりこの Toric ってのは、「トーラスな」 みたいな形容詞なのかな (゚∀゚)
また新しい英単語おぼえちゃったかもっ (゚∀゚)



なるほどー
Toric なんて単語、知らんぞと昔思ったことがありましたよ。
なるほど、そういうことだったんですね。



さすが Softimage、 フォースにまでトーラスを登場させるなんて!! (゚∀゚)

このレガシーなフォースくんたちは、ICE 以前の時代からありましたよね?

ってことは、
何年も何年も前から、
ICE が登場する以前から、
つまりあの伝説のデモ 「Pushオペレータ on トーラス」よりも昔から、
XSI は、トーラスだったんですね!


世界標準トーラス! (゚∀゚)


トーラス! (゚∀゚)
トーラス! (゚∀゚)
トーラス! (゚∀゚)








.

| | コメント (0) | トラックバック (0)

2011年12月26日 (月)

ICEな抽選シーンあり〼。

先日の XSI男忘年会(略称)で抽選に使った ICE シーンを、ダウンロードできるようにしますた。


ダウンロード XSIManParty2011_Chusen.zip (347.9K) 


XSI 2012 のシーンファイル1個です。


実は、厳密に言うと忘年会当日にシミュレーションを実行したシーンそのものではありません。 そのシーンを整理したのがこのシーンです。

不要なオブジェクトを削除したり、分かりやすいように名前を付けたり、あとは ICETree の中でちゃんと仕事をしてない部分があったのでそれを取っ払ったり、コメント付けたり、そういう感じです。 

なのでまあ、本質的には何も変わっていません。



先日貼っ付けた動画を、もう一度貼っ付けておきますね。







すげえ大ざっぱには、以下のようなオブジェクトで出来ています。

Sche


シーン中に、ICETree は3つあります。




ひとつは、PC という名前の PointCloud です。 

Chusen_icetree1

クリックするとでかい画像。



上部にあるエミッタからパーティクルが発射されます。参加者の人数を手で入力します。これが Rate になっているのですが、 Total Number にしてあるので、その数のパーティクルが最初にドバッと発生して、以後は発生しません。

壁や XSI 男の生首などの仕掛けに衝突するのは、Simulate Rigid Bodies ノードの中のコリジョンを使っています。

このコリジョン生首や壁などの配置およびアニメーションがけっこう重要でしてね。 というのは、何もしないと、当然ですが、出口付近にパーティクルが殺到してしまうのです。 そして渋滞を起こし、渋滞と言うより便秘になってしまい、パーティクルが完全に動かなくなってしまうのです。

Sattou

なので、生首や壁を置いてかき回し、パーティクルがなるべくバラけたタイミングで出口に到達するように調整しました。  それでもどうしても溜まってしまうので、一部の生首は回転もさせますし、ポジションも動かします。 ポジション動かさないとダメですね。 すくうように、あるいは押すようにパーティクルをかき回さないと、どうしても便秘を解消できない感じがありました。

これらの生首コリジョンの動きも ICE 制御にすれば良かったんですけどねえ。 でもシーン作り始めたのが前の晩ですからね、しかも ICE Kine とかやったこと無いし、そこまでやってたら絶対に間に合わないと判断しまして、Fカーブや Expression で動かすことにしてしまいました。






こうしてある程度かき回されたパーティクルはやがて左下の 「当たりゾーン」 に行くわけですが、パーティクルの pos X が -50 よりも小さくなったら当たりゾーンに入ったとみなして、パーティクルの形状を XSI 男に変化させ、かつ顔がこちらを向くように向きを強制的にセットし、数を数えるために独自アトリビュートを加算します。

この独自アトリビュートへの加算のツリー部分が、ガルさんに質問して教えてもらった部分なのですが、なぜこのようなツリーになるのかまだ今ひとつわかっていません。 今後のカンニングのためには非常に使えそうなツリーですが、仕組みをもうちっとスッキリ理解しておきたいものですねえ。 やはり、ポイントは Array だな。 Array を制す者は ICE を制す、と死んだばあちゃんが言っていたんですよ。 当時はよく分からなかった俺ですが、今ならその重要性がわかります。 ごめんな、ばあちゃん。 ← 仕組みを分かってないと広言している俺が言うと説得力ミニマム



今回はパーティクル座標で判定するという安易な方法でやってしまいましたが、本当はそうではなく、ピンボールのスイッチのように、コリジョン自体でスイッチが入るような仕組みにできると面白いんですけどねえ。 今ある ICE ノードとアトリビュートでも出来そうな気がするんですが・・・・。 誰かそういうコリジョン判定ツールキットのような、ライブラリ的に使えるコンパウンド集みたいのを出してくれませんかねえ。 そしたら、非ICE のリジッドボディを使って作ろうとして挫折したピンボールゲームが、ICE で作れそうな気がする。








次に、Wall というオブジェクトに ICETree があります。

こいつが、当たりゾーンに入った数を検知して閉まるという、シャッターです。

Chusen_icetree2

クリックするとでかい画像。



先ほどセットした独自アトリビュートの ATARI をゲットしてくるのですが、この ATARI の数値をそのまんまツリーで使えないのは何故なのか、俺はよく分かっていません。 やはりガルさんに教えてもらってこのような Array を使ったツリーになったのですが、Array を制してないので ICE を制してない俺には、なにやらよく分からないのです。 ごめんな、ばあちゃん。 違った。 ごめんなさいガルさん。



ともかく今は、こういう場合でつまずいたら、こんなツリーにすればできるかも、と丸暗記しておくことにします。 いつか理解してやる。



で、ATARI の数値が手打ち入力した景品の数に達したかどうかを判定し、達していたら抽選終了ですので、シャッターを閉じて、それ以上パーティクルが当たりゾーンに入れなくします。 同時に、TheEnd という独自アトリビュートに True をセットします(後で使います)。



このシャッターなんですが、ATARI が景品の数とイコールになった瞬間に入り口を閉ざすので、その時のパーティクルの微妙な位置具合によっては、シャッターオブジェクトとのコリジョンによって、上流方向に戻されてしまうわけですよ。 なので、最後の1個がなかなか入れてもらえないという現象が起こります。 殺到してくるパーティクルに、何度も何度もギロチンのように振りかざし続けられます。 このシャッターとのコリジョンで、パーティクルがたまたま当たりゾーン方向に弾かれると、やっと終了になります。 たぶんこの現象が起きますからやってみて下さいな。 上の動画でも、そうなってますね。


最初はこれがひどくてですね、最後の1個が永遠に入れないのではないかという感じだったんですよ。 なので、シャッターの先に、少し薄めの補助コリジョンオブジェクトを装着しました。 パーティクルが当たりゾーン側に弾かれ易くしたつもりなのです。 これでいくらか改善したような気がしたので、それでよしとしました。


思うに、ATARI の数が景品の数に達したら、すぐにシャッターが降りるのではなく、例えば 2フレ後にシャッターが降りるとかにすれば良かったのではないかと思います。 っていうか、それをやろうとして色々やってみたのですが、俺の力ではそういうツリーを組めず、あきらめました。 なにせ忘年会の前の晩に急遽作り始めた ICE ですから、にわか仕込みの俺には無理ですた orz




ということで識者のお方に質問。 

あるアトリビュートの状態を判断して、条件が満たされた時に、「その2フレ後」 など、任意の時間が経過した後に何かアクションを起こすには、どういうツリーを組めばいいでしょうか?  アドバイス下さい m(_ _)m  #ICEドリル




ともかく、最後の1個がなかなか入らないという問題は、補助コリジョンオブジェクトによって少しだけ改善されはしたものの、基本的には放置されました。 しかし、当日シミュレーション用のノートPCを提供してくれ、かつ前夜からこのシーンの動作確認に協力してくれたマルプラさんがこのギロチンシャッターの挙動をえらく気に入ってくれて、結局そのまま残そうという話になったのでした。 狂ったような勢いで無慈悲に振り降ろされ続けるシャッター。 次々に玉砕して戻されるパーティクルたち。 マルプラさんにとっては、サディスティックな愉悦だったようです。



シャッターオブジェクトのギロチン降下は、PointPosition に数値を足して、ジオメトリの位置全体を下に動かしているだけです。 最初自分でやった時はなぜか上手くいかず、ガルさんに聞いたら同じようなツリーで答えてくれて、もう一回やったら上手く行ったという。 ま、俺は単に何かやらかしていたんでしょうねえ。 ガルさん、本当に助かりますよいつも。


あとは、もう1箇所の ICETree である 「抽選終了」 の文字の表示判定のために、TheEnd という独自アトリビュートをセットしています。 でも本当は、この TheEnd は要りません。 なぜなら TheEnd が True になる条件は ATARI の数が景品の数に並ぶことであり、その判定はすでに1回済んでいるからです。 でも、その後、他のオブジェクト多数に ICETree を組んで何かやらせようとした場合、全部の ICETree で ATARI をゲットして Build Array from Set して・・・・とやるのは面倒だと思い(コピペはできるものの、見た目に煩雑になる)、単純に True か False をセットしておいて、以降はそれをゲットした方が楽かな、と思っただけです。 最終的には 「抽選終了」 の文字の ICETree 1箇所でしか使わなかったんですけどね。





で、その、「抽選終了」 の ICETree です。

Chusen_icetree3

文字オブジェクトは、ただのポリゴンメッシュですね。

で、先ほどの TheEnd が True か False かを読み取り、False だったら PointPosition に 0,0,0 をセットしています。 つまりこのオブジェクトの全頂点がワールド原点にコラップスした状態になり、ビューポート上では見えなくなったということです。 True になると、元の PointPosition がセットされるので、ちゃんと 「抽選終了」 と読める状態になります。





以上。








なんつうか、もうちょっと凝った感じにしたいですね。 アクロバティックな仕掛けにしたかった。 ピラゴラスイッチ的な。


そのためには、まずはコリジョン判定が Actual Shape になってくれないとダメですね。 これは 2012 SAP 以降の Simulate Bullet Physics ノードでできるんでしたっけ? あるいは Momentum? 


あるいは、液体だとか、クッションのような柔らかいものなども仕掛けに入れられれば、もっと面白いですよね。 そうなると、Lagoa か?


リジッドボディ的コンストレインも極めねばならないでしょう。 ヒンジとか、ボールジョイントとか。 こういうのが無いと、ピタゴラスイッチにはなりませんね。



あとは、風とか使いたいんですよね。 普通に ICE の風はありますけど、この範囲でだけ吹いている風、などということをやろうとすると、自分でそういう ICETree 組まないといけないですよね?  昔のパーティクルや、現在もまだ残る非ICE なリジッドボディシステムにあるような、Vortex とか Eddy とか Fan のような、アイコンでインタラクティブに影響範囲を決められるような Force って、まだ ICE には無いですよね?  これ、すごく需要があると思うけどなあ。 っていうか、できる人はササッと作っちゃうのかな。 そういうのを作ってコンパウンドとして配布している人、いないかな・・・・。



いつかそういうのを提供できる側になりたいと強く思います。 ええ。 死んだばあちゃんのためにも。





まあともかく。
抽選システム作り、デキはともかく、すんげえ楽しかったです。




前夜の実験から当日まで全工程で協力してくれたマルプラさん、
いつものように教えてくれたガルさん、
景品係をやってくれた msk さん、
景品を提供してくれた嘔吐デスクのW辺様、
そして盛り上げてくれた参加者の皆様、
ありがとうございました (゚∀゚)








.

| | コメント (4) | トラックバック (0)

2011年12月25日 (日)

XSI男忘年会(略称)2011 終了しますた。

狂乱の宴が終わりました。



いやあ、ヤヴァい。 ヤヴァいくらいに楽しかった。 こんなに楽しい呑み会は、なかなか無い。 参加してくれた皆さんのおかげです。 盛り上げてくれた皆さんのおかげです。 くだらないネタなどにも好意的に反応してくれる皆さんのおかげです。 本当に有難う御座いました。 以下、時系列順に報告です。



まずはゼロ次会です。

01

最近リニアワークフローで人気のマルプラさんに協力してもらい、俺と二人だけで、1次会会場近くのマクドで最終打ち合わせをしています。 マルプラさんの VAIO ノートに XSI がインストールされており、俺が前の晩に作ったシーンデータを開いて、ちゃんと再生できるか確認しています。






そして1次会へ。

02

新宿歌舞伎町の甘太郎コマ大通り店です。 左側の無料案内所に飛び込みたいのを必死でこらえます。



新宿は甘太郎が何件もあるんですよね。 案の上、最初は違う甘太郎に行ってしまった人もいたようです。 これが新宿甘太郎トラップです。 けけけけけ。


集合場所では、目印として、XSI男お面XSI男Tシャツを組み合わせて作った XSI男案山子を掲げています。 

03

これで見落とされたら立場ありません。


ちなみにお面は去年のXSI男忘年会で有田さんが作ってきてくれたやつです。



そしてあとは、ひたすら狂乱。

04

05

06

07

全部で38人でした。わあ。いっぱい集まったなあ。


一番遠方からの参加は、大阪のマルプラさん(日帰り)かと思いきや、アメリカはニューヨークから参加のゲーム会社勤務モデラー、スドーさんがいました。


属性は各種アーティスト、プロデューサー、TA、スマホアプリ開発者などがいましたかね。映像系の方が多かったけどゲーム業界からも数人。







その後は抽選です。 なんと、嘔吐デスクのW辺さんが景品を提供してくれましてね。ノート、ペン、ステッカーなど各種 XSI/嘔吐デスクグッズです。 高橋mskさんも個人所有のグッズを若干提供してくれて、合計29品集まりました。




前の晩に急遽作った抽選券。

08

参加者の皆さんに1枚ずつこれを配りました。 裏に番号が書き込まれています。



そしてこれが、やはり俺が前の晩に急遽作った XSI シーンです。

08b

マルプラさんのノートPC上で再生される、ICE リジッドボディシミュレーションです。このシミュレーションによって当選者が決まります。


参加者の数と景品の数は当日本番になるまで正確には確定できなかったので、後から入力し直すことが前提でした。 ってことで呑み会会場でまず ICETree を開き、パーティクルの Rate に 38 と入力します。つまり38個のパーティクルが発生することになります。次に ICETree の別の箇所に景品の数である 29を入力します。この数を境に、当選かどうかの判定をします。 

Simulate Rigid Bodies ノードでシムするのでおそらく毎回結果は変わるのですが、これは(たぶん)コリジョンの判定具合のゆらぎが変わるというだけで、パーティクルの発生パターンそのものが変わるわけではありません。その場でパーティクルの発生パターンからかき回せば、ツリーに変な仕込みはなく、公平な抽選であることを確実にできます。 ってことでその場で適当にランダムシードをかき回します。ってことでエミッションの Seed に、当日の日付である 1223, 当日になって最終確定した参加者の数 38, 当日になって最終確定した景品の数 29の数字を使って、適当な値にします。たしか、1223 * 38 / 29 にしたんじゃなかったっけ?


以上で準備完了です。いよいよシミュレーションを再生すると、パーティクルは重力によって仕掛けの下の方へ落下しつつも、リジッドボディのコリジョンにより様々な障害物でかき回され、最後にパーティクルは当たりゾーンへと導かれます。29個を超えると当たりゾーン入り口のシャッターが降りるようになっています。これも ICE制御です。シャッターが降りるとそれ以上パーティクルが当たりゾーンに入れなくなり、シム終了です。同時に「抽選終了」の文字が現れますが、これは PointPosition が全部0だったものを元に戻しているだけなんですが、やはり ICE 制御です。


などとコトバで説明してもアレなので、動画を貼っておきます。



これはこの記事で説明するためにキャプチャした動画ですので、実際の会場で再生したシムとは結果が異なります。 実際のシムはキャッシュも取っていないので、二度と同じ状態は再現されません。一発勝負です。

ってことで、当たりゾーンに入ったパーティクルの ID を見て、ゴール順でグッズを選んでもらい、全部配布し終えました。 いやー 面白かった。皆さん、こんなくだらないネタでも好意的に受け入れてくれてありがとうございました。仕込んだ甲斐がありました。 そして嘔吐デスクW辺様、超ありがとうございますた(゚∀゚)!!!




あとはもう、ひたすら狂乱が21時まで続きました。


にぎやかしにフライヤーを作って掲示してたんですが、皆さん、あまり気付かずにスルーしてたんじゃないでしょうかね。

09  10






XSI男Tシャツ率も異常に高かったです。

11

俺はもちろんのこと、今まで購入してくれた皆さんも着てきてくれる人が多かったです。

そして、先日の第3次募集の時に少し多めに注文しておいて、この忘年会会場でも購入を呼びかけたのですが、新たに3枚買って頂きました。マルプラさん、新Iさん、8木さん、ありがとうございますた(゚∀゚)!!!  

皆さんの気持ちはと金は、再び責任もって福島まで届けますからね。



その後21時からさらに2時間、同じ会場で2次会になりました。2次会は31人でしたかね。同じように狂乱が続きました。


2次会終了時に店の前で記念撮影です。

12

いやあ、楽しかったねい。






寒波が来ていて相当寒かったのですが、こんな格好の変態もいました。

13

四季のある日本において、5ヶ月も前から服装が変わらない変態です。



いや、だから、タローくん。

14

イエーイじゃないっちゅうの。 寒いっちゅうの。



そして3次会突入。

15

当日仕事で忙しかった MacW部さんが2次会からかけつけてくれたので、3次会以降はいつものように宴会部長を託しました。お世話になりますた。



よくわかりませんがこのポップコーンがお通しでした。

16

船長?


で、朝5時までやってたんでしたっけ?
俺もう、途中で寝ちゃって。
みんな若いし元気だよなあ。 俺もう、ダメ。
でも断続的に起きて吞んで、おそらくは意味不明なこと喋って、また寝て。
3次会の時点で、けっこう疲れてたんですね。

1次会2次会が人数多かったので、予想していたより色んなことが大変だったんですよ。 最初は、店の予約して、集金して、金払うだけの役割だーって気楽に思ってたのに、そうもいかないんですね。 なんせ全員が集合時間に来るわけではないので受付・集金などは五月雨式になるし、2次会参加の意向を聞いて回ってある程度人数がそろったから店と交渉してそのままの席でいいかどうかなど調整だとか、抽選やら告知やら。 みんなと話もしたい。 名刺交換もしたい。 写真も撮りたい。 会計の段階になると集まった千円札の多さにビビる。酔っているから数えるのに何度も間違える。

とかなんとか。 なので皆さんの協力無しにはできませんでしたよ。 マルプラさんは0次会どころか前の晩から付き合わせて抽選シムの準備、そして受付の時に抽選券の配布や集金をお願いしました。 mskさんは景品係でした。 孫六さんには集合時に案山子を持ってもらいました。 F松には会計の時に金を数えてもらいました。 それ以外でも細かいところで皆さんに協力してもらい、また、ありがたいことに多くの人にねぎらいの言葉もかけてもらいました。


5時過ぎに、ようやくお開きになりました。

18  17

3次会から駆けつけてくれた人もいましたね。間に合ってよかった。



さすが忘年会シーズン、朝5時の新宿駅はなかなかごった返していまして、だんだんみんなとはぐれて行き、それぞれ帰途につきました。


朝6時くらいか、チャリンコでの家路、空が綺麗でした。

19




とまあ、こんな感じで、狂乱の夜は終わったのでした。
ひたすら笑顔が絶えない呑み会でした。
何度も言いますが、こんなに楽しい呑み会ができたのは皆さんのおかげです。
感謝します。
またやりましょうよ。
来年も企画します。
まあ、今年と同じようにただの呑み会になるはずですけどね。
やりましょう。





宿酔は、並程度ですた。 俺、ウコンドリンク2本吞みましたから。





.

| | コメント (0) | トラックバック (0)

2011年12月23日 (金)

SHED からクリスマス便りであります。

なんて美しいのでしょう。


ちょっとブラックなのか? すいません、完全には理解してませんが、ともかく絵が美しいからもうそれで良い。 デザインも色も質感もライトもbokehも動きも、全て、美しい。




で、SHED のミケルくんですよ。

クレジットを見ると、どうやらミケルくんが中心になって作った作品のようです。

http://www.akaosaru.com/



そう、あの陽気なスペイン野郎のミケルくんです。

渋谷で警官に職質されたミケルくんです。




マメな彼は、「こんなん作ったよ。メリークリスマス!」 って、わざわざメールで知らせてくれたんですよ。  ほうほう、こんなもん作ってたんですか。モントリオールは寒いだろうなあ。

今、メイキングオブ的なものも作っている最中だそうですよ。楽しみですね。





いやあ、クリスマスですねえ。 嫌いではないですこの季節のこの雰囲気。 俺は今日、XSI 男呑み会があるのでとりあえずクリスマスどころではないんですがねw






ミケルのムービーと並べるのもアレだけど、クリスマス気分ってことで、これ行きましょう。


テイラーたん・・・(;´Д`)ハァハァ

今日の呑み会来てくれないかな・・・(;´Д`)

会費は俺がおごるから・・・・
(;´Д`)

自家用ジェットで、新宿歌舞伎町まで、ビューンと・・・・・
(;´Д`)




.

| | コメント (3) | トラックバック (0)

2011年12月22日 (木)

組関係なビール。

芸能界・相撲界などは、長年に渡り、組関係と癒着していたと言われています。 しかし最近はその癒着構造に終止符を打とうという大きな流れが起こり、もう誰にも止められません。




そんな中、俺は、某組 の忘年会に呼んで頂きました。

断りでもしたら、どうなるかわかりません。
組関係ですから。
ビクビクで行ってきました。



俺は組員でもないのに、いわばゲストとしてご丁寧にも呼んで頂いたのですが、普通に吞み代を徴収するあたり、さすが組関係です。 これがいわゆるシノギというやつでしょうか。




そしたら、忘年会のさなか、俺に名字が似ている組関係のあのお方から、
ビールを頂きました (゚∀゚)

Img_0001
東急の包装。




開けてみると、

Img_0004
埼玉地ビールセット (゚∀゚)



個人ではなく、として贈って下さるとのこと。
ありがたく頂きました。
辞退でもした日には、何されるかわかりません。組関係ですから。

これでもう、この組から永遠にカツアゲされ続けること確定でしょうか。




ということで、某組様には、俺のスクリプト/プラグインの永久無料ライセンス Serial No. 0014を、謹んで進呈いたします!!  ((((;゚Д゚))) gkbr





こんなにいっぱいもらっちゃって、ありがたいなあ (;Д;)
これで俺はもう、組関係から足を洗えないんだろうなあ (ノД`)
裏社会とつながって生きていくしかない。
CGの道を極める。これがCG極道。
往生しなっせ (#゚Д゚)

違うか。
よくわからん。














明日は XSI男忘年会ですよ。
Are you ready, guys and gals?
(゚∀゚)

持ち物リスト:

・会費4000円(必須)
・名刺(推奨)
・デモリール(推奨)
・ウコンドリンク((必須)
・エチケット袋((必須)
・おやつ(300円まで。必須)


狂乱の宴だぜ everybody
(゚∀゚) !!




.

| | コメント (0) | トラックバック (0)

2011年12月20日 (火)

Making of 花火。 c05。 Comp。

しばらく間が空いてしまった。






### コンポジット編







例によってインチキブレイクダウン風行きましょう。

720p で再生すれば、それなりに鮮明に見えます。たぶん。


まあアレですね、すいません、何がどうというほどのことはやってませんね。 参ったな、ほんとに書くことが無い。









一応、AE 作業画面。
Aescreen
クリックするとでかい画像。



うーむ、ナニがどうでもないなあ。




カイワレ大根だかモヤシだか知りませんがこの変なヒョロヒョロ花火を、5つの Pass に分けて XSI からレンダしてますね。 単なる別レンダです。 1つずつ色を変えるからです。

で、Starglow で1レイヤずつ色を変えていますね。

でもなんだか、色んな色が混じって綺麗なんだか汚いんだかわからん。 たぶん汚い orz







あとは、デプス Pass を出していますね。 なぜかデプス1と2に分けているようです。なんでそうしたのかは、今となっては不明です。 たぶん意味無いです。




デプス Pass は、LenscareDepth of Field に使われていますね。 レンズボケ。


でも、俺の経験では、こんなツブツブっぽい、ごちゃごちゃとしたデプス Pass 素材でレンズボケやっても、綺麗にボケてくれないことの方が多いと感じています。

Dep

もっとこう、面積が広いものなら、綺麗に行くことの方が多いと思うんですがねえ。 こういうごちゃごちゃしたやつだと、なんだかエッジが汚い感じになることが多いと感じています。


そしてその辺の探求は、いまだサボってやってません orz



なんか、このカットは、ボケなんかやらない方が良かったかもなあ。もっと引いて、要素がごちゃごちゃに重ならないようにした方が良かったような気もするし。

まあ、花火大会応募締め切りの1日だか2日だか3日だか前くらいにやっていた作業なので、良いも悪いもクソもなく、とにかく終わらせることだけを考えて、ひたすら前に進んだのでしょうね。 そんな作り方してんだから、気に入らなくても仕方ないですね。






ってことで、あまり工夫もしていなく、ゆえに特筆するべきことがなく、自分でも気に入ってないこのカット、お願いですから全力でスルーして下さい。






一応解説をコンプリートしようとして書いているだけで、内容的にはすげえ薄くなってますねえ。まあ仕方ない。ほんとに薄いんだから。







.

| | コメント (0) | トラックバック (0)

2011年12月19日 (月)

第3回XSI男Tシャツ 発送しますた。

またまた、俺の机は男Tに占拠される。

Img_0006

今日、発送しますた (゚∀゚)




いつものように、クロネコヤマトの営業所に持ち込みました。

実は割と最近、この営業所に勤める60年配のおじさんが、うちのすぐ近所の人であると判明しまして、たまに家の前でこんにちわ~なんて挨拶したりしてました。 第1回目も、第2回目も、そして第3回目の今日も、たまたまですがこのおじさんが対応してくれました。


クロネコヤマトのメール便は、厚さが1センチサイズだと80円、2センチサイズだと160円なんです。 で、この XSI男Tシャツの M サイズくらいまでは1センチサイズなのですが、L以上になるとけっこう厚くなっちゃって、1センチサイズではなくなってしまいます。


でもこのおじさん、1回目も2回目も、サイズオーバーなのは実は分かっていながら、オマケで、全て1センチサイズとして扱ってくれました。 皆さんから預かっている送料も80円ですから、1センチサイズじゃないと俺も困るんです。






でも今日はちょっと、しぶとかった。


  おじさん:「んー これ、いくらなんでも1センチじゃないねえ。ほら」


とか言って、2センチサイズの料金を取ろうとする。まあ当然なんですが。
それにしても、なかなか受け付けてくれないんです。2センチにしなさい、と。


なのでそこはもう、ゴリ押しというか、なんというか。


  俺:「いやあ、前回も前々回も、全部1センチサイズで扱ってくれたじゃないですかあ」

  俺:「今回だけダメってのも、ねえ」


これは常套手段です。  実は第1回目の時から、「あれ? 前回は1センチサイズで受け付けてくれたけどな?」 などとすっトボけたんですがね。


最後には、


 俺:「震災復興支援ですからねえ。復興を願うみんなの気持ちを、ヤマトが運ぶんです!」


とかなんとか、無駄に熱い言い方でおじさんを幻惑し、結局おじさんは折れてくれました。


  おじさん:「俺が会社から怒られるかもなあ(苦笑)」

     俺:「大丈夫ですよ、ヤマトはいい会社ですから!」


おじさん、ありがとう。感謝しますほんとに。





今回は、12枚発送でした。 ご協力頂いた皆さんに感謝します! (゚∀゚)

Img_0011

第1回目はギターに迫るくらいの高さになりましたが、さすがに今回は、ペットボトルくらいでした。



おそらく2日後くらいに着くと思います。 買ってくれた皆様、もうちょいお待ち下さい。





実は、手元にあと7枚あります。

へへへへへ。

狂乱の宴で、買ってくれる人がいるといいなあ。。。。

.

| | コメント (0) | トラックバック (0)

2011年12月15日 (木)

Pass Override のコピペで激怒。

忘れないうちに書いておかないと。


先日、Pass Override の複製のやり方を教えてもらいますた。記録しておきます。





Partition や Group などに対してのオーバーライドは、プロパティを複製できるじゃないですか。 

例えばこういう場合ですが、

Por1

↑画像中で選択状態になっている Override を、赤矢印のように同一 Pass 内の他のパーティションへドラッグすれば移動になりますし、Ctrl + ドラッグならドラック先に複製されます。 青矢印のように、他の Pass の任意のパーティションへも同じ操作が可能です。 さらに、Pass ごと複製した場合、オーバーライドのプロパティも一緒に複製されます。 便利です。 っていうか当たり前です。



でも、Pass Override の場合は・・・・


Pass Override がある状態で、Pass ごと複製したときは、さすがに Pass Override もちゃんと複製されてました。まあ当たり前ですわな。 問題なし。


しかし、新規で作った Pass や、Pass Override を設定する前に複製してしまった Pass などは当然、Pass Overide を持っていないので、どうにかコピーしてやらねばなりません。

で、さっきのパーティションの時のように、ドラッグ&ドロップで複製できると思うじゃないですか。

Por2

できません (゚Д゚#)

Override のアイコンをドラッグし、Pass の文字の上にドロップしようとするのですが、マウスカーソルが駐車禁止マークみたいになって、ドロップさせてくれないんですよね。

そのくせ、Pass Override を Partition にドロップすると、できてしまう。  Pass Override って、例えば Mental Ray Options の上書きだとかそういう使い方をするものであり、Partition に Pass Override しても意味無いわけですよ。 阿呆ですかあんた。



勝手な予想ですがね・・・。

Pass Override ってのは比較的新しい機能です。 昔は Override のドロップ先は Partition や Group などしかなかったわけですよ。 でも Pass Override が出来た今は、Override がドロップできる対象は Partition や Group だけではなく Pass オブジェクトにも広げなければいけないわけです。 でも Softimage の中の人が、Pass へのドロップを許可するようにプログラムを書き換えるのを忘れているためにいまだに Pass へはドロップできず、かつ Pass Override を Partition にドロップするのを禁止するように書き換えることも忘れているため Partition にはドロップできてしまうという。 こんな状態で放置されているというのが、俺の予想です。 違いますか嘔吐デスクさん。





しかたないので今まではゼロから Pass Override を作り直していました。 Pass が10個あったら10個作り直してきました。 そんな阿呆なことよくやってたな俺。 まあ、Pass Override が同じパターンで増える時はOverride するのではなくそっちをデフォルトにし、少ない方を Override することになるので、Pass Overide の数が増え過ぎてどうにもならなかったという事態にはあまりならず、なんとか堪えられたのだと思います。 でもめんどくせえと常に思ってましたよ。

特にPass Override の数は少なくても、1つの Override の中に項目が多いと、パラメータの追加がすんげえめんどくさいじゃないですか。

こういう場合。

Por3

これ、同じ Pass Override を Pass2 でも手で再現しなければいけないとなったら、嫌ですよね。 やってましたけど。





そしたら、193 さんというお方が、やり方を教えてくれたのです。

ちと、変な手順です。
以下に書きます。


まずは、コピー元の Pass Override を選択して Ctrl + C です。

Por4

これでコピーバッファにぶち込まれました。




次にコピー先の Pass へ移動し、空っぽの Override を作ります。

Por5

普通に Get > Property > Override でやるだけです。 パラメータを追加する必要はありません。それを手でやらない方法を説明してんです。




で、次にその空っぽ Override を選択した状態で、Ctrl + V です。 すると、

Por6

このように、ペーストされますた(゚∀゚)





しかし、画像の中の赤丸が付いた Override、これはさっきの空っぽの Override ですが、これとは別に新たに Pass Override ができるんですよね。 そして空っぽの方は、ゴミとして残ります。 なので手で消してあげます。



以上。







できることはできたんですが、謎のワークフローですよね。




まずは、空っぽの Override をあらかじめ用意しておかなければいけないというのが、意味不明です。

そして、せっかく用意した空っぽの Override の中にペーストしてくれるのかと思いきや、空っぽ Override のことは全力でシカトし、何事もなかったように新しい Override を作りやがります。 だったら空っぽ Override 要らねえじゃん (゚Д゚#)   でも、無いとダメなんです。 無いとできませんよ。 やってみて。

しかもこの空っぽ Override を選択している状態でペーストしないとダメなんです。やってみて。

そこまで重要な、空っぽ Override ちゃん。 

でもシカトされ、最後にはゴミとして手で消される。

どうなってんですか XSI この野郎 (゚Д゚#)ゴルァ


いつものことながら、まったく意味不明のソフトウェアです。



こんな意味不明のワークフローを発見してくれた 193 さんは、なんつうか、変態だと思います。





193 さんありがとうございますた (゚∀゚)








.

| | コメント (0) | トラックバック (0)

2011年12月14日 (水)

Tori と踊る男。

いや、あのですね、ほんとは RSMB の実験だったんですよ。


ReelSmartMotionBlur ね。RE:Vision の、スヴァらしい2Dモーションブラー生成プラグインですね。 AE とかで後付けモーションブラーをやる、アレですね。




RSMB に食わせるためのモーションベクタ素材を出すワークフローについて、実に久しぶりだったので忘れていて、手順の確認のために何か素材が必要だったのです。 なので、なんでもいいのでテストモーションを作ろうとしたのでした。 

普通ならキューブとかトーラスとかがくるくる回っているとかで十分なんでしょうけど、まあそれと同じレベルで、XSI 男がTポーズのままでくるくる回っている画像を用意しようと思ったんですよ。 キューブもトーラスも XSI 男も、ただのプリミティブですからね。




しかしここで運命の分かれ道。





↓ こうすれば良かったものを、

A1



↓ 思わず、こうしちゃったんですね。

A2


前者は、ただのTポーズなプリミティブですわね。 はい、くるくる rot Y でもさせれば、RSMB の実験には十分でしょう。


後者は、全身どころかフェイシャルまでリグが入った、Ready To Animate なキャラクタなわけですよ。






ここで男が、ニヤリと笑いました。

A3

こうなるともはや男の思う壺です。

しかたなく、キーを打ち始めました。深夜に。









で、まあ、結局、こうなりました。 720p 再生でどうぞ。




RSMB なんてどこにも出てきません。
どうでも良くなりました。




1秒ループなダンス。

BGMは例の、パーティキュラー花火大会の時に作った曲です。
Garage Band でその時のデータ開いて、テンポ変えて、パーカッションのトラックを追加した程度。 先に1秒ループでダンスの動きを作っちゃっていたから、テンポはもう、120 bpm とかにすれば自動で合っちゃう。 さすが絵も音もその発生から100%デジタル同士ですからね、無調整でパーフェクトに合いました。楽ちんです。

いや、まあ、アレですよ、モーション作業自体はほんの20分か30分か。 ただの1秒ループですからね。 そこまでは良かったのですが。




ふと思いついて、トーラスを降らそうと思っちゃってからが大変で。




まず、ジオメトリをインスタンスするとけっこう重いんですよね。このシミュレーションだけで、計算始めると15分か20分はかかっていると思います。 まあ世の中のプロフェッショナルなリジッドボディのシミュレーションと比べれば別に重くもなんともないのでしょうが、こんなどうでもいい動画のためにシミュレーションだけに20分とかかかるのは、重いです。


トーラスごときで重いのはもちろんそれ自体腹が立つわけですが、もっと腹が立ったのは、昔から思っていたことではありますが、なんで ICE パーティクルのビルトインShape の中には cube や sphere や cone があるくせにトーラスがねえんだよ(゚Д゚)ゴルァ!!  ということです。 これだけしょっちゅう使うんだからねえ、毎回 Instance Shape ノードとか出すのも面倒だし、そもそもビルトインの方が軽いでしょう。  時期メジャーバージョンアップの時は、Shape に必ずトーラスを追加して下さい。わかりましたか嘔吐デスク様。


で、そんなことをしているうちにコリジョンオブジェクトが上手く機能しなくなったり。 ある程度シーン作成が進んでから、整理をしようとして名前とかちゃんと付け始めるのですが、コリジョンオブジェクトを入れた Group の名前を変えたり、他の Model の下にぶら下げたりなどしているうちに、なぜだか ICE ツリーから認識されない状態になってしまったというか、コリジョンが突き抜けてしまうようになってしまったというか。 まったくもう。


しかたなくコリジョンオブジェクトをゼロから作り直す所から始めてなんとか設定できても、リジッドボディは再生するたびに微妙に結果が変わるものだから、気に入った状態が出てきても、キャッシュを取っていないとその結果は永遠に再現できないんですよね、たぶん。 なので、良い状態を失うまいとして常にキャッシュを取るようになりさらに作業効率が落ちる。 まったくもう。



とかなんとか、トーラスを出して以来すごく大変になっちまったんです。 やっと終わったよ。 馬鹿か俺は。




もうモーションブラーもクソもないですね。ブラーやってねえし。

もうヤケクソですよ。ICE わかんねえんだもん。

XSI 男忘年会では、この動画のように、皆さん、踊り明かしましょうよ。 踊ればきっといいことありますよ。 だってほら、すごく楽しそうじゃないですかこの男。






そうそう。 大発見がありました。

Torus の複数形って、なんだかわかります?

Toruses とかじゃないんですよ。


Tori って言うんですって!


鳥じゃないですよ。 トリだかトゥリみたいに発音するのかな。 ともかく、Tori はトーラスの複数形なんです。 たまにありますよね、複数形にすると変な風に変わる英単語って 。トーラスもそういうコトバなんですね。






ほんとですってば。  調べたんだから。








.

| | コメント (0) | トラックバック (0)

2011年12月10日 (土)

同じ名前の子をイッキに選択するの。

いや、まあ、さっさとこのスクリプト書いときゃ良かったな、って思っただけの話なんですがね。






こういう時。

S1

このように、色んな Model の下に同じ名前のオブジェクトがいっぱいあります。 この例の場合は light です。 こいつらをイッキに選択したい。






Shift とか Ctrl 押しながら選択していくのはめんどくさいじゃないですか。

5個6個ならいいですけど、20個とか面倒ですよ。

面倒じゃないあなたはCG屋に向いてないと俺は思いますよ。






で、今までどうしていたかというと、XSI のインターフェース右上の文字入力フィールドでやってました。

S3



これですね。 1個だけ選択すると、画像のように選択しているブツが表示されるので、ここをワイルドカードに書き換えてあげます。



S4

このように、Model の部分をアスタリスク * に置き換え、Enter を押すと、全ての Model の下にある light が選択されます。 便利です。





でも、この、テキスト入力の工程が、麺独裁のですよ。



Model.light と表示されている時に、Model の文字のあたりにマウスカーソルを置いてダブルクリックすると、ドットよりも手前の部分、つまり Model の文字が選択状態になってくれると良いのですが、なってくれません。 そんな便利にはできていないそうです。



結局カーソルキーとかも使いながらごちゃごちゃと手作業です。 これがけっこう麺独裁。




じゃあスクリプト書けばいいじゃんということになるのですが、単純に考えると、


 SelectObj( "*.light" );


って書けばいいだけので、なんら問題はないんですが、でも、これじゃ light 以外には使えないじゃないですか。 hoge とか hage に使えなきゃ意味無いじゃないですか。


なので今までは上で書いたように、右上のテキスト入力フィールドを使っていたんですね。 

まあ、単に思考停止していただけです。






今日ふと思って、


 SelectObj( "*." + Selection(0).name );


と書いてみたら、アラ便利。

うん、これでいいじゃないか。

なんで今までこれに思い至らなかったのだろう。






light の代わりに Selection(0) です。 つまり、現在選択しているもののうち、一番最初のものを表します。  何かひとつ選択し、このスクリプトを実行すると、 全ての Model 以下で、選択されているオブジェクトと同じ名前を持つものを、イッキに選択するというものですね。





ついでに、


 SelectObj( "*." + Selection( 0 ).name );InspectObj(  Selection );


このように Inspect まで入れれば、PPG 表示もできますかね。

意外と便利でした。







全然大したネタじゃなくてすいません。
なんで今までこうしなかったんだろうなあ。
別に難しくもないのに。
さっさとやっときゃ良かったなあ。



と思ったので、
一応載せておきますた。













| | コメント (0) | トラックバック (0)

2011年12月 9日 (金)

万死のカスタムパラメータにフロントエンド UI スクリプトで天誅。

昨日のつづき。





標準のカスタムパラメータセットでは、パラメータの表示順を変えることもできないし、グループ表示とかスライダ幅調整だとか、そういう高度な UI もできないし、ならばスクリプトでやろう、という話をします。



昨日と同じシナリオで行きましょう。 シーンルートに Hage という名前のカスタムパラメータセットがあるんですが、これがまた汚くて見づらいファッキンプロパティでして万死に値します。 どげんかせんといかん。 はい、同じシナリオです。


どげんかしましょう。 この万死プロパティを便利に使うための PPG を、スクリプトで生成します。




JScript
---------------------------------------------------------------

//    シーンに残らないカスタムプロパティを作成  oP に格納
var oP = XSIFactory.CreateObject( "CustomProperty" );
oP.name = "Hage Proxy";


//    元になるカスタムプロパティセットのパラメータを全部取得
var oCPSet = ActiveSceneRoot.Properties( "Hage" );
var oParamA = oCPSet.Parameters( "AAAAAAAAAAAAAA" );
var oParamB = oCPSet.Parameters( "bbbb" );
var oParamC = oCPSet.Parameters( "CCC" );



//    プロキシパラメータを作成
oP.AddProxyParameter( oParamA, "aaa", "Hage A" );
oP.AddProxyParameter( oParamB, "bbb", "Hage B" );
oP.AddProxyParameter( oParamC, "ccc", "We pray for Fukushima" );



//    以下、どのようにでも UI 作成
//        UI を作るときのアイテムの名前は、上のプロキシパラメータで指定した第2引数
//        つまりこの場合、aaa, bbb, ccc
//        (例)    Hage の CCC というパラメータに対するプロキシパラメータは、
//            この PPG の中では ccc という名前で呼ばれ、UI上には "We pray for Fukushima" と表示される


var oL, oItem;
oL = oP.PPGLayout;

oL.AddGroup( "HegeHege" );
    oL.AddRow();
        oItem = oL.AddItem( "aaa" );
        oItem.SetAttribute( siUICX, 45 );
        oItem.SetAttribute( siUIWidthPercentage,40 );
        oItem.SetAttribute( siUINoSlider, true );
        oItem = oL.AddItem( "bbb" );
    oL.EndRow();
oL.EndGroup();

oL.AddGroup();
    oL.AddGroup();
        oL.AddGroup();
            oL.AddGroup();
                oItem = oL.AddItem( "ccc" );
                oItem.SetAttribute( siUICX, 85 );
            oL.EndGroup();
        oL.EndGroup();
    oL.EndGroup();
oL.EndGroup();

oL.AddRow();
    oItem = oL.AddButton( "Remove", "Remove Animation ⊂(^ω^ )" );
    oItem = oL.AddButton( "Reset", "( ^ω^)⊃ Reset Value" );
oL.EndRow();



//    Logic 使えば、元のカスタムプロパティセットではできないこんなことも
oL.Language = "JScript";
oL.Logic =    Remove_OnClicked.toString()+
            Reset_OnClicked.toString();


//    アニメーション全て削除
function Remove_OnClicked()
{
    var oParams = PPG.Inspected(0).Parameters;
    RemoveAllAnimation( oParams );
}


//    全部のパラメータにゼロを入れる

function Reset_OnClicked()
{

    //    ちなみに 0 番目のパラメータは PPG.name なので、除外して、1からスタート
    var oParams = PPG.Inspected(0).Parameters;
    for ( var i=1; i<oParams.count; i++ )
    {
        oParams(i).value = 0;
    }
}


//    Inspect しておしまい
InspectObj( oP );




---------------------------------------------------------------



このスクリプトを実行すると、

Hageproxy

このようになります。


シーンルートには、元になる Hage があります。 その PPG が画像右側です。 万死です。

そして画像左側の Hage Proxy という PPG は、Hage を元にして作った、便利 PPG です。  昨日書いた記事と同様、Hage のパラメータをプロキシパラメータとして埋め込んでいます。 そして PPGLayout を駆使して並び方の調整、表示する名前の変更、グループ表示、ボタン追加などをやっています。 この辺が、スクリプトじゃないとできない所だと思います。



そしてこの Hage Proxy ですが、シーンルートなどに実体がありません。 閉じたらハイそれまでよ、という PPG です。 スクリプトが実行されるたびにその都度生成され、閉じたら死ぬ PPG です。

昨日のやり方だと、Hage とは別に、シーンにカスタムプロパティセットを作る必要がありました。 ブツの数を増やしたくない、シンプルに保ちたい場合は、今回のように、実体の残らない PPG にするのがよろしかろうと思います。

実体を残さないもうひとつの利点は、表示の順番や表示する項目などを、いつでも何度でも書き換えられることです。  昨日のやり方だと、一度プロキシパラメータを作ってしまうと、パラメータの表示名くらいは変えられますが、順番などは変えられず、またゼロから作り直すしかありませんでした。  今回の場合は、そもそもスクリプトを実行するたびに PPG を作り直すんですから、どのみち毎回作り直しです。でもその作り直し作業は、手でドラッグ&ドロップをするのではなく、スクリプトをサッと書き換えるだけです。コピペで順番を換えたり。断然ラクです。




もうひとつのポイントは、このスクリプトは自己インストール型である必要は無いということです。 ただのスクリプトとして、スクリプトエディタから実行してもいいし、ボタンを作ってもいいし、独自のスクリプトランチャから発射してもいいし、なんでもいいです。

通常、パラメータやボタンの配置などを司る PPGLayout は、自己インストール型のプロパティ、つまりプラグインとして存在しないと、その UI を保てません。 普通に Animate > Create > Parameter > New Custom Parameter Set から作るカスタムパラメータセットでは、上のような UI は出来ないのです。 出来てもそのセッション内でしか有効でなく、XSI の再起動後には UI が壊れてしまいます。

しかし今回の場合は、そもそもシーンと一緒にセーブするプロパティではありません。その場で生成し、その場で死ぬプロパティです。 ウインドウを開いて閉じるまでその UI が使えればいいわけです。 なので、自己インストール型もクソもなく、ただスクリプトでその場限りの UI を構築すればいいということになります。 実体としては、元のカスタムパラメータセットである Hage がシーンと一緒にセーブされていればそれで良く、Hage の値をいじる時にこのスクリプトが実行されれば良いわけです。 Hage に対するその場限りのフロントエンドを作っていると考えればいいと思います。

自己インストール型にしなくてもいいということは、そのシーンデータを人に渡すときなどに、先方の環境で特別なプラグインなどが必要ないということになります。 これは大きなメリットだと思います。 シーンデータを納品しなければいけない仕事などで、先方に「このプラグインがないとシーンを開けません」 などと言わずに済みます。 これはデカいです。 納品時に、「もし今後そちらでデータをいじるなら、このスクリプトを使うと便利でっせ。無くても問題ないですけど」 と言ってスクリプトを渡してあげたりすると、感謝されるかもしれません。されないかもしれません。知りません。

見づらい UI のままで作業できる人は元の Hage をいじればいいし、便利な UI が欲しい人はスクリプトを実行すればいい。 あれば便利。 なくてもいじれる。 スヴァらしい。


もちろん、このスクリプトを自己インストール型にするのも良いでしょう。 メニューに登録したい時などは、自己インストール型にするしかありませんしね。 そして、このスクリプトを自己インストール型にしたところで、やはり、それを先方にも配布する必要はありません。 何度も言うように実体としては Hage が残っていればそれでよく、このスクリプトはあくまでもフロントエンドですから。 あれば便利。 なくてもいじれる。 スヴァらしい。








最大の問題は、「俺、スクリプト書けねえよ ⊂( ^ω^)⊃ニューン という人には出来ないということです。 


解決策としては、

 1.社内のテクニカル野郎を脅迫して書かせる
 2.junki にビールをおごって書かせる
 3.自分で努力する


の3つしかありません。 2を強くおすすめします。 



3の人のために、以下にポイントを書いておきます。 上のスクリプトを雛形にして、必要部分を書き換えるだけです。 とかエラソーなこと書いて、そんなに大したスクリプトじゃありません。 もっと素敵なやつを誰か書いて下さい。





//    シーンに残らないカスタムプロパティを作成  oP に格納
var oP = XSIFactory.CreateObject( "CustomProperty" );
oP.name = "Hage Proxy";


ここでプロパティを作成します。 シーンルートとか、何かのオブジェクトにぶら下げるのではなく、いわば空中に作成するようなものです。 閉じれば終わりのプロパティ。 2行目は名前なので何でもいいです。2バイト文字も使える。 なんならこの2行目が無くても別にいいです。 なにやら適当な名前が付きますが。






//    元になるカスタムプロパティセットのパラメータを全部取得
var oCPSet = ActiveSceneRoot.Properties( "Hage" );
var oParamA = oCPSet.Parameters( "AAAAAAAAAAAAAA" );
var oParamB = oCPSet.Parameters( "bbbb" );
var oParamC = oCPSet.Parameters( "CCC" );


ここは重要ですね。 元になるカスタムプロパティセット内にあるパラメータを、全部取得します。 パラメータを取得しておかないことには、プロキシパラメータを作れませんから。 まあ、この例のように oParamA などの変数に格納せずとも、いきなり次の AddProxyParameter メソッドに食わせてもいいのですが、説明上わかりやすかろうということで、今回はこのように格納しています。

1行目では、シーンルートに Hage というプロパティがあることが前提の書き方になっています。 本題から逸れて煩雑なスクリプトになるのを避けるために今回はあえてエラーチェックを入れていませんが、ほんとはエラーチェックすべきです。つまり、もしそのプロパティが存在した場合は進め、存在しない場合はエラー出して終了せよ、というチェックです。






//    プロキシパラメータを作成
oP.AddProxyParameter( oParamA, "aaa", "Hage A" );
oP.AddProxyParameter( oParamB, "bbb", "Hage B" );
oP.AddProxyParameter( oParamC, "ccc", "We pray for Fukushima" );


ここも重要というか、核心ですね。 プロパティ内に、プロキシパラメータを作成しています。 

第1引数は、たったさっき取得した oParamA など、元のカスタムパラメータセット内のパラメータです。 

第2引数は、作られるプロキシパラメータの、この Hoge Proxy というプロパティ内における名前です。 aaa となっています。 この行で作られたプロキシパラメータは、スクリプト的には aaa と名づけられたということです。 以降、このスクリプトの中でこのパラメータを参照したいときは aaa と呼ばれます。

第3引数は UI 上に表示する名前です。 "Hage A"  などと、スペースを入れたりすることもできます。





//    以下、どのようにでも UI 作成
//        UI を作るときのアイテムの名前は、上のプロキシパラメータで指定した第2引数
//        つまりこの場合、aaa, bbb, ccc
//        (例)    Hage の CCC というパラメータに対するプロキシパラメータは、
//            この PPG の中では ccc という名前で呼ばれ、UI上には "We pray for Fukushima" と表示される

var oL, oItem;
oL = oP.PPGLayout;
 
oL.AddGroup( "HegeHege" );
    oL.AddRow();
        oItem = oL.AddItem( "aaa" );
        oItem.SetAttribute( siUICX, 45 );
        oItem.SetAttribute( siUIWidthPercentage,40 );
        oItem.SetAttribute( siUINoSlider, true );
        oItem = oL.AddItem( "bbb" );
    oL.EndRow();
oL.EndGroup();
 
oL.AddGroup();
    oL.AddGroup();
        oL.AddGroup();
            oL.AddGroup();
                oItem = oL.AddItem( "ccc" );
                oItem.SetAttribute( siUICX, 85 );
            oL.EndGroup();
        oL.EndGroup();
    oL.EndGroup();
oL.EndGroup();
 
oL.AddRow();
    oItem = oL.AddButton( "Remove", "Remove Animation ⊂(^ω^ )" );
    oItem = oL.AddButton( "Reset", "( ^ω^)⊃ Reset Value" );
oL.EndRow();




ここは、詳しい解説は友愛シリーズでも読んでもらえますかね。 上で作成したプロキシパラメータを、PPG 内で、どんな見栄えで表示するかを司っています。


ひとつ留意すべきなのは、PPG にアイテムを追加する(つまり表示させる)行で、

oItem = oL.AddItem( "aaa" );


となっている部分です。 ここで指定する名前は、aaa ですね。 先ほど aaa という名前のプロキシパラメータを作ったばかりですね。 この名前のパラメータを、AddItem メソッドによって UI 上に追加せよと指令を出していることになります。 oParamA ではダメですし、"Hage A" でもダメです。 追加したいのは、このスクリプト内で作ったプロキシパラメータです。 そのスクリプト的な名前は aaa です。 なのでここでは aaa を追加せよと言ってあげないと、XSI 様が迷います。


そしてこの AddItem される順番で UI 上に表示されるわけです。 AddProxyParameter が実行された順番ではありません。 なので、この PPGLayout 部分でどうにでも好きな順番で書けばいいことになります。 




Logic 以下は、オマケみたいなものなので、すいません本題から逸れるので詳しい解説はしません。 ごっそり削除してもOKです。 ボタンを押したらこういうアクションをしろ、とかそういう部分が書かれていますので。

今回の場合は、まあ、サンプルとして、アニメーションを削除するボタン、全部 0 にするボタンを付けています。 普通のカスタムパラメータセットにはこういうボタンを仕込むことはできないけれど、今回のようなスクリプトで作成されたフロントエンド PPG の中ではこんな自由度もありますよ、ということを伝えたかっただけであります。 よくある、X の値が入力されたら連動して Y の値も変わるという、いわゆる OnChanged のロジックも仕込めます。 パラメータの値によって ReadOnly(グレー表示で値変更不可) にしたり解除したりというロジックも仕込めます。 自由です。







このスクリプトを、GUI からの操作で自動生成できるツールを書いたら便利かもしれないなあ、と妄想。 妄想ですよ。



.

| | コメント (0) | トラックバック (0)

2011年12月 8日 (木)

カスタムパラメータの順番を入れ替えられないので激怒してプロキシ。

カスタムパラメータって、一度パラメータを作ってしまうと、PPG 上の順番を変えられないですよね。 




腹が立ちます。 これだけで XSI は万死に値します。






しかたなく、ワークアラウンドとしてこんなのもあるよ、というだけの話ですが。








まず、最初はこんな状態だとします。

R1

Hage というカスタムパラメータセット以下に3つのパラメータがありますが、何も考えずに作られたこのきったねえパラメータ達。 反吐が出ます。 これを作った奴は万死に値します。



このカスタムパラメータセットの中で順番を入れ替えるのはおそらく不可能なので、プロキシパラメータを外部に作ります。


まず、 カラのカスタムパラメータセットをもう1個作ります。

R2

Hogege というのができました。 まだ空っぽです。





次に、元パラメータをドラッグ&ドロップして、プロキシパラメータを作ります。

R3

このとき、順番が重要です。 ここで順番を間違えると意味ないですからね。万死に値します。 ちゃんと、並べ替えたい順にドラッグしましょう。





しかし、こうして出来上がったプロキシパラメータを見て下さい。

Rrr

順番が望みの通りになったというだけで、Model 名から含めたフルネームになり、かつ、スペースとかも入ってない、非常に読みにくい、きったねえパラメータ群 になりました。 これじゃちっとも意味ありません。 万死に値します。





なので、Edit Parameter Definition を使って、修正してやります。

R4

修正したいパラメータの上で右クリックですね。



で、出てきた PPG の中で、名前はもう、スペースも含んで、ガンガン好きなようにいじってやりましょう。



結果、こうなりますた。

R5

美しくなったじゃないですか (゚∀゚)

もう万死はやめていいですよ (゚∀゚)





スペースも使えます。
びっくりマークとか、記号も使えます。
パラメータの表示名の文字数をある程度統一してやれば、スライダの幅も統一できます。



そして、なんせプロキシパラメータなので、それぞれのパラメータは元のパラメータそのものです。 どちらの PPG でいじってもお互いに連動します。 連動というより、同じパラメータを違う UI でいじっているだけということです。 ラクです。 たぶん。



そして、同じパラメータだということは、もともとのパラメータがFカーブでアニメーションしていたり、何かとエクスプレッションでリンクしていても、なんら問題ないということです。

R6

なんら失われる情報もありません。 同じパラメータですから。





と、並べ替えるだけなら、これが一番ラクなんではなかろうかと思っていますが、どうですかね。





ただ、並び順をまた変えたいとかなったら、またもうひとつ CPSet を作るのは嫌ですよね。

あるいは、グループ分けやドロップダウンメニュー、スライダの幅調整、スライダ無し、などなど比較的高度な UI が欲しいとなると、やはりスクリプトを書くしかないでしょう。 

汎用的なスクリプトを書くのは難しいですが、その仕事専用とかのスクリプトであれば、すぐ書けます。 シーンに残らないその場限りの PPG を作り、元のパラメータを取得してそれを元にプロキシパラメータを作り、あとは PPGLayout を駆使して好きなように並べる、というパターンが良いと思います。 シーンに残らないその場限りの PPG にするのなら、気が変わって今日はこの順番で表示させたい、とかいう時でもスクリプトを書き換えるだけです。 Logic も仕込めるので、例えば全てデフォルト値にリセットするボタンとか、全部のパラメータにイッキにキーを打つボタン、とか、そういう標準のカスタムパラメータセットではできないこともできます。

そしてセルフインストール型である必要もないので、プラグインがないとシーンが開けないとかそういうこともないでしょう。元パラメータは標準のカスタムパラメータセットであり、全ての情報はそこに格納されていて、使う時だけ、元の PPG を開く代わりにその場限りの PPG を作成し、プロキシパラメータを貼り付けてそっちからいじる、という構造のスクリプトですからね。 例えば外部から請けた仕事で、納品データにプラグインが必要だ、とかいうのは嫌がられるでしょうから、避けたいですもんね。 実際にこの方法で仕事したことも何度かあります。タコ親父とか。おやっさんの味は俺が継ぎます。 



近日中に、そんなスクリプトの話を書くかもしれません。書かないかもしれません。神の味噌汁。






っていうか花火とかなんとか、未完のシリーズが多すぎる・・・・・
ヤヴァい・・・・・
忙しいとか言い訳して、やり始めたことを途中で放置する・・・・・
この期に及んでまた宿題増やしてどうすんだ・・・・・



俺は万死に値します orz






.

| | コメント (0) | トラックバック (0)

カスタムパラメータの名前にスペースを入れるの。

カスタムパラメータをいじくってたんですよ。


で、カスタムパラメータって、パラメータの名前にスペースを入れると、そのスペースは勝手にアンダーバーに変換されてしまうじゃないですか。 嫌だなあと思っていたんですよ。 スクリプトで作ったカスタムパラメータなら、UI 上での表示用の名前を別に持つことができて、そちらはスペースが使えるので問題ないんですよね。 でも普通に GUI 上からカスタムパラメータセットを作り、そこにカスタムパラメータを追加すると、スペースが許されない。 そして UI 表示用の名前を別で持たせることができない。




・・・・・と思い込んでいたんですが、ごちゃごちゃいじくってたら、なんだか、できました。 以下にそれを書きます。



まず、シーンルートに hoge というカスタムパラメータセットを作りました。
で、その hoge の中に、Number of fuckin Particles という、まあありがちな名前のパラメータを作りました。

Space1

この時点では、単語の間にスペースを入れて入力しています。







すると、出来上がったパラメータには、勝手にアンダーバーが入っています。

Space2

まあ、しかたないですよね。 XSI の中で、オブジェクト名でも何でも、スペースなんて許されていませんから。 これはパラメータ名も同じです。 スクリプトからやれば UI 表示用の名前を持てると上で書きましたが、それはあくまでも PPG への表示用であって、XSI にデータとして保持されているパラメータ名には、やはりスペースなどは許されていません。 当然です。


GUI からやった場合でも、スクリプトからやった時のように、PPG 表示用の名前を別で持てさえすれば、それでいいのにねえ。 なんでそうしないのですか嘔吐デスクさま。






と、あきらめていたのですが、 ふと、 こんなことをやってみましてね。

Space3

Edit Parameter Definition ですね。 これ自体は、よく使います。パラメータの名前を変えたい時はもちろん、値のレンジを変えたい場合とかにもよく使います。 Integer を Float にするみたいな値タイプの変更はできないんですけどね。





で、再度パラメータの名前をいじくったんです。

Space4

勝手に入れられてしまったアンダーバーを、再びスペースに入力し直したということですね。





そしたら。

Space5

できちゃった (゚∀゚;)



なんで?  どうして?  意味分かりません。
わかんないけど、スペース有りの表示ができちゃいました。



でもどうせ XSI のことだから、きっと、一度シーンを保存して、また開き直すと、やっぱり勝手にアンダーバーに戻っちゃってるんでしょう~ と思ってやってみたら、シーンをロードし直してもちゃんとスペースが活きてますた (゚∀゚;)







スクリプトエディタのログを見てみると・・・・



最初にパラメータを作った時、つまりこの時点ではスペースを入れて入力したわけですが、

 SIAddCustomParameter("hoge", "Number of fuckin Particles", siDouble, 0, null, 9999, null, 2053, null, 9999, null, null);

こうなってました。 はい、俺が入力した通り、スペース有りとしてログされています。 しかしこれはあくまでも俺が XSI に送ったコマンドであり、結果として XSI がそのまま受け容れたかどうかは別問題です。 XSI はものの名前にスペースを許していないので、結果としてはスペースがアンダーバーに変換された名前でシーンに残ります。


その後、パラメータをマークすると、

 SetMarking("Number_of_fuckin_Particles");

このようにログされています。アンダーバーです。 上で書いたように、スペースは勝手にアンダーバーに変換されたことがわかります。まあ、GUI 上での見た目でもそうだとわかりますよね。


パラメータの値をいじっても、

 SetValue("hoge.Number_of_fuckin_Particles", 3534.716, null);

このようにログされます。 やはりシーンの中にはアンダーバーに変換後のパラメータ名で保持されているのがわかります。



で、次に、上に書いた Edit Parameter Definition のログですが、

 EditParameterDefinition("hoge.Number_of_fuckin_Particles", "Number of fuckin Particles", 5, 0, 9999, 0, 9999, "Number of fuckin Particles", "Number of fuckin Particles");


このようにログされています。 


マニュアルを見ると、最後の引数が Desctiption というもので、「概要・説明」というような意味ですが、実際のパラメータ名よりも説明的なバージョンの名前で、ここで指定した名前が PPG 上での表示に使われると書いてあります。 つまり、この部分はスペースや記号を含んでも良いんですね、きっと。

でもなあ、GUI でいじった時点では、PPG の中に Desctiption という項目はないわけですよ。 そしてその操作の結果ログされた一文では、 Desctiption をいじったことになっている。 わっかりにくいなあ。 これは、UI へのインプリメントがマズイのではないかという気がします。 Desctiption という項目が存在していて、それをいじれるなら、PPG の中にもそれをインプリメントすればいいだけではないか。 なぜそうしないんだ。 まあ、いかにも XSI らしいですけどね。 けけけけ。



ま、ともかくですね、こうしてめでたくスペースが入ったパラメータ名の表示を実現できたわけですが、上に書いているようにこれはあくまでも表示用の名前だけであり、実際のパラメータ名ではないようです。 その証拠に、スペースが入った後のパラメータをいじくった時にログされたのは、

 SetValue("hoge.Number_of_fuckin_Particles", 413.39, null);

これです。 パラメータ名としては、あくまでもスペースは無しでアンダーバーになって保持されていることがわかります。 しつこく書いているように、ものの名前にスペースは許されてませんから、当然です。






以上。





PPG ではスペース付きの表示にできるって、もう、定説でしたかね? マニュアルに書いてますか? 知らなかったの俺だけ?




っていうか、なんか不具合出ないでしょうね・・・?

俺もまだ発見したばっかりで、長期的にこの状態で運用した実績があるわけではないので、なんか問題が出てきそうな気もします。 悪寒しますよね。 XSI ですもの。




.

| | コメント (4) | トラックバック (0)

2011年12月 6日 (火)

2011 & 2012 で RCTools45。

昔から定番であり、もはやトラディショナルとさえ言える便利ツール RCTools を、最近の環境で、やっと使えるようになりますた。



どういうことかと言いますと。



たしか、RCTools42 までは、自分の環境 = Windows7 64bit  +  XSI 2011 SAP SP1 もしくは 2012 SP1 で問題なく使えていたと思うんですよね。


その後、RCTools43 が出たと思うんだけど、このバージョンはたぶんスルーしちゃいました。で、現在最新版だと思われる RCTools45 なんですが、俺の 2011 SAP SP1 や 2012 SP1 では動きませんでした。


動かないというのはどういう状態かと言いますと、ポップアップはできるけど実際のコマンドを走らせると XSI 自体が落ちる、というものでした。 ポップアップまでは問題ないんですよ。 でも、Complete All などポップアップの中の項目を選んだ瞬間、XSI 自体が落ちます。しかもクラッシュセーブせずに。 再現率 100% でした。





なので 42 に戻そうかな、でももうそんなに RCTools 使わないしな、などと思いながら放置していたんです。

今日、たまたま RCTools を使いたい場面が出てきたのですが、でも久しぶりだったので諸々の問題を忘れていて、あれ? 何か問題あったよな? なんだっけ? とか思いながら RCTools を実行した瞬間に XSI 様がセーブもせずスパーーンと綺麗に崩御あらせられたので窓から砲丸投げのようにモニタを遠投しました。

やっぱり 42 に戻すぞゴルァと思いながらも、そういえば最近 myara さんが RCTools について何か書いてたよなと思い出し、ああそうだ、トラックバックもしたんだった、などと思いながら彼の記事を読んでみました。




うん、そうか、これは、違うな。 この記事には XSI がクラッシュするとは書かれてなかった。 Custom Filter が使えない問題でしょうかね。 俺もそのエラーはずっと出ていまして、でも俺はその機能使わないし他の機能は使えているのでまあいいやーって放置していた部分ですねたぶん。

まあともかく、彼の場合はスクリプトファイルの文字エンコードとやらを変更したことによって解決したようですが、俺が困っているのはそのエラーではなく XSI が落ちるという問題です。 残念、この記事の話とは違ったらしい。





------------------------------------------------------------
後日追記:
コメント欄参照して下さい。

myaraさんによると、myaraさんの方でもクラッシュはしていたそうです。

そして、彼がやったことと合わせて考えると、下記に俺が書いたように全部のファイルの文字エンコードを直すのではなく、rcCustomFilterSettings.vbs さえ直せばそれで良いようにも見えます(俺の方では未実験)。

そして俺も上記で触れていますが(書いた時点では自分のクラッシュ問題と関係があると思わなかったけど)、俺の方でも myara さんと同じく、XSI 起動時に RCTools の rcCustomFilterSettings 由来のエラーは毎回出ていました。


などなど総合的に判断すると、どうやら俺のこの記事は、myara さんが書いた記事と全く同じ問題について、全く同じことをして解決したと書いているだけのようにも思えます。 つまりこの記事読まなくても、myara さんの記事を読んでそれを真似すれば、全く同様に RCTools45 が使えるようになる(=起動時エラーも無いし、クラッシュもしない)と思われます。


いやあ、myara さん、混乱させてすいませんねえ。
どうやら、myara さんの記事だけでよかったのに。 
すいません orz
------------------------------------------------------------





などと思いながらも、他に手も無く、調べるのも面倒で、まあダメもとで文字エンコードとやらを変えてみようかな、と思いました。 俺も彼と同じく Noptepad++ を愛用しているのでこれを使ってスクリプトファイルを開き、ANSI エンコードを UTF-8 に変えて保存しました。 ひとつひとつ試すのは面倒なので、RCTools のフォルダの中にある全部のスクリプトファイルでこれをやりました。



そしたら直りました。
RCTools45 しても XSI 様は落ちません。
2011 SAP SP1 でも、2012 SP1 でも。




ええ? スクリプトファイルの文字エンコードの問題だったってことですか?
文字エンコードだけで崩御するくらい、XSI 様は弱いのですか?
それとも、それだけで XSI 様を崩御させられるくらい文字エンコードってのは強いんですか?


なんだかよくわかりませんが、直りましたですよ。



一応もう少し書いておくと、RCTools45 をインストールし、インストール先のフォルダの Plugins フォルダに行ってですね、この中にあるスクリプトファイル、つまりテキスト形式のファイルですが、これを全部、エンコード変えたのです。

Rc1

プラグイン本体は dll なんですよね。 C++ か何かで書かれてコンパイルされているバイナリファイルです。 これはもう、いじりようがないというか、そもそも文字エンコード云々の話は関係ないファイルです。バイナリですから。 なのでそれ以外のファイルです。画像ファイルはもちろん除いて。 JScript と VBScript と Python と、全部ありますね。 作者様は全ての言語を扱えて、書きたい処理の内容に都合の良い言語を選んでいるのでしょうかね。それともただの気分でしょうかね。




Notepad++ の場合は、スクリプトファイルを開いて、

Rc2

「フォーマット」
メニューをクリックすると、「ANSI エンコード」 にマークが付いているのがわかると思います。 それを、「UTF-8 に変換」 を選んでやると、UTF-8 にマークが付きます。 この状態で上書き保存します。 以上。 そんだけ。


Notepad++ じゃなくても、文字のエンコードを変えられるソフトウェアなら何でもいいと思います。






そもそも、この文字エンコードって、なんなのですか? 俺よく知りません。 まったくもってわかりにくいですよね。 いちいちそんなこと気にしなければ誰かの作ったプラグインも使えないなんて、なんか、まだコンピュータの世界って遅れてるなあとか思いませんか。 

iPhone だの iPad だの、俺は持ってないですけど、アップルが出してきた製品とかって、そういうのを一切気にしないでひたすら目的のためだけに使えるようデザインされてますよね。 それと比較するのは正当かどうかわかりませんが、ほんと、余計なことを気にせず使いたいですよね。 ドライバがどうした、とか。 Mac と Windows がどうした、とか。 日本語キーボードとして認識されちまって云々、とか。 アサヒとキリンがどうした、とか。 まあ、キリンが美味いに決まっているんですがね。









それにしても、昔からこの RCTools はバージョンが上がるたびに必ず何か問題が出て苦労してきた気がします。 正直言えば、使わなくて済むならそれに越したことはない。

単純なエッジループの選択などは XSI 標準の機能でもできるのでこの RCTools を使う意味は昔よりは薄れたと思います。 しかし俺の場合、あちこちに散らばった複数のエッジループをイッキに選択したい、という時にどうしてもこの RCTools が必要になります。


例えば、こういう場合ですね。

Rc3

画像左側のように、選択したいループの一部をあらかじめいくつでも選んでおき、RCTools から Complete All でイッキに右の状態になります。 これが便利なんです。 

XSI標準の機能でやる時のようなループ選択をどんどん追加していく考え方ではなく、ループの一部をあらかじめ選んで後からイッキにループを形成する、というフローが重要なんです。 こっちの方が遥かにラクですから。 この例はたった3ループですけど、シリンダみたいなもうちょっとカッチリした形状で、似たようなループが大量にあるオブジェクトの中の、任意の場所のループを10箇所とか選びたいみたいな状況ってけっこうよくあるので、RCTools 使わなかったら本当に大変ですよ。 


標準機能で、こういう選択がラクにできる方法を知っているお方がいらっしゃいましたら、どうか教えて下さい。 そうしたらそのときこそ、RCTools とお別れできるかもしれません。



あー それとこの RCTools45 ですが、XPOP3 がベースなんですね。 個人的には XPOP2 ベースの方が好きかもしれない。 XPOP3 はポップアップがちょっとだけ重いんですよね。 3 になってからグラフィカルな部分でのカスタマイズの幅が増えたのですが、その分重くなってしまったようです。




myara さん、あなたの記事がなかったら、これ、できませんでした。
ありがとうございました。
年末は大いに吞み散らしましょう。
グラシアスアミーゴ。





.

| | コメント (5) | トラックバック (0)

2011年12月 2日 (金)

XSI男Tシャツ 第3次はもうすぐ〆切〼。

以前、この記事でXSI男Tシャツの第3次募集を告知しましたが、〆切りの日程をまだお知らせしていませんでした。 というより、決めていませんでした。 XSI男忘年会も迫ってきたことだし、そろそろ〆切ることにした方が良さそうです。

Img_0108

ということで、


  2011年12月7日(水)に〆切ります。


購入ご希望のお方は、それまでに連絡を下さいませ。




また、すでに注文を頂いているお方へは、個別でメールを送ります。 振込先口座などをお伝えしますので、入金をお願いします。






さすがに尻すぼみ気味とでも言うか、第3回ともなると、注文枚数は少ないですね。現在まだ10枚にも達していません。 でもまあ、いいんです。 今まで十分寄付できたと思うし、今後はまた形を変えて、なんらかの形で復興のお手伝いができればいいと思っているので、いいんです。




ちなみに! Tシャツ作製をお願いしているアートスペースさんでは、今回のTシャツの主旨を理解して下さり、プリント版の再製作料(再版代金)を割引きしてくれてます! 本来 2,000円かかるらしいのですが、震災復興支援目的のTシャツなので、1,000円にしてくれるそうです!  イエイ、カッコいいぜアートスペースさん (゚∀゚)



個人的には、XSI男ステッカーとかも欲しいなあ。 どっかで安く作れないかな。







ではでは、さらなるご注文、お待ちしております (゚∀゚)






305710_113025022138124_1000029188_2 Img_0117

301625_109766009130692_100002918800 Img_0058 Img_0004
Img_0072  Sany0016


| | コメント (0) | トラックバック (0)

« 2011年11月 | トップページ | 2012年1月 »