Autodesk Signs Agreement to Acquire Softimage

 今日一日、CG系 Blog はこの話題でもちきりでした。私は乗り遅れましたがorz

 Alias が買収された時もかなり驚きましたが、今度は Softimage ですか。これで名実共に Autodesk 帝国の できあがりというわけですね。

 それにしても、Autodesk が何をしたいのかサッパリわかりません。ゲーム系の強化?まあ確かに、ゲーム関係だと XSI のシェアが高いのはわかるんですがだからって XSI を買えばいいのか?っていうとそれも違う気がするし。

ユーザーからすれば、近い将来この三つのソフトが統合されて新しいプロダクトが発表されるのなら喜ばしいことなんですが反面開発速度の鈍化や価格の高止りの恐れもあるわけで、複雑な気持ちです。

まあ、正直なところハイエンド系アプリケーションは得意不得意があっても機能としては似たり寄ったりで近年は行き詰り感も感じてきているのでCG製作プラットフォームとしては統一してしまってもいいんじゃないかと思います。

…そのプラットフォームが糞じゃなければwww

その他ソフトウェアベンダーやCG製作会社は、そのプラットフォーム上で何如に商売をするかを考える時代になってるんじゃないかと思うのです。これまでもその傾向は強かったんですが、これからはもっともっと顕著になっていくのではないでしょうか。

そうすると気になるのが、我らが Houdini の存在です。 気持ち的にはこれからも独立して開発を続けて欲しいところではあるんですが、現実的には XSI 上の ICE のようにどこかのプラットフォーム上で動作する一ツールとして進化をする道も探っていくんじゃないかなと思います。今はまだ Houdini の能力を受け止めるだけの力を持ったプラットフォームが存在しないので独立して開発を続ける意味があるしそうでなければ存在できないですが、次の世代のプラットフォームが姿をあらわした時に大きな変化が起こるかもしれません。

なんでテクスチャファイルはcropしないといけないのか。JPGで圧縮したテクスチャはレンダリングを軽くするか。

この記事が気になっていたので、ちょっと考察してみました。実験はしてないんで本当にどうなってるかは要調査ですがww

・テクスチャを jpg にするとメモリ使用量は減るか?
→読み込む時に必ず全部のデータを展開しないとイメージが取得できないので非圧縮のデータと変わらない

・圧縮してあるテクスチャを読み込むとメモリ使用量が増える?
→元ファイル読み込み領域+展開領域は必要そう

・どんなファイルフォーマットでも同じ?
→TIFF の tile 分割形式のようなものをうまく扱うことをしていれば No。ただ、普通は libjpg やら libtiff を使ってるだろうからファイルフォーマットによって劇的にメモリ使用量が変わることはないんじゃないかと思う。

・使用しない領域もずっとメモリに展開しておかないといけない?
→No。レンダリング前にタイル分割をしたり mipmap を作っておけば、必要になった領域だけメモリに読み込むことが可能になる。

・他の方法は?
Mentalray のメモリマップドテクスチャのように、メモリに展開しなくても必要な部分だけ取得する方法はある。

---

理論的には、画像の一部しか使っていなくても全てメモリに展開しておく必要はなさそうです。実際の実装ではどうなっているかを知りたかったので、lucille のソースをちょっと見てみました。そうしたら
texture_loader.c にビンゴな記述が。どうやら、一度読みこんだデータを分割して使う仕組みがあるようです(圧縮してディスクキャッシュ化は未実装…?)ということで、メモリの最大使用量はテクスチャ展開後のサイズではあるものの、賢いレンダラはうまくやりくりするための仕組みがあるようです。

でも、ソースも無い状態でこれをきちんと検証するのは結構手間ですね。。。

---

その後いろいろ調べてたら、3Delight のテクスチャフォーマットが正に タイル化した TIFF のようです。更に mipmap 化したものをマルチイメージで持っています。これなら、タイル化の規則と mipmap 化の規則さえわかれば直接 3Delight 用のテクスチャが作れます。更に mipmap の生成アルゴリズムも自分でいじれるので、嬉しい人には嬉しいかもしれません。