2008年3月1日土曜日

blender - ファイルフォーマットを書き換えたい(3)

注意:TOEIC400点、英検3級レベルの人が訳しています。
誤訳があるなんて当たり前だと思ってみてください。
むしろ全部訳しなおしてくれる人がでることを祈っています。

http://www.blender.org/development/architecture/

Data block types

All blocks as stored in the Main tree are called Library blocks (sometimes called Libdata). Library blocks all start with the ID struct:

すべてのブロックはMain treeに蓄えられ、Libraryブロックと呼ばれる。(たまにLibdataと呼ばれる)
Libraryブロックは全てID構造体から始まる

// ここにID構造体のコード

Let's take a closer look at one of the Library blocks, the Mesh. Of course such a block is actually a collection of many more blocks, either in arrays or as a List. Here we store the vertices, faces, UV texture coordinates, and so on (blue in picture). These blocks are called Direct Data. Such data is meant to be a direct part of the Mesh block, and is always written together with a Mesh or read back from the file.

さあ、MeshのLibraryブロックをまじまじと見てみよう。
もちろん、このようなブロックは実際多くのブロックのコレクションであり、配列かリストである。
ここに私たちは頂点、面、UVテクスチャ座標などを蓄える。
これらのブロックはDirect Dataと呼ばれる。
このようなデータは、Meshブロックの直接的な部分ということを意味し、いつもMeshと一緒に保存されるか、ファイルから読み込まれるかする。

Apart from this - permanent - data, there's also temporal data that can be linked to the Mesh, as for example the Display Lists. This data always is generated on the fly, not written in a file, and set at NULL when read from a file. Since all Library and Direct data resides in files too, it is important to design it compact, and leave temporal data out of it.

これ(永続的なデータ)から区別して、Meshへリンクできる一時的なデータがある。例えばDisplayリスト。
このデータは、いつも飛ばされて、ファイルに書かれないし、ファイルから読み込まれてもNULLがセットされる。
すべてのLibraryとDirect dataはファイルにあるので、小さく収めることと、一時的なデータを(ファイルから)取り去ることが重要である。

We now get to a very important rule in Blender's design: the usage of pointers inbetween blocks in Blender is restricted to pointers to Library data. This means a pointer to any Object or Mesh is allowed anywhere (in a vertex for example), but a pointer to a specific vertex cannot be stored anywhere.

This rule ensures a coherent and predictable structure, which can be used by any part of Blender code (especially for database management and files). It also defines how to make a decision when something should become Library Data; when you want it to be crosslinked (re-used) everywhere within Blender.

私たちは今、とても重要なBlenderの設計を得た。Blenderのブロック中でのポインタの使用は、Libraryデータへのポインタに制限されている。これは、全てのObjectやMeshへのポインタが、どこへでも許されることを意味するが、具体的な頂点へのポインタは、どこにも蓄積されない。

When files get saved, the Direct Data always immediately follows its Library Data. Since saved data can contain pointers these have to be restored when reading back. The pointer rule here helps with quickly restoring the pointers to all Direct Data, since these pointers only exist within a single and relative small context. Only the pointers to Library data are stored in a global list, and all restored at once in one call (lib_link_***).

ファイルが保存されたとき、Direct Dataはいつも、即座にそのLibraryデータに従う。
保存されたデータはポインタを含めることができるので、これらは読み込んだとき復活する。
ポインタは全てのDirect Dataへのポンタを素早く復旧するのに役立ち、これらのポインタは1つで比較的小さいコンテキストに存在する。
Libraryデータへのポインタはグローバルリストに蓄えられ、全ての復旧に1度呼ぶだけで済む。(lib_link***).

(NB: when adding game logic to Blender - Sensors, Controllers, Actuators - it was originally decided to have it reside within the Object context as Direct Data. Later on the need arose for having Sensors on Objects triggering Controllers in other Objects. This feature actually should make it Library Data, which wasn't done. A quite ugly patch for this was in a rush added to the file reading code. Until now it is still a disputed design issue; potentially the Message Actuator and Message Sensor should have been used instead.)

Sensor、Controller、Actuatorといった、GameLogicで加えられたものは、独自に、Object内にDirectDataとして持つことが決定した。後に、Object上のScensorが他のObject内のControllerをトリガするといった必要が生じた。この特徴は、実際Libraryデータにするべきであった。このための凄く不細工なパッチがファイルへ猛烈に加えられた。現在これは未だに争点となっている設計問題であり、将来的に、MessageActuatorとMessageSensorは取り替えられるべき)

External Library Data

One of the design requirements was being able to import data from other files, or have it dynamically linked as a sort of templates. Evaluating other 3D programs at that time (Alias, Softimage) I noticed they use the actual OS filesystem for it; creating 'project' directories with a directory tree inside and a single file for each data block. Apart from it being very clumsy and complex to maintain, I suspected it to be quite slow too. :)

設計に要求されることに、他のファイルからのデータインポートや、それがテンプレートのソートのように、ダイナミックにリンクされることであった。そのとき他の3Dプログラムを評価していて(XSIとか)、私はそれらがOSのファイルシステムを使ってることに気づいた。
->あるディレクトリtreeの内側に、プロジェクトディレクトリを生成することと、data blockごとに1ファイルあること。
とてもぎこちなく複雑に保持することは別として、私はとてもじっくり、それを疑った。

Nevertheless, Blender should have at least the benefit of this approach. The usage of names for Blender data therefore closely resembles that of a filesystem, with a Blender file being a group of directories containing all of the individual files.

それでもやはり、Blenderはこのアプローチの恩恵を受けるべきであった。Blender dataの命名規則は、それゆえ、ファイルシステムととても似ていて、Blenderのファイルは、ディレクトリのグループに全ての独立したファイルを含んでいる。

When using data from other files (dynamic linking), it is evident that only the Library Data blocks can be linked to. Blender then automatically reads its associated Direct Data. However, to make reading from extern files more useful, it also expands its full linked tree. For example a linked Object will also invoke reading its attached Mesh and attached Materials and Textures. Such expanded data is called "Indirect". In the interface you can recognize this with a red colored library icon. When saving to a file, such expanded (Indirect) data is not written at all. This enables the editor of the external file to change links to the Object, like adding an Ipo or add another Material.

ダイナミックリンクにより、他のファイルからのデータを使うとき、LibraryDataブロック群がリンクできることだけを確かめる。 Blenderは、それから、自動的にその想定されたDirectDataを読み込む。
しかし、もっと便利に外部ファイルを読み込むために、それをフルリンクされたtreeに広める。 例えば、リンクされたObjectは、それに付けられたメッシュやマテリアル、テクスチャの読み込みを引き起こす。このような広げられたデータは、"Indirect"と呼ばれる。
インタフェースでは、あなたはこのことを、赤い色のlibraryアイコンで理解できる。
ファイルを保存するとき、このように広げられたデータは、すべて保存されない。
これは、エディタで、外部ファイルのオブジェクトのリンクを変更すること (Ipoを加えたり、他のマテリアルを追加したりするような)を可能にする。

A typical usage of this feature is dynamical linking a Scene from another file. Whatever is in that Scene always will be read.

この特徴の典型的な使用法は、他のファイルからSceneをダイナミックリンクすることである。
どんな中にあろうと、Sceneはいつも読み込まれる。

While saving linked Library data, only its ID component is written. This ID then contains a pointer to the used "Library" (= external file), and the fact IDs have unique names then guarantees the links always restore correctly.

リンクされたLibrary dataを保存する間、そのID componentは書き出される。
このIDは、それから、使用されているLibrary(=外部ファイル)へのポインタを含んでいて、
だからIDは、リンクから全ての復旧を正しく行うために、一意の名前を保障している。


---
ふぅ、あと2章か…

0 件のコメント: