Philosophy of Hiroshi
memlogさんの記事より。
VisualWorks、何やるんだろう?募集要項を見ると、すごく面白いことができそうな気がするんだけど。社内でピンで技術屋をやるのも面白いけど、VW みたいに大規模な体制で時間とお金をかける開発仕事も魅力だよなぁ。無い物ねだりなんだろうけど。
カタログスペックだけだったら(w 受かるなぁと思いつつ、ほんとに受かるのぉ?という気持ちもありつつ、どんな会社なんだろう?という興味もあるものの、結局今の仕事があるから受けることはできないんだけど。そもそもゲームとかしない(し、興味もあまりない)んでVWに行ってもどうなんだろう?っていうのもあるし。
でも、魅力的な求人なのは確か。ウチの会社だと、こんな求人は出せそうもないなというのが一番の問題かも。
メモリ2Gのマシンだと50万が限界なのに、8Gだと1000万でも余裕って。まじですか。。。20倍の差とかになると、工夫とか技術とかより遥か以前の問題だなぁ(涙。これを描画するためにもハイスペックなビデオカード使ってるだろうしどんなスペックのマシンなんだろうか?
今までいろいろなエラい人の話とかコンサルな人の話を聞く度に違和感を感じて、何とかそれを伝えようとしても説得力を持って伝えることができなかったのですが、この記事が全てを語ってくれています。
世の中のエグゼクティブ(笑 な方々は大層トヨタ方式がお好きなようで、何かある度に”トヨタが云々”とか”見える化が云々”とか言っているのですが、結局は聞きかじった事柄だけを鵜呑みにして、”世界一の企業がやっているんだから真似をしないと!!”という的外れなことを言ってるだけだったりします。私はそれを聞く度に「あなたの会社は”世界一の会社”なんですか?」と問い正したくなります。
この記事でも言及されているように、
違う土地には、違う樹木が育って、ことなる実を結ぶ。それがどのような形のものかは、あなたと私が自分で必死に考えなければならないのだ。
この視点を欠いたままトヨタ方式を真似したとしても、文字通り百害あって一利無しにしかならないのに、何故それが判らないのか。そちらのほうが不思議です。
もちろん見習うべき点は積極的に取り入れていくべきですが、それだって自分達が置かれている状況と照らし合わせて考察を繰り返せば、全く違った解決策に辿り着くことも多々あるはずなんですよ。むしろ同じ手法になるほうが不自然だと思いませんか?
トヨタ信者の経営者やコンサルタントは、この文章を 100回音読してください。話はそれからです。
Fluids Technical Evening – Side Effects Software Inc.
Houdini で作る Fluid を始めとしたダイナミクス系のチュートリアル。シビレル!!
こういったシミュレーション的な表現は3dsmax でも似たようなことはできないこともないけど、プラグインをじゃんじゃん買ったり、力技で何となくそれっぽい形にしたりとトホホ感が漂うのが切ないのです。
ParticleFlow のダメさもトホホ感に拍車をかけているわけで、このチュートリアルでやっているようにパーティクルからメッシュを生成して、そこから更にパーティクルを発生させてしぶきを作るなんて芸当を max+ParticleFlow でやろうとしたら絶対落ちます。私が試したんだから間違いない(笑
こういうデモを見ると Houdini 使いたい!!って思う。ここまで使いこなせるようになるまで大変なのはわかるんだけどネ。
最近は LL Language ドップリな chiyama ですこんにちは。
こんなことをいきなり書くのも、id:ryocotan の日記を読んだからなんですけどね。
http://d.hatena.ne.jp/ryocotan/searchdiary?word=%2a%5bWebcco%5d
この職業占い(?)の選択肢、選択に困る人って多いんじゃないでしょうか? IDE と Emacs/Vim と言われても、私はコーディングは Emacs じゃなきゃ発狂するし、かと言ってデバッグで gdb 使えと言われてもそこは VisualStudio のデバッガ使いたいじゃん?みたいな。VisualStudio って、存在意義の 95% はデバッガですよ。と言うか gdb 使い辛いッス(涙。私の場合、年がら年中コード書いてるわけじゃないんでコマンドを忘れたら何もできないのは勘弁。コマンドを覚えてたら最強のツールなんですけどね。
LL Language も同じくで、とにかくメモリ管理とか考えずにガシガシ書くぜオラオラオラ!!っていう時には LL Language 最強なわけですが、結局どこかで C/C++ で書き直したくなる時が来るんですね。私の経験上。ある時にはパフォーマンスの問題だったり、ある時には使いたいライブラリの問題だったりするわけですけど、やっぱりできることの幅は C/C++ の方に分があるわけです。じゃあ最初から C/C++ で書けば?って話になるかと言うと、立ち上がりの面倒臭さが災いしてそんな気になれません。#include
結局何が言いたいかと言うと、これらの間を取り持ってくれる何かって無いのかなぁ?ということです。VisualStudio のキーバインディングを Emacs 化してくれるようなものがあるのは知ってるし試したことはあるんですが、どれもこれも中途半端で逆にストレスが溜まるだけで結局不自由でも規定の環境がいいやってことになるんですよね。
LL Language と C/C++ の橋渡しの話もそうで、LL Language でザクザクとプロトタイプを書いた後、C/C++ で本格的に開発していけるような環境って無いものかなぁ?と思うわけです。最近触っている Processing はちょっと 有望かも?と思っています。これが Emacs から直に実行できて、かつ C/C++ へのトランスレータが 用意できたら今ある要望は満たせるかもしれません。あとは 3DCG 関係に限って言えば Maya がいい感じですね。こちらは完全にシームレスっていう訳ではないですが、 とりあえず DG+python で検証して、その後 C/C++ 化というのがしやすくなっています。
ここらへんの環境の谷間的分野は何となく次の解決策への道筋が見えてはいるものの、まだ未整備な状態なんですよね。あまりにもニッチすぎて誰も手をつけていないとも言えるんですが(涙。
去年の夏から Houdini 熱にとりつかれていたものの、vaio じゃ動かないし OSX 版の Houdini も無いしということで 触れないまま悶々としていたんですが、ゴニョゴニョと工夫することで何とか動かすことができました 🙂
chiyama@osx>xhost +
chiyama@osx>ssh ubuntuchiyama@ubuntu>setenv DISPLAY osx:0.0
chiyama@ubuntu>cd /opt/hfs9.1.179
chiyama@ubuntu>source houdini_setup
chiyama@ubuntu>houdini
やってることは VMWare Fusion 上で Ubuntu を動かして、そこで Houdini を立ち上げ、表示は X Forwarding を使ってOSX 上の XDarwin で表示しているだけなんですけど。これなら OpenGL を使うアプリケーションでも問題なく表示できるので Houdini もサクサク動いています。
最初は ssh の X Forwarding 機能を使っていたんですが、これを使うと意外とパフォーマンスに影響が出るらしく、直に転送してしまったほうが体感できるぐらい速くなります。
一部、メニューのボタンとかマウスカーソルの表示がおかしかったりしますが、我慢できる程度なので割り切って使っています。
これはすごい。Blender でここまでできるようになってるんだなぁ。
これはもう、CG ツールもコモディティ化の一途を辿るばかりですね。