Polyedit、メタセコで出力したパーツのマッピングが
異様に細かくなってしまうのですが。
こんな風に↓
http://park.zero.ad.jp/~zbk80769/map1.jpg
「平面マッピング」でいくら大きく指定してもです。

どうも、最初にL3のパーツアセンブラからSUF出力したパーツで
こうなるようなのですが。

建築系でマップのズレを解消するために
L3で基本パーツ配置→Polyeditでマッピングし直し→L3
という方法を試そうとしていたのですが・・・・。

問題のパーツデータもUPしときます。http://park.zero.ad.jp/~zbk80769/wall1.lzh

[この記事に返信]

直ってしまいました(笑)。
大騒ぎしてすみません。
しかし、atr・・・単なる色指定のファイルと思いきや侮りがたし。

で、結局こーいう事↓がやってみたかったのです。
http://park.zero.ad.jp/~zbk80769/d214.jpg
床のタイルを表現する場合、パーツの大きさが違うと
テクスチャがずれるので床を一つのパーツにしてテクスチャを貼ろうと。

[この記事に返信]

> えっ、ATRファイルっていうのは単に色情報だけで

↓最近は違う
http://isweb26.infoseek.co.jp/computer/ozap/mtol3/
私みたいに変な使い方する人以外はatrファイルは削除しましょう。

> > 選択するエリアを大きくする程マッピングは細かくなります。

あうッ、これは間違い、寝ぼけてたんだろうか．．

>問題のSUFファイルをメモ帳で開くと、

uvshade (x1 y1 z1 x2 y2 z2 u1 v1 ...
x1 y1 z1:点の座標
x2 y2 z2:法線のベクトル
u1 v1:uv座標（x1 y1 z1がテクスチャのどこに張り付くかという情報）

PolyEditを使用したならUV座標は256以上にもマイナスにも
なかなかならないと思うので-1021という値はどうやった
のか不思議．．

＞http://park.zero.ad.jp/~zbk80769/d214.jpg
いいねぇ、エレベータも作って、最近のスケルトンなタイプの
やつ。


[この記事に返信]

> Polyedit、メタセコで出力したパーツのマッピングが
> 異様に細かくなってしまうのですが。
> こんな風に↓
> http://park.zero.ad.jp/~zbk80769/map1.jpg
> 「平面マッピング」でいくら大きく指定してもです。
>
> どうも、最初にL3のパーツアセンブラからSUF出力したパーツで
> こうなるようなのですが。
>
> 建築系でマップのズレを解消するために
> L3で基本パーツ配置→Polyeditでマッピングし直し→L3
> という方法を試そうとしていたのですが・・・・。
>
> 問題のパーツデータもUPしときます。http://park.zero.ad.jp/~zbk80769/wall1.lzh
>

PolyEditで「マップ･シェード」のメニューの「簡易マッピング」の
係数を大きく（今回は１０）に設定。L3付属のパーツデータコンバータ
でマッピング形式を「平面（前から）」にして再度保存しました
ところ、
http://www.gem.hi-ho.ne.jp/h-kouzuki/others/report.JPG
このような感じになりました。しかしなぜか横長になってますね…

そのままコンバータにかけずに行ったところ、マッピング面指定が
悪いのか、変なことにしまいました…
http://www.gem.hi-ho.ne.jp/h-kouzuki/others/wall1.JPG

[この記事に返信]

> > Polyedit、メタセコで出力したパーツのマッピングが
> > 異様に細かくなってしまうのですが。
> > こんな風に↓
> > http://park.zero.ad.jp/~zbk80769/map1.jpg
> > 「平面マッピング」でいくら大きく指定してもです。

Taichiです、宍戸幸次郎さん、BlueFoxさん、こんばんわ

メタセコのsuf出力時に拡大率10倍、ATRファイル出力無しで再出力。
（マッピングは、平面。「現物にフィット」させました）
Ｌ３で取り込んだところ、BlueFoxさんの画像

>http://www.gem.hi-ho.ne.jp/h-kouzuki/others/report.JPG

↑とほぼ同じ結果が得られました。

マッピング画像が横長になってしまうのは貼りつけたマッピング画像
である「市松」が正方形の為、Wall1.sufの縦横比に強制されてしまう
為と思われます。
正しく貼りつけたい場合はWall1.Sufと同じ縦横比のマッピング画像を
用意する必要があります。


[この記事に返信]

メタセコでマッピングが細かくなるのは、wall1.atrと言う
ファイルが同フォルダ内に有るからでは？＜削除

PolyEditで出来ないのは単にマッピングを失敗してるだけでは？
選択するエリアを大きくする程マッピングは細かくなります。
↓PolyEditでマッピング張りなおし、L3で模様密度100%で
http://isweb26.infoseek.co.jp/computer/ozap/wall01.JPG


[この記事に返信]

> メタセコでマッピングが細かくなるのは、wall1.atrと言う
> ファイルが同フォルダ内に有るからでは？＜削除

えっ、ATRファイルっていうのは単に色情報だけで
マッピングに関しては無かった筈ですが・・・。

> PolyEditで出来ないのは単にマッピングを失敗してるだけでは？
> 選択するエリアを大きくする程マッピングは細かくなります。

ありゃ、きちんとマッピングされてますねぇ。
エリアが大きく(パーツが大きく)なりすぎると
テクスチャの大きさは反比例して小さくなる、という仕様なのでしょうか?

[この記事に返信]

問題のSUFファイルをメモ帳で開くと、

atr BodyM

prim	uvshade	(	-8	-951	701	0	0	-256	-1021	-1533
			8	-951	701	0	0	-256	-1021	-1533
			8	-984	701	0	0	-256	-1061	-1533
			-8	-984	701	0	0	-256	-1061	-1533 )

prim	uvshade	(	-8	-951	634	0	0	-256	-1021	-1362
			8	-951	634	0	0	-256	-1021	-1362
			8	-984	634	0	0	-256	-1061	-1362
			-8	-984	634	0	0	-256	-1061	-1362 )

prim	uvshade	(	8	-951	667	256	0	0	-1021	-1446
			8	-984	667	256	0	0	-1061	-1446
			8	-984	634	256	0	0	-1061	-1362
			8	-951	634	256	0	0	-1021	-1362 )

と、こういうのがズラズラーッと並ぶのですが「uvshade」が
マッピングを指定する部分だとすると、
他のパーツファイルに比べると「uvshade」によって区分けされている
列が異常に多い・・・。
だんだん訳が分からなくなってきました(笑)。

[この記事に返信]

データをちゃんと検証してないのでややナニですが…。

> えっ、ATRファイルっていうのは単に色情報だけで
> マッピングに関しては無かった筈ですが・・・。

ATRファイルは思いっきりマッピングに関係しています。
テクスチャの画像ファイル情報はこのファイルに指定しますし、
ポリゴンに貼られたUV座標とテクスチャ画像範囲の関連付け、
といった情報もこれにしっかり書いています。

またパーツと同じフォルダに同じ名前のATRがあると、L3はそれを
優先的に読み込みますので同じフォルダに怪しいATRが存在してい
ると思ったようにレンダリングできなくなることはあります。

さて、PolyEditはデフォルトでLシリーズに相性のよいUVを貼ります
が、メタセコイアではデフォルトでUVの範囲が異なった値になってい
るということがあったような気がします。
#ていうか、そもそもメタセコの出すATR、なんだか変だぞ？

この状態でメタセコイアでアトリビュートを保存してしまうと、上記
の問題が発生する可能性は十分考えられます。

とりあえず、L3使うならテクスチャはPolyEditで貼りましょー。


[この記事に返信]

なお、L3では操作性を簡略化するために実はまだイロイロ捨ててま
すので、

> またパーツと同じフォルダに同じ名前のATRがあると、L3はそれを
> 優先的に読み込みますので同じフォルダに怪しいATRが存在してい
> ると思ったようにレンダリングできなくなることはあります。

これを逆手に取ると、独自の質感設定でお友達を出し抜けること請け
あいです。たとえばアンビエント、ディフューズなどたいていの
パラメーターはRGB別に指定できたりとか〜。（をい）


[この記事に返信]