Raw Importは、バイナリファイルを読み込んで、その中のデータを表現したDetailアトリビュート、Pointアトリビュートまたはボリュームを作成します。 これには、データのビット深度やエンディアン(バイト順序)などのファイルレイアウトの正確な仕様が必要です。
読み込みはブロック単位で行なわれ、指定されたブロックのみが読み込まれます。 一部のファイル形式では、複数個のRaw Importノードが必要になります。 例えば、1つ目のRaw Importノードでヘッダ情報を読み込み、それ以降のRaw Importノードでは、Ignoredブロックを設定して、読み込む必要のあるデータを取得します。
テキストデータに関しては、
Table Import SOPを使用すると良いでしょう。
パラメータ ¶
Raw File
読み込むファイル。
Reload Geometry
ファイルの再読み込みと再クックを発動します。 ディスク上のファイルに変更があった場合に役立ちます。
File Layout ¶
Endianness
Rawデータの バイト順 。 すべてのデータが1バイトでない限り、そのデータが作成された方法に基づいて、これを設定する必要があります。 データを作成したプログラムが採用している“エンディアン”を調べること以外で、これを何に設定するべきか知る術はありません。 ただし、“Little”(デフォルト)が最近のシステムでよく使用されています。
Little (Intel)
マルチバイト数値内の 最下位(Least Significant) バイトが最初になります。 これは、最近のアーキテクチャ(IntelやARM)の通常のメモリレイアウトに一致するので、使用頻度が高いです。
Big (Network)
マルチバイト数値内の 最上位(Most Significant) バイトが最初になります。 これは、場合によっては“ネットワーク順序”と呼ばれ、ネットワークプロトコルでは一般的ですが、それに限りません。
ガリバー旅行記で、そのタイトルの名前の主人公が小人の国に漂流した話を皆さん知っていると思いますが、 その島の国々がなぜ戦争をしていたのかを思い出せないのではないでしょうか。 これは、卵を割る時に、小さい方から割るべき派と大きい方から割るべき派に対立したのが原因でした。
コンピュータ科学の世界でも同様の問題が起こりました。 マルチバイト値を格納する時、あなたは大きい部分を先に格納するのか？それとも小さい部分を先に格納するのか？
Point Count
ファイルからPointアトリビュートを読み込む場合、そのアトリビュートを格納するためのポイントを作成する必要があります。 これは、そのポイントの数の決め方を制御します。
No Points
ポイントは作成されません。 この場合、Pointアトリビュートブロックはありません。
Specific Points
指定した数のポイントが作成されます。 ポイントベースのブロックすべてがこのサイズになります。
From Header
ブロックがDetailアトリビュートを作成する場合、そのDetailアトリビュート値を使用することで、ポイントの数を設定することができます。 これによって、ポイント数がファイルに埋め込まれている場合にマルチパスを実行する必要がなくなります。 Detailブロックは、最初のPointブロックより前に配置する必要があります。
From File Size
ほとんどのファイルソースは、ファイルサイズを決定することができます。 これが可能な場合、他のすべてのブロックを考慮した後の残りの容量を計算することで、ポイント数を推測することができます。 これは、HeaderブロックまたはTrailerブロックが、残りのバイトをPointアトリビュート間で配分できるように適切に定義されている必要があります。
Number of Points
作成するポイント数。
Point Count Attrib
Detailブロックによって作成されるDetailアトリビュート。 この値は、作成するポイント数を决めます。
Number of Blocks ¶
Block #
ブロックの名前。 これは、DetailブロックまたはPointブロックではアトリビュート名となり、Volumeブロックではボリューム名となります。 Ignoredブロックに関しては、ブロックを出る理由をコメントするのに役立ちます。
Import Target
ブロックから読み込まれたデータの配置先。
Ignored
データは、無視されます。
Detail Attribute
データは、Detailアトリビュートに格納されます。
Point Attribute
データは、生成されたすべてのポイントにわたってPointアトリビュートに格納されます。
Volume
データは、ボリュームに格納されます。
Tuple Size
データエレメント毎のエントリー数。 Pointアトリビュートの場合、“P”アトリビュートは最大3のサイズでなければなりません。 同様に、浮動小数点ボリュームは、1～4のタプルサイズにのみ対応しています。
Type
このブロックに格納されるデータのタイプ。
Float
浮動小数点値。
Integer
整数値。
Precision
各値が格納されるビット数。
8-bit
整数の場合、これは0から255の符号なしの値です。 浮動小数点の場合、0から255の符号なしの値は、0から1の浮動小数点値に呼応します。
16-bit
整数の場合、これは-32768から32767の符号付きの値です。 浮動小数点の場合、これはbinary16またはbfloat16のどれかです。
32-bit
整数の場合、これは符号付き32ビット値です。 浮動小数点の場合、これはbinary32浮動小数点表現です。
64-bit
整数の場合、これは符号付き64ビット値です。 浮動小数点の場合、これはbinary64浮動小数点表現です。
Use BFloat16
通常の16ビット浮動小数点表現(Halfと呼ぶことが多いです)で、binary16です。 これは、値の範囲と精度の両方を削減して浮動小数点をもっと少ない容量で格納する方法として、OpenEXRやOpenVDBで使用されており、Houdini内部でも使用されています。
BFloat16は、binary32の切り捨てバージョンで、値の範囲はそのままに、精度を8ビットに削減されています。 これは機械学習でよく使用されています。
Collate with Previous
ディスクからPointブロックを読み込んだ時、他のPointブロックと交互配置(インターリーブ)するか、独自の連続ブロックを形成するのか指定することができます。 そのブロックが丁合(Collated)されるものだとマークされていない場合、独自の連続ブロックを読み込みます(場合によっては、Collatedとマークされている連続ブロックを含みます)。 そのブロックが丁合(Collated)されるものだとマークされている場合、丁合されるすべてのブロックは、各ポイントと次のポイントを交互に順々に読み込まれていきます。
Volume Resolution
読み込むボリュームの解像度。
軸が-1の場合、それは動的として扱われます。
動的な軸は、(利用可能ならば)合計ファイルサイズの残りを受け取り、それを動的な軸で均等に割ることで決まります。
したがって、2つ以上の軸が動的である場合、ボリュームは偶数の正方形または立方体でなければなりません。
Volume Order
バイナリ数値の エンディアン と同様に、ボリュームデータをX軸を最初に置くべきか、Z軸を最初に置くべきかの対立があります。 ボリュームデータを読み込む場合、そのデータを作成したプログラムで使用されている規則に基づいて、これを設定する必要があります。
ZYX
Z軸は最も外側のループです。 ファイル内の連続エレメントは、連続したX値です。 これは、Houdiniの内部ボリュームレイアウトに合致します。
XYZ
X軸は最も外側のループです。 ファイル内の連続エレメントは、連続したZ値です。 これは、OpenVDBの内部ボリュームレイアウトに合致します。
| See also |
