日々適当

SIをmaya様に合わせるかという話題をしていた時に、そいえばVueもそんなプリセットがあったよなって思い出した時に確認してみました。



ちなみにSoftimage風にするプリセットもありますけど、これを設定してみても、どの辺がSoftimage風なのかよく分かりません。色だけ少しそれっぽくなりますがw



ビューポートオペレーションをSキーで行えるわけでも無し（ましてOPZが有効になるわけじゃなし）、やめておいたほうがよいっす。
で、maya風にします。これ、Windows版のキーマップを参考に変更されているため、Command +Qとか動かなくなります。んが、mayaのAlt + マウスのLMRボタンの動作は何となく踏襲していますから、maya使いにはちょっとだけ取っつきやすく感じるかもですね。まぁ、感じるだけで動作がちょいと違うし、やめておいたほうがいいとは思いますが。よく似た操作で結果がちょっと違ってくるってのはたぶん相当イラッとします。そんな意味で、VueのデフォルトのSIやmayaとは全然違う操作って方がたぶん混乱しません。
ちなみにVueのデフォルトは、マウスの右ドラッグがカメラビューでのパン、投影ビューでのドリー、Commandキーと組み合わせるとズーム、そこにShiftキーを追加するとカメラビューでのドリーになります。癖ありすぎです。

なお、modoも同様な設定があります。これのSoftimage風のはちゃんとSキーでのナビゲートが可能です。mayaは少なくともmac版についてはズームがうまく動かないかな。でもmayaメインなら、modoのデフォルトがAltのみAlt+ShiftやAlt + Controlの組み合わせとマウスのドラッグなので、mayaと操作を混乱する事になる事は間違いないでしょうから、これはmaya風にするかmayaをmodo風に（できるなら）するのが幸せになる第一歩のような気もします。
まぁ、僕はmodoデフォルトで慣れちゃったので、混乱しながら突き進みますけど。

将来maya様に移行する時、SI風のオペレーションをmaya様に何とか実装するのか、それともその時に備えて今からmaya様のルールでSIを操作するのか、迷いどころです。後者を選ぶ時、それはAlt教に入信するという事なのです。しかし、ビューポートオペレーション（ドリー、回転）はAltを使っての操作という事は分かるのだけど、その他ショートカットがどうなるのか、さっぱりなのです。
と言うのを思ったのはですね、先日ちょいとParallels上のSoftimageをmaya風のキーマップに設定しててそのまま忘れて今さっき起動したら、maya風の操作がさっぱりで、なんだかいろいろ困ったからなのですよ。



コンポーネントの選択はどうやるのですか？というものですよ。
ていうか、maya様使ってコンポーネントのセレクトツールにする時って右クリックでメニューをだして切り替えている印象があるんだが、ショートカットは特に設定されていないのか？

とか何とか非常に苦労するような気がします。ていうか間違いなく苦労するな。苦労するぐらいなら、maya様じゃなくてhoudiniとかに行きたいな。でもそれは仕事との事情的に許されないだろうな…………………………鬱ですよ。

基本的なところはAlt教に入信しつつ、mayaにもカスタムな設定をしつつSI側にも同じ設定を適用というのをちまちまとやっていくしかないですか。ここいらへん（Suite UsersNotes [ダイキンCOMTEC]）を参考にちまちまやりますか。あー、面倒くせ。恨むぞAutodesk。

ちょいと都内に出るついでに千鳥ケ淵を歩いてみました。
今年は半蔵壕方向から歩いています。

昨日今日の暖かさで一気に咲いたようですけど、まだ満開には至っていない感じでしょうか。





おかげでまだ空いていました。
満開のころになってかつ休日だと、展望台的な所（ボート乗り場の上）がいっぱいで進入するのも大変な事になってるはずなのだけど、まだスカスカです（それでも一番縁に立つにはちょっと待つ必要はありましたが）。





それにしてももし水に近い位置で撮りたいのなら、やっぱり九段下方面から半蔵門方面に抜けるべきですね。基本的に左側通行で列が進んでいくから、今日歩いたルートだと柵に近づける場所が限られます。



んで、せっかくなので靖国神社も通過します。





でもって靖国通りを歩いて市ケ谷駅へというのが本日の寄り道でした。



今年は桜をどれぐらい見れますかねー。

現行Mac Proは横置きにしてもいいよってAppleがアナウンスしたからか、いわゆる19インチラックに収めるためのラックが登場してきているようです。と意識したのは、SonnetがxMac Pro Server Thunderbolt 2 PCIe Enclosure [Sonnet] を発表したのが目に入ってきたから。
これは、4Uのサイズ（1Uは44.45mm）に納める箱で、Mac Proが一台とPCIeスロット、専用のモバイルラックを入れる空間を持ったものっすね。Mac Proの底面をむき出しにする事で、なかなか独特な見た目となっております。
思うに、この構成の場合は通常のデスクトップとして利用できる形状にしたほうが良いような気もします。いわゆる、従来のMac Proと同等の内容をそれで持たせられる的なもんね。もちろん、これに加えて19インチラックを縦置きするようなケースも売られているんで、それに入れて机の横に置くなんて事も可能ですけど、コストがさらにかかる事になり微妙です。
あ、でもキャリア付きのケースに入れる事で、いろいろな装備を備えた上で持ち運びに便利ってのはメリットやもなぁ。

マシンルームに納めておくなら、こっちのタイプ→Rack mount for two latest Gen Mac Pro'sなんじゃないかって気はします。
非常にシンプル。4Uの空間に2台置く事が出来ます。
とはいえ、これは計算力を求めるならちょっとスペース効率悪いですよね。

そこで、MP rack [H-Squared] というものがありました。6Uで6台。6台載せると30kgにもなるけど大丈夫か？という気もするけど問題ないのでしょう。これだと先の4Uのと比べて倍のスペース効率を実現します。

もっともそれだけのMac Proをラックに収めて利用するケースってそもそもどんなのがあんだ？って所で、これはAMDのGPUを使いたいって時なんですかね。でもOS Xにこだわらないのなら、NVIDIAのGPUを搭載し1Uのスペースに2CPU、2GPUを実現するモデルが売られていたりするし（AMDのでも作るのは可能だろうしもしかしたら売られているかもしれない）、だからMac Proを大量にラックに収める需要はそんなに無いような気もします(^^;
（骨壷が大量に並んでいるようなその光景は是非見てみたいと思いますが.）

Xserveが懐かしいです。

されました。

Maya Tips:Maya2015新機能 [borndigitalのブログ]

maya 2015。なかなか高機能になっているように見えますね。
Bifrost（ビフロストって読むかと思ったらバイフロストらしい）がまだちょっと期待外れな雰囲気です。現状まだリキッドシミュレータであり、その効果は非常に素敵だと思うんだけど、そのパラメータを制御するための仕組みとしてICE的なものが見れるかと期待していただけにちょっとがっかりっすね。
ともあれ、おそらく今後触っていくのであろうツールとして興味深くビデオを拝見させていただきました。

なお、要求されるシステムは　System requirements for Autodesk Maya 2015 [Autodesk Help and Support]

Microsoft Windows 7 (SP1), Windows 8 and Windows 8.1 Professional operating system
Apple Mac OS X 10.8.5 and 10.9.x operating system
Red Hat Enterprise Linux 6.2 WS operating system
Fedora 14 Linux operating system
CentOS 6.2 Linux operating system

だそうで、なんでLinuxの動作環境のバージョンって上がらないんでしょうかね？
一方でMacはLionが切られました。WindowsもVistaが切られておりますな。

Softimageは2015は単体での購入は出来ないみたいで、ECS Unlimiteにのみ付属してくるようです。製品紹介のページなんて無いに等しい感じで、新規ユーザーの登場を完全に拒否した形になっておりますね。悲しい事です。

System requirements for Autodesk Softimage 2015 [Autodesk Help and Support]

mayaの情報をコピペしたのかもしれませんな。
新機能はこちらのPDFに記されているようです。小さな変更点が羅列されております。それなりにうれしい内容も多いんですけど、当然ながら地味でございます。そしてこれが最後と思うと涙が止まりません…

でもまぁ今後何年かはきっと付き合っていくんだと思うんです、SI 2015とは。だから、せめてサポート期間中に大きなものから小さなものまでバグをとにかく潰して欲しいものです。それこそSP10とSP20とかだしてもらってけっこうですんで。せめてそれぐらいは頼みますよ、Autodesk様。

坂田城跡ってところにちょろっといってきまして。
偕楽園にでも行こうかなとも思ったんですけど、どうせ混んでるんだろうなぁってわけで、んじゃ坂田城跡梅まつりってのをやっているっていうからそっち行ってみっかなというわけで。
千葉県北東部の山武郡横芝光町にある城跡は九十九里浜まで車で多分20分ぐらいとうちょっと内陸の平地に盛り上がった丘がかつて城として用いられていたところを今は農家の方々が利用している土地となっているようです。というわけで、梅がいっぱいあるわけですけど、偕楽園や熱海梅園みたいに観賞用として梅が配されているわけではなく、梅の実を収穫するための梅林でございました。故に、ほぼ梅の花は単色。白い花をつけておりました。しかし、満開。花を見るには一番よいタイミングだったかもしれません。



観賞用じゃないゆえに、逆に偕楽園とかじゃ望めないであろう風景。




畑やビニールハウスと梅が見れたりとか。軽トラとか。
それにしても春って感じですね。





というわけで、梅をばしゃばしゃ撮影して、ここを後にします。
せっかく九十九里浜付近まで来ているという事で海まで足を伸ばしてみました。





太平洋の荒波をって感じっすね。
まぁそんなわけで、せっかく晴れているし気温も暖かなのに家にいるのは何だかもったいないと思ってしまってふと思いついてのドライブは、そこからまっすく帰ってきて終了となりました。

アナと雪の女王公式サイト

原題は Frozen 。ゴールデングローブ賞のアニメ映画賞やアニー章の各種賞、アカデミー賞の長編アニメ映画賞を受賞しちゃっており、エンディングのコピーライトも年が2013と書かれている事からも分かりとおり、これ、アメリカでは2013年の11月に公開されています。日本での公開がすごく遅れた映画ってことっすね。ていうか、来週にはDVD, Blu-ray発売ですよ。どういうことよ、この遅さは。ということで、さまざまな動画がネット上にしかも公式から公開されており、その中でも Let it goの各種バージョンはYouTubeのみならず、劇場で映画本編上映前に流れたりして、非常に強い印象を残してくれました。



でもって、世界中で大好評らしく、アカデミー賞までとっちゃったとなれば期待は嫌でも高まるというものですよね。

ということで観に行ったわけです。日本語吹き替え版を近場のシネコンで。結構お客さんでいっぱいでした。しかもイスの上に頭が出ないぐらいの身長の観客がとっても多い。そして上映中は、そのような観客も非常に楽しんで観ている空気を感じました。
映像的に、もぉスゲースゲーと心の中でつぶやきっぱなしでした。
ちなみに今回のこの映画のディズニーのチャレンジは雪の表現だったようで、昨年のシーグラフでこんな発表をしたようです。スゲー。

こーいう映画を観るたびに書いていますけど、本当に最近は、絵的に何か不自然で気持ち悪くて物語に集中できないってのは基本的にあり得なくなってきています。それが僕にはものすごいことに見えているんですけど、近ごろのCG屋的には当たり前なんでしょうか？

ということで安心して物語に集中できるわけですが、物語は非常にシンプル。そしておとぎ話です。安心して楽しみましょう。
キャラクターの掘り下げがちょっと物足りない感じはしましたが、そこいら辺はバランスをとったんでしょうね。よい春休み映画だったと思います。

それはそうと、この映画の同時上映で短編映画がくっついてきます。これ、S3Dを非常に意識した造りだったと思うんですけど、残念ながら僕は2D上映で見ています。どうも、日本語吹き替え版のS3Dはこの映画には存在していないようなんですけど、なんででしょ？
なんで日本語吹き替え版で観たのかといいますと、YouTubeでLet It Goの日本語版を観て、ディズニーは結構こだわってキャスティングをしているらしい事を感じたから。

▶ LET IT GO - Special Edition in 25 Sprachen - DIE EISKÖNIGIN - Frozen - Disney - [YouTube]

声優方面で問題を感じる事はありませんでした。S3Dの日本語吹き替え版がもし公開される事があるなら、また観に行きたいッすね。
ドラもんを観た後、気が向いたら字幕版のS3D上映を観に行くかも、かな。

さて、というわけで、緯度・経度・高度を指定した位置にGoogleEarthのカメラを制御するスクリプトがとりあえず出来ました。
まず、その位置の標高を取得するためのPythonスクリプトです。

# -*- coding: utf-8 -*-
#getElevation.py
import sys
from urllib import urlopen
import xml.dom.minidom

imputParam = sys.argv
lat = imputParam[1]
lng = imputParam[2]

url = "http://maps.googleapis.com/maps/api/elevation/xml?locations=" + lat + "," + lng + "&sensor=false"
xmlStr = ( urlopen( url ) ).read()

dom = xml.dom.minidom.parseString( xmlStr )
elevation = float( dom.getElementsByTagName("elevation")[0].childNodes[0].nodeValue )

sys.stdout.write( str ( round( elevation , 2) ) )

これをとりあえず getElevation.py という名前でデスクトップに置いておきます。
んで、以下のAppleScriptを実行。

set lat to 36.107447
set lng to 137.548871
do shell script "python ~/Desktop/getElevation.py " & lat & " " & lng
set elv to result
set ditance to 15000 - elv

tell application "Google Earth"
SetViewInfo {latitude:lat, longitude:lng, distance:ditance, tilt:0.0, azimuth:0.0} speed 5
end tell

これで乗鞍岳上空15km（海抜で15km）の位置に移動するはずです。



まずは課題を一つクリアでございます。

AppleScriptからGoogleEarthを成業するとき、View Infoってパラメータが重要で、それは

latitude (real) : lat
longitude (real) : long
distance (real) : distance in meters
tilt (real) : tilt in degrees
azimuth (real) : azimuth in degrees

です。このうちdistanceってのはカメラの高度だと思っていたんですけど、微妙に違うみたいなんです。
たとえば

tell application "Google Earth"
set lat to 35 + 21 / 60 + 19.01 / 3600
set lng to 138 + 43 / 60 + 53.48 / 3600
SetViewInfo {latitude:lat, longitude:lng, distance:20000, tilt:0.0, azimuth:0.0} speed 5
end tell

これを走らせると、富士山を中心にとらえて、Google Earthのステータスには
標高 3458m
高度 23.46km
となります。



distanceに20000って指定しているから20kmのつもりなんですけどね。どうも地面の形の影響を受けているようなんです。
ちなみに、Google Earthの環境設定の3Dビューにある「起伏の強調度」の値をデフォルトの1から最小値の0.01にすると標高に変化ありませんが、高度が20.03kmに、3にすると30.37kmになります。
ややこしいのでそこの値は1として考えると、高度の値は

高度 = 画面中央の標高 + distance

って事のように見えます。
だから、一定の高度からの見た目を得たい場合、標高を考慮したdistanceを指定してやらねばならないというわけっすね。
さて、どうするか。目標の場所における標高を得るには

Google Elevation API - Google Maps API ウェブ サービス ― [Google Developers]

というのがあるのだそうです。決まった形のURLでリクエストすると標高を返してくれる素敵なサービスですね。
書式は

http://maps.googleapis.com/maps/api/elevation/outputFormat?parameters

であり、outputFomatは、xml か json。
parametersはいくつかあるようですが、一点の標高を得るだけならlocationsとsensorが必要みたいです。
locations=(35.0 + 21.0 / 60.0 + 19.01 / 3600.0),(138.0 + 43.0 / 60.0 + 53.48 / 3600.0)
これで富士山の位置になるはずです。緯度の範囲は-90から90、経度の範囲は-180から180ですね。あ、計算式じゃなくてちゃんと計算結果を入れましょう(^^;（計算結果を入れると　35.3552806, 138.7315222 となるはずです）
sensorは現在地の取得のためにセンサーを利用をするか否かということで、この場合ならfalseでいいでしょう。ということで、

http://maps.googleapis.com/maps/api/elevation/xml?locations=(35.0 + 21.0 / 60.0 + 19.01 / 3600.0),(138.0 + 43.0 / 60.0 + 53.48 / 3600.0)&sensor=false

というURLにアクセスします（注：計算式が入っていますけど、ちゃんと計算した結果の数字を与えないとダメです）。そうすっと帰ってくる値は

<?xml version="1.0" encoding="UTF-8"?>
<ElevationResponse>
<status>OK</status>
<result>
<location>
<lat>35.3552806</lat>
<lng>138.7315222</lng>
</location>
<elevation>3457.9763184</elevation>
<resolution>152.7032318</resolution>
</result>
</ElevationResponse>

となります。ここからelevationの値をとり出してdistanceを決めてやればよさそうですね。
と言う方針で今後考えてみたいと思います。

蛇足ながら、この値を取得するために使用したPythonスクリプトは以下の通りです。

from urllib import urlopen

lat = 35.0 + 21.0 / 60.0 + 19.01 / 3600.0
lng = 138.0 + 43.0 / 60.0 + 53.48 / 3600.0
url = urlopen("http://maps.googleapis.com/maps/api/elevation/xml?locations=" + str(lat) + "," + str(lng) + "&sensor=false")
html = url.read()

print(html)

そんなわけでSoftimageの開発終了とサポート終了時期の明示と既存ユーザーへの対応が正式発表されてそれなりに時間が経ったわけです。現在のAutodeskのサイトに置かれている「よくある質問と回答」の内容はその発表時から変化なく、既存サブスクユーザーがMayaかMaxへの移行を選んだ場合、期限が過ぎるとSoftimageを使用する権利をうしなうとなっておりますが、Softimage Mailing listの方に投稿された記事によると、その制限を撤廃する方向で動いているようです。これについては正式発表待ちですね。

さてSoftimage。XSI以前の3Dから使ってきておりますが、僕が触った一番古いバージョンはおそらくSoftimage|3Dの3.5です。ただ、それはおそらく保守に入っていなかった環境だったんでしょうね。時代は既に3.7でしたから。ということでがっつり触ったバージョンは3.7以降でした。Softimage|3Dは3.7と3.8という小数点以下のアップグレードを行いつつ、さらにそれより小さい規模のアップデートであるSPでバージョンを重ね（しかも今みたいに毎年メジャーアップグレードがあってその中でSPが出るじゃなくて、年単位でSPが出る、みたいな）、すなわち保守をしているユーザーに、非常にコストパフォーマンスが悪いという印象を植え付け、その結果ユーザーが離れていきました。それがおそらく現在の状況に繋がる原因になっているんじゃないかって気がします。
XSIのリリースがもう2、3年早かったら状況は変わっていたでしょうか。

それにしても、どこに移行しますかね。
移行先として選ばれうる環境は思いつくところで

Autodesk maya
Autodesk 3ds max
MAXON CINEMA4D
NewTek LightWave
THE FOUNDRY MODO
Side Effects Software Houdini
Blender

ぐらいでしょうか。一番よさげなのはICE的な内容がSoftimage以上に充実しているHoudiniなんですけど、これは残念ながら初期コストと維持費が非常に高い。会社で入れてもらおうと思っても、なかなか厳しいものがあります。趣味レベルでやるなら非商用バージョンが非常にお安いので、自宅用はAutodeskを切ってしまうのも選択肢としてありかなぁとは思っています。そんな意味で、今年のAutodeskのサブスクは継続するだろうけど、来年はもう切るかもしれません。ちなみにAutodeskのソフトは、サブスクリプションに入っている場合、過去3バージョンを使用する権利を得られますが、サブスクリプションを切った場合、そのタイミングでの一番新しいバージョンのみを使用する権利となるようです。それより古いバージョンを起動するのは正確にはライセンス違反となるようですね。だから、つい最近Autodeskはアップグレードを廃止するという事を発表していますが、アップグレードで新しいバージョンを手に入れようとサブスクリプションに入っていない会社があったとして、その会社が複数バージョンのAutodeskアプリでの仕事を受けていた場合、建前上、ライセンス違反をしていた可能性があるわけっすな。
逆にコストがかからないBlenderですけど、こっちは初期投資は少なくともゼロなので、自分が動く手間を惜しまず時間を作れるのなら使ってみてもよいのですけど、躊躇するもんがありますね。
Autodesk帝国の手から離れてTHE FOUNDRYに身をゆだねてMODOという手もありますな。これはおそらく現在開発中のバージョンがTHE FOUNDRY傘下になってから初めて開発されるバージョンとなりましょうから、NUKEやMARI等のTHE FOUNDRYアプリとの連携やそのような映像方面に向けた機能の強化がどのように図られるか、今後に注目ですけど、まだ、移行する、というようにはなりにくいかな。
もっとも僕の場合はECSPに移行してしまっているので、既にmayaが起動する環境と言う事もあり、mayaってのが一番有力です。ECSPライセンスは強制的にECSUになることからmaxも使えるようになるわけだけど、触らないだろうなぁ…。釈然としませんけどね。職場ではだからmayaが一番のターゲットなんだろうなと思っています。
まぁ猶予はあるし、mayaを少しずつ触りながら、他のツールも触ってみつつ、でもSoftimageを中心に据えてしばらくやっていきますよ。
ちなみに僕は基本Mac使いなわけで、だから基本的にMac用が存在しないソフトは世の中に存在しないも同然なのです(^^) その唯一の例外がSoftimageでした。これを起動させるためだけにWindows PCを一台保持しているしParallels上でWindowsを動かしたりしているようなものです。だからもしかしたら数年後、Windows PCを触っていない自分ってのもありうるかもしれませんなぁ（まぁ仕事で使っているソフトの一つがどうしてもWindows上でしか動かないので触らなくなると言う事は当面あり得ないでしょうが、それは共用機にインストールされたソフト（ちょっと特殊なソフト）ということで、自席はWindowsじゃなくなってるかも…）。もっとも数年後、WindowsもMacも残っていなかったりして、って未来もありうるやもですが…