2008年02月25日
スカルプテッドプリムの不具合？
…で、その神田明神を作っておるときにでっくわした、困った現象があるのでござるが、それがスカルプテッド・プリムの表示のバグ（？）でござる。
まずはこの擬宝珠（ギボシ）のスカルプテッドプリムをご覧くだされ。
これは、カッチリした形状のスカルプテッドプリムを制作する方法として拙者が行き着いた手法、「Photoshopで直接、ポジションマップのRGBチャンネルを修正する」という荒業（てか、チカラワザ）を使って制作したものでござる。
この方法を使えば、マップ的には3D空間のX,Y,Z軸に平行なラインであれば完全に直線なラインに補正する事ができる筈なのでござる。
出力結果はご覧のとおり、見事に横のライン（XY平面に平行なライン）が真っ直ぐなオブジェクトが制作できて、「おおお！大成功！！」とご満悦だったのでござるが…
これを後日（もしくは他のSIMから移動してきて再表示）見てみると…
このように、真っ直ぐなはずのラインがガッタガタ。；；
ポジションマップを見てみると、微妙に滲んだような色の変化が起こっておるのでござる。
何らかの原因で、サーバにアップしたデータが壊れたのか？ と思い、再アップしてみるも…
最初はキレイに表示されるデータも、同じくタイミングによってはガタガタになったりするではござらぬか。
しかもガタガタになった後、再度きれいに表示される事などもあり、サーバ上のデータは壊れていない事がわかる。
他の人がキレイに表示されているときに、自分だけがガタガタに見える事もある。
…と云うことは、ローカルPCの環境の問題なのか？？
「頂点の位置計算はGPUの仕事だから、グラボが壊れかけてるんだよ。」
…と云うご指摘も頂いたが、グラボのGPUが壊れかけておれば、PCの動作そのものが不安定になりそうなものでござる。ましてや真っ先に影響が出そうな他の3DCGソフトウエアが、すこぶる快調に動作しているのでグラボが壊れたという線は薄い。
となると、クライアントのバグである可能性が最も高そうでござる。
バグならバグで、しっかりとした再現性があれば良いのでござるが…これがタイミングによっては再現されなかったり、症状が出やすいデータと、出にくいデータがあったりもして謎が深まっておったのでござる。
これまでの症状を総合して考えてみると、ロスレスJPGの圧縮をデコードする際に失敗することがある…と考えると、全てがストンと腑に落ちるのでござるが…そんなバグ、認識されており申すかな？（＞お詳しい方。）
兎も角、現在建築中の神田明神には、このチカラワザスカルプテッドプリムで、完璧な直線にすることを前提に制作したオブジェクトを多々使っており申す故、ヒジョーに困った現象なのでござる。
リンデンのアホー。；；
…と叫ぶしか無いのでござろうか。
まずはこの擬宝珠（ギボシ）のスカルプテッドプリムをご覧くだされ。
これは、カッチリした形状のスカルプテッドプリムを制作する方法として拙者が行き着いた手法、「Photoshopで直接、ポジションマップのRGBチャンネルを修正する」という荒業（てか、チカラワザ）を使って制作したものでござる。
この方法を使えば、マップ的には3D空間のX,Y,Z軸に平行なラインであれば完全に直線なラインに補正する事ができる筈なのでござる。
出力結果はご覧のとおり、見事に横のライン（XY平面に平行なライン）が真っ直ぐなオブジェクトが制作できて、「おおお！大成功！！」とご満悦だったのでござるが…
これを後日（もしくは他のSIMから移動してきて再表示）見てみると…
このように、真っ直ぐなはずのラインがガッタガタ。；；
ポジションマップを見てみると、微妙に滲んだような色の変化が起こっておるのでござる。
何らかの原因で、サーバにアップしたデータが壊れたのか？ と思い、再アップしてみるも…
最初はキレイに表示されるデータも、同じくタイミングによってはガタガタになったりするではござらぬか。
しかもガタガタになった後、再度きれいに表示される事などもあり、サーバ上のデータは壊れていない事がわかる。
他の人がキレイに表示されているときに、自分だけがガタガタに見える事もある。
…と云うことは、ローカルPCの環境の問題なのか？？
「頂点の位置計算はGPUの仕事だから、グラボが壊れかけてるんだよ。」
…と云うご指摘も頂いたが、グラボのGPUが壊れかけておれば、PCの動作そのものが不安定になりそうなものでござる。ましてや真っ先に影響が出そうな他の3DCGソフトウエアが、すこぶる快調に動作しているのでグラボが壊れたという線は薄い。
となると、クライアントのバグである可能性が最も高そうでござる。
バグならバグで、しっかりとした再現性があれば良いのでござるが…これがタイミングによっては再現されなかったり、症状が出やすいデータと、出にくいデータがあったりもして謎が深まっておったのでござる。
これまでの症状を総合して考えてみると、ロスレスJPGの圧縮をデコードする際に失敗することがある…と考えると、全てがストンと腑に落ちるのでござるが…そんなバグ、認識されており申すかな？（＞お詳しい方。）
兎も角、現在建築中の神田明神には、このチカラワザスカルプテッドプリムで、完璧な直線にすることを前提に制作したオブジェクトを多々使っており申す故、ヒジョーに困った現象なのでござる。
リンデンのアホー。；；
…と叫ぶしか無いのでござろうか。
Posted by KT爺 at 00:12│Comments(12)
│ものづくり
この記事へのトラックバック
先日、1プリムの人形を作成した記事を書きました。http://cargo.slmame.com/e176220.htmlその後、より正確な形状を再現できる方法が紹介されているのを見つけて、http://www.cattaka.net/index.php?SecondLife%2FC...
スカルプトが崩れる?【S-Cargo ブログ】at 2008年03月19日 22:46
この記事へのコメント
たまーにSKINや服などのテクスチャがぼやけたままだったり、
読み込まれたりを繰り返す現象がありますが
それがｽｶﾙﾌﾟﾄのテクスチャにもでているのかもしれないですねー
仕様というしかないのでしょうか・・・
読み込まれたりを繰り返す現象がありますが
それがｽｶﾙﾌﾟﾄのテクスチャにもでているのかもしれないですねー
仕様というしかないのでしょうか・・・
Posted by shin at 2008年02月25日 00:29
まさにスカルプマジック！
Posted by ore at 2008年02月25日 00:39
スカルプテクスのRGBをフォトショップで補正ですか。
さすがです。
後日見て、とか他から移動した直後っていうことだと、Shinさんの言われているようにテクスチャ読み込み中の症状に思えますね。
オブジェクトを右クリック→編集すると優先的に読み込まれて正常な形状に戻ったりもしますけど。
LODのせいって訳でもなさそうですしねぇ。
症状の出やすいデータと出にくいデータの違いがあるなら私もぜひ知りたいものです・・・。
さすがです。
後日見て、とか他から移動した直後っていうことだと、Shinさんの言われているようにテクスチャ読み込み中の症状に思えますね。
オブジェクトを右クリック→編集すると優先的に読み込まれて正常な形状に戻ったりもしますけど。
LODのせいって訳でもなさそうですしねぇ。
症状の出やすいデータと出にくいデータの違いがあるなら私もぜひ知りたいものです・・・。
Posted by やぶさか at 2008年02月25日 01:11
＞Shin殿
コメント、どもでござる。＾＾
テクスチャの解像度を段階的に上げていくプログレッシブ表示による形状の破綻は、サーバが重いときなどに良く再現され申すが…
症状を見ると、今回の事例はプログレッシブ表示の遅延とは、また別物のようなのでござるよ。。。
スカルプテッドプリムを使った商品のクオリティに影響してしまうので、仕様と云うにはあまりに深刻な気がするのでござる。^^;
>ore殿
や、マジックでなくて。ｗ
＞やぶさか殿
ごぶさたでござる＾＾
テクスチャの読み込み途中であれば、もっと激しい崩れ方をするのでござるが、どうもこれが読み込み完了した状態として表示されてしまうのが、今回の大問題なのでござる。
玉光殿も同じ症状で「ムッキー！！」となっておられるようでござった。
http://tamahikari.slmame.com/e146143.html
以下はしっかりと検証したものではなく、あくまで拙者の印象でござるが…
症状が出やすい…と云うより、症状が出た場合にその変化が顕著なのが、スムーズなグラデーション状態ではなく、スカルプト形状の頂点数で分割したブロック状のポジションマップを仕様したオブジェクトでござる。
RGB値を手作業で修正するのは、実質このタイプのものでなければ出来ない（できたとしても、ヒジョーにやりにくい。＾＾；）故に、拙者はこちらのタイプを使っており申した。
また、このおかげでマップの色が滲んでおるのが視認できたのでござる。
一方、スカルプテッドプリムの頂点定義には使用されない色まで含まれたスムーズなグラデーション状態のマップでは、この症状が出ても、その変化が少ない気がしたのでござる。
これは、「隣のピクセルの色が滲んでブレンドされても、元からスムーズなグラデーション値を持っていたために、RGB値の変化が少ないからではないか？」 と思った訳でござるよ。
では、ピクセルの色が滲むのはどういうとき？？ と考えたときに思い当たるのが
「JPG圧縮された状態」
ロスレスのチェックを忘れたのであれば、最初から崩れた状態で表示されるハズでござるし、これは何度もチェックをしたので間違う訳は無い。
てことは、もしかしたら…これは可逆圧縮の筈のロスレスJPGのデコードが上手くいってない状態の表示なのではなかろ～か…と。
そんな考えに至った訳でござる。
（順序立てて説明すると長げ～～でござる。；；）
あくまで、素人の推測でござる。
ちゃんとした知識を持った人が見たら、きっと穴だらけでござろうから、
「この症状で悩んでるジジイがいたなあ…」程度に覚えておいてくだされ。；；
コメント、どもでござる。＾＾
テクスチャの解像度を段階的に上げていくプログレッシブ表示による形状の破綻は、サーバが重いときなどに良く再現され申すが…
症状を見ると、今回の事例はプログレッシブ表示の遅延とは、また別物のようなのでござるよ。。。
スカルプテッドプリムを使った商品のクオリティに影響してしまうので、仕様と云うにはあまりに深刻な気がするのでござる。^^;
>ore殿
や、マジックでなくて。ｗ
＞やぶさか殿
ごぶさたでござる＾＾
テクスチャの読み込み途中であれば、もっと激しい崩れ方をするのでござるが、どうもこれが読み込み完了した状態として表示されてしまうのが、今回の大問題なのでござる。
玉光殿も同じ症状で「ムッキー！！」となっておられるようでござった。
http://tamahikari.slmame.com/e146143.html
以下はしっかりと検証したものではなく、あくまで拙者の印象でござるが…
症状が出やすい…と云うより、症状が出た場合にその変化が顕著なのが、スムーズなグラデーション状態ではなく、スカルプト形状の頂点数で分割したブロック状のポジションマップを仕様したオブジェクトでござる。
RGB値を手作業で修正するのは、実質このタイプのものでなければ出来ない（できたとしても、ヒジョーにやりにくい。＾＾；）故に、拙者はこちらのタイプを使っており申した。
また、このおかげでマップの色が滲んでおるのが視認できたのでござる。
一方、スカルプテッドプリムの頂点定義には使用されない色まで含まれたスムーズなグラデーション状態のマップでは、この症状が出ても、その変化が少ない気がしたのでござる。
これは、「隣のピクセルの色が滲んでブレンドされても、元からスムーズなグラデーション値を持っていたために、RGB値の変化が少ないからではないか？」 と思った訳でござるよ。
では、ピクセルの色が滲むのはどういうとき？？ と考えたときに思い当たるのが
「JPG圧縮された状態」
ロスレスのチェックを忘れたのであれば、最初から崩れた状態で表示されるハズでござるし、これは何度もチェックをしたので間違う訳は無い。
てことは、もしかしたら…これは可逆圧縮の筈のロスレスJPGのデコードが上手くいってない状態の表示なのではなかろ～か…と。
そんな考えに至った訳でござる。
（順序立てて説明すると長げ～～でござる。；；）
あくまで、素人の推測でござる。
ちゃんとした知識を持った人が見たら、きっと穴だらけでござろうから、
「この症状で悩んでるジジイがいたなあ…」程度に覚えておいてくだされ。；；
Posted by KT爺
at 2008年02月25日 13:12
at 2008年02月25日 13:12はじめまして。
私も「PhotoShopでスカルプを作るチカラワザ」をときたま利用しており、その関連で興味深く読ませていただきました。
スカルプトが正確な形にならないというと、よくある原因としては
・アップロード時の圧縮で歪んだ
・遠ざかったために省略された
といったあたりが浮かびますが、流石にそのあたりは考慮された上のことと存じます。
となると…ロスレスでアップロードされているという話だと、むしろ↓このへんが関係するかもしれません。
https://jira.secondlife.com/browse/VWR-2404
「小さい画像をロスレスでアップしたのにロスレスにならない」、というバグが報告されているそうです。
スカルプトテクスチャは小さいサイズの場合が多いので、関連しているかもしれません。
#私も（ベータグリッドでですが）ロスレスでアップロードした方がむしろ変な形になる、という症状に遭遇したことがあります。
#今のところ、スカルプトテクスチャ自体のサイズを拡大し、通常のアップロードを行うことで圧縮ノイズを軽減させる、という方法を取ってはいますが…。
ご参考になれば幸いです。神田明神の完成を楽しみにしております。
私も「PhotoShopでスカルプを作るチカラワザ」をときたま利用しており、その関連で興味深く読ませていただきました。
スカルプトが正確な形にならないというと、よくある原因としては
・アップロード時の圧縮で歪んだ
・遠ざかったために省略された
といったあたりが浮かびますが、流石にそのあたりは考慮された上のことと存じます。
となると…ロスレスでアップロードされているという話だと、むしろ↓このへんが関係するかもしれません。
https://jira.secondlife.com/browse/VWR-2404
「小さい画像をロスレスでアップしたのにロスレスにならない」、というバグが報告されているそうです。
スカルプトテクスチャは小さいサイズの場合が多いので、関連しているかもしれません。
#私も（ベータグリッドでですが）ロスレスでアップロードした方がむしろ変な形になる、という症状に遭遇したことがあります。
#今のところ、スカルプトテクスチャ自体のサイズを拡大し、通常のアップロードを行うことで圧縮ノイズを軽減させる、という方法を取ってはいますが…。
ご参考になれば幸いです。神田明神の完成を楽しみにしております。
Posted by Noras at 2008年02月28日 02:23
こんばんは。
スカルプの歪みの件は僕も去年から状況に遭遇しており、Norasさんの言う通りJiraの対策状況を追いかける日々です。
RC1.19以降のクライアントで、アップロード時の歪みはかなり軽減されたようですが、キャッシュにのこってるスカルプ画像がぼけたままな件は、未だに直っていないようです。
対策としては、多少ぼやけても形が維持できるように、大きめの画像（１２８x１２８）で作成したり、16x16でもある程度の形が維持できるような頂点配列にしたり等、形が甘くなるのを前提に作る感じでしょうか。
私もこの問題で、お面の制作でかなり苦労してます＾＾；
スカルプの歪みの件は僕も去年から状況に遭遇しており、Norasさんの言う通りJiraの対策状況を追いかける日々です。
RC1.19以降のクライアントで、アップロード時の歪みはかなり軽減されたようですが、キャッシュにのこってるスカルプ画像がぼけたままな件は、未だに直っていないようです。
対策としては、多少ぼやけても形が維持できるように、大きめの画像（１２８x１２８）で作成したり、16x16でもある程度の形が維持できるような頂点配列にしたり等、形が甘くなるのを前提に作る感じでしょうか。
私もこの問題で、お面の制作でかなり苦労してます＾＾；
Posted by AKIBE at 2008年02月28日 10:58
>Noras殿
どもでござる～。＾＾
ポジションマップは、128でも６４でも同様の症状が出申した。
一旦は正常に表示されたものが、ときどき崩れて表示される事がある…
と云う症状から、今回の件は「サーバ上の画像データがロスレスになっていない」と云うことでは無いと思うのでござるが、
兎も角、ロスレス圧縮周りのバグを一掃してもらえれば、いっしょに解決せぬかのう…と、のん気に構えてみるでござる。^^;
URL先…
え…英語は苦手でござるが、時間が出来たら一度じっくり翻訳して読んでみるでござるよ。
情報、かたじけない。＾＾
＞AKIBE殿
いらっしゃいでござる～。＾＾
そうそう。 この現象にでっくわした時に、AKIBE殿にIMしてみようと思いつつ先延ばし…延ばしにしていたのでござる。ｗ
やはり、AKIBE殿も苦労されておったのですな。
仕様なのかバグなのか…と云う点で、対策も大きく変わってくるでござる。
拙者も現在は、「これはバグだからいつか直る」と信じて（笑）ローカル環境での表示（SLV使用）を基準に、SL内で崩れるのはあまり気にしないようにするでござる。^^;
どもでござる～。＾＾
ポジションマップは、128でも６４でも同様の症状が出申した。
一旦は正常に表示されたものが、ときどき崩れて表示される事がある…
と云う症状から、今回の件は「サーバ上の画像データがロスレスになっていない」と云うことでは無いと思うのでござるが、
兎も角、ロスレス圧縮周りのバグを一掃してもらえれば、いっしょに解決せぬかのう…と、のん気に構えてみるでござる。^^;
URL先…
え…英語は苦手でござるが、時間が出来たら一度じっくり翻訳して読んでみるでござるよ。
情報、かたじけない。＾＾
＞AKIBE殿
いらっしゃいでござる～。＾＾
そうそう。 この現象にでっくわした時に、AKIBE殿にIMしてみようと思いつつ先延ばし…延ばしにしていたのでござる。ｗ
やはり、AKIBE殿も苦労されておったのですな。
仕様なのかバグなのか…と云う点で、対策も大きく変わってくるでござる。
拙者も現在は、「これはバグだからいつか直る」と信じて（笑）ローカル環境での表示（SLV使用）を基準に、SL内で崩れるのはあまり気にしないようにするでござる。^^;
Posted by KT爺 at 2008年02月28日 16:37
重いSIMでおこりますね。
まっさらの新しいSIMではすぐに綺麗に表示されるんですが；
その意味でもサーバ上の画像データがロスレスになってないわけでは
なさそうです。
玉光さんともお話したんですが、
板タイプの頂点が重なった部分があるものに起きて
普通のスカルプではおきていない気がします。
まっさらの新しいSIMではすぐに綺麗に表示されるんですが；
その意味でもサーバ上の画像データがロスレスになってないわけでは
なさそうです。
玉光さんともお話したんですが、
板タイプの頂点が重なった部分があるものに起きて
普通のスカルプではおきていない気がします。
Posted by SALA at 2008年03月06日 20:54
＞SALA殿
いらはいでござる～＾＾
…んでござるな。 一度崩れたデータが二度と元に戻らない訳では
ないので、サーバ上の元データは問題なさそうでござる。
スカルプトタイプに関しては、拙者が作ったデータは全て
シリンダータイプのみでござるが、やはり未だに症状は出ており申すよ。
いらはいでござる～＾＾
…んでござるな。 一度崩れたデータが二度と元に戻らない訳では
ないので、サーバ上の元データは問題なさそうでござる。
スカルプトタイプに関しては、拙者が作ったデータは全て
シリンダータイプのみでござるが、やはり未だに症状は出ており申すよ。
Posted by KT爺 at 2008年03月07日 21:36
僕もありましたね～この症状・・・
一度綺麗に表示されたスカルプが、一定時間たつと一部崩れてそのまんま。
しかも３０分以上たった後に潰れてるものだからチェックに異常に時間がかかりました。しかも一部って・・・
何度繰り返しアップロードしてみても同じだったので、ああこれは元の画像だなぁと思いました。でも修正する技術は持ち合わせていなかったので、崩れる場所の頂点を密集させて再度スカルプ画像を作ることで解決させました。
一度綺麗に表示されたスカルプが、一定時間たつと一部崩れてそのまんま。
しかも３０分以上たった後に潰れてるものだからチェックに異常に時間がかかりました。しかも一部って・・・
何度繰り返しアップロードしてみても同じだったので、ああこれは元の画像だなぁと思いました。でも修正する技術は持ち合わせていなかったので、崩れる場所の頂点を密集させて再度スカルプ画像を作ることで解決させました。
Posted by よねまる at 2008年03月30日 03:11
>よねまる殿
「一度綺麗に表示される」という事は、それが正常な状態であって、
その後に崩れるのは元画像ではなくビューワー側の不具合でござるよな。
…となると、バグとして修正してもらえるのを待つしかないでござるなあ。
上にも書いたように、グラデーション状のポジションマップでは症状が出ても
それほど目立たない（ことが多い気がする）ので、最近は極力ブロック状のポジションマップは使わないようにしておるでござる。
「一度綺麗に表示される」という事は、それが正常な状態であって、
その後に崩れるのは元画像ではなくビューワー側の不具合でござるよな。
…となると、バグとして修正してもらえるのを待つしかないでござるなあ。
上にも書いたように、グラデーション状のポジションマップでは症状が出ても
それほど目立たない（ことが多い気がする）ので、最近は極力ブロック状のポジションマップは使わないようにしておるでござる。
Posted by KT爺 at 2008年03月31日 19:08
さっき同じSIMの仲間と話してましたけど、まだ崩れる不具合は消えてないですね～・・・
参りました（；´Д｀）
キャッシュが劣化するのかとも思いましたが・・・それもなし。
ビューワー側の不具合なのはほぼ確定っぽいですね～。
テクでどうにもならないところが、テンション下がるというかｗ
これって、結構重大問題だと思うんですけど（；´Д｀）
参りました（；´Д｀）
キャッシュが劣化するのかとも思いましたが・・・それもなし。
ビューワー側の不具合なのはほぼ確定っぽいですね～。
テクでどうにもならないところが、テンション下がるというかｗ
これって、結構重大問題だと思うんですけど（；´Д｀）
Posted by よねまる at 2008年04月27日 16:20
