スカルプテッド・プリム
ここではスカルプテッドプリムに関する情報を列記しています。
ここにある情報は限りなく正しいと思われる情報を書き込むが、実際には違うかもしれない。
しかし、私自身は限りなく正しいと考えています。
スカルプテッドプリムとは
32*23の頂点のそれぞれのオブジェクト空間の座標を記録して、その座標空間を24bitの色情報(r,g,b)として、保存したものがスカルプテッド・テクスチャーであるという説明が書籍では説明されているが、実はこれは誤りである。
３Dモデリングソフトによって抽出されたUVMAP情報をもとにUVテクスチャーマップを展開する。
この手順が一般的であるが、しかし、高度な３Dモデリングソフトなどを熟知しかつ使いこなせないとまともに3次元オブジェクトを作ることは出来ない。敷居の高い技術となっている。
WINGS3D、メタセコイアなどのフリーウェアにも一部スカルプテッド・テクスチャーを生成する機能、もしくは外部プラグインが存在する。
市販のペイントソフトを使って慎重に設計すれば、３Dモデリングソフトを使わずにスカルプテッド・テスクスチャーを作成することが出来る。
しかし、流布しているあやまった情報のために挫折する者も多い。
スカルプテッドプリムの原理
スカルプテッドプリムの原理は非常にシンプルである。コレを理解することはさほど難しくない。
しかし、一貫して頭に叩き込まなければならないことは、32*32の「頂点情報」を保存するわけではない。という点であり、32*32の「面情報」であるという点である。
スカルプテッドプリムの種類
スカルプテッドプリムには以下のように幾つかの種類がある。
1.
PLANE 板状のスカルプテッドプリム
2.SPHERE 球状のプリム
3.CYLINDER 筒状のプリム
4.TORUS リング状のプリム
PLANE
PLANEは板状のスカルプテッドプリムである。
扱う頂点情報は33*33となる。
面情報は32*32面が必要である。
SPHIRE
球状のプリムで、現在のクライアントバージョンSL-1.19.1.4においては通常の状態で、デフォルトでサポートされてるプリムである。
通常、スクリプトを使わない限りにおいて球状以外のスカルプテッドプリムを使用することは出来ない。しかし、次期バージョンでは全ての種類のスカルプテッドプリムが標準で選択可能となる予定である。
形状は板状の33*33の格子状のシートをまず、筒状に丸め、右端の頂点は左端の頂点と同じ行の頂点同士が同一座標に重なるように強制的に動かされ、事実上、情報としては捨てられる。
次に上端と下端の頂点を1点に集中させることで、球を表現する。
頂点情報の数は33*33-33-（31+31）＝994
面情報数は32*32となる。
CYLINDER
筒状のプリム。
形状は板状の33*33の格子状のシートを、筒状に丸め、右端の頂点は左端の頂点と同じ行の頂点同士が同一座標に重なるように強制的に動かされ、事実上、情報としては捨てられる。
頂点数は33*32＝1056
面数は32*32面となる。
TORUS
リング状のプリム。
形状は板状の33*33の格子状のシートを、筒状に丸め、右端の頂点は左端の頂点と同じ行の頂点同士が同一座標に重なるように強制的に動かされ、事実上、情報としては捨てられる。
次に列が同じ上端と下端の頂点の座標が強制的に同一座標に再配置され、下端の頂点情報は捨てられる。
頂点数は32*33-32＝32*32＝1024個
面数は32*32面である。
このようにそれぞれのスカルプテッドプリムは32*32の面情報を保存すれば、それぞれが相互に変換することができるという特性を持つ。
実は「面情報」の保存こそがスカルプテッド・テクスチャーの本質でなのである。
面情報とは？
面情報とは、面を構成する4点の情報のことである。
コレは33行33列の頂点情報をどう64*64ないし128*128の情報に変換するかという話にもつながる。
以下の図は頂点情報を面情報へと変換する際のプロセスを示している。
このように面を囲む、軸の頂点が持つ色座標をそのまま移動するだけである。
これが一番基礎となるPLANEスカルプトのテクスチャーマップの原理である。
このような操作を33*33の頂点に対して行うことで64*64のテクスチャーマップ
として変換が可能となる。
実際にSecondLifeはテクスチャーマップをどう読み込んでいるのか？
データの作り方としては上記でまず間違っていないと思われる。
が、実際には、面白い現象が起きている。
それは、適当な点をまったく別の色で１ピクセルだけ変更したテクスチャーを読み込ませても、SL上での表示になんら変化が現れない場合があるということだ。
すべての位置で起きるわけではない。
ただ、ある法則性にしたがってこうした不可解な現象が起きる。
上記の方法で作成したテクスチャーマップには実はかなりのデータの無駄がある。
１頂点を最大４ピクセルを使って、端の方では２ピクセルで表現したが、コレはデーターの格納方法として、非常に無駄が多いように思われる。
実験の結果だけいえば･･･作られたテクスチャーデーターに対してSLが利用している情報は実はきっかり３３*３３のような印象を受ける。
まぁそれでも球だったりトーラスだったり、シリンダーだったりするとまた話は変わってくるのだが･･･
基本的には６４＊６４ドット中SLが実際の読み込みで使ってるドット数は３３*３３でしかないようだ。
しかし、他のデータについて、まったくの無駄であるのか？
という点に関しては多少異論の挟む余地がある要に思う。
なぜなら次の画像のような場合が存在するからだ。
スカルプテッドプリム頂点情報に対する誤解が蔓延する理由は？
ずばり、誤解を含むのではあるが、正しい情報でも有るからだ。
それは、「必ずしも面と面を接して配置する必要がない」というものだ。
面同士がと接触しない場合はSL内部で補完が行われその分が引き伸ばされる。
しかし、補完された分はテクスチャーが不定形かつ強引に引き伸ばされるため、テクスチャーを作る際に作りにくくなる。
それは正常に面同士を接触させた場合と異なりテクスチャーマップ内に亀裂を生じさせるからである。
また、空間内にの座標軸の並びに対して昇順になってない座標の並びは裏側と認識され、インワールドではレンダリングされず透明化されることがある。
こうしたSLのある意味で柔軟性が「頂点情報の塊と考えても同じ」と誤解されそのまま説明された。
これは私の考える、誤解が蔓延した理由であろうと推測する。
まぁ、スカルプテッドに関する情報源が英語であり、一度定着してしまうと定説を覆すにはえらく手続きと時間が掛かるという日本独特の権威主義と言語的な壁の存在もまた理由としてあげても良いだろう。
#あの人のサイト
に書かれてだからそれでよいはずだというのは典型的な権威主義ではないだろうか？例外はマイクロソフト社の発表する文章に対してだけかもしれぬｗ
英語の情報原点となった人物が誤解して記述していたという可能性もあるだろう。(所詮はWIKIであるという話もあるが･･･)
英語圏の人間であれば複数の情報ソースからその矛盾に気が付く機会も多いが、スカルプテッドに４つの型が存在することもあまり知られてない事実の一つであるが、これも英語圏では比較的早期に知られていたようだ。
「･･･ようだ」というのは私の印象でしかないので、確証があるわけではない。
最終更新：2008年09月15日 13:52
