食い寝るえぃだぁ～

ROKURO ProやWings 3Dではきれいに見えているのにSLではガタガタってことありませんか？

あたしゃ、いつも悩みます。初めのころは、ROKURO Pro制御点とかNURBS(Non-Uniform Rational B-Spline)とかいろいろ調べました。sculpt textureも自分なりに直接作ったり してみました。玉砕の日々でした；；

このように、登れる、美しい、離れても階段なスカルプトプリムが恒常的 に使える日が来るといいのですが........ 今は「美しい」が叶いませんねorz

ここでは、ガタガタの原因と、それをいかに抑えるかについて述べたいと思います。
毎度ですが、ここで述べる内容も思い込みにより間違いの可能性があります:ｐ

分解能

Wevefront OBJについてでも述べた通り、 sculpt textureは色で座標を表します。x,y,z座標はR(ed)、G(reen)、B(lue)の各成 分で表現します。ROKURO Proでは0～254までの値を使ってOBJの-1～1の値を表現して います。OBJ上では2/254(＝1/127＝0.007874)が分解能になります。この倍数でない座標はSL上(sculpt texture上も)どこかに強制移動させられます。

例えば、頂点座標が
 v 0.007800 0.0 0.0
 v 0.007000 0.0 0.0
 v 0.006000 0.0 0.0
となっていても、これらは、sculpt texutreの色成分としては恐らく同じ値になります。

OBJ変換ツールは、離散座標(grid)に頂点を移動する機能があります。 ROKURO Proだけで作る場合ははじめからgrid指定しておけばよいです。

次の図は、一番奥の赤い図形が「とりあえず完成」、真ん中の緑が「grid処理後」、 一番手前は「SLでの見栄え」です。
* grid処理後の図形は、次で述べる最大化処理後、grid処理して、比較の ためにリサイズしたものです
grid処理した緑が、SLでの見栄えとほぼ同じであることがわかると思います。要するに gridを使っていない場合、赤図形→SL図形となるわけですから、 それなりにガタガタになるということです。SLに持ち込む前に grid処理して確認するのがよいでしょう。我慢できなければ修正するしかありません。

最大化処理

最大化とは、各軸の最小、最大値をそれぞれ-1,1にマッピングすることで、255 の離散数値を図形にマッピングできます。最大化しないとどうなるでしょう。

最大化しない場合は、各軸の最小、最大の間にあるgridしか使えません。次の図は、 上側が最大化しない場合、下側が最大化処理した場合、場合の見栄えです。

次の図はテクスチャを貼り付ける前のものです。

左は、最大化なしでSLに持ち込んだ図形です。右は、最大化して SLに持ち込んだ直後の図形で、これをSLでリサイズすれば真ん中の図形になります。

SLにもっていった後、一手間がかかりますが、最大化した方がより細かな表現が 可能になります。

画像解像度

次に、sculpt textureのサイズについて比較してみます。

まずは、ロスレス圧縮なしの場合です（画像アップロードの際に「ロスのない圧縮を使用」をチェックしない場合)。 つまり、アップロード時にリンデンのサーバ側で圧縮されるということです。
右から64x64、128x128、256x256、512x512です。

ガタガタになるのは、不可逆圧縮により色(sculpt textureでは位置)情報が再現できない ためです。

では、次に「ロスのない圧縮を使用」をチェックした場合です(128x128よりも小さな 画像の場合選択できます)。下の図は64x64のロスレス圧縮になります。 ちなみに、128x128のロスレス圧縮でも見栄えはまったく変わりません。
本記事冒頭で使ったものです。

以上から、64x64のロスレス圧縮がベストと思われるかもしれませんが、 残念ならがそうではありません。

今回みたいにスナップショット撮るだけなら正解かもしれませんが、 常にこのような美しい表示ができるわけではなのです。みなさんも、スキンや服の テクスチャがもやもやってことありませんか？
いつまで経っても直らないから、CTRL+ALT+Rでリロードしますよね。リロードしても 自分のクライアントには効果がありますが、他人様の状況は変えられません。 同じ問題がスカルプトプリムにも 起きます。次項に続きます。

Lindenに期待

リンデンさん、プログレッシブの意味分かりますよね？ はじめモヤモヤしていているけど徐々に改善していく画像を プログレッシブ画像というんだよ。

リンデンさんには問い合わせるつもりですが、とりあえず、現状は以下の問題があります。

画像はすべてプログレッシブな処理がされているようです。それは別に良いのですが、 問題は、プログレッシブしないままロードが止まってしまうということです。 すると、先ほどお見せした美しい階段が...

と、なります。手前が64x64のロスレス、奥が128x128のロスレスです。

突然やってきます。そして、なかなか元に戻りません。こうなると、inventoryを開いて 元のスカルプトテクスチャを表示してもモヤモヤのままです。inventoryの中にある テクスチャで、モヤモヤでないもの(プログレッシブ済みというかアップしたときと同じもの)を スカルプトテクスチャとして貼りなおせば美しさが戻ります。

つまり、リンデンさんのサーバにはロスレスの正しい画像があるけど、 プログレッシブ途中でダウンロードが停止してしまう。結果として ガタガタというわけです。

これが解決するまではどうしようもありません。
わたしの場合は、ケースによって使い分けています。64x64ロスレスは基本的に 使っていません。精度が求められる階段のようなものは実験的に作ることはあっても、 配布は怖くてできません。曲面的な要素をもつものは512x512か256x256を使っています。 128x128のロスレスの場合もあります。

リンデンさんには、高々10kバイト程度のイメージはプログレッシブ処理しないで と要望するつもりです。これまでもサーベイウインドが現れるとお願いしてるんですが ...変わりませんね。
クライアントが要望通り修正されれば、64x64ロスレスで決定です。