« 2011年5月 | トップページ | 2011年7月 »

2011年6月

2011年6月23日 (木)

XSI男Tシャツ 第2次募集開始。

以前、東日本大震災で被災した福島県の人々への復興支援として XSI男Tシャツを作って寄付金を募ったんですが、その後、あのTシャツを欲しいと言って下さる方がちらほらいらっしゃいましてね。

Pff1

で、Tシャツ作成サービスのアートスペースさんに確認してみたら、版は3ヶ月無料保存なので、今なら前回作った版が残っている。つまり新たに製版代はかからないので比較的安上がりにできる。 で、仮に10枚注文したとすると、Tシャツ代やプリント代や送料など含めて、おおよそ 12,000円くらいのコストがかかることがわかりました。 1枚あたりのコストは 1,200円ということになりますね。 前回と同じ 3,500円で販売すれば、1枚につき 2,300円くらいの寄付ができるので、10枚分だと 23,000円くらいの寄付ができる。  大きい金額ではないものの、全然OKじゃないですか。



ってことで、もう1回募集することにしました。
募集要項は前回と全く同じ。
http://junkithejunkie.cocolog-nifty.com/blog/2011/04/xsi-c76a.html
これを参照して下さい。
ご注文お待ちしております。



流れをざっくりまとめると、

1. junki へ注文メールを送る (*)
2. junki から返信(振込先のお知らせなど)
3. お金の振込み(*)
4. junki が振込みによる入金を個別に確認
5. 締め切り後、合計枚数を junki が(有)アートスペースへ発注
6. アートスペースから junki に納品
7. junki から注文者へ発送


1.のメールに、サイズや色や名前や住所などを明記して頂きます。
この注文メールの締め切りは2011年7月3日とします。

3.のお金の振り込み期限は、2011年7月5日とします。

7.の最終納品は、8月に入ると思われます。 今、Tシャツ屋さんは混んでいるそうです。正確な日程は出ませんのでご了承下さいませ。


価格は前回と同じ、1枚 3,500円です。 送料は実費で1枚 80円です。

全売上金のうち、Tシャツ作製コストを差し引いた残りを、福島県災害対策本部に寄付します。






このプロジェクトがどういう経緯で進んできたのかは、以下の記事を順に読めばわかると思います。まあ、読まなくても全然いいですけど。


浪江に思いを馳せる
http://junkithejunkie.cocolog-nifty.com/blog/2011/03/post-f172.html

XSI男Tシャツを思いつく

http://junkithejunkie.cocolog-nifty.com/blog/2011/03/xsi-df72.html

途中経過 Tシャツ屋を決めたり
http://junkithejunkie.cocolog-nifty.com/blog/2011/03/xsi-3a87.html

途中経過 発送方法を調べたり
http://junkithejunkie.cocolog-nifty.com/blog/2011/03/post-8647.html

正式受付開始
http://junkithejunkie.cocolog-nifty.com/blog/2011/04/xsi-c76a.html

正式受付終了 しかし延長
http://junkithejunkie.cocolog-nifty.com/blog/2011/04/xsi-46da.html

XSI男Tシャツが届く
http://junkithejunkie.cocolog-nifty.com/blog/2011/04/xsit-ac19.html

XSI男Tシャツを皆さんに発送する
http://junkithejunkie.cocolog-nifty.com/blog/2011/05/xsit-3fb3.html

寄付実行 会計報告 XSI男Tシャツプロジェクト完結
http://junkithejunkie.cocolog-nifty.com/blog/2011/06/post-ac03.html





今回は、10枚を目標とします。10枚に満たなくてもまあ、やりますけど。
10枚に満たなかったら、未練がましく募集を延長する可能性もあります。
期限などはどうかユルく見てやって下さい。




前回購入しそびれたあなた、これが最後のチャンスかもしれませんよ。
前回購入してくれたあなた、もう1色いかがですか。
会社を経営しているあなた、今年の夏のボーナスはこのTシャツ現物支給なんてどうですか。社員が喜びますよ。

Pff2
.

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

2011年6月19日 (日)

撮影台。

なんだか意味はわかりません。 わかりませんが、XSI Base にこんなスレッドが上がっていました。
http://www.xsibase.com/forum/index.php?board=1;action=display;threadid=45138

ディスニーのマルチプレーンカメラ台の話と、メンタル霊への不満がどう関係あるのか、俺はよくわかりません。



でもそのリンク先のビデオが面白かった。 そんだけ。 直リンクしておきますhttp://wimp.com/multiplanecamera/

ディズニーによる、アニメ撮影で使うマルチプレーン撮影台の説明ビデオですね。 たぶんずいぶん昔に作られたビデオなんでしょうね。誰向けなのだろう。明らかに素人向け・一般向けの説明なので、アニメの舞台裏的なTV番組用とかだろうか。

内容は特に新しいものでもなんでもない、いわゆるアニメ撮影台の説明映像です。アニメの撮影野郎であれば当然知っているであろう内容だし、撮影野郎じゃなくても知っている人は多いでしょう。 ただしこのビデオはマルチプレーンな撮影台の説明ですね。マルチプレーンじゃない撮影台に対し、マルチプレーンだとこういうことができますという解説をしています。

おそらくはすいぶん昔に作られたこのビデオ、説明のための図解動画すらも全て手描きらしき絵図ですね。おそらくこの撮影台で撮影してフィルムにしたのでしょうね。 今ならCGでサッと出来そうなものですが、手でこれを作るのは大変ですよ。 しかも非常に分かり易くて、見ていて爽快でした。 あー面白かったというだけの話です。はい。





にしても、ええと、現在2011年ですね。 ってことは、今どきの若いアニメ撮影野郎だと、もしかして撮影台のことを知らなかったりするのかしら。  いや、一般教養として話を聞いたことくらいはあるはずですね。 でも、感覚として理解しがたいものになっているかも知れません。 今やほぼ100% AfterEffects とかでやっちまいますからね。 レイヤ重ねたい放題です。 撮影の部屋を2階の天井までぶち抜く必要もありません。 セルに埃も付きません。 マガジン換えたりもしません。 考えてみればすげえ時代なんですね。 俺はアニメ撮影野郎ではありませんがCG屋なのでエフェクト的なことをしなければいけないことも多いわけでして、それで言うと、ビームとかグロウみたいなエフェクトは昔、オプティカルプリンタで多重露光してやっていたわけですよね? スターウォーズのライトセイバーもそうやって作ったんですよね?  知識としては知っていても、あまりピンと来ません。 イマジカのエントランスでへぇ~と見るだけ。


しかし、いかに撮影台が無くなろうと、もうしばらくの間は撮影台の伝統がアニメ撮影に影響を及ぼし続けるのではないでしょうかね。 フィルムでアニメを作っていた時代の監督や演出の人々が、まだまだ現役ですからね。 いまだに背景の引き幅をミリで指定してますもんね。 マルチボケとかいう言葉も使いますよね?  密着引きとかなんとか。 俺は撮影野郎じゃないからあまり詳しくないのですがね。


あと10年か15年もしたら、フィルム時代の人は完全に引退してしまい、撮影台っぽいコトバやワークフローも無くなっていくのかな、と思います。ま、デジタル撮影に引き継がれて定着したコトバも多いので、完全には無くならないでしょうけど。


今、20歳やそこらで作画や制作進行をやっているような子が今後演出をやり始めるようになると、引き幅なんかはピクセル指定になるんでしょうかねえ? でも最終的な解像度が変わるとピクセルもあまり意味がなくなるような気がする。 パーセントが良いのかな? まあ、数値じゃなくて絵で引き幅が描かれていればそれでいいと言えばいいのか。  

あるいは、引き幅なんかは演出が数値で特に指示を入れなくても、撮影の判断で幅を決めていいことにしちゃダメですかね? リテイク増えますかね? っていうかもう既にそうなってるかな? カットによるか?   演出的にすごく意味がある時は 「通常よりかなり速め」 みたいな指示が入るといいと思うんだけど、普通のフォローなんかでは、撮影が主体的に引き速度を決めた方がいいのではないか、という気もするんですよね。 なんか、カットごとにいちいちミリで指定されて、それをピクセルに換算するツールまで作って忠実に演出の言う通りの引き幅を再現することに、ある種の空虚さを感じるのは俺だけですかね。  まあ、俺は専門家じゃないし当事者でもないので、かなり勝手で頓珍漢なこと言っているかも知れません。



撮影にも色んな人がいるでしょうが、引き速度とか画ブレみたいな、いわば「画面の動き」に燃えている人はあまり見ない気がするんですよね。 基本は演出様の指示に従順に従う姿勢が強いように見える。 打ち合わせでも、どっちかというと「じゃ、L/Oにミリ指示入れておいて下さい」 みたいに言うことが多い印象がある。  

エフェクトとか、レイヤの重ね方(合成の仕方)とか、入射光なりフレアなりパラなりケラレなり、そういう方向の「絵作り」 = つまり必ずしも時間軸を伴わない1枚の絵の「見た目」には、主体的にやろうとする人が多いと言うか、すごくこだわる人が多いように見えます。 まあ、時間軸云々は関係ないか。 なんて言えばいいのかな。 「タイミング萌え」「動き萌え」ではなく、「エフェクト萌え」「合成萌え」 に突き動かされているというか。  「コンポジットで絵を作るぜ!!」 「あんなシンプルな、2階調か3階調しかないセル画が、ほらこんなリッチな画面になったぜ!」 「それが撮影のイリュージョンだぜイエイ!!」 という気概ですかね。うん、これははこれでスヴァらしいのですが。 


上で言った 「画面の動き」 につながるような方向の話、例えば 「この引き幅はベテランの俺じゃなきゃ一発で出せないぜ!」 とか 「魂のこもったこの画ブレを見よ!!」 とか 「このクイックPAN、動き出しのほんの数コマのツメがこだわりなんだけどなあ、わかるかなあ~」 という撮影野郎は少ない。 っていうか俺はほとんど見たことない。 


撮影野郎もある意味でアニメータじゃなきゃいけない、って俺は昔から思っているんですが、どうですか。 だってカメラワークとかガンガンやるわけでしょ。 エフェクトだって動きのあるエフェクトが多いわけで、AfterEffects のエフェクトのスライダいじってるだけじゃダメですよね。タイミングとFカーブで勝負しなければならない場面も多いですよね。臨場感出すために気持ちの入った動きを付けなければならない場面とか多いですよね。 せっかく素材がカッコ良くても、撮影野郎も動きにこだわってくれないと最終的に良いカットにならない場合が多いと思うのです。平板で残念なタイミングのエフェクト、クイックの意味を誤解しているかのような残念なPANやTB、画面が実に機械的に動く残念な画ブレ、おそらくなんとなくやっているだけでリアルな状態を観察したことすら無いのではないかと思わせるいかにも後付けくさい残念な手持ちカメラ風手ブレなど。 画面全体に効果が及ぶ類のことですから、イッキに画面全体が残念になります。 モニタワークも撮影野郎の役割になることが多いと思うのですが、やはり同じだと思います。 グロウっぷりとか色の調整とかだけにこだわるのではなくて、表示物の発生のタイミングや、刻々と変わり続けるモニタリング中の数値やグラフの動きのランダ ム具合、スクロールする文字のカクカク加減など、もっとペキペキに動きにこだわってくれると、断然カッコ良くなるはず。例えば3つくらい並んだ棒グラフっぽい表示が、おそらくは何かの状態をモニタリングしていて刻々とグラフの長さが変わるわけだけど、なーんとなくランダムに動かしているだけのものが多いじゃないですか。いかにもウソくさくて臨場感を大いに殺ぎますよね。オモチャに見えてしまう。緊迫した戦闘シーンとかだと、非常にいけません。これひとつでシーンを台無しにしてしまいます。ウソはウソでいいから、もっとウソに見えない、つまり「それっぽい」動きにしなくてはいけません。どんなにリッチなデザインのグラフでも、動きがオモチャだと、一瞬でオモチャになるわけです。例えばだけど、ビデオカメラを手持ちして歩きながら前方を撮り、ある点をトラッキングして、そのYポジションをモニタのグラフの動きにエクスプレッションでつなぐとかってどうですかね。計器らしいランダムな動きをそれっぽくするための手がかりになりそうな気がします。手持ちカメラの手ブレもビデオ撮ってトラッキングして、そこからなんらかのデータを拾うことができそうですよね。 それっぽい状態を目をつぶってでもできるようになるまでは、こういう実験もあるといいんじゃないかなあ。やってる人はやってると思うけど。 ともかく撮影さん、レイヤ重ねてエフェクトいっぱいかましてリッチな画面にするだけでなく、動きとかそっちの方向にもどうか心を開いて下さい。お願いします。 誰に何をお願いしているんだ俺は。


っていうか、撮影野郎の中でも、コンポジット重視野郎と動き重視野郎の2つの潮流が出来てもいいんじゃないかなんて思います。 みんながみんな合成が上手いわけじゃないし、みんながみんな動きが上手いわけでもない。 動きが好きで、動きが上手い人だけが、動きを極める傾向をどんどん磨いていけばよい。 でもまあ、最低限レベルの動き作りは全員ができないとダメか。日常業務で出てきますからね。ということで新人くん、避けて通れないからまず画ブレの練習行きましょう。 ほらそこ、機械的に上下上下上下上下上下上下とかやっちゃダメです。 パターンもずらして、上下だけでなく左右の揺れも当然入れましょう。 デジタルなんだから、1ピクセルたりとも左右に動かしてない絵は、1ピクセルたりとも左右に動かない絵に見えてしまうんですよ。そんな画ブレはいけません。だってそんな風にカメラは揺れないでしょ。 しかも、左右方向の揺れは特大画ブレの時のためにとっておくとか、そんな馬鹿なこと言っちゃいけません。人間様の作業の都合じゃないですかそれ。特大じゃないと左右には揺れないって、どんな揺れですか。   意識としては、画像をタテヨコに動かすという感じではなく、カメラが何者かに揺らされているという「受動」の意識でやりましょう。 パターンずらしも、ただのランダムではいけません。多くの場合は、少し傾向のあるランダムが良いのですが、まあそこは探って下さい。法則として知ってしまうとやはり魂が抜けると思います。画ブレというのはいわば「揺らぎの画面効果」ですので、法則を見出すのではなく、「感覚」や「センス」などという目には見えないものに頼ってもいいと思います。その方が魂が宿る気がするのです。 「感覚」や「センス」は、趣味ではないプロダクションワークの普段のCG作業では避けますよね。想像力もしくは伝達能力の低いDがよく言い訳に使うような、基本的にはいかがわしいものなわけですが、画ブレにはこれに頼る部分を残しておきたいです。説明しようがない部分もあるし、説明してしまうと説明した側もされた側も腑抜けになりそうなんだもん。  別にリアルな画ブレじゃなくてもいいんです。わざわざロールとかも丁寧に入れて、ズームにレンズボケまで連動させた結果、リアルになり過ぎちゃってかえって変な画面になる場合も多いですからね。 例えばシンプルな絵のギャグ作品でドタパタ中に起こる画ブレなんかは、ある程度記号化された画ブレの方がむしろ良い場合もあるような気がします。 必ずしもリアルを目標とする必要はなく、重要なのは演出意図に合った絵作りを主体的にしましょうということです。画ブレに宿る魂なんて、演出がシートの裏にメモ書く程度で指示できるわけがないじゃないですか。撮る人が主体的に命を吹き込まないと、宿らないわけです。命を吹き込む=アニメートですよお兄さん。 ウィグラーとか誰が書いたエクスプレッションとか、そういうの使っても全然いいですけど、むしろプロダクションワークでは積極的に使った方がいいとは思うんですけど、機械的にならぬよう、腑抜けにならぬよう、演出意図や場面の雰囲気に沿ったなんらかの魂を込めて下さい。お願いします。 誰に何をお願いしているんだ俺は。




完璧に話が逸れていく。典型的な暴走。 すいません。 いつものことなんですが、なんか、書いているうちにヘンな霊に憑依されるんですよね。 俺じゃなくて霊が書いているんですよこれは。





ところで、上に書いたような、撮影さんはアニメータ野郎よりも合成野郎の方が多く見えるという話ですが、これってたぶん作画も同じですよね? シンプルなキャラがガンガンいい動きを見せるような、いわゆる 「よく動く」 みたいな作品よりも、線が多くて影がリッチですんげえ可愛い女の子の1枚絵を描きたいという人が多くなっているような気がします。そんな話を作画の人から聞いたこともある、かな。たぶん。たしかにそんな実感があるような気がします。 これも善し悪しですよねえ。 綺麗な1枚絵だけで食っていける人はそれでもいいでしょうし、動きだけで食える人はそれでいい。 でも1つの作品を作るためには大抵の場合両方が必要です。 偏りすぎてはいけません。


おそらくは3DCGも同じ傾向がある気がします。 モデリング、シェーディング、ライティング、レンダリングなどは重視されるというか、そういう作業が大好きな人が圧倒的に多いような気がするんですよね。これが撮影で言う合成野郎であり、作画で言う一枚絵野郎ですかね。  一方、アニメーションが好きだという人は、もちろんいるけど、どっちかというと少ないと思う。 動かすこと、命を吹き込んでその世界に実在させることなどよりも、単体としてのルックデヴに力が偏りすぎちゃっている気がする。 結果、パッと見は綺麗で可愛いリッチなキャラクターなんだけど、動くと命が宿ってなかったり、動きの部分や種類によっては安直なダイナミクスとかシミュレーションで済まされるようなことも多い。命の宿ってないキャラに、ヘアーがどうしたとかクロスシミュレーションがどうしたとか、あんまり意味無いじゃないですか。セカンダリモーションはプライマリモーションに命があってこそですよ。 みんな、ファイナルなんとかあたりの流れを汲む綺麗な見た目の人間とか、レンダリング頑張りました系のCGだけをやりたいのかなあ。それがCGやる最大のモチベーションなのかなあ。 どうなんでしょう。  あまりアニメーションを軽視しない方が良いと思うんですが、どうですか。 ま、軽視はしてないと思いますが、 「それは俺の仕事じゃない」 と思っている人が多いのかな。どうなんだろう。


あとはプロデューサーさんに頑張ってもらって、レンダリング野郎もモーション野郎もバランス良くかき集めてもらうしかないですかね。 ではその方向でお願いします。 誰に何をお願いしているんだ俺は。







違う。
ディスニーの撮影台のビデオが面白かったから書き始めたんだった。
お前、いったいどこの霊だ。
俺に何を書かせるつもりなんだ。









そういえばかなり前になりますが、某社さんがいまだに撮影台を保有しているという情報を入手し、見学を申し込んだらあっさり見学させてくれまして、色々解説もして頂いてすんげえ面白かったです。 天井の高い部屋に、2台ありました。 以下はその時の写真。


Img_0154
この会社も今ではデジタル撮影になってしまっているので、この撮影台は使っていないそうです。デカいものだから捨てるに捨てられず、骨董品的な価値もあるから残しておこうという感じでしょうかね? いやあ、もったいないからとっておきましょう。


光の量がすごいというか、熱いというか。
Img_0161
ライトは左右から1発ずつと、下から1発かな?
下からのライトはT光用ということでしょうかね。
カメラは上の箱の中に、下向きに入ってます。っていうか箱に入ってなかったっけかな。むき出しのまま装着されていたんだっけかな。



これがカメラですね。
Img_0158
まさに、3DCGソフトウェアのカメラのアイコンになっているような形のカメラです。カッコいいですねえ。 俺もデジタルな世代ですからね、こういうフィルムなカメラはあまり見たことなかったですよ。



こういうハンドルをグルグル回して台をスライドさせるんですね。
Img_0151
Xポジションにキーフレーム打つとかそういうのじゃないわけですよ。 フェアリングして止めたいならFカーブいじってイーズアウトとかじゃなく、1コマあたりのスライド幅をだんだん小さくしていくしかないわけですよ。 アナログです。 カッコ良すぎです。



マルチプレーンしてます。
Img_0152
下の台には背景美術、上の台にはセルが乗ってますね。カメラワークがあるときに、上の段と下の段でスライド幅を変えれば、奥行きが出てより立体的に見えますわね。電車の窓から見る街の風景ですわね。

あと、上のプレーンだけにピント合わせれば背景がボケますよね。スライド幅のためだけじゃなくて、ピントの制御もマルチプレーンの大きな役割ですよね。

ん? あれ? マルチプレーンで作るボケがマルチボケなわけですが、あれ? 単純に背景ボカすのもマルチボケって言いましたっけ? なんとなく、手前にナメものBOOKがあってそれをボカすような時にマルチボケって言っているような気もするんだけど、違う? 手前か奥かは関係ない? 手前だろうが奥だろうが、マルチプレーンを使った距離の差によるピンボケがあれば、なんでもかんでもマルチボケって言うんでしたっけ? 原理というか語源から言えば手前奥関係なくマルチボケって呼びそうだよね。 よくわかんなくなっちゃった。




スライド幅やらカメラとの距離やらライトやら、ある程度機械で制御できるようです。
Img_0136
これは、遠隔操作のためのコンソールという意味なんでしょうかね? つまり台の所まで行って手でハンドル回す代わりに、このリモコンで制御するというだけのもの?  それとも入力を記憶させていって後からその動きをプロシージャルかつオートマチックに再現させるような、いわばモーションコントロールカメラということなんでしょうかね? そのときに詳しい説明を聞いたはずだったんだけど、不覚にも失念してしまいました。もったいない。



これは、入射光とかに使うフィルタかな。
Img_0167
色んなエフェクトを得るための、色んな素材があるんですよね。 楽しそうだ。



これは擦りガラスを使ったオーラT光ですね。
Img_0133
台の上に、距離の違う2種類の擦りガラスがあります。これによってピントのボケたパターンが浮かび上がってうにょうにょとオーラになるんだと思います。 

色んな種類の擦りガラスを用意して色々実験しながら撮っていたそうで、それどころかガラスを自分で削って新たなパターンを作ったり、ガラスではなく透明のシートの間にジェルを挟んだものを使ったりと、実に楽しそうなことをやっていたそうです。 光の屈折を制御する職人さんたちということになりますね。カッコいいぜフィルム撮影野郎。 今どきはフラクタルノイズのダイナミックプログレッシブでプリコンポしてディスプレイスにコロラマだ。意味わかんねえ。これはこれで職人技なわけだが、なんつうかこう、わかんねえ。 擦りガラスの屈折をいじる方がなんとなく楽しそうだ。


でもまあ、手間はとんでもねえものだったみたいですね。 時間の無い中、フィルムゆえに失敗の許されない状況で、オスメスマスク作ったりセルの裏塗りしたりと、アナログ撮影ゆえの又はマルチプレーンゆえの膨大な手間をかけて撮っていたと聞きます。 俺みたいな門外漢がアナログなものを見てカッコいいとかほざいているのは、おそらく本職の人から見ればちゃんちゃらおかしいでしょう。 AfterEffects でポンとできるのであればその方がいいに決まっているぜ、お前が言っているのは古いものやリアル手作業があるものを何でもカッコ良いとする安易なロマンチシズムだぜ、と怒られそうです。すいません。



でもまあ、最初からデジタルで考えるより、アナログな光の屈折の挙動なりそういうことを知っていたほうが、最終的にはデジタルで表現するにしても絶対に有利ですわね。温故知新というやつですかね。




無理やりまとめのようなことを書いてみたが、
まとまってないのは俺が一番よく知っている。
まあいいじゃないか。 俺のブログだ。
俺の妄想や暴走を書くのだ。




.

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

2011年6月10日 (金)

2012 SP1。

おおー なんつうか、これ、どうなの。


2012に早速 SP1。
http://xsisupport.wordpress.com/2011/06/09/softimage-2012-service-pack-1
-available-for-download/



対応が早いというか、ソッコーで SP1 出さなければいけないほどのアレなプロダクトを出していたということなのか。


マテリアルのレンダーツリー自動破壊機能は結局どうなりましたか。解決を見ましたか。



めんどくせえからインストールはまた今度にしましょう。
なになに、2012 とは別インストールになるんですね。つまり共存可能。
ライセンスは 2012 と同一のライセンスで動く、と。
590D1 ね。 了解。



なんかもう、それどころじゃないのよ。





.

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

2011年6月 6日 (月)

Avid XSI の終焉。

これは重要情報じゃないですかね。


Avid 時代のXSI にもうすぐお別れ。

eX-SI Support による注意喚起

http://xsisupport.wordpress.com/2011/06/03/software-retirement-notice-for-xsi-7-01-and-earlier/

そこからリンクされている亜米利加嘔吐デスク公式
http://usa.autodesk.com/adsk/servlet/pc/item?id=13621063&siteID=123112



7.5よりも以前のバージョン、つまり 7.01 や 6.xx ということになると思うんですが、つまりイコール Avid 時代のバージョンですね。 その Avid な XSI は2011年8月1日でサポート終了、以降はライセンスの移動などができなくなる、と言っているように見えます。 ライセンスを他のマシンに移したい人は8月1日以前にやってくれという意味のことが書いてありますね。


7.01 を持っている人は多いんじゃないかな。 
ドングル(SI0)なら、ドングル差し替えるだけでライセンスが移動できると思う。だから上の日付は関係ないと思う。たぶん。
SLP な人は、ライセンスの移動は早めにやっておいた方が安全そうですね。

「通常のライセンス移動のシステムを使った移動ができなくなるというだけで、申請すれば時間はかかるけど手動で移動手続きをしてもらえる」 なのかどうかは書いてませんので、わかりません。リセラーさんに聞いてみるといいと思います。 



この情報、AREA に載っている?
AREA Japan は?
っていうか日本の嘔吐デスク公式サイトでも見つけられない。
載ってないのかな。
重要情報だと思うんですがね。
まあ、載っていたとしても、嘔吐デスク様のサイトで目的の情報にたどり着けることはごく稀なんですけどね。




.

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

2011年6月 3日 (金)

乱立2011。

XSI 2011 ってバージョンが乱立しているじゃないですか。
アホみたいに。



Softimage 2011
Softimage 2011 SP1
Softimage 2011 SP1 Hotfix1
Softimage 2011 SP1 Hotfix2
Softimage 2011 SP2

Softimage 2011 SAP

Softimage 2011 SAP SP1






俺の知る限り、これだけバージョンがありますね。Hotfix はバージョンというよりは、修正された DLL のみが配布されて、インストール済みの XSI のフォルダに潜って行って手動で上書きするみたいなやつだと思いますが。


で、細かい修正内容はいざ知らず、有名な シェーダ接続自動ブチ壊し機能 をどこまで修正したのか、という観点でのみ同一性を確認すると、次のようになると思います。


2011 SP1 Hotfix1  +  2011 SP1 Hotfix2  =  2011 SP2  =  2011 SAP SP1


どうなんでしょう? シェーダ接続を自動でブチ壊してくれる機能を修正したこと以外の観点で見ても、やはりこのようになりますかね? これは嘔吐デスクの人じゃないとわからないか?

仮にこれが正しいとすると、Hotfix 1 と 2 を両方とも適用している人はもう SP2 と同じだから、SP2 は入れなくても良いということになりますね。 逆に言うと、SP2 を入れてしまえば Hotfix 1 と 2 は適用せずに済むことになりますね。





で、わかりにくいのは SAP と 非SAPで、サービスパックの番号が統一されてないことです。

同じ Service Pack 1 =  SP1  という名前が付いたものには、 2011 SP1 2011 SAP SP1 があるわけですが、 これが SAP の有り無しだけの違いならいいのですが、そうではない。 上で書いたように、2011 SAP SP1 に相当するバグフィックスがなされているのは、 2011 SP2 です。



思うに、


  SAP と名を冠したバージョンでサービスパックを出すのは初めてだから、いきなり SP2 とするわけにはいかない。 SP1 から始めなければいけない

  一方、非 SAP の方はずっと前に SP1 を既に出してしまっている。なので新たに出すなら SP2 とするほかない


という考えのもとに、このようなわかりにくいバージョニングになったのではないでしょうかね。


いい加減にしろ嘔吐デスク(#゚Д゚)
ひどすぎですよ。 わざと混乱させて楽しんでるのか、ってくらいのわかりにくさです。 



SAP SP1 を欠番にしていきなり SAP SP2 を出す、というはダメなんでしょうかね?  そうすれば、2011 SP2 と SAP SP2 で、同じ SP 番号なら同じバグフィックスレベルだということになり、わかりやすいじゃないですか。

XSI に限らす世の中のほとんどのソフトウェアで、 SP2 というものが存在したら、それは SP1 を含んだ形になってますよね。 ということは、SP2 さえインストールしてしまえば SP1 をインストールする必要は無く、つまりユーザは SP1 の存在を忘れてしまえると思うのです。 だから、SAP SP1 を出さないままいきなり SAP SP2 を出したとしても、ユーザ的には「あれ? SP2 が出てるぞ? SP2 があるってことは SP1 もあったということなのかな? それは聞いてないぞ?  でも SP2 入れれば SP1 も兼ねてるから、SP1 が存在したかどうかなんてもうどうでもいいねー」 ということになると思うんですよね。 考え方として乱暴ですかね。







で、さらにひどいのが、XSI のインターフェース上の表記に SAP の文字が無いということです。



↓この画像は、2011 SAP SP1 の、インターフェース左上の表記です。
2011sp1

SAP って書かれてないんですよ。
あれ? 2011 SP1 なの?  SAP SP1 じゃないの?
 と、一瞬焦ります。

だって、2011 SP1 と SAP SP1 は、バグフィックスした段階が一緒ではない、別バージョンですからね。




↓でも、同一の XSI で Help メニューから About 画面を出すと、
2011sapsp1

正しく SAP SP1 であることがわかります。 ビルドのバージョンを見てもわかりますね。


だったら、左上の表記にも About 画面と同じく SAP の表記をすればいいじゃねえか。
左上の表記だと、まるで俺が 2011 SP1 を使ってるみたいじゃねえか。
2011 SP1 と、SAP SP1 って、バグ修正の段階が違う、つまり別バージョンですぜ嘔吐デスクさん?

おちょくってんのか
(#゚Д゚)




と、今日も悪態をつきますよ。 ええ、つきますとも。

嘔吐デスクさんがまとめサイトみたいなのを作って大々的に告知すべきですよ。この手の情報って、中のスタッフが自発的にやっている eX-SI Support や、中のスタッフが自発的にやっているインターネット上での質問への回答などに任せっきりで、自分では何もしないんだから。日本ではもっとひどい。 自力で頑張って情報探すしかない。

盆デジさんはまだ頑張ってるか。こういう情報出してくれるから。嘔吐デスクは、毎回同じ書式でこういう風に出すだけだから、わかりにくいし、埋もれちゃいがちです。 しかもこの書式の都合上、そのページの中で話題にしているバージョンまわりのことだけ、最小限に触れているという感じが否めません。 今回のようなわかりにくい場合、SAP も含めて表のようにして比較が書かれているまとめページが必要だと思うんですよね。 SP2 が SAP の SP1 に相当するんですよ、とか、元々がわかりにくいにしても、ちゃんと公式に書いてくれればまだ理解のしようがあります。 仕事して下さい嘔吐デスクさん。





.

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

2011年6月 2日 (木)

色がへくーす。

先日、かのお方に教えてもらった 16進数への変換 を使って書いた小ツールなんですが、けっこう便利に使ってます。



スライダで色を決めると、16進数の RGB 値になっている文字列を返す PPG です。

Hex


//    カスタムプロパティ作成
var oP = XSIFactory.CreateObject( "CustomProperty" );
oP.name = "色がへくーす";


//    カスタムプロパティに必要なパラメータ作成
oP.AddParameter2( "R", siDouble, 1, 0, 255 );
//    色パラメータは、RGB個別にパラメータ必要
oP.AddParameter2( "G", siDouble, 0, 0, 255 );
//    そして、R,G,B の順にパラメータを追加する必要がある
oP.AddParameter2( "B", siDouble, 0, 0, 255 );
//    途中で変なもの挟むとわかりにくくなるよ
oP.AddParameter2( "RRGGBB", siString, "" );   
//    0x 無しの16進数文字
oP.AddParameter2( "sHex", siString, "" );   
//    結果の16進数文字
oP.AddParameter2( "bHeader", siBool, true );   
//    0x 付けるかどうか

//    上で作成したパラメータを、PPG に追加(PPGLayout)
var oL = oP.PPGLayout;
var oItem = oL.AddColor( "R" );   
//色コントロールは AddColor で R のみ指定する
oItem.SetAttribute( siUINoLabel, true );
oL.AddRow();
    oItem = oL.AddItem( "sHex", "へくーす" );
    oItem = oL.AddItem( "bHeader", "0x" );
oL.EndRow();


//    スライダいじると自動でアップデートされるよう logic の仕込み
oL.Language = "JScript";
oL.Logic =    OnInit.toString() +
            bHeader_OnChanged.toString()+
            R_OnChanged.toString() +
            G_OnChanged.toString() +
            B_OnChanged.toString() +
            GetRGBHex.toString() +
            to2keta.toString()+
            ColorChange.toString();

function OnInit()
{
    ColorChange( );
}
function R_OnChanged( )
{
    ColorChange( );
}
function G_OnChanged( )
{
    ColorChange( );
}
function B_OnChanged( )
{
    ColorChange( );
}
function ColorChange( )
{
    PPG.RRGGBB.value = GetRGBHex( );
    bHeader_OnChanged( );
}
function GetRGBHex( )
{
   
//    0~1を 0~255 にし、それをさらに16進数に変換し、
    RR = Math.round( PPG.R.value * 255 ).toString( 16 );
    GG = Math.round( PPG.G.value * 255 ).toString( 16 );
    BB = Math.round( PPG.B.value * 255 ).toString( 16 );
   
//    ケタを合わせ、
    RRGGBB = to2keta( RR ) + to2keta( GG ) + to2keta( BB );
    return RRGGBB;   
//戻す。
}
function to2keta( str )
{
    if ( str.length <2 )   
//もうちょっとマシなケタ合わせルーチン教えて下さい
    {
        str = "0" + str;
    }
    return str;
}
function bHeader_OnChanged( )
{
    if ( PPG.bHeader.value )
    {
        PPG.sHex.value = "0x" + PPG.RRGGBB.value;
    }
    else
    {
        PPG.sHex.value = PPG.RRGGBB.value;
    }
}

//    PPG を表示しておしまい
InspectObj( oP );




何に使うのかと言いますとですね、今のところ XPOP3 で自作のポップアップメニューを作るのに使ってます。 XPOP3 は、メニューアイテムの背景色を16進数の RGB で指定しなければいけないんですが、これがめんどくさくて、しかも XSI の中にあるカラーピッカー・カラーホイールって16進数表記が無いんですよね。 無いよね? 無いと言ってくれ。 Photoshp のカラーホイールは16進数での RGB 表記も同時に出るので、しかたなく Photoshop と行き来してたんですよね。

なので、XSI の中だけでやりたかったというだけです。XSI の使い慣れたスライダで色を決め、その結果出てきた16進数の RGB 値(文字列)をコピペで XPOP3 のコードに持っていく。それだけです。

スライダをいじくって色を変えると、下の RGB 表記がインタラクティブにアップデートされます。あとは手でコピペして使ってくれというものです。 ど頭の 0x の表記を付けるかどうかはチェックボックスで切り替えられます。 XPOP3 では 0xRRGGBB と書いてやる必要があるみたいです。たぶん。







スクリプティング的なところでは、10進数を16進数に変換するあたりがポイントでしょうか。


function GetRGBHex( )
{
   
//    0~1を 0~255 にし、それをさらに16進数に変換し、
    RR = Math.round( PPG.R.value * 255 ).toString( 16 );
    GG = Math.round( PPG.G.value * 255 ).toString( 16 );
    BB = Math.round( PPG.B.value * 255 ).toString( 16 );
   
//    ケタを合わせ、
    RRGGBB = to2keta( RR ) + to2keta( GG ) + to2keta( BB );
    return RRGGBB;   
//戻す。
}
function to2keta( str )
{
    if ( str.length <2 )   
//もうちょっとマシなケタ合わせルーチン教えて下さい
    {
        str = "0" + str;
    }
    return str;
}



ここで、


  数値.toString(16);


とやっています。 いや、きっとポイントでも何でもなく、自分は今まで知らなかったというだけなんですが。 toString は元になる何かを文字列に変換するメソッドですが、括弧の中に○○進数というのを指定できる、のかな? こんなの知らなかった。簡単じゃないか。 ありがとうごてつさん。


これは JScript の場合であって、他の言語では全く違うと思います。 VBScript では Hex( 数値) ってのが使えますね。 これもすごく便利ですね。 a = Hex( 255 ) とかやると、a には FF が入っています。 これに相当することを JScript でやりたくて、でもわかんなくてモニタを投げていたら、賢人が教えてくれたのです。 ありがたいことです。  ぱいそんではどうやるのかな。


Math.round( 元の数値 * 255 ) とかやっているのは、XSI のスライダでは 0~1 の小数点を含んだ範囲なので、0~255の範囲の整数にリマップしているつもりです。 レンジのスタートは同じで、レンジの終わりだけが 1 だったものが 255 になればいいんだから、単純に 255 を掛け算している。小数点以下は四捨五入。 というつもりなんですが、これで計算式合ってる? テキトーですいません。


ケタ合わせはこんなのでいいのだろうか。文字列の長さを調べて、2文字以下だったら頭にゼロを足して2文字にした状態=2桁の文字列 にして返しています。 もっと上手い方法というか、プログラミングの常套手段的な、お定まりの方法あるんでしょ? 教えて下さい。






あとは、XSI の PPG にカラーなコントロールを付けるのはどうやればいいか、の参考になるんじゃないですかね。 


//    カスタムプロパティに必要なパラメータ作成
oP.AddParameter2( "R", siDouble, 1, 0, 255 );
//    色パラメータは、RGB個別にパラメータ必要
oP.AddParameter2( "G", siDouble, 0, 0, 255 );
//    そして、R,G,B の順にパラメータを追加する必要がある
oP.AddParameter2( "B", siDouble, 0, 0, 255 );
//    途中で変なもの挟むとわかりにくくなるよ
oP.AddParameter2( "RRGGBB", siString, "" );   
//    0x 無しの16進数文字
oP.AddParameter2( "sHex", siString, "" );   
//    結果の16進数文字
oP.AddParameter2( "bHeader", siBool, true );   
//    0x 付けるかどうか

//    上で作成したパラメータを、PPG に追加(PPGLayout)
var oL = oP.PPGLayout;
var oItem = oL.AddColor( "R" ); 
//色コントロールは AddColor で R のみ指定する


この辺の話ですが。
R,G,B は、コントロールとしては1つしかないけど、RGB個別のパラメータを与える必要があります。 でも PPGLayout に追加するときは、AddColor の呪文を使って R だけを追加します。 
※AddItem じゃない所が味噌です。 ま、おそらく AddItem と siControlRGB などの組み合わせでも可能かと思いますが、AddColor の方が楽でしょう。

順番が重要です。 Property.AddParameter2 などを使ってパラメータを追加するときに、 R G B の順番で必ず連続して追加しましょう。 この例では、パラメータの名前を "R" "G" "B" としています。 連続で追加しています。 もっとわかりやすい名前にすれば良かったな。。。。

順番が重要である理由は・・・・説明するのが面倒だなw

ええと、後に AddColor を使って R だけを PPG に登録するとXSI のあのカラースライダになるわけですが、このとき、PPG にとっては、パラメータが何であってもかまわないんですね。 AddColor のカッコの中で 「この名前のパラメータが RGBR  だぞ」 と指定すされたPPG は、カスタムプロパティ内の次のパラメータ次の次のパラメータをそれぞれ G B とみなしてしまうわけです。

最初にカスタムプロパティにパラメータを追加する時点で、その追加した順番は記憶されています。 PPG はこの順番を頼りに、最初に R だと指定されたパラメータを起点として続く2つのパラメータをゲットしてくるわけです。 なので順番が大事なのです。

まあ、俺はこの仕様はどうかと思いますけどね。パラメータが3つ分かれているのはいいとして、順番に関係なく、ちゃんとパラメータの名前で RGB 指定できるようにするべきじゃないですかねえ。





あとは、OnInit やら OnChanged やらで、数値が変わった時にどんな挙動をさせるか、その処理の参考になるかも知れません。

OnInit は PPG が開かれたとき(リフレッシュされたとき)に自動的に起動されるファンクションです。 それ以外の パラメータ名_OnChanged は、パラメータの数値に変化があった時に自動的に起動されるファンクションです。

ソースを見ると、OnInit が起動された時も、 RGB のパラメータに変化があった時も、ColorChange というファンクションに飛ばすようになってます。

ColorChange の中で、16進数に変換するファンクションに飛ばし、次に 0x を付けるか付けないかのファンクションに飛ばしています。 16進数変換のファンクションの中では、さらに2桁に変換するファンクションに飛ばしたりもしています。

こういうの、スパゲティコードって言うんですか? 違う? 俺の中では、無駄の無い、ロジカルな構造のつもりで書いているんですけどね。

でもまあ、ダブったコードを減らそうとしてファンクションでまとめすぎると、やはりわかりにくくなることはありますよね。 ファンクションでまとめるのは、実は 「無駄なくまとめられた」 という自己満足に過ぎないことも多く、ダブっていることを承知で、色んなファンクションの中に同じコートを書いてしまった方が分かり易い場合も多いです。 コピペすりゃいいわけだし。 これはいつも悩みどころです。




それではごきげんよう。



.

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

2011年6月 1日 (水)

福島復興支援XSI男Tシャツ 会計報告。

福島復興支援XSI男Tシャツプロジェクトですが、会計報告が遅くなりました。すんませんすんません。



最終的に、33人のお方が合計57枚を購入して下さりました。
超ありがとうございます。 心から感謝します。
このブログを読んでくれた人だけでなく、俺の友達やら身内やら、かなり広い範囲でご協力を頂きました。一人で何枚も買ってくれたり、家族の分まで買ってくれたりしたお方もいらっしゃいました。 実にありがたいことです。




1枚 3,500 円での販売でしたので、57枚で 199,500 円の売り上げになりました。 約20万円? すげえ。

送料の 80円は実費としてクロネコヤマトに払うお金でした。よって寄付の額には関係ありません。




Tシャツ作製のコストですが、この明細書↓にあるように、
Img_0031

アイテム代(ベースとなるTシャツ代) 640円 x 57枚 = 36,480円
製版代 1版(1色) 5,000円
プリント代 240円 x 57枚 = 13,680円
たたみ・袋詰め代 25円 x 57枚 = 1,425円
送料 無料
合計 56,585円(税込み)

でした。 これはTシャツ屋である(有)アートスペースに支払った金額です。振込みの手数料は小額なので俺が負担しました。
領収書は↓この写真です。
Img_0080

57枚も注文を頂けたので、コストはだいぶ下がりましたね。枚数が増えたことで送料が無料になったし、プリント代も枚数が多いほど安くなります。そして製版代も枚数が多ければ1枚あたりのコストは下がるわけで、結局 56,585円 ÷ 57枚 = 1枚につき約 992円で作製できたことになります。1000円切りましたねえ。なので1枚につき2500円以上が寄付になったわけです。イエイ。


ということで、

売り上げ合計 199,500円 - 作製コスト 56,585円 = 142,915円

を、福島県災害対策本部に寄付してきました。
Img_00022b

郵便局で振り込みました。災害対策本部向けの振り込みは、手数料が無料でした。

また、Tシャツ屋であるアートスペースさんも復興支援プロジェクトをやってまして、Tシャツ1枚の売り上げにつき20円を日本赤十字社を通して寄付するそうです。なので、今回の XSI 男Tシャツの売り上げから 20円 x 57枚 = 1,140円 が寄付されたはずです。


ということで14万!
 俺は満足です。 14万円という金額は、復興に必要なお金のほんのほんの一部でしかありませんが、まあなんつうか、気が済んだじゃないですか。 被災者のため、というのはもちろんなんですが、結局は自分のためというか、自己満足的なところがあるのは認めざるを得ないと俺は思っています。その意味で、俺はいったん気が済みました。俺たちも少しは力を出せたわけだし、大切な福島の友人たちも喜んでくれているから十分満足だ、という気分です。 元々は浪江町に住む友人が被災したことがきっかけで始めたプロジェクトでしたが、今は愛知に避難しているその友人夫婦にもこのTシャツを贈りました。すんげえ喜んでいました。福島市に住む友人にも贈りました。すんげえ喜んでいました。 「福島を胸に掲げて街を歩けるのは誇らしいぜ!」と言って2枚も買ってくれた友人もいます。ひとりで3枚も買ってくれた人もいます。福島に住む両親の分まで買ってくれた人もいます。俺としてはすんげえ気が済みました。

今回協力してくれた人の中には、俺とは全く違う思いを抱いて購入してくれた人もいるでしょう。っていうかそういう人の方がきっと多いでしょう。気が済むとか済まないとかの問題ではない!という人もいるでしょうし、自己満足ではなく純粋に助け合いの心から買ったのだ!という人もいるでしょう。もしかすると必ずしも福島に気持ちは向いていなく、ネタとして買ってくれた方もいるかも知れません。俺はそれで良いです。全く問題ねえっす。俺の思いや俺の信念に同調して欲しいとは特に思いません。あなた独自の思いやあなた独自の信念に基づいて福島復興支援XSI男Tシャツに協力してくれて、本当に感謝します。ありがとうございました!!!





クロネコヤマトのメール便で送りましたが、一人のお方だけまだ返事をもらえてなくて未確認なのですが、それ以外のお方は全員無事に届いたことが確認できてます。



Tシャツの生地は意外としっかりしてますね。もっと安いTシャツをベースにすることもできたんですが、生地が薄そうなんですよ。あまりにもすぐにボロボロになるんじゃ悲しすぎると思って、少し生地が厚めだと思われるやつにしたんですね。若干値段は上がったけど、たぶん正解です。 ただし、プリントの色落ちが・・・・ 黒のプリントなので、鮮明な黒を保つのは難しいのかな。 1回洗濯すると真っ黒じゃなくなるというか。 トーンカーブでシメたくなりますね。


発送作業も、大変だったけど、楽しかったです。
Img_0001
テープ型の糊を1つ、使い切りました。
プリンタの黒インクを1カートリッジ、使い切りました。






写真頂きました。
Pff_chakuyou
クリックででかい画像が見れます。



これでこのプロジェクトはいったん終了です。
実に楽しかった。
皆さん、本当にありがとうございました。




・・・・でも実は、第2次募集をやろうかな、と思っています。 受付を締め切った後に、何人かのお方からTシャツ欲しいと言われていまして、10枚くらい集まるならやる価値あるかな、と思っています。 今ならまだTシャツ屋さんに版が残っているので、おそらく製版代がかかりません(半年くらいで破棄すると言っていた気がする)。 ただ、それでも枚数が10枚やそこらだと1枚あたりのコストがだいぶ高くなってしまうでしょう。 その分寄付額が減ることになりますが、まあいいんじゃないですかね。 1枚あたり500円の寄付だったとしても、やらないよりはいいですからね。

ということで、また募集します。
近々告知しますのでそこから受付開始になりますが、まあ前と同じです。
協力して頂ける方は、もうフライングでもいいので適当に連絡下さいませ。





.

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

« 2011年5月 | トップページ | 2011年7月 »