« 2011年2月 | トップページ | 2011年4月 »

2011年3月

2011年3月31日 (木)

XSI男Tシャツ途中経過その後。

前回書いたように、見積もりを取っているTシャツ屋さんにTシャツの重量を教えてくれないかとメールしたのですが、ソッコーで返事が返ってきましてね。スヴぁらしい。レスポンスが良い。


で、結論としては「クロネコヤマトのメール便でバラで送るのが一番安いですよ」だそうです。


俺、メール便は240円だと思ってたんですが、それはB4封筒で厚みが2センチの場合で、A4封筒で厚みが1センチ以下なら80円だそうです。 そのTシャツ屋さんは、実際にヤマトのメール便で XL のTシャツを80円で送った実績があるそうです。


なので、ひとりでTシャツ3枚購入する場合を考えると、B4封筒に3枚入れて厚みが2センチに収まるかとか気にしているくらいなら、1枚ずつA4に入れて3枚バラバラに送った方がいいということですね。 梱包は封筒に入れて宛名書くだけなのでまあそんなに手間でもないし、封筒の資源が無駄と言えば無駄ですがたかが知れていますし、宛先は一緒なので配送の無駄はないし。 しかも1枚発送の場合は80円、2枚なら160円、3枚なら240円という風に、実に分かりやすい送料体系にできそうです。


なるほど、そういう手があったか。 Tシャツ屋さんありがとう ヽ(゚∀゚)ノ



ということで、前回書いた定形外郵便というのは撤回、クロネコヤマトのメール便になる可能性が高いです。






ということで、近々正式な受付を始めます。

とか言ってなかなか進まない。
すいません。
その間、まわりの人を恐喝しといて下さい。
その場でジャンプさせてみて下さい。
チャリンチャリンと音がしたら、Tシャツを押し売りして下さい。




.

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

2011年3月29日 (火)

XSI男Tシャツ途中経過。

途中経過を報告します。


現在、10人のお方から合計17枚の購入の意向を頂いております。 ありがたいです( ;∀;)



Tシャツ作製サービスは3社見積もりを取りました。 品質は劇的に変わるとも思えないので、一番値段が安かった会社にします。その会社は、Tシャツ1枚の 売り上げに対し20円を、今回の地震の義捐金として赤十字に寄付するそうです。つまり、福島復興支援のTシャツを作ると、被災者全員に配分される(はず の)赤十字にも義捐金が行くわけで、一石二鳥です(゚∀゚)

他のTシャツ屋でも同じような寄付をしている所があるようですが、まあ全部から見積もりを取るのはキ リがないので、もうこの会社にほぼ決定です。 また、義捐金寄付の期間中は製版代の消費税分もタダにしてくれるみたいです。なかなか好感度高い。



デザインに関しては、おひとりの方から、We support Fukushima よりは We pray for Fukushima の方が好きだという表明がありました。それ以外はありません。なので、このままなら We pray for Fukushima で行きたいと思います。


プリントのサイズは、B4くらいまで同じ値段で可能だそうです。 前回乗せたイメージ画像に近い、けっこうでかいプリントができそうです。でかけりゃいいってもんじゃないですけど。



色に関しては、Tシャツの地の色はひとりひとり自由に選べることがわかりました。正式発注するときに、十数種類の色から選んで頂く形になります。

一方、プリントの色(文字を含む図柄の色)は1種類のみ。 そもそも1枚のTシャツに複数色にすると値段が高くなります。 また、1枚のTシャツに使う色数は1色だったとしても、下地の色に合わせてプリントの色を変えたいなどと言い出すと、やはり高くなります。 高くなった分寄付が減るのも嫌だし、かと言って販売価格に反映させると多くの人に御協力頂けないかもしれません。  なので、プリントの色は下地のバリエーションへの汎用性が高いと思われる黒1色で決定とさせて頂きます。




現在発送方法を検討しています。 

前回は 「着払いで」 と書きましたが、着払いって、発送する側は楽ですけど受け取る側は気分的にちょっとめんどくさいんですよね。俺も何度も経験ありますが、自分が払う側の時は着払いは避けたい気分が働きます。 なので、基本は元払いで発送できるよう、調べ中です。 送料を含めた代金を先に振り込んで頂き、こちらから元払いで発送するということです。なるべくこの方向で行きます。


今朝、適当にTシャツ3枚をB4の封筒に詰め込んでクロネコヤマトの営業所に持ち込んでみましたが、厚みが2センチを超えているのでメール便(240円)では送れないとのことでした。 2枚でもダメでした。 1枚なら大丈夫でした。

郵便局に持ち込んでみると、3枚詰め込んだやつは定形外郵便で580円でした。1枚だと240円でした(メール便と同じ)。 2枚は量ってもらうの忘れた。 レターパック500というやつだと500円なんですが、こちらは封筒が決まっているやつで、Tシャツ3枚はどう見ても入りませんでした。 ゆうパック(小包)だと、事業所持込み割り引きが付いても600円ですね。 定形外郵便だと、大きさの制限はユルいけど重さでけっこう細かく変わるんですね。


ただ、これは俺の手持ちのテキトーなTシャツの場合です。今回作製するTシャツもまあそんなには変わらないと思うけど、生地の厚さなどわからないので、1枚ならともかく3枚ともなると結構重量が変わってくるかも知れません。なので現在、発注予定のTシャツ会社にTシャツの重さを量ってもらえないかメールで問い合わせている最中です。 B4の封筒に XL を3枚入れた重さを教えてくれ、とかメールしたんですが、果たしてやってくれるだろうか・・・・。 やってくれたらそりゃもう、間違いたくおたくに発注しますよゴルァ

ということで、まだ決定ではないですが、元払いの定形外郵便で発送という可能性が高いと思っています。 枚数で送料が変わりそうです。

ただ、近隣のお方はなるべく俺からの手渡し(Tシャツと現金引換え)をお願いしたいです。送料かからないし、振り込み手数料もかからないし、俺のミスも防げます。 Tシャツ引渡し呑み会でも開催するとか。


あとは、封筒代とか、Tシャツ会社への代金の振り込み手数料とか細かいお金が多少かかりますが、大した金額でもないのでこれは俺が負担します。 もしとんでもない数の注文が来て無視できなくなったらまた相談しますが、まあそんなことはないでしょう。





ということで、発送方法が確定したら、正式な受付を始められると思います。もうすぐです。 たぶん10日間くらい受け付けます。その後Tシャツ屋に発注し、みなさんの手元に届くにはさらに2~3週間なりかかると思います。 俺の発送作業も手間取るかもしれないし、すいません、ユルく見て下さい。




XSI男とかぜんぜん知らない俺の友達からも、恐喝して注文取ろうと思います。
けけけけ。



.

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

2011年3月25日 (金)

XSI男Tシャツ。

思いつきではあるんですがね。



先日の地震で被害に遭った人々へ、俺はどんな手伝いができるかなーって考えてたわけですよ。 まあ、前に書いたように、俺の気持ちは主に浪江に向いているんですけどね。


で、ふと義捐金を募るためのTシャツなどはどうか、と思いついて、某所でつぶやいてみたら、少なくとも数人は協力してくれそうな感じでした。


ずっと前から、いつか XSI 男Tシャツ作りたいなーと思っていたんですよね。ちょうどいい。やるか。やろう (゚∀゚)




ということで、XSI男Tシャツを作製します。
詳細はまだ未定です。今、試しに見積もり取ったりしています。


基本的には、

 ・よくあるオリジナルTシャツ作製サービスのどこかを利用して、Tシャツを作る
 ・1着の作製コスト(作製サービスに払うお金)は、(枚数によるが)おそらく1200円くらい
 ・それを、有志の方々に購入してもらう
 ・作製コストを差し引いた売り上げ金額の全額を、福島県災害対策本部に寄付する

 ・価格は、1着3500円か、高くて4000円くらい(送料別)
 ・junki の手元にTシャツが届き、購入した人には junki から手渡しか、junki から着払いで発送
 ・お金の支払いは、手渡しの時は現金引換え(つまり送料無料)、発送の場合は銀行振り込み
 (振り込み手数料は各自負担)

というつもりでいます。 まだ仮の仕様です。変更になる可能性があります。


なぜ被災地全体ではなく福島県なのか、ということについてですが、すいません、ほんと、個人的な思い入れだけです。 しばらく悩んだのですが、やはり福島県にしようと思います。

被災者全体への寄付となると、俺としてはモチベーションが曖昧になってしまって嫌なんです。 こういうことって、当たり前だけど、誰に頼まれたわけでもなく自分の思いから行動するわけじゃないですか。ならば自分のモチベーションが最大限に働く状態でやりたいのです。被災者全体を対象とした個人個人への寄付の分配は日本赤十字社がやっているので、そちらにお任せすればいいし。俺もそっちにも募金しようと思います。

もっと正直に言えば、福島県全体ではなく福島県双葉郡浪江町限定にしてもいいくらいの気持ちがあるんですが、それだと個人的すぎて他の人に協力してもらえそうもない。 ならば福島県全体まで対象を広げるのがちょうどいいのではないか。 これなら俺のモチベーションも保てるし。

実際、福島という土地全体が大好きで、そうだなあ、おそらく過去に福島県内で合計20泊くらいはしているんじゃないかな。ツーリング、キャンプ、温泉、スキー、酒、食い物。 いっぱい遊んだ土地です。 猪苗代湖キャンプ、会津で酒、東山温泉、桧枝岐でキャンプ、木賊温泉は最高、シルクバレーの変なキャンプ場、湯の花温泉も最高&蕎麦も美味い、阿武隈で鍾乳洞とキャンプ、入水鍾乳洞も穴場、西郷村でキャンプ、喜多方でラーメン、桧原湖、いわき湯本温泉、小名浜で水族館、磐梯山でスキー、南会津で林道走りまくり、波立海岸、そしてもちろん浪江。ほら、なんぼでも出てくるぞ。
浪江以外に住む知人もいる。 家族を疎開させひとりで被災地に残る友人もいる。是非復興して欲しい。




などと、俺の個人的な思いばかり述べてすいません。

ともかく、もしご協力してくれる方がいたら連絡下さい。 数によって値段が変わってくるので、大まかにでも発注見込み数を把握しておきたいのです。 このブログにコメントして頂くか、junkithejunkie[ 亜っと ] gmail [ 怒っっっと ] com に、[XSI男Tシャツ] という文字をタイトルに含むメールを下さい。 

その連絡を頂いても、まだ正式発注ではありません。値段とか決定してないですから。 あくまでも概算を見積もるためのものです。 後日正式なお知らせをしますので、正式発注はその後に再び連絡を頂くことになります。今回の連絡で寄付の意思を示してくれた人は正式発注の時に絶対に買えよ、とは言いません。 でもまあ、基本的には正式発注の時にちゃんと購入してくれるつもりがあるお方だけ、連絡を頂けると嬉しいです。

お金のからむことなので、トラブルになるのは何としても避けたい。なので、趣旨に賛同できる方のみ、ご協力下さい。 質問なども遠慮なくして下さい。


考え方としては、

  junki がTシャツを販売してその利益を寄付する 

ではなく、

  有志が集まって寄付する。ただ寄付するよりはTシャツとか何かあった方が人が集まりそう(=寄付額が増えそう)だから、寄付で集めたお金の一部を使ってみんなのTシャツを買ってもいいことにする

だと、俺はとらえています。それに賛同できる方のみ、ご協力をお願い致します。

当たり前ですが、最終的にキッチリ会計報告します。


多少の不手際やモタつきは許して下さい。こんなことやったことないし。
Tシャツの衣服としての品質も、あんまり期待しないで下さい。
少しでも疑問や違和感があれば、質問して頂くか、参加をご遠慮願えればと思います。
すんません、トラブルにビビっているんです。







今のところ、10枚くらいは作製できそうな見込みです。 20枚くらい行きたいんだけどなあ。 

某さんがステキなことを言ってくれていましてね、「自分用1枚、保存用1枚、布教用に1枚=合計3枚買います」 だそうです。嬉しいなあ。  

なるほど、どうせ生地やプリントの品質はそんなに良いTシャツになるわけじゃないだろうから、普段着用していればそんなに遠くない将来にボロボロになっちまうかも知れませんよね。なので予備あるいは保存用として1着追加はいいアイデアです。 布教用というのはつまり、今回買いそびれた人や、junki が呼びかけても協力しないだろうが俺が言えば協力するだろう、という身近な人向けという感じですかね。 その人のためにあらかじめ1着余分に購入しておいて、後からその人からお金を回収すればいいわけですね。 なるほど。じゃ俺も3枚にします。







問題のデザインですが、すいません、こんな感じで許して下さい。
Pff_pray

単色で済ませると安くあがるんですよ。 俺にとっての XSI 男とはビューポートキャプチャの男なので、最初はキャプチャであれこれいじくっていたんですが、結局色数によるコストの問題で、単色にすることにしました。 おそらくこれが最も安く、かつ堅牢にできます。

白い部分はヌキになります。つまり、Tシャツの生地の色になります。

We pray for Fukushima の代わりに、We suport Fukushima はどうだろう? と思ってやってみたのですが、
Pff_support
どうでしょう・・・? どっちが好きですか? ご意見下さい。

どっちもあちこちで言われている、いわば「借り物」のコトバなので、ほんとはオリジナルのコトバにしたい気持ちはあるんですが、思いつかない・・・・。







Tシャツの色は、果たして個人個人の希望に合わせて発注できるのか、それとも10枚発注なら10枚同じ色でないといけないのかとか、今問い合わせ中です。 できれば7~8色の中から選べるといいんですけどねえ。 せめて2色から選べるとか。 

イメージ。
Pff_colorvariation

これはあくまでもイメージですよ。 最終的にこうなると確定したわけではありません。どんな色が好きッスか?

プリントのサイズは、もう少し小さくなってしまう可能性があるかな。 大きいと、製版代が高くなるんですよ。 



サイズは1着1着自由に選べるはずですが、XXL とか XXXL みたいなでかいサイズになると100円とか200円とか高くなります。 でも取りまとめのミスを防ぐために、たとえ XXL以上だったとしても同じ額にしようかなあ、と思っています。その分寄付する額が減るということになりますが、ミスってトラブるのは避けたいので、たぶんそうすると思います。





こんなTシャツ要らないですって?
そんなお前は赤十字へ GO だ ドカッと寄付して来いドルァ





ご協力頂けると嬉しいス。



.

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

2011年3月19日 (土)

浪江!!!!!。

俺の知っている人は、皆、生存を確認しております。


福島県双葉郡浪江町は、俺の大切な友人が住む土地です。
いや、俺の大切な友人が住んでいた土地だと言い直さねばならぬ。
現在は避難生活ですが、「新しい故郷を探さないといけないのかも知れないな」と言っていました。

俺が宇宙で一番好きな酒を造っている蔵がある土地でもあります。
いや、俺が宇宙で一番好きな酒を造っていた蔵があった土地だと言い直さねばならぬ。
蔵は海の目の前でした。津波が全部かっさらって行きやがりました。
ここの家族も全員無事で現在は他県へ身を寄せていると情報が入ってきていますが、町があの状態だから、蔵を復興させられるのかどうか、なんとも言えないでしょう。今はそれどころではない。


今こんな状態の町です。

冒頭の部分が浪江ね。



俺は2007年と2010年の2回、この町を訪れました。シンプルで素朴で良い町です。酒が美味い。魚が美味い。マコガレイが美味いんだこれが。 マコガレイのお造りを食った港の店も、もちろんもう無いのですが。



今回の地震で死んだり被害を受けたりした全ての人のために祈ることなど、俺にはできません。なんとなく、気持ちにウソが入ってしまう。

しかし浪江に関しては、微塵のウソも偽りもありません。浪江の復興を祈ります。俺が愛する人たちがいた町の復興を、腹の底から祈ります。 俺にどんな手伝いができるか、何をするのがベストなのか、何が現実的なのか、現在は様子を見ているところです。 ひとまず今は、祈るだけ祈っておきます。



XSI 男も応援してくれています。
俺と一緒に祈ってくれるのか。いいやつだなあ。
Namie

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

2011年3月11日 (金)

ベベルをあきらめないで。

最近もう、ベベルばっかりです。いったいもう、何千本のエッジをベベルしたのだろう。


その中で、最近発見した技というわけではないんだけど、毎日ベベる時に気にしていることを、ちゃんとまとめて考察したことがなかったので、残しておこうと思いますた。 いや、ベベる前に分割を考えましょうというそれだけの話で。そんな活気的な話ではないし、バリバリモデリングする人は当たり前のようにやってることだとは思うんですがね。





こういうブツがあります。
B1

黄色の矢印で指しているエッジだけをベベりたいとします。


普通にベベると、
B2

非常に汚いポリゴンが出来てしまいます。思いっきりねじれた、非平面なポリゴンです。



でもあきらめてはいけません。



側面に分割を入れることによって、どう変わるか見てみます。
B3

上の列、A1~D1がベベル前の状態です。 側面に、赤い印の頂点から、水平や垂直方向に分割を入れています。 ベベル後が下の列、A2~D2です。 先ほどの汚いポリゴンができたのは、分割無しのDですね。

Aはもう、ベベったエッジから発生したポリゴンがよじれているので論外です。 Cは、真ん中にできた台形のポリゴンが超よじれています。このアングルだとわかりにくいですが、寄ってみるとひどいポリゴンだと言うのがわかります。そもそもこんな台形欲しくないし、論外です。

となると、この中ではBが一番キレイなように見えます。



でも、
B4

うーむ、やはりこの三角ポリゴンが気に入らないですね。 このエッジだけをベベろうとしている以上、ここにポリゴンが発生してしまうのは仕方ないんですが、問題は向きです。三角なのが気に入らないのではなく、向きが気に入らないんです。 ベベルによって出来たポリゴンとも、ベベル前から存在していたどのポリゴンとも、ツライチで平面になっていなく、独自の向きを持っているというのが気に入りません。 

結果的に出来たメッシュによじれたポリゴンはひとつもなく、キッチリした見た目にもなっているので、こういうパターンのベベルも場合によってはアリでしょう。 しかし今回は、ベベルで出来たポリゴン以外で、勝手な方向を向いているポリゴンを発生させないことにこだわりたいのです。


あきらめてはいけません。



分割の入れ方を変えると・・・・・
B5

1がベベル前です。 赤い印の頂点から、垂直や水平ではなく、上の斜面の傾きに一致した分割を入れています。 この状態でベベったのが2です。 これでキレイなベベルになりますた ヽ(・∀・` )ノ


相変わらず真ん中に三角形のポリゴンは発生するわけですがそれは当たり前です。大事なのは、この三角形が上の斜面と完全にツライチで平面になっているということです。 




なにしろ完全にツライチの平面なんだから、その後の処理は格段に楽だし、よじれた面などとは無縁です。
B5b

なんならベベル後にこの三角形のエッジを削除したって良いでしょう(赤い矢印)。

他の頂点へ接続したり、ぐるっと一周回すようなエッジループを作るのもアリでしょう(黄色の線)。

最初の分割のためにできてしまったエッジは、あくまでもベベルをキレイにやるために一時的に入れたエッジなので、最終的には必要ありません。有無を言わさず削除します(青い矢印)。

イエイ。 これで良いのです。




ちなみにこのような「あるエッジと傾きが一致した分割」を入れる方法ですが、色々あるでしょうが、簡単なのはスライスツールですね。ナイフのアイコンのアレですね。 Left や Right などパースの無いビューでスライスツールを起動し、上の斜面を構成する2つの頂点を Ctrl でスナップしながらピックすれば、その2点をつなぐ傾きでオブジェクト全体にスパッと分割が入ります。気持ち良いです。 オブジェクト全体に入るのが嫌なら、先にポリゴンを選んでおいてからスライスツールを起動します。そうすると、そのポリゴンにしか分割が入りません。




ベベりたいエッジが斜面のエッジ(下の画像の黄色い矢印)だった場合は、
B6

赤い線の方向で分割を入れておけば、同様に美しいベベルができます。 中央にできた三角ポリゴンは、隣接するポリゴン(上面)と完全にツライチです。



最初の分割では、ベベりたいエッジが、そのエッジに対して水平でも垂直でもない傾いたエッジと隣接しているにも関わらず、水平や垂直に分割を入れてしまっていたのが間違いでした。 傾きに合わせた分割さえあれば、キレイに行きます。たぶん。俺がやった限りでは成功率100%。 

これが求めていたベベルです。 過去には、キレイにベベルできない時はベベル機能を使うことをあきらめてしまい、Ref プレーンやスナップを駆使して泣きながら手ベベルで対処したことも1度や2度ではありません。今ではあきらめず、まず分割を試します。 そのおかげで窓から遠投されるモニタの数は最小限で済んでいます。 あきらめたら負けなんです。 岡村さん、俺もう、あきらめないことにしたよ。





さて、今度はこういうベベルをしたいとします。
B7
黄色いエッジをベベります。



例によって、分割違いを試してみると、
B8
B と C では、黄色い印のポリゴンが歪んでしまいました。 前回のベベルでは、この B と C の分割パターンが正しいベベルにつながったのに、今回はダメです。  むしろ、A と D が上手く行っているように見えます。 前回はべべるエッジがあの1本だけだったからですね。ベベりたいエッジと隣接したエッジの状態によって分割の方法を使い分ける必要があるということが、わかります。


さて、A と D が上手く行っているように見えると書きましたが、A の青い印のポリゴンに寄って見ると、
B9
パースのないフロンとビューで確認すると、ベベルによって発生したポリゴンが歪んでいるのがわかります。 これではダメです。

ということでこの場合は、歪んだポリゴンがひとつも発生しなかったは D だけでした。 Dはそもそも分割無しです。 なんでもかんでも分割すりゃいいってもんじゃないことが、わかります。




ということで、ベベルが上手く行かない時は、あきらめずに分割パターンを試したり、分割しなかったりすると、夢が叶います。たぶん。






岡村たん。。。。。



お、なんかこっちの方がいいな










いや、これが一番いいな。







.

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

2011年3月10日 (木)

淫スタンスのリネーム。

日々スクリプト書きながらの作業です。


インスタンスが増えてきました。名前の管理がうざったいです。 インスタンスマスターの名前に準拠した一定のルールでリネームしたいんです。 インスタンスマスターの数は少なくてインスタンスの数が多いという場合ならさほど苦痛にならないんですが、マスターの種類が多いと苦痛です。スクリプト書きます。




//    お好みでデフォルト値を変更。 ここの値は後にリネーム実行ファンクションに渡される

InstName = "<Pre><MasterName><Post>";    //    <Pre><MasterName><Post>
Prefix = "";
Postfix = "_Inst1";

//    ================================

//    あらかじめインスタンスを入れる箱(コレクション)を作っておく = oInstaces
var oInstances = XSIFactory.CreateObject( "XSI.Collection" );
oInstances.Unique = true;    //    これは要らないかな

//    現在選んでいるオブジェクトをループしてインスタンスかどうかを調べる
for ( var i=0; i<Selection.count; i++ )
{
    //    もしも siClassID が siModelID で、 かつ、 種類が siModelKind_Instance なら、 それは Instance
    if ( Selection(i).IsClassOf( siModelID ) && Selection(i).ModelKind == siModelKind_Instance )
    {
        oInstances.Add( Selection(i) );    //    箱にインスタンスを追加
    }
}
//    ここまでで、処理すべきインスタンスの収集完了

//    収集したインスタンスのコレクションをループして、全員をいったん無意味な名前にリネーム
for ( var i=0; i<oInstances.count; i++ )
{
    oInstances(i).name = "FuckMyInstanceMasterPlease";    //    無意味ですってば。
}

//    もう一回同じコレクションをループして、実際のリネーム実行
for ( var i=0; i<oInstances.count; i++ )
{
    //    実処理はファンクションに飛ばしている。 ファンクションに必要な引数を渡している
    RenameInstance( oInstances(i),  oInstances(i).InstanceMaster, InstName, Prefix, Postfix );
}

//    ================================

//    リネーム実行ファンクション
function RenameInstance( oInst, oMaster, InstName, Prefix, Postfix )
{
    //    名前を置換するための準備。 正規表現よくわかんねえよドルァ
    var RE1 = new RegExp( "<Pre>", "gi" );
    var RE2 = new RegExp( "<Post>", "gi" );
    var RE3 = new RegExp( "<MasterName>", "gi" );
    //    性器表現なら得意なんですけどね。

   

//    トークンを変換している
    ResultName = InstName.replace( RE1, Prefix );
    ResultName = ResultName.replace( RE2, Postfix );
    ResultName = ResultName.replace( RE3, oMaster.name );

   

//    Instance の名前j変更して終わり。 このファンクションが、ループの回数だけ呼ばれて繰り返される
    oInst.name = ResultName;
}


インスタンスを選んで実行します。
Renameinstance
上が実行前、下が実行後です。

スクリプトの冒頭で、お好みに合わせてリネームのルールを書き換えます。

デフォルトだと

InstName = "<Pre><MasterName><Post>";
Prefix = "";
Postfix = "_Inst1";


こうなってます。 3種類のトークンがあります。 <Pre> トークンは Prefix に代入した文字列に置換されます。 <Post> トークンは Postfix と置換されます。 <MasterName> トークンは、インスタンスマスターの名前と置換されます。 トークンは使っても使わなくてもいいし、トークン以外の任意の文字列を入れることも当然出来ます。


仮に、

InstName = "<Pre><MasterName>-hagehage<Post>";
Prefix = "Instance_";
Postfix = "_Gorua";


にしていた場合の結果は、

Instance_インスタンスマスターの名前_hagehage_Gorua

になります。





以下にスクリプティング的な解説をします。 いや、これもさほどのことはやってないのですが・・・。



現在選んでいるものがインスタンスかどうかを判断する方法


    if ( Selection(i).IsClassOf( siModelID ) && Selection(i).ModelKind == siModelKind_Instance )

直接 Instance という Type なり ClassID なりあればいいのですが(あるのかな?)、普通に siType や siClassID の中には無かったので、2段階にしています。

Instance は Model の一種です。 なので Class が siModelID かどうかを調べることによって、まずは Model かどうかをチェックしています。それが赤字部分です。 ちなみにここは Selection(i).type == siModelType などと書いても同じ結果になります。

そして、Model だった場合は、もう一段階チェックします。 Model オブジェクトには ModelKind プロパティがあるので、それを調べると Instance かどうかが判別できます。それが青字部分です。 通常の Model か、リファレンス Model か、Instance かの3種類に判別できます。 SDKガイド参照。

この ModelKind プロパティですが、Model オブジェクトに対して効くプロパティですので、Model 以外のものが選択されていた場合はエラーになります。 しかしこのスクリプトの場合は、まずは赤字部分で Model かどうかを調べて、Model だった場合にのみ青字部分が評価されるので、変なもの選択していてもエラーは出ないはずです。たぶん。

このように、if の中で && を使って複数の条件を指定している場合は、一番左から順に評価され、そこを通過したものだけが && 以降の次の条件に進むようです。たぶん。マニュアルに書いていたわけでも WEB で調べたわけでもありません。今までの経験から、挙動を見るとどうやらそれで正しそうだ、という程度の話です。 間違ってたら教えてくださいまし。 ちなみにこれは JScript の話です。 if の構造などは言語によって違うはずなので、違う言語で書く場合はそれぞれに合わせた書き方をするしかありません。これは XSI の話ではなく、スクリプト言語の話なので、XSI の SDK ガイドを見ても載っていません。 WEB で探すなり本読むなりするしかありません。



一度無意味な名前にしておく

//    収集したインスタンスのコレクションをループして、全員をいったん無意味な名前にリネーム
for ( var i=0; i<oInstances.count; i++ )
{
    oInstances(i).name = "FuckMyInstanceMasterPlease";
}


これなんですが、おそらく連番系リネームの常套手段じゃないでしょうかね? リネーム後の名前が自分自身の名前とダブってしまい、数値が加算されて間の空いた数値になるのを防ぐために、一度違う名前にしてます。


こういう場合です。
Renameinstance2

画像の上部分が元の状態です。 スクリプトの中の、無意味リネームの部分をコメントアウトして実行した結果が画像の下部分です。

数値を 1 と付けようとして、すでに 1 が存在していたら 2、それも存在していたら 3・・・・という風に評価されて数値が決まるわけですが、実行前の状態で 7 まで埋まっているので、リネーム後の名前は 8 から始まっちゃうんですね。 結果、1 から 3 まで連番、間が空いて、8 から 11 まで連番、という名前になってしまいます。 でも間が空くのは嫌じゃないですか。 だから、一度全部違う名前にしちゃういます。そうすれば、 上の例で言うと 4 以降は存在していない状態になるので、リネームした時にちゃんと 4 から始まってくれます。 そんだけ。




インスタンスマスターの取得方法

    RenameInstance( oInstances(i),  oInstances(i).InstanceMaster, InstName, Prefix, Postfix );


この RenameInstance というのは、俺が勝手に作ったファンクションです。 そのファンクションに、カッコの中で引数を渡しています。 その引数の2つ目、 oInstances(i).InstanceMaster によってマスターを取得しています。

これは Model に対して効くプロパティです。 oInstances(i) の部分はすでに Instance が入っているので、そして Instance は Model なので、結果 InstanceMaster プロパティが効く、と言えばいいでしょうかね。 

Instance じゃない Model(つまり通常の Model やリファレンス Model )に対して InstanceMaster プロパティの呪文を唱えるとエラーになります。 Model に対して効くプロパティだとは言え、あくまでも Instance という種類の Model じゃないと効かないということになります。 ただしこのスクリプトの場合、上に書いたように最初に Instance だけをコレクションにぶち込んで、その後の処理はコレクションの中身に対してだけ行うので、もう Instance 以外は除外されています。 安心して InstanceMaster プロパティを唱えられます。


余談ですが、この InstanceMaster プロパティは昔はありませんでした。 なので GetMaster コマンドを使ってました。 七ちゃんから IntanceMasterプロパティが搭載されたので、ラクになりました。 Object Model の方がラクです。実行速いし、芋づるしやすいし。

更に余談ですが、上で出てきた ModelKind プロパティは六ちゃんで初めて搭載されました。それ以前はインスタンスかどうかを調べるのに、対象のオブジェクトにまずは GetMaster コマンドをかましてみて、インスタンスじゃなかったら GetMaster コマンドの結果が null になるから、それで判断してました。

淫さまというプラグインを書いたのは、たぶん ver5 の頃だったと思う。 なので淫さまは未だに GetMaster コマンドを使った書き方になってると思います。もう五ちゃんや六ちゃんに戻ることはなさそうだから、そのうち直しておこう。





正規表現で置換してリネーム

の部分は、すいません俺よくわかってません。わからないまま、上手く動いた時のコードをコピペして使ってるだけです。 誰か詳しく解説してください。

基本的には、指定したパターンを探し出し、この場合は <Pre> <Post> <MasterName> という3つがそのパターンになるわけですが、そこをユーザが指定した文字列に置き換えるということをやっているわけです。 パターンが何回繰り返し出てきても全部置換するために g というスイッチを入れ、大文字小文字の区別をしないために i というスイッチを入れている・・・・のかな? わからんままやっているんです。すいません。


っていうか、ほんと、正規表現って宇宙語ですよ。 こんなもの読んで理解できたら人間じゃありません。 俺は人間ですから理解できません。いいんです。

人間が読める GUI で条件を指定すると正規表現の文字列に変換して吐き出してくれるソフトウェアとかって、ないですかね?



こんなところでしょうかね。

今回のスクリプトは割と今後も使いそうだから、そのうち淫さまの一機能として組み込むことにします。


ごきげんよう。



.

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

2011年3月 8日 (火)

M2。

なんだか、来たようです。
http://vimeo.com/20314570
なぜかビデオの埋め込みが許可されないので、Vimeo でご覧下され。


ヘルゲさんの Momentum ver2.0 降臨だそうです。
http://www.exocortex.com/simulation/momentum

もはや無料ではありません。
有償ソフトウェアになりました。



もうすぐ出るようなことは言っていたけど、有償になるらしいというのも聞いていたけど、びっくりしたのは、Exocortex から発売?? 

開発はヘルゲさんだとして、Exocortex はどのように関わったのでしょうかね? ただの販売チャネル? それとも Slipstream とかのノウハウを生かして、シミュレーションのスピードアップに貢献しているとか?

いずれにせよ、Exocortex という着地点が見つかったようで、良かったですね。ヘルゲさん個人では今後のサポートやら何やらで限界があるでしょうからね。そしてあの巣はとっくの前に崩壊状態になってたみたいですからね。 去年の末、スペイン人がボソッとつぶやいていました。

50ページ以上のマニュアルが付くそうです。チュートリアルビデオも作ると。さすが、ちゃんと発売する感じがありますね。

どんなことができるかは、
http://vimeo.com/20273305
こっちのビデオに詳しいですね。前に出していた Teaser と似た内容ですが、サンプルの数が圧倒的に増えている。
ICE で扱う機能もあれば、非ICEな機能もあるように見えますね。


肝心のお値段は、

1ライセンス $149
50ライセンス $1999
無限ライセンス+ソースコード付き $4999

だそうですね。
わあ、なんだかすげえ売り方。 ソースコード付きってのは、ええと、改造できる人は改造していいってことなのかな? よくわかりません。 個別ライセンスは手が届く値段で良かったですね。 っていうか、個人でも買えてしまう値段なところが微妙ですね。高ければあきらめるのに・・・・・。 ともかく、全く保証なしのフリーウェアよりも、バグフィックスや継続的な開発をより望める有償ソフトウェアの方が流れとしては歓迎できますよね。こんだけ安いんだし。

全てのシミュレーションはプロットできると謳っているから、ライセンス1本だけ買って、シミュレーションして、プロットして、後は複数台のマシンでレンダリングするって出来そうに思えるんですが、どうでしょうかね。



しかしまあ。
Lagoa とか
Momentum とか
Slipstream とか
3DL とか
em シリーズとか
アーノルド君ももうすぐなのかな。こちらは高そうですが。

どうしたんでしょう?
XSI に追い風が吹いているんでしょうか?
おかしいなあ。
XSI なのになあ。



それにしても、この物理シミュレーションでリアルな動きを作りますとか、物理的に正しい超速グローバルイルミネーションでリアルなレンダリングしますとか、この流れはもう止められないですね。 

物理エンジン系、ライトシミュレータ系、モーションキャプチャ系・・・・これらは、例えばサンジゲンさんがやっているような超人為的フェイクでゴーゴー俺様が絵の全てを支配してるぜ系と対極にあるような気もするんですが、ここはひとつ対極という捉え方をしない方が良さそうですね。両方のいいとこ取りをできるようにならないといけないですね。モーションキャプチャのような現実から取って来たデータや、ソフトウェアのシミュレーション機能ばかりに頼っていては絵作りのできないCG屋になってしまうけど、だからといって何でもゼロから手で作り上げるのは現実的ではない場合の方が多いし、そこにある機能はどんどん使うべきでもある。 だから、俺様の力=ソフトウェアの機能 ではなく、 俺様の力=俺様の絵作り能力 だけでもなく、 俺様の力=俺様の絵作り能力+ソフトウェアの機能 と捉えてやっていくのが正しいというか、そうするしかないと言うか。 

嬉しいような、また宿題が増えてげっそりするような・・・・。

.

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

2011年3月 4日 (金)

Hierarchical Scaling。

Local Transform のプロパティの中にある Hierarchical Scaling って何に使うんだろうなーと思っていたんですがね。 あんまり使わないしまーいーや、とスルーしてたんですが。

どうやらスケーリングを親からどう引き継ぐかの挙動を決めているらしくて、他のソフトウェアからデータを持ってきた場合などで、その計算方式が違うと正しくスケーリングされない(シアーがかかってしまったり)するらしい。それを防ぐものらしい、としか思ってなかったんですが、今日その効能を実感しました。



Instance にマイナスのスケールを入れてシンメトリにしたかったのだが・・・・。

Hierarchicalscaling1

対称になってくれない・・・・(;Д;)

Model の下にキューブがあります。緑色のオブジェクトです。
その子供に、XSI男さんが二人います。 彼らは、それぞれ独自にローテーションされています。
この Model を Instance します。
左右対称にしたいので、Instance のスケールX を - 1 にします。

すると、左右対称になってくれるのは親であるキューブだけなんですね。子供である XSI男さんたちは、向きが対称状態になってくれません。

この時、二人の XSI男 の Hirerarchical Scaling はオンでした(デフォルトのまま)。



そこでこれをオフにすると、
Hierarchicalscaling2

ちゃんと対称状態になってくれますた。ヽ(・∀・ )ノ


子供が親からスケーリングを引き継ぐ時に、親の軸でスケールするのか自分の軸でスケールするのかを決めているようですね。 デフォルトのオンだと自分自身の軸でスケールされ、オフにすると親の軸でスケールされるようです。 今回のような Instance にまるごとスケールをかけて対称状態にしたい場合は、オフが望ましいということになりますね。 最初オンだった時は、XSI男さんたちは自分自身のローカルXでスケールされていたため、その場でXが反転していただけだったのですね。


ということを実証するために実験。
男さんたちのジオメトリをいじり、明白に左右対称を崩しておきます。

その上で、最初と同じく Hierarchical Scaling をオンにしてみると、
Hierarchicalscaling3

やっぱりね。 自分自身がその場でXスケール反転していただけでした。



今思えば過去に、Instance にマイナススケールを入れたら、元Model に含まれる子供のパーツの向きが  Instance 上でおかしくなってしまい、泣く泣く Instance をあきらめて普通に複製したことが何度かあります。 なんだあ、ここをいじれば良かったのかあ。 リグの都合とか無ければ、これで良さそうじゃないか。 早く言ってくださいよハゲ



いつからこのオプションが付いたのか知りませんが、ずっと昔から、ヘタすると ver1.0 からあったのかもしれません。 ノーマークでした Orz




.

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

2011年3月 3日 (木)

不毛な妄想を続ける。

不毛な妄想はまだ続いています。




ここを読むと、
http://area.autodesk.com/softimage2012


まず、2011 SAP の機能は普通に 2012 に入ったように見えますね。サブスクリプションユーザだけウマーな期間は半年で終わるわけですねハゲ

あれ? ICE FX Builder ってなんだっけ? 2011 SAP からの、ICE モジュールが付いてメニューから ICE ノード降臨ができるようになったという、アレのこと言っているのかな・・・? ノードの出し方に選択肢が増えたというだけなので、新機能的に言うのもどうかなあというか、そんなたいそうな名前を付けるほどのものでもないと言うかハゲ





Bone Primitive はビデオにも出てましたが、シェーディングができるようですね。 レンダリングはできるんだろうか? できるといいですね。 Length が Envelope に影響を与えることはできるようになったんだろうか? そういうオプションがないと片手落ちですハゲ





XSI Mailing List からの情報ですが、
https://groups.google.com/group/xsi_list/browse_frm/thread/4ecc9602659c0d23?hl=en
64bit のビューポートキャプチャで QuickTime が使えるそうですよ。 嬉しい人が多いのではないかな。  そういう俺は、キャプチャで QT を使う意義がよくわかってないので、そんなに嬉しくないです。 TARGA 連番とかじゃダメですかね?







それと、これも List で誰かが言っていたのですが、ICE モデリングって、オペレータスタックのフリーズに相当することってできるんでしょうかね? オペレータのインプットになるオブジェクトを自在に変えたり、パラメータを変えたりというプロシージャルなワークフローが ICE モデリングの真髄ではあるわけですが、結果生成されたジオメトリをフリーズするのは、どうやるんだろう。 ま、PointCloud も普通にフリーズくれてやれば動かないポイント群になるし、ICE のデフォーメーションも普通にフリーズで固着できたと思うので、やはり普通にフリーズすることになるんでしょうかね? でもそれだと、オブジェクトまるごとのフリーズになりますよね? ICE ツリーの中の、このノード以下のツリーだけフリーズとかってできないのかな。










Maya様の新機能 Editable Motion Trails http://area.autodesk.com/maya2012 に触発されてか、こんなプラグインを開発している方もいらっしゃいます。
http://vimeo.com/20538565
Fカーブに従ってビューポートに軌跡が描かれ、また、ビューポートの軌跡をいじるとFカーブも更新されるようにするそうですよ。 ほうほう。 いいですねこれ。 2012 のベータを使って開発してるんですね。

ビューポートに描かれている軌跡の線、こういうのが新機能の「インタラクティブツール SDK」 でできることなのかな。 ううむ、C++ 勉強したくなってくる。 でもまあ、こういうのって言語の文法だけ覚えてもダメで、アルゴリズムというか、やりたいことをベクターだのドットプロダクトだので表現する脳味噌が必要になると思うんですよね Orz


インタラクティブツール SDK については、もうちょっとだけ情報出てました。
http://xsisupport.wordpress.com/2011/03/02/a-little-more-about-the-interactive-tool-sdk/

画面上に独自のコントロール用のグラフィックを出し、ピックやドラッグもできて、マウスをオーバーするとハイライトしたりもするし、コンテクストメニューも出せるし、ボタンを付けたり、ツール内でのショートカットを定義したりもできる・・・・ という感じのようですね。

つまり、Tweak ツールとか言うんだっけ、現在でいうところの M キーを押した時の状態のようなツールを独自に作れると考えても良さそうですね。 M キー押すと独自のモードに入るじゃないですか。マウスをポリゴンやポイントなどコンポーネントの上にオーバーさせるとハイライトもされるじゃないですか。クリックもドラッグもできます。右クリックでコンテクストメニューも出ます。また、ボタンが3つ表示されるし、そのボタンを押した状態をトグルするための、ツール内でのみ有効なショートカットもあります。 まさにこういうことを、独自ツールでできるということですね。



上で出てきたのと同じスレッドですが、色々夢が語られています。
https://groups.google.com/group/xsi_list/browse_frm/thread/4ecc9602659c0d23?hl=en
TD さんたちが狂喜しているようです。あんなのもできるぜ、こんなの作るぜ、と妄想しているみたいです。 単純な例では、ブツの表面上に思い通りにスペキュラを配置するためのライトのマニピュレーション機能とか。  

アデランス
のようなスキャッタリングツールのインタラクティブ版とか作れないかな。 ICE と組み合わせてるとなお良し。


インタラクティブ SDK を使うためには OpenGL を知っていなければいけない
そうです。とは言え OpenGL の超ローレベル関数などを知っていなければいけないというわけではなく、ある程度便利に使えるよう整備してくれてるみたいです。詳しくは、上のリンクの中にもありますが、ここに書いてありました。 これは Softimage チームの人なのかな。 かつてエイリアススケッチを開発していたという人です。わあ、懐かしい。


C++ を知らなくても、JScript などからいじれるようにする方法はないかしら。
例えば、ちょうど XPOP のように、ポップアップメニューを描画する部分は C++ で書かれていても、その描画ルーチンに指示を出すためのカスタムコマンドがあればいいのかな。 誰かそういう汎用ツールを作ってくれないかしら。 俺の周りでそれができそうなのは、あの人とあの人と、それとあの人かな。何卒よろしくお願いします。





肝心の XSI の扱いの低さ についてですが、
http://area.autodesk.com/products
ここの序列を見ると、まあ去年と同じでないですかね? モーションビルダーよりは確実に下であり、やっと FBX と並ぶくらい。XSI より下の方はカテゴリが違うから、3DCGを直接扱う DCC ソフトウェアの中では、一番下ですね。 納得ですご主人様。 我々は所詮 XSI ですから。

ちなみに FBX ってデータコンバートツールですよね? つまり XSI はデータのコンバートにでも使ってやってくれという意味ですね?  承知しましたご主人様。 コンバートでも何でもやらせて頂きます。 



嘔吐デスク様トップページの左側の Product の中には、
http://usa.autodesk.com/
XSI の名前はありません。 当然です。

これはゲーム制作というタスクでフィルタしたページですが、
http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=14879449
XSI の名前はありません。 もちろんです。


この辺には名前が出てる。
http://usa.autodesk.com/media-entertainment/games/
http://usa.autodesk.com/media-entertainment/film/
もったいなきことです。


あっ。 XSI用にこんなものを用意して下さったのですか嘔吐デスク様っ
http://download.autodesk.com/us/softimage/2012topten/pc/project.html
実に畏れ多き事です。






・・・・ええと、2012 は4月11日出荷という話をフォーラムかメーリングリストで読んだ記憶があるような、無いような。 わかりません。 ただの電波かも知れません。 信じないで下さい。 ほんとに曖昧な記憶でしかないので。



早くいじらせろ嘔吐デスクこのハゲ



.

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

2011年3月 2日 (水)

不毛に想いを馳せる。

さあ、来ましたね。
今年も不毛な話、行きますよ。


まずはここのビデオ、全部見ましょう。
http://area.autodesk.com/blogs/marks/introducing_softimage_2012_with_ice_modeling
そんなにヘビーなビデオじゃないです。割とさらっと見れます。
ヘビーなビデオ見せて欲しかったぜこのハゲ



以下、同ページに載っている新機能リストから、気になった部分だけ抜いて書いてます。


●General

Scene Layer Manager - changes and highlights

    * Child layer now supported (can now parent in the Explorer as well)
    * Ability to create layers as children (or as separate layer)
    * New icon to quickly create a new layer

ビデオでもやってましたが、Child Layer ってのは、現在すでにある Layer の Group とは違うもんなんでしょうかね? あんまり変わってないような気がしちゃうのですが。
操作方法が便利になったようではあるけれど、概念として新しいのかはよくわからないよこのハゲ。


File Menu -Recent Scenes now respects non-project paths

    * A file D&D from say C:\Temp will now show C:\Temp in the recent scenes menu (instaed of the current project)

XSI の project フォルダ構造以下にある scenes 以外からドラッグ&ドロップでロードしたシーンも、Recent Scenes メニュー(最近つかったシーン)に反映されるとありますね。なるほど、良さそうですね。

でも相変わらずセーブする時は Scenes 以外にはセーブできないんでしょこのハゲ。



Explorer

    * Scene Layers can now be parented

これもビデオに出てましたが、エクスプローラ上でレイヤがドラッグ&ドロップで親子状態にできるみたいですね。
地味な新機能ですねこのハゲ。


Schematic

    * Expression in Resolution Plane of Chain now supported
    * New indicator for CustomOP and ScriptedOP
    * New Hotkey options for commands
    * Maya interaction mode can use "P" key and drag to parent

わっ スケマティックの更新は久しぶり? スケマティック Loveheart01 な俺としては歓迎します。

ただ、ビデオでもありましたが、イマイチよくわからんかった。 Expression in Resolution Plane of Chain now supported の意味がわからん。でもなんかすごく良い予感がする。

あと、カスタムオペレータ、スクリプトオペレータが仕込まれていることを現す文字が付いた、と。 従来で言うところのエクスプレッションの E やキーフレームアニメーションの A みたいなやつに、新たに2種類加わったということですね。

あと、今まであまり充実してなかったスケマティック操作のスクリプティングやショートカットキーなどが改善されたようです。これは期待! スクリプトからできることが増えると嬉しい! というか、今までスケマティックがらみのこと、スクリプトから何も出来ないに等しかったと思います。 並び替えとか自由な配置がスクリプトからできると、自作ツールの作り甲斐があります。

ところでシーンをロードするとよくスケマティックが壊れたりリセットされたりするのは直ってるのかよハゲ。




●Texturing

Texture Editor

    * New ability to "Pin" the selection in the texture editor for use with texture editor operators.
          o The pinned selection will not move when applying texture editor operators or commands
    * New icon to allow selection the pinned components
    * New Relax operator by Polygonal Design
    * New Regularize operator by Polygonal Design

やっと PIN が付いた! 部分的にロックして動かなくするというやつです。 ここだけはもう調整したから今のまま動かさず、それ以外の部分は全部 Relax とか、やりたかったんだよね。っていうか今どき UV ツールにはこれ基本でしょう? 今さらやっとかよハゲ。

ビデオでもやってましたが、新しい Relax がどういうものなのか、よくわかりませんでしたハゲ。

Regularize ってのは、ビデオによると、元のジオメトリのポリゴンの大きさを考慮に入れた Relax のようなもの、という感じがします。Relax は UV 上でのみ考慮された平均化であるのに対し、Regularize は大きいポリゴンには大きい UV 面積を与え、小さいポリゴンには小さく与えることによって、テクスチャの歪みを最小限に抑えるということじゃないですかね。 元のジオメトリがほぼ同じ大きさのポリゴンだけで構成されている場合はあまり関係ないけど、大きさが極端に違うポリゴンが隣り合うようなジオメトリの場合、UV 上の2D面積を同じにしてしまうと、いわばチェッカー模様があるポリゴンを境に急激に大きくなったり小さくなったりするわけで、それを避けているのではないかと思います。違うかな。そうだとしたら、かなり良いと思う。

単独 UV ソフトウェアによくあるような、UV の歪み具合(ストレッチ度合い)を色で表現する機能はまだですかハゲ。  

っていうか、ビューポート上でのモデリングツール(デフォーメーションツール)を全て UV にも効くようにして欲しいですよね。2D的に、ということにはなるけれど。UV にラティスとか欲しいじゃないですか。操作も完全に統一してほしいし。どうなの嘔吐デスクさんハゲ。

UV を元に、ジオメトリの複製を実際に3Dビューポート上で開きにして、通常のモデリングツールでその開きポリゴンオブジェクトをいじくって、その結果を UV に戻す、なんていうツールは作れませんか。 背の大きいあなた、作れませんか。 きっとできますよ。



●Animation

Play Control

    *   New 'Stop' icon in the Play Control
    *   For heavy scene this will not speed up exiting the evaluation - but it will stop any toggling of the play button

再生ストップボタンが搭載されますた! ( ^∀^)ゲラゲラ
ええと、たぶんこれは、今までは重いシミュレーションを再生すると永遠に返って来ないこともあったけど、このボタンがあれば、即座にではないけれど、その計算が終われば、必ず返って来ます、って意味じゃないでしょうかね?

あたりめえだろがハゲ
今までそうなってなかったのかよヴォケ




Consistent FCurve Editor

    *   Common Icons across Softimage, Maya, 3ds Max, MotionBuilder
    *   Isolate Selection
    *   Suites mode and Classic Mode

なにやら Maya様や Max様や MB様のFカーブエディタと同じアイコンを使わせて頂けるだそうで。へえ、あっしら XSI ごときに、何とももったいなきことにございます。

ビデオにありましたが、あまり見た目は大きく変わらないような気がしました。アイコンの配置やデザインが多少違うというだけに見えます。でも、どうやらハンドルの長さや傾きを入力するボックスが無いように見えるな。Maya様や Max様には必要ないものなのかな・・・。俺はよく使うんですが。 ま、従来のFカーブエディタのモード(クラシックモード)もちゃんと用意されているので、きっと俺はそっちを使います。あーーー良かった。Fカーブエディタが変な風に変わってたらカダフィさんに頼んで嘔吐デスクにミサイルをブチ込んでもらうところでしたよこのハゲ

そしてFカーブの Isolate ができる! これはスヴァらしい。 現在選択中のカーブ以外を一時的に見えなくできるんですね。 これ欲しかった。

今までも選択したパラメータのみを表示するモードはありましたけど、左側の Explorer を使わざるを得ない作りで、不便でした。ほぼ使いませんでした。

ところでFカーブエディタ周りもスクリプティング環境の整備が遅れてきた分野ですが、それについては触れられてませんね。ってことはこのバージョンでは変わらないのでしょうねハゲ



●ICE

ICE modeling

わーすごいすごい。 はいはい、すごいすごい。

いや、ほんとにすごいと思いますよマジで。でもあまりにもディープなエリアだと思うので、今は軽くビデオ見ただけでスルーしてます。 避けていると言われても仕方ない・・・ Orz

しかしこれはまずいですね。本気で ICE やらないとまずい。 パーティクル、デフォーメーション、キネマティクスに続き、トポロジの生成まで ICE の波がやって来ましたよ。もうなんでもかんでも ICE です。俺、ツブツブを飛ばしてタービュライズで乱すとか、その程度で止まってます。まずいまずい。なんとかせねば。 ICE が全てに置き換わることはないと思うけど、知っておかないと他と仕事ができなくなるような、そんな日が来ますよこれは。 なんでもかんでも ICE。朝から晩まで ICE。いずれ俺が普段やっている通常のスクリプティングも ICE になるでしょう。もとから ICE ってそういうものだし。

このスレッド↓を見ても、ほんとそう思います。
https://groups.google.com/forum/#!topic/xsi_list/nmus1TnkON8/discussion
ICE をこんな変なことに使ってるぜー 的なスレッドです。
やがてメシを食うのも風呂入るのもビールを呑むのも、ICE 化されるでしょう。


Cloth

    * Syflex Cloth now uses ICE
    * The Syflex legacy toolbar remains for backwards compatitibilty

財布レックスが ICE 化されたそうで。ほうほう。俺実は、財布レックスって一度も使ったことありません Orz

サイフレックスって最強の Cloth ツールなんでしょう? でも布なんて、普段の仕事で滅多に出てこないんですよ俺は。 あったとしても、トラディショナルな昔からの Cloth でやってしまう。それすら、結局ボーンの SRT に変換してしまって最後には手付け。 ダメですねえ古い人間は。

しかし、サイフレックスのこの↓画像。
http://usa.autodesk.com/adsk/servlet/limage?siteID=123112&imageID=16477384&id=16111495
ちょっとあなた! 違いますよ! 俺が作った画像じゃないですよ!
なんだかエロいですね。 普段の XSI 男くんは衣服無しのマッパーなわけですが、当然見慣れているからマッパーでもエロく感じません。 しかし上半身にTシャツを着せただけで、急に下半身の着衣無しが気になり始めます。 実にエロいです(;´Д`) ビデオの中でも、パラメータいじって服がズルっとユルくなって肩がはだけ、乳首があらわになったりしてます。 ヤヴァいです(;´Д`)

ビデオの中で、逆さ吊りの責めに遭っている犬もラヴリィですね。Volume のパラメータを上げてパンパンに膨れてます。チニーさん爆笑してます。 でもこれ、何かに使えるよなあ。 なんだかサイフレックス、いかにも「安直に」何かに使えそうに見えるんだよな。 いじってみるしかないなあ。 どんどん宿題増えるよハゲ


SubFrame Sampling

    * When creating new simulations a new "Simulation Settings" property is created. Used for more accurate collisions and fast moving emitters.

サブフレームが ICE のシステムレベルでサポートされたということですかね。 フィリップさんがやっていたこの辺のことが、パラメータ一発でできるようになったと考えてもいいんでしょうかね? シーンのフレームレートを上げる必要もなくなるのかな。でも結局はフレームレート上げることになる気がするよこのハゲ


  *New compounds

またいっぱいコンパウンドが追加されたようですが、あまりにも多いのでスルーしますよハゲ  ま、今回の ICE Modeling がらみでトポロジをいじくる関係のやつが大半のように見えますね。あとは上記のサイフレックスか。


あー、あと、フラクチャリングっていうの? ビデオにあった、ボロノイ分割みたいなやつ、気になりますね。ビデオ見ただけでは、実際にどう使えるのかイマイチわかりませんでした。Momentum あたりと組み合わせて、ICE 標準機能で分割して、Momentum で飛ばすとかできないですかね?




●SDK

ヤヴァい。 SDK まわりはすんげえパワーアップしたように見える・・・! いっぱいあるので気になったとこだけ・・・。

    * PPGLayout.SetViewSize , SetViewPosition, ViewSize, GetViewPosition New API for OM and C++

PPG のウインドウのサイズ、ポジションを取得あるいは設定できるようになりますた。夢がかないますた( ;∀;) 

要は、スクリプトから自作 PPG のサイズや出現位置をコントロールできるってことですよね・・? 今まではですね、標準の縦長の PPG に上手く収まるように、PPGLayout の呪文を駆使して苦労してインターフェース作ってきたわけですよ。友愛シリーズもその一環です。タテの大きさは Preference にもよるけど基本的には PPG の内容に合わせて自動でリサイズされてたわけですが、横サイズはデフォルトのままか、最後に手でリサイズしたサイズを記憶しやがってるので以降それになってたわけですね。 でも今度から自分で決めれるのですよね? 嬉しいです( ;∀;) つまり、たとえ手でリサイズされた PPG があったとしても、次に自作ツールの PPG が出現する時には初期化されたサイズにすることもできるはずだし、超横長な変態 PPG も作れるということですよ。 これは大きい。

  * Allows setting and getting the size of a Modal Property Inspector

モーダル PPG のサイズまで変更可能! 夢がかないますた( ;∀;)
今まで、モーダル PPG は、非モーダルのような最後のサイズを覚えてることも PPG の内容によってタテが自動でリサイズされることもなく、XSI 様が勝手にお決めになられた唯一のサイズでしか表示できなかったんです。やっと、やっとモーダル PPG も人並みになれました。

っていうかなんでこの辺今まで出来なかったんだよ。そのために今までどんだけ工夫したと思ってんだよ おかげで UI 系のスクリプティングすげえ覚えちゃったじゃねえかよハゲ

  *New C++/OM API for manipulating schematic view and schematic nodes.

これはさっきの、スケマティックがらみのことがスクリプトで色々できるようになりましたぜ、ってことですよね。えへへへ。


  * New Anchor points (View, View Context, Node Context)

よし、アンカーポイントどんどん増やせ。っていうか全部付けろ。 要はインターフェース上のメニューに自作ツールをぶち込める箇所が増えたということです。


  *Get/PutChecked methods to MenuItem object to support checkmarks

おおっ XPOP3 のごとく、メニューアイテムにチェックボックスを付加する機能が付いたようです。これは便利なはずだ。


  * Application.OpenUndo: Open undo complex.
  * Application.EndUndo: Close undo complex.
  * Application.IsUndoing: Returns true if some command is undoing or redoing.

この辺の意味がわかりません。アンドゥの制御が可能? 自作スクリプトで、アンドゥした時に、どっからどこまでのブロックがアンドゥされるとか指定できるという意味かな? OM じゃなくてコマンドを書いていても、1コマンドずつアンドゥじゃなくて自分で指定したブロックでアンドゥになるという意味かな? だとしたらすんげえ嬉しいが。違うかな。わからん。



Interactive Tool SDK

    * C++ API for building plugin tools that can be used in 3D views
    * plugin tool examples in examples workgroup
    * Tool Wizard in the Plugin Manager
    * New Math classes CLine and CPlane (used by the Tool SDK)

この「インタラクディブツールSDK」とは・・・? なにやら、自作の3Dオブジェクト(ビューポートに表示され、レンダリングはされない、独自の、何らかのコントロール用オブジェクト)が作れると言っている気がするんだが、違いますかね?

どのみち C++ の API のようだ。JScript で書けないと俺はできませんよハゲ


●Data Management

よくわからんのでパスハゲ


●Rendering

Mental Ray 3.9

    * Unified Sampling is an alternative method for aliasing

アンチエイリアスに新しい方法が追加されたということでしょうかね?


  * Vector Displacement Maps

これ、ビデオにありましたが、すげえですね。耳のない XSI 男に、耳がディスプレイスメントで生えてくる! 気持ちわりい!  要は、従来のディスプレイスメントマップは法線方向にしかジオメトリを持ち上げてくれなかったけど、その方向をマップで自在に制御できるという意味のはずです。Ben さんのプラグインでもあったしな。技術的にはさほど新しくないことだと思うんだけど、ようやく実用レベルで実装されたということかしら?

にしてもビデオを見ると、なんだか意味不明の怪しいマップから耳が出来ています。完成形を想像しながらこのマップを手で描くのは無理なんではないか? ビデオの耳のマップは Mudbox から持ってきたとのことです。つまり、通常のモデリングなりスカルプトなりでまずは立体を作り、そこからそれ用のツールを使ってベクターディスプレイスメント用のマップを書き出し、それを使ってベクターディスプレイスメントするというのが、現実的なワークフローになるのでしょう。ノーマルマップに似た工程になるのかな。

ただ、そのマップを書き出すためのツール(ノーマルマップで言うところの Ultimapper 的な)が XSI に搭載されているのかどうかはわかりませんでした。Mudbox などその機能を持ったソフトウェアから書き出したマップをレンダリングするための RenderTreeノードが付きました、ってだけの意味かもしれません。


っていうかおい、iray はどうなったんだよハゲ。
ずっと前に無償提供約束したじゃねえかよ。
この嘘つきがハゲ。




●Crosswalk
ひとまずスルーハゲ
ひたすら入出力を便利にしようとしているように見えますね

あ、ひとつだけ。

  *Import .3ds, *.dxf, *obj, *.dae formats                         

3DS って標準で読めるの? 前にもう辞めたのかと思ってたよ。


●Suites and Interop

    * A new Suites mode for the FCurve Editor
    * Single Step interop for Mudbox
    * Single Step interop for 3ds Max
    * Single Step interop for Maya - Updated
          o You can now start in Softimage

Maya様 Max様など、他のソフトウェア様とのやりとりがしやすくなったということですよね。へえ、あっしらは旦那様方のプラグインですので、部分部分で便利に使ってやって下さればそれで満足でやす。もったいないことでございやす。へえ。ハゲ


●Documetation

    * Moving to Web-based help

げっ、これまでのあの使いやすいヘルプを、変えると言うのかこのハゲ

まあ、タブで複数ページを開くのとかできなかったから不便でもあったけど、インクリメンタルなキーワード検索とか、同期ボタンとか、快適すぎるんですよ。超軽いし。特に SDK ガイドの操作感は、麻薬です。

HTML になると、リンク関係はまあ問題ないとして、このサーチの便利さやナビゲーションの軽さは保たれるんでしょうかね? ここ、失いたくないなあ。毎日読むものですからね。 画像なんかは、現在の縮小されてエイリアシングしているふざけた画像よりは良くなる気がします。

従来バージョンのヘルプも付いてくる、ってわけにはいかないですかハゲ








なんとなく、


 ・とにかく今後はなんでも ICEで行きましょう

 ・Maya様や Max様の下僕として、ご迷惑をかけぬよう、データのやりとりでご面倒な思いをさせぬよう、入出力を整えましょう。
操作も Maya様 Max様のユーザ様を戸惑わせぬよう、ちゃんと統一しましょう

 ・メンタル霊はあまりやる気なし。アーノルド君も出て来そうだし。あとはシラネ



な感じのバージョンアップに見えるのですが、どうでしょう?

毎年のように、現在 XSI Base などでは wow! とか really great version! みたいなお祭りになってます。そしてリリース後1ヶ月もすると、 Autodesk should not have released this piece of crap とか Mental ray still crashes on XXX とかそういう呪詛の言葉で埋め尽くされるのです。季節の風物詩なので、生温かく見守ります。とか言って、俺もこんな鬱屈した形でそのお祭りに参加してるんですがねこのハゲ




まだ出てもいないソフトウェアなのに。
出たら一目瞭然でわかることなのに。
ごちゃごちゃと、不毛な時間を使っています。
年に1回の通過儀礼とは言え、
やはり不毛です。

ハゲ。

| | コメント (12) | トラックバック (1)

2011年3月 1日 (火)

養子に出す。

繰り返しの多い、煩雑な作業の日々です。
つまりスクリプト大量発生の危機です。





//    1個だけ選ばれていて、かつ 3D オブジェクトじゃないと受け付けないのである

if ( Selection.count == 1 && Selection(0).IsClassOf( siX3DObjectID ) )
{
    var oObj = Selection(0);    //    複製元のオブジェクトである
    var oChildren = oObj.FindChildren( );    //    そのガキを保存しておくのである

    var oDup = SIDuplicate( oObj ) (0);    //    複製実行である
    var oDupChildren = oDup.FindChildren( );    //    複製した方のガキも保存するのである

    var oModel = ActiveSceneRoot.AddModel( );    //    シーンルートに Model が降臨するのである
    oModel.name = oObj.name + "_model";        //    Model に名前を付けるのである
    oModel.AddChild( oDup );            //    複製されたブツは Model の子供になるのである

    //    リネーム実行である。  すでに新しい Model の子供になっているから、同じ名前が付けられるのである
    //    複製したゆえに内部的な親子番号は新旧で一致しているのであるからして安心してfor loop の番号でリネームできるのである
    oDup.name = oObj.name;    //    複製されたブツの名前を元の名前に一致させるのである
    for ( var i=0; i<oDupChildren.count; i++ )
    {
        oDupChildren(i).name = oChildren(i).name;    //    ガキの名前も元の名前に一致させるのである
    }

    SelectObj( oModel, "Branch" );    //    ブランチ選択状態にするのである
}//    終わるのであるニダ。




選んでいるブツを複製し、新しい Model の子供にし、複製元と同じ名前にリネームするというスクリプトです。
新しい Model の子供になるということは、新しい名字のもとで、同じ名前で居られるということです。養子に出す、あるいは嫁にくれてやるようなものです。XSI の世界に夫婦別姓などというものはありません。同じ家族(Model)になってしまったら、名字(Model名)は必ず一緒です。その代わり、その名字の元で、別家族(別Model)に存在する人と同じ名前のまま居ることが可能なわけですね。

ノード単体で選べば単体複製、ブランチ選択とかしていれば階層ごと複製されます。



同じパーツを色んな部分で繰り返し利用したい。 若干変えなければいけない部分もあり Instance にはできない。だから普通に複製する。複製されたブツの名前はケツに数値が付いたものになる。1ノードだけならまあいいが、階層丸ごと複製したい。そうなると複製されたブツを全部リネームしてやるのが実にめんどくさい。 シーンの構造上、どのみち別 Model にすることはわかっている。別 Model なら同じ名前が存在できるから、名前が変わらないままだといいのに、複製した瞬間は同じ Model にぶら下がっているから強制的に名前を変えられてしまう。 Duplicate Options で階層を none にしてもどうやら複製してから親子を切り離すようで、やはりケツに数値が付いた名前になってしまう。 泣きながらリネームする。


ということを数週間も繰り返してとうとうモニタが2個水没したので、スクリプト書きました。まったく、いつもこうなんだから。早く書けよ俺。モニタがもったいねえだろ。







スクリプティング的には特筆すべきことは何もないですかね。 手でやる作業をほぼそのまんまリニアに羅列しただけですね。 無理やり少し書いておくと・・・、

ガキをゲットするのには FindChildren の呪文を唱えています。オプションを何も指定していない(カッコの中が空っぽ)ので、無条件に階層の中にいるブツが全部取得されます。 そいつらを複製後にリネームしているだけです。

ノード選択で1個しか選択してなかった場合は、oDup には1つのブツしか入りません(ガキは複製されない)。 これは SIDuplicate コマンドの元からの挙動です。 そしてその後のリネームループは oDup のガキの数( oDupChildren.count )で発生するループにしてあるので、ガキがいなければそもそも発生しないループです。 結果、ブランチで選択してれば複製後の階層にガキがいるのでリネームループが発生し、ノード選択ならガキがいないからループが発生せずにスルーされるという挙動になります。 いちいちガキの存在の有無をチェックするコードを書く必要がないのでラクです。なるべくこういう構造になるように普段から気にしたり、あるいは気にしなかったりします。


また、スクリプト中のコメントにあるように、複製すると、Creation Order とか言うんだっけ、内部的な番号もそのまま複製されるようなので、ループの中で同じインデックス値のものは、確実に新旧一致します。たぶん。 ラクです。

「複製された時には、内部番号は変わりません」とかなんとか、そういうことは SDK ガイドには書いてません。 普通書いてないですわな。 この辺は実際にスクリプト書いて実行してみて、その挙動から判断しています。 今回の場合は、何も考えず複製後にループ処理でリネームしてみて、新旧で名前の一致するオブジェクトを目で見て比べたらちゃんと同じブツだということが判ったので、あー 複製したら内部番号も変わらないんだなー と判断したということです。 何でもマニュアルに書いてあるわけじゃないので、こうやって実地で挙動を把握していきます。マニュアルに書いてあることでさえ、マニュアルをひっくり返すのがめんどくさい時は、挙動だけを見て あー こうなんだなー とアタリを付けて書き進めてしまうことも多いです。 上手く行ったと思っていると思わぬ落とし穴にハマることも多いんですが(その書き方だと特定のタイプのブツには効かなかったぜゴルァとか)、まあそうなったらその時初めてマニュアル開けばいいんです。



オブジェクト1個しか選べなくしたのは、めんどくさいからです。 複数選んでいるとき、普通にループ処理で複製させると、あるブツが処理対象に入っている別のブツの子供だった時に起こるダブりを回避せねばならないので、それがめんどくさかったわけです。 Expand 使えばダブり状態も自動で回避できるんだっけ? 全然違う? 忘れました。どーでもいいことは忘れます。日々のスクリプト書きではすぐに使い始められることが最優先なので、モニタを壊さなくて済む程度の利便性さえあれば細かいことは気にしません。複数選択に対応させる意味があるか?と考えると、俺の作業的には必須ではなかったので、そうなりゃ1個しか対応してませんよーにしちゃった方が遥かにスクリプティングがラクになります。

あ、ブランチ選択は複数選択ではないので(ブランチ状態で1個選択されているという状態ならば)、大丈夫です。




ごきげんよう。


.

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

« 2011年2月 | トップページ | 2011年4月 »