Poly to Poly
Main/History
GraphiX
LScript
Plugin
Knowledge
Blog

 [ ○仕様面 ○八苦 ○バグ/問題対策 ]
 [ LW-SDKメモ ○クラスリスト ○グローバルリスト ○ビルドNo. ]

 覚え書き(071001)。 マニュアルと重複するものもあり。

◇モデル付加情報

●UV補間タイプ[8 & 9]
 VMPA { sizeU4, 補間タイプU4, 色U4 }
 VMADをサポートするVMAPに対して付与されるぽい。 実質的にsizeは00 00 00 08 固定?
 UVの場合は補間タイプと色はリストの先頭が[0]としての順番。 初期値は0/Liner、Grayなら6。
 エッジウェイトやAPSLの場合はゴミデータ?
 7.5以前で読み込み/保存をするとVMPAは消滅。8以降で再度読み込んだ際に初期値で補完される。

 同名UV MAPに対する最後の更新(編集や読み込み)が優先され、「モデラ上にある別ファイルのUVであっても同名MAPであれば勝手に変更される」
 なので、補完方法毎にUV名を変える等、複数のUVMAPを持つ必要が出るかも。
 勝手に改竄された事に気づかず作業を進めると致命的な結果になりうるから注意。

●スケッチカラー。
 PTAG { type COLR, poly[VX], tag[U2]* }
 7.5では任意だったが8.0でポリゴン生成時に強制的に付与されるようになった。
 KnifeTool等でポリゴン生成がされる時、初期設定色で上書きされる。
 スケッチカラーToolでは消せない。 LScriptからも触れない。
 現状、消去出来るのは「Point/Polygon Info」のみ。
 無闇な色付けは無駄にデータが太るだけで得るもの無し。

●エッジウェイト[9]
 通常のWEGT属性のVMAP。 但し、参照されるのはVMAD部のみ。

●APSL(アダプティブなんちゃら関係)[9]
 VMAD{ type APSL, dim 1, name APS.Level, vert[VX], poly[VX], value[F4] }
 プリミティブポリゴンの生成時には付かないみたい。
 一度でもサブパッチにすると付く。 VMPAも付与される。
 明示的に消さない限りVMAP/VMADをサポートするモデラ(6.5?)では消えない。

◇モデラ動作

●モーフの編集。
 選択範囲内の頂点全てに「編集行為」が作用する。編集行為の際、選択された頂点内にモーフマップが割り当てられてない頂点があると0が割り当てられる。
 意図的に頂点を選択していない状態は「非選択」ではなく「全選択」と同等なので、頂点を選択せずに編集すると全頂点にモーフマップが割り当てられるという事。
 但し、無駄なモーフデータでモデルが肥大化するのを厭わないのであれば気にする必要はない。
 1Skinモデルの顔に多様な表情付けをするだけで、ジオメトリの数倍のファイルサイズになるけどね(・з・)

●VertexPaintのversion。
 LW 8.2以前は3.5.4、LW 8.3は3.5.5、LW 8.5は3.5.6(Newtekに移管?)、LW 9.0は3.5.6、LW 9.2は3.5.6(2006/6)、LW 9.3は3.5.6(2007/5)
 3.5.6の内部記載日時は変わってるけどCopyrightは2005で止まってる。
 LW 9.2と9.3に添付されているver3.5.6はLW 9.2のLWS4形式のシーンを扱えない。

◇レイアウト動作

●VMAP補完。
 接続した面(頂点)全てに同一UVマップが割り当てられていれば問題はないが、ステッカーの様にピンポイントでテクスチャを張ろうとして局所的に不連続UVを使う場合、問題を起こしうる。

 面倒な場合は全てに同一UVマップを割り当ててしまえば楽。 但し、頂点追加や再分割等によるUVの変化を管理しないと意図しない結果を招く事になる為、注意が必要。 また、LWOファイルは肥大化する。

 必要な面だけにUVを割り当てる場合、必要な箇所+一回り大きい範囲(余白)にUVを割り当て、必要な面と余白面を不連続UV化させる。
1-2-3-4 
|B|B|B|
5-6-7-8
|B|A|B|
9-a-b-c
|B|B|B|
d-e-f-g
 頂点1〜g、テクスチャマッピング対象面をA とする。
 頂点1〜gへUVを割り当て、それ以上の範囲へはUVを割り当てない。
 頂点6,7,a,b,のUVをUnweld後に不連続化させ、6A,7A,aA,bA、6',7',a',b'とする。
 6A〜bA以外(Bの面)に対して<0,0>を与えておく。 Bの外周に接続する点/面のUVはモデラ上で不定になるが、レイアウトでは0で補完される。 補完値0とBのUVでマッピングされるが、Bは0なので余計な画素が拾われる事は無い。
 但し、一部のプラグイン(Unreal等)では不都合が出る。 その際は接続した頂点全てに同一UVを割り当てるしかない。

 6,7,a,bのみにUVを割り当て不連続化すれば、より一層無駄が出ない様に思えるが、不連続UVは頂点ではなく面が持つデータの為、面BがUVを持たなくなってしまう。
 その状態では6,7,a,bをマージした再に6',7',a',b'が消失してしまい、6,7,a,bのVMAPとしての値を引き継いでしまう。
 するとレイアウトで補完される値0と結び成されるマッピング状態が面BのUVとして適用され、余計な画素を拾う原因となる。

●局所的なモーフ。
 未割り当ての頂点に対しては基本的にレイアウト上で補完される為、必要な個所のみにモーフマップを付ける事でLWOファイルを軽量化出来る。
 但し、モデラは補完をしてくれない(モーフに限らずウェイトも)。
 LW8のレイアウトのウェイト表示は補完した表示がされない。
1-2-3-4 
| | | |
5-6-7-8
| |  | |
9-a-b-c
| | | |
d-e-f-g
 6に0以外の値が付与されている場合、1,2,3,5,7,9,a,bに明示的に0を付与しないとサブパッチのFreezやナイフ等での再分割時に値が補完されない。。
 その為、0以外の値を付与した頂点の周囲の頂点には終端記号として0を付与するのが好ましい。
 但し、面が四角である限り、更なる外周に対しては割り当てる必要はない(4,8,c〜には不要)。
         4 
        /|
      7-8
     /| |
   a-b-c
  /| | |
d-e-f-g
 三角を含む場合は話が変わってくる。 三角の場合は構成する頂点のいずれか1点にでもモーフが付与されていた場合(値は問わない)、他の2点にもモーフを付与する必要がある。
 これを怠るとプレビューやレンダリング時に不正な筋や影が出る。
 gに0以外が付与されている場合、b,c,fに0を付与すれば良いと思われるが、bは三角を構成する頂点なのでその三角に属する7,aにもモーフを割り当てないといけない。
 さらに7,aは別の三角を構成する頂点なので、4,8,d,eにも連鎖的にモーフを割り当てる必要が出てくる。

●親子組換え時のスケール値の変化。
 親子関係を組替えるとスケール値が変わる。
 浮動少数の誤差の範囲と思われるが、XYZバラバラの変化なので、組替える毎に適宜リセットしておかないと、階層の深さによっては滅茶苦茶な状態になる。