Alembic

Siggraphにつきいろんな情報が行ったり来たりしてますね。
LW10が出るだとか、SIがウンタラSuiteみたいな感じでサブキャラ扱いされ始めたとか、あれこれありますが、個人的にはついさっきGETしたこれが一番ヒットでした。

Alembic

Alembicは泣く子も黙るハリウッド最大手ILMとSPIによる共同開発のオープンソースプロダクト。
非常に興奮したので早いところ中身がしりたい!!!!と思い、無謀にも翻訳に挑戦してみた次第であります。

読む前に注意なのですが、何の情報もなく、上記のHPを読み解いてのみ得た情報です。
僕の英文読解能力はかなり乏しく、また、翻訳となると更に心許ないものです。
なのでかなりの部分、もしかしたら相当大きな部分ですら間違ってるかもしれませんが、そこはご了承ください。というかむしろ間違い指摘して頂きたいです。

という前置きはありつつ、一応個人的な理解には至った(気がした)ので、公開することにしました。
間違ってたら本当にごめんなさい。。

というわけで以下原文と、僕による超意訳型翻訳文です。どうぞ。

 
 
INTRODUCTION

Alembic is an open computer graphics interchange framework. It contains the infrastructure to support tools for collaboration management while also offering a generic, extensible data representation scheme. Alembic distills complex, animated scenes into a non-procedural, application-independent set of baked geometric results. This ‘distillation’ of scenes into baked geometry is exactly analogous to the distillation of lighting and rendering scenes into rendered image data.

Alembicはオープンなコンピュータグラフィックスインターチェンジフレームワークです。
共同作業の為のツールサポートのインフラ、拡張可能なデータ表現法を含みます。
Alembicは複雑さを取り除き、アニメーションシーンを手続き非依存にし、アプリケーション非依存のベイクされたジオメトリにします。(?)
この、シーンをベイクされたジオメトリに’distillation(蒸留)’することは、ライティングとレンダリングシーンをレンダーイメージに蒸留することと類似しています。

Alembic is focused on efficiently storing the computed results of complex procedural geometric constructions. It is very specifically NOT concerned with storing the complex dependency graph of procedural tools used to create the computed results. For example, Alembic will efficiently store the animated vertex positions and animated transforms that result from an arbitrarily complex animation and simulation process which could involve enveloping, corrective shapes, volume-preserving simulations, cloth and flesh simulations, and so on. Alembic will not attempt to store a representation of the network of computations (rigs, basically) which are required to produce the final, animated vertex positions and animated transforms.

Alembicは、計算済みの複雑な手続き型ジオメトリ構造を、効率的に保存することにフォーカスしています。
これはとても特定的で、手続き型のツールを使って作られた複雑な依存関係を保存する心配が必要ありません。
例えば、Alembicはエンベロープやシェイプ修正、ボリューム保存の為のシミュレーション、布や筋肉のシミュレーションなどなど、様々な、複雑なアニメーションやシミュレーションの、アニメーション済みの頂点位置とトランスフォームを効率的に保存します。
Alembicはアニメーションされた頂点位置とトランスフォームの最終結果を計算するために必要なリグなどのネットワーク情報などは保持しません。

 
WHAT IS ALEMBIC?

Alembic…

  • …Is a data representation scheme for storing computer graphics scenes
  • …Distills the results of artist disciplines for handoff to other artists in other disciplines
  • …Is focused on the greatest common divisor between applications, the ‘periodic table of cg primitives’
  • …Is extensible to support new workflows and new tools

Alembicは、

  • CGのシーン保存の為のデータ表現法です。
  • 作業の結果を別工程に渡すデータを蒸留します。(超意訳)
  • …Is focused on the greatest common divisor between applications, the ‘periodic table of cg primitives’ (全くわからん)
  • 新しいワークフローとツールの拡張をサポートしています(つまりどういう事?APIがある?)

Alembic Is Not…

  • …A dependency graph, nor a procedural data transformation tool
  • …A replacement for native application scene file formats
  • …An asset management application
  • …A general rigging storage solution

Alembicは、xxxではありません。

  • ディペンデンシーグラフ、または手続き型データの変換ツール
  • ネイティブなアプリケーションシーンファイル形式の置き換え
  • アセットマネジメントアプリケーション
  • リギングストレージソリューション

Alembic Would Be Used…

  • …To bake the results of an animated scene for hand-off to lighting & rendering
  • …To hand off an animated creature for cloth or flesh simulation
  • …To store the results of a cloth or flesh simulation for use in lighting & rendering
  • …To hand off animated geometry to a physical simulation engine
  • …To store the results of a physical simulation engine for use in lighting & rendering

Alembicが想定する用途は、

  • ライティング、レンダリングに渡すためのアニメーション結果のベイク
  • クロスや筋肉のシミュレーションにアニメーション済みキャラクタを渡す
  • ライティング、レンダリングで使用する、クロスや筋肉シミュレーション結果の保存
  • 物理シミュレーションエンジンにアニメーションジオメトリを渡す
  • ライティング、レンダリングで使用する物理シミュレーションの結果を保存

Alembic Would Not Be Used…

  • …To transport complex procedural animation rigs between different applications
  • …To make lossless round trips out of and into the same computation context
  • …To construct complex networks of procedural tools

Alembicが想定(対応)していない用途は、

  • 他のソフトに複雑な手続きアニメーションリグを渡す
  • …To make lossless round trips out of and into the same computation context (何の事か見当もつかない)
  • 手続き型ツールの複雑なネットワークを構築する

 
 
はい、英文にはかなり自信ありませんが、一応なんとなくは把握出来ました。

Alembicはおそらく、レンダリングやライティング、および各作業間でのデータのやりとりの際に複雑なデータをやり取りせずにすむようにするための仕組みです。
一番主なのはおそらくシーケンシャルジオメトリ(アニメーションとか全部ベイクされた連番ジオメトリ)に関する部分じゃなかろうかと思われます。

とにかく複雑さを排除した点、リグなどの構造は一切持たない点を強調しているあたりから、それは間違いないように思えます。

また、Google Codeの当該ページにある、RelevantFileFormatsの項を除くと、GTOなどのファイルフォーマットが見受けられます。

GTOはTweak Software社によるオープンソースなジオメトリファイルフォーマットです。
提供されているものは、そのままだとLinux上でしか動作しない点、RenderManとの連携にかなり重点がおかれている点などから、日本国内で使っているところはほぼないと思われますが、海外の大手では比較的導入が進んでいるフォーマットだとも聞きます。

OpenSceneGraphってのは初耳ですし、シーングラフというのが若干不穏ですが、スルーしておきます。
もしかしたら簡単なシーン情報を持ち運ぶための仕組みだったりとか・・・?
シーングラフという概念はゲームなど、リアルタイムの世界では一般的だけども映像の世界ではそうでもないとか勝手に思っていました。完全に違いますね。すみません。
どなたか詳細ご存知であれば是非ご教授願います・・・!!

 
にしてもILM&SPIは良くぞやってくれました。
僕がHoudini使いたいけど使えない理由のひとつとして、データのやりとり、というのがありました。
Mayaで組んだキャラクタをHoudiniに持っていくのは一苦労。かなりあれこれやる必要があって時間がかかる。ならMayaで良いや、となっちゃう。
もしAlembicを使って簡単にキャラクタやBG、プロップスのジオメトリベイクが出来る様になればもっともっと用途は広がる・・・!!

ってまぁGTOをWindows用に直して使えばいいんですけどね、、、
まぁ僕に出来るかどうかは別として・・・:P

ともあれ、こういったものが大規模なリリースとともに世に出てくれると、いろんな人の目に付くので開発もそこかしこで行われて、いずれはMaxだのSIだのともやりとりがしやすくなって、、とか。
勝手に良い様に良い様に考えてしまいますね。
わくわくしますな!

と、妄想は膨らむものの、現在まだソースコードはUPされていないようなので、
詳細を知ることは出来ません。
続報に期待、です。

 
余談ですが、翻訳中やたらと”distill”という単語を目にしました。
蒸留とかそういう意味らしいんです。
おそらくデータをクリーンに、という意味で使ってるんだろうなとは推測できるのですが、
なぜあえてこの言葉を用いたのか。
分かり易いから、か?

うーん、わからない。

やはり英語。英語が大事です。
がんばります。

——————————————————————————–(追記)
ますおさんもAlembicに関して詳しく書かれています。
* little things of mine * >> Alembic

うーん、わかりやすい。さすがです。

昨日見た時点ではソースも何もUPされてなかったのですが、C++のライブラリのなんですね。

で、早速ソースDLして眺めてみました。

うーん、誤解してましたね。
Alembicで用いるシーケンシャルジオメトリはメインがGTOなのかと思っていたのですが、独自形式っぽいですね。
.abcという拡張子のファイルを扱っています。
そのほかにもあれこれ扱っているみたいです。
なんか僕が思ってた以上に用途は広そう・・・?

うーん、もっとドキュメントとか欲しいところです。

何にしても今後に期待出来るプロダクトなのは間違いない・・・!
観察継続します。

「Alembic」への7件のフィードバック

  1. 各種レンダラ、ReLighting System、もしくはコンポジットにも大きく関わりますね~
    各社どこまで乗っかってくるのか気になるところですね

  2. “distill”…
    なんとなく僕は抽出するみたいな感じで捉えましたけど、比喩的な意味も含むんですかね。
    英語は”don’t think,feel!!”ってことですかねw

    Alembic楽しみです。実際、ソフト間のやりとりに頭を悩ませるのは不毛だし、本来バリアフリーでなければいけないと思います。長所を生かした使い方をバリバリするためには、スムーズな移行が大事だと思います。それを、独自のフォーマットで固めてしまうのは、ソフトが自分の首を締めてしまうのと一緒だと思います。
    実際、今MayaからHoudiniにキャラを持ってこようと思うと、FBXぐらいしかないですが、
    FBXもまだまだ実装が甘いですし、distillされたデータが欲しい時はbgeoを出したりしてます。早くサクっと出せるようになって欲しいものです。。

  3. こむずっかしぃ英文ですねぇ〜…。
    なんでこんなに分かりづらい表現を使うんですかね…。
    自分も分からない単語があったので、ちょっと挑戦したくなっちゃいました。

    …Is focused on the greatest common divisor between applications, the ‘periodic table of cg primitives’

    の”divisor”というのは、割り算で言うところの「割る数」なので、the greatest common divisorで、一番共通項の多い割り数=「最も標準化された」とでも訳すしか無いでしょうか。
    つまり、「アプリケーション間で最も標準化された物を目指しています。つまり…」となります。
    次の”periodic table”ですが、これは、原子記号のあの表(H, He, Li, Beというヤツ)の事です。
    …が、「CGプリミティブの元素記号表」とはどういう表現でしょうか、全く意味不明です…。

    次の、

    …To make lossless round trips out of and into the same computation context

    ですが、これは分の区切れる場所が分かりづらいのが問題だと思います。
    これは、
    …To make lossless round trips
    out of and into
    the same computation context
    の3つに分ければわかります。
    “round trips”で「往復」なので、ここは、「(データ)ロスのない往復」
    out of and into 「出て行く時と入る時に」
    the same computation context「同じ計算の一連の流れ(conputation contextをプログラマーの人ならなんて訳すのかわかりませんが…。)」
    つまり、「データロスのない、同conputation contextへの、インとアウトの往復作業をする事」

    …日本語にしてもよく意味わからないですよねw

  4. >チラオカさん
    まさにど真ん中ですよね。
    まずはレンダラ環境をどうにかしない限り、Alembicもあまり威力を発揮しなさそうな気もしています。
    もうMayaユーザもMaxユーザもみんなV-Rayでも使えば良いんでないかと思います!
    スタンドアロンも使えて高速だし使い方もそこまで難しくない、さらにライセンスも安いし将来も期待されている。
    現状購入可能なレンダラとしては、やはりこれしかないでしょう。
    AtomKraftもV-Ray対応考えてるみたいでしたしね!
     
    って回し者みたいだwwww
     
    >akimotoくん
    そうです。don’t thinkです。
    というか英和辞書の一番最初のを持ってきただけです。すみません。
    まぁでも意味通じるよね!

    Houdiniだとbgeoのおかげでシーケンシャルなジオメトリデータってかなり一般的なベイク方法なんだけど、他のソフトだとかなりイレギュラーと言うか、そんな文化自体無かったりするので、これを機に一気に広まってほしいところです。
    GTOはbgeo並みに高機能なフォーマットみたいなので、かなり期待してます。
     
    FBXはシーン情報のやり取りにはいいのかなと思います。カメラとかね。
    でもジオメトリはどうしてもリグとか複雑になるし、やはりジオメトリベイクが吉!
    ということでFBXとの良い住み分けも含めて期待しております:D
     
    でもやはり本領発揮はまともなレンダラ環境での使用なんだろうねぇ・・・(遠い目
     
    >Shun Imaizumiさん
    やっぱり小難しい感じですか、、、ですよね、、、
    ちょっと安心しましたw
     
    greatest common divisorというのは最大公約数のことらしいのですが、CGアプリケーション間の最大公約数とか、CGプリミティブの(元素の?)周期表とか言われても、何がなにやら、、という感じです、、、
    辞書の助けを借りつつなんとか訳は出来ても意味はわかりませんでした・・・ww
     
    To make lossless~、、の方はそうやって切るんですか!
    なるほど。勉強になります。
    言ってることは多分データのやりとりに関する利点なんでしょうけども、、全貌が明らかにならないうちはなんとも、、、
     
    うーん、、中身も見た上でちゃんと理解したいところです。
    ともあれ英語・・・!!が、がんばります・・・。

  5. “…Is focused on the greatest common divisor between applications, the ‘periodic table of cg primitives’”
    というのは、おそらく、「3DCGのソフト間でのデータの互換性の確保を焦点としている」
    という意味なのではないでしょうか

  6. “…Is focused on the greatest common divisor between applications, the ‘periodic table of cg primitives’”
    「CGアプリケーション間の共通項である”プリミティブ(頂点やポリゴン)のフレームごとのリスト”に焦点をあてている。」
    って感じですかね。

    意訳
    「どのCGソフトでもシーケンシャルなジオメトリやパーティクル扱うでしょ。
    それが、共通なフォーマット持ってたら扱いやすくなるでしょ。」

    distill(蒸留する)っていうのは色々混ざったものから必要なものを
    抽出することだから、リグやらの大量ノードネットワークがある中から
    本当に必要なもの(ジオメトリなど)を抽出するという意味では
    すごくあってる気がしますけどね。

    他社と共同作業するときにリグとか他社に公開したくないデータが
    ない状態で相手にデータを渡せるというもいいところなのかな。

  7. >miyaさん、inagakiさん
    お二方、しっかりした訳をありがとうございます。
    とても助かります!
    英語は大事・・・(遠い目

    ジオメトリキャッシュするよー、結果だけ持っていくよー。
    頂点情報だけだったらクリーンでしょ?

    ってぐらいのノリなんですかね、Alembic全体を通してのコンセプトって。
    メインはジオメトリベイクだと思ってるんですが、シーングラフに関するものもあるとかで、
    どこまでカバーするつもりなのかなーとは思っています。

    リグっていう観点で見たら確かにそうですよね。
    各社好き勝手に作業出来て、中身の共有も必要ない。
    うーん、今後は更にアウトソースだったりスタジオの分散化だったりが進むんでしょうかね。

    動向を見守っていかねば!と思います。

コメントを残す

メールアドレスが公開されることはありません。