2008年03月27日
TECH EXPOに出店完了
http://slurl.com/secondlife/Tech%20Expo/186/72/241
なんとかTECH EXPOのほうに出店できましたー。
ただTECH EXPOでは現在1週間限定で1L$で売り物が置けるスペースが出来てるのでMiniTECHの20%手数料は正直痛い。
なんとかTECH EXPOのほうに出店できましたー。
ただTECH EXPOでは現在1週間限定で1L$で売り物が置けるスペースが出来てるのでMiniTECHの20%手数料は正直痛い。
2008年03月19日
最近……
なんか便利になるという触れ込みのHUDがやたらに増えてきた感じだが。
みんなつけてるのかな？
私の場合気ぐるみアバターが多いからフォルダごと付け替えることが多くて
FlightFeatherですら後付がめんどくさい。
さらに色変更とかHoverCycleのコントロールHUDとか自前のもあるし。
これまでのHUDギャラリー。
みんなつけてるのかな？
私の場合気ぐるみアバターが多いからフォルダごと付け替えることが多くて
FlightFeatherですら後付がめんどくさい。
さらに色変更とかHoverCycleのコントロールHUDとか自前のもあるし。
これまでのHUDギャラリー。
Posted by Seyfert Slade at
10:16
│Comments(1)
2008年03月13日
某所で新作TINY
朝6時に某所で「タイニーの宇宙展」向けの新作タイニーをコリコリと作ってました。
大体完成で手足を左右反転させる作業が残ってます。
いままでの製品を追っていれば「ああ、あれのTINYバージョンだな」とわかるはず。
テクスチャは宇宙展スペシャルバージョンになる予定。PlatinumEdition。
大体完成で手足を左右反転させる作業が残ってます。
いままでの製品を追っていれば「ああ、あれのTINYバージョンだな」とわかるはず。
テクスチャは宇宙展スペシャルバージョンになる予定。PlatinumEdition。
2008年03月10日
TechExpoに出店内定
TechExpoというメカやSF物を扱っているSIMに出店する予定です。
MiniTechという本格出店の前の力試し的な販売ブースですが、
Stingray Hovercycleを１ヶ月置いてOkという内定を頂きました。
売り上げがよければ本格出店のチャンスも。
http://slurl.com/secondlife/Tech%20Expo/186/72/241
MiniTechという本格出店の前の力試し的な販売ブースですが、
Stingray Hovercycleを１ヶ月置いてOkという内定を頂きました。
売り上げがよければ本格出店のチャンスも。
http://slurl.com/secondlife/Tech%20Expo/186/72/241
2008年03月05日
スカルプTweak（１）
まずX,Y,Zがそれぞれ0～128～255の整数値であるこについての一例。
上のような円錐を作るとして、底面に平行な面で分割すると底面の円より小さい円が現れる。
それをスカルプテッドプリムの座標系に直すとどうなるか。
底面が、0～255一杯に広げたとしてもそれより小さい円では0～255の一部分しか使われない。
理想は黒の線の円であるが、整数値で扱わざる得ないため、それに属する整数の座標（黄色）の集合で近似される。
さらに、スカルプテッドプリムではせいぜい32角形で近似するため使用される近似の点は一部となる（濃い黄色）。
近似で使用した点をつなぐと必ずしも円の近似とは合いふさわしくない凹んだ場所が出てくるのである（赤い線）。
さらに小さくなると近似の点が32よりも少なくなり、32の頂点のうち複数の頂点がひとつの場所を
あらわすようになってしまう。
整数化されることを考えていないと理想でいくら細かく作っても、スカルプテッドプリムになった時点で
その細かく作った部分がむしろ逆効果になってしまう可能性が発生する。
もちろんこれは近似してスカルプテッドプリムで使用する点を採用する際に採用する点を注意深く選ぶことで
ある程度は防げるものの、整数化の影響を考えずにそのまま単純処理すると存在しなかったしわなどが出てくる原因となる。
上のような円錐を作るとして、底面に平行な面で分割すると底面の円より小さい円が現れる。
それをスカルプテッドプリムの座標系に直すとどうなるか。
底面が、0～255一杯に広げたとしてもそれより小さい円では0～255の一部分しか使われない。
理想は黒の線の円であるが、整数値で扱わざる得ないため、それに属する整数の座標（黄色）の集合で近似される。
さらに、スカルプテッドプリムではせいぜい32角形で近似するため使用される近似の点は一部となる（濃い黄色）。
近似で使用した点をつなぐと必ずしも円の近似とは合いふさわしくない凹んだ場所が出てくるのである（赤い線）。
さらに小さくなると近似の点が32よりも少なくなり、32の頂点のうち複数の頂点がひとつの場所を
あらわすようになってしまう。
整数化されることを考えていないと理想でいくら細かく作っても、スカルプテッドプリムになった時点で
その細かく作った部分がむしろ逆効果になってしまう可能性が発生する。
もちろんこれは近似してスカルプテッドプリムで使用する点を採用する際に採用する点を注意深く選ぶことで
ある程度は防げるものの、整数化の影響を考えずにそのまま単純処理すると存在しなかったしわなどが出てくる原因となる。
2008年03月04日
Rendering in SL viewer(2)
It is recommended to use 64x64 images. In theory 32x32 should give you the same quality but current code will not use your last (top!) row of your texture both as vertices and as the row to get the pole from. It will incorrectly trigger generation of a pole 1 row early and you'll hence get your 2 last rows of vertices filled with the pole.
64x64イメージを使用することをお勧めします。理論上では32x32でも同等のクオリティになるはずですが、現在のプログラムではテクスチャの最終行（イメージ一番上）を頂点列と極を取得する行の両方として使用しません。それにより不正な極の生成を誘発し、最後の2つの行の頂点が極に満たされる状況が発生します。
Note that the next levels of detail are 17x17 vertices and 9x9 vertices which are taken in the same way as above but the texture will be interpolated first. The textures are scaled down (using interpolation) with the same degree as the mesh. Hence a 32x32 texture at lowest detail ends up being an 8x8 while a 512x512 would end up being a 128x128. You can only predefine how your sculpture will look for each LOD by having blocks of similarly colored pixels. Make sure the most important pixels are positioned on those positions that are used at every LOD.
The quality of your final result is also determined by the JPEG compression. Read the warning at the start of this section and please vote for VWR-2404 on JIRA.
（レベル・オブ・ディティール処理による）次の段階は17x17頂点、そして9x9頂点となる。その際にも上と同じような処理が行われるが、最初にテクスチャの補間が行われる。テクスチャのスケールがメッシュと同じ度合いに（補間処理が行われて）縮小される。32x32であれば最低レベルになると8x8、512x512であれば128x128といったふうになる。ブロックに近い色を配置することのみで各段階でどう見えるかを事前に定義することが可能である。重要な位置の頂点をあらわす画素が各段階のレベルでも使用されることを確認してください。
最終的なクオリティはJPEG圧縮によって決定されます。最初に記述した注意の項目を読んでJIRAのVWR-2404の投票をお願いします。
64x64イメージを使用することをお勧めします。理論上では32x32でも同等のクオリティになるはずですが、現在のプログラムではテクスチャの最終行（イメージ一番上）を頂点列と極を取得する行の両方として使用しません。それにより不正な極の生成を誘発し、最後の2つの行の頂点が極に満たされる状況が発生します。
Note that the next levels of detail are 17x17 vertices and 9x9 vertices which are taken in the same way as above but the texture will be interpolated first. The textures are scaled down (using interpolation) with the same degree as the mesh. Hence a 32x32 texture at lowest detail ends up being an 8x8 while a 512x512 would end up being a 128x128. You can only predefine how your sculpture will look for each LOD by having blocks of similarly colored pixels. Make sure the most important pixels are positioned on those positions that are used at every LOD.
The quality of your final result is also determined by the JPEG compression. Read the warning at the start of this section and please vote for VWR-2404 on JIRA.
（レベル・オブ・ディティール処理による）次の段階は17x17頂点、そして9x9頂点となる。その際にも上と同じような処理が行われるが、最初にテクスチャの補間が行われる。テクスチャのスケールがメッシュと同じ度合いに（補間処理が行われて）縮小される。32x32であれば最低レベルになると8x8、512x512であれば128x128といったふうになる。ブロックに近い色を配置することのみで各段階でどう見えるかを事前に定義することが可能である。重要な位置の頂点をあらわす画素が各段階のレベルでも使用されることを確認してください。
最終的なクオリティはJPEG圧縮によって決定されます。最初に記述した注意の項目を読んでJIRAのVWR-2404の投票をお願いします。
2008年03月04日
Rendering in SL viewer(1)
Rendering in Second Life viewer
This analysis is based on 1.16.0(5) source and some tests.
セカンドライフビューワーでのレンダリング
この考察は1.16.0のソースといくつかのテストによるものです。
Warning: Textures are stored using lossy JPEG2000 compression. If the texture is sized 64x64 or below the compression artifacts are numerous and very bad, once you take 128x128 they are still there but greatly diminish. Therefore for now 128x128 will give you much better results even though this is a serious memory waste. Note that going beyond 128x128 will give you little benefit so please don't! Update: Lossless JPEG2000 compression is implemented, but does not upload all images correctly. This issue is in JIRA as VWR-2404; please vote for it to support fixing this feature.
注意：テクスチャは非可逆圧縮のJPEG2000形式で収納されます。テクスチャが64x64、あるいはそれ以下の場合の圧縮の非常に多くの悪い副作用画発生します。128x128にすればまだ若干の副作用はありますが副作用は軽微になります。128x128はよりよい結果をもたらしますがこれは深刻なメモリの無駄遣いでもあります。ほんの僅かの差のために128x128より大きいテクスチャを使用することはやめましょう。
更新：可逆圧縮のJPEG2000が導入されましたが全ての画像が正しくアップロードできるわけではないようです。この問題はJIRAのVWR-2404で報告されており、正しくアップロードされるために対応の必要性について投票をお願いします。
Important: When we refer to the texture in terms of how the viewer code sees it, the first row (0) is the bottom row of your texture. For the columns they are left to right.
重要：ビューワーのプログラムがテクスチャを参照する際は最初の行（Y=0)はテクスチャの最下辺となります。各行は左から右に参照されます。
The Second life viewer will at it's highest level of detail render a grid of vertices in the following form:
セカンドライフビューワーが最高の詳細度で頂点の配列を生成する際には以下の法則に従います。
1 top row of 33 vertices all mapped to a pole
31 rows of 33 vertices taken from your texture
1 bottom row of 33 vertices all mapped to a pole
縦33頂点の最上位置のひとつの頂点が極にマップされる
縦33頂点のうち31の頂点のが(その下に)マップされる
縦33頂点の最下位置のひとつの頂点が極にマップされる
For each row the 33th vertex is the same as the 1st, this stitches the sculpture at the sides. The poles are determined by taking the pixel on width/2 on the first and last row of your texture. (In a 64x64 texture that would be the 33rd pixel as we start counting columns from 0).
各行の33番目の頂点は1番目と同じもので、スカルプチャの端が縫い合わされることになる。極はテクスチャの幅の1/2のX座標の最上辺と最下辺のピクセルが採用される。（64x64のテクスチャであれば33番目のピクセルは桁位置0からカウントされたものになる）
For example, a sculpture at the highest level of detail Second Life supports requires a mesh of 33 x 33 vertices If we have a 64x64 texture, this grid of vertices is sampled from the texture at the points:
たとえば、セカンドライフがサポートする最大の詳細度では33x33のメッシュ画必要となるが、これを64x64のテクスチャで供給する場合、頂点の配列のために採用される画素は以下のようになる。
This analysis is based on 1.16.0(5) source and some tests.
セカンドライフビューワーでのレンダリング
この考察は1.16.0のソースといくつかのテストによるものです。
Warning: Textures are stored using lossy JPEG2000 compression. If the texture is sized 64x64 or below the compression artifacts are numerous and very bad, once you take 128x128 they are still there but greatly diminish. Therefore for now 128x128 will give you much better results even though this is a serious memory waste. Note that going beyond 128x128 will give you little benefit so please don't! Update: Lossless JPEG2000 compression is implemented, but does not upload all images correctly. This issue is in JIRA as VWR-2404; please vote for it to support fixing this feature.
注意：テクスチャは非可逆圧縮のJPEG2000形式で収納されます。テクスチャが64x64、あるいはそれ以下の場合の圧縮の非常に多くの悪い副作用画発生します。128x128にすればまだ若干の副作用はありますが副作用は軽微になります。128x128はよりよい結果をもたらしますがこれは深刻なメモリの無駄遣いでもあります。ほんの僅かの差のために128x128より大きいテクスチャを使用することはやめましょう。
更新：可逆圧縮のJPEG2000が導入されましたが全ての画像が正しくアップロードできるわけではないようです。この問題はJIRAのVWR-2404で報告されており、正しくアップロードされるために対応の必要性について投票をお願いします。
Important: When we refer to the texture in terms of how the viewer code sees it, the first row (0) is the bottom row of your texture. For the columns they are left to right.
重要：ビューワーのプログラムがテクスチャを参照する際は最初の行（Y=0)はテクスチャの最下辺となります。各行は左から右に参照されます。
The Second life viewer will at it's highest level of detail render a grid of vertices in the following form:
セカンドライフビューワーが最高の詳細度で頂点の配列を生成する際には以下の法則に従います。
1 top row of 33 vertices all mapped to a pole
31 rows of 33 vertices taken from your texture
1 bottom row of 33 vertices all mapped to a pole
縦33頂点の最上位置のひとつの頂点が極にマップされる
縦33頂点のうち31の頂点のが(その下に)マップされる
縦33頂点の最下位置のひとつの頂点が極にマップされる
For each row the 33th vertex is the same as the 1st, this stitches the sculpture at the sides. The poles are determined by taking the pixel on width/2 on the first and last row of your texture. (In a 64x64 texture that would be the 33rd pixel as we start counting columns from 0).
各行の33番目の頂点は1番目と同じもので、スカルプチャの端が縫い合わされることになる。極はテクスチャの幅の1/2のX座標の最上辺と最下辺のピクセルが採用される。（64x64のテクスチャであれば33番目のピクセルは桁位置0からカウントされたものになる）
For example, a sculpture at the highest level of detail Second Life supports requires a mesh of 33 x 33 vertices If we have a 64x64 texture, this grid of vertices is sampled from the texture at the points:
たとえば、セカンドライフがサポートする最大の詳細度では33x33のメッシュ画必要となるが、これを64x64のテクスチャで供給する場合、頂点の配列のために採用される画素は以下のようになる。
(32,0) (32,0) (32,0) ... (32,0) (32,0) (32,0)
(0,2) (2,2) (4,2) ... (60,2) (62,2) (0,2)
. .
. .
. .
(0,60) (2,60) (4,60) ... (60,60) (62,60) (0,60)
(0,62) (2,62) (4,62) ... (60,62) (62,62) (0,62)
(32,63) (32,63) (32,63) ... (32,63) (32,63) (32,63)
2008年03月04日
テクスチャの対応
Texture Mapping
The position map of a sculpted prim also doubles as the UV map, describing how a texture will wrap around the mesh. The image is already an explanation of what vertices correlate to what pixel, which is used to generate UV coordinates for vertices as they are created. This presents a big advantage for texture mapping over procedural prims created in Second Life because you can do all of your texturing in a 3D modeling program such as Maya, and when you export the position map you know the UV coordinates will be exactly preserved in Second Life.
テクスチャの対応
スカルプテッドプリムののポジションマッピングはUVマッピングの複合したもので、テクスチャがどのようにメッシュに貼り付けられるかを指定するものである。イメージはどの頂点がピクセルに対応しているかをあらわし、生成された頂点のUV座標を設定するために用いられます。これによってテクスチャマッピングをPrim製作の手続きで出来ることになり、Mayaといった3Dモデリングプログラムで全てまかなうことが出来き、ポジションマップをエクスポートすることでUV座標がSL内でも正確に一致するようにできます。
The position map of a sculpted prim also doubles as the UV map, describing how a texture will wrap around the mesh. The image is already an explanation of what vertices correlate to what pixel, which is used to generate UV coordinates for vertices as they are created. This presents a big advantage for texture mapping over procedural prims created in Second Life because you can do all of your texturing in a 3D modeling program such as Maya, and when you export the position map you know the UV coordinates will be exactly preserved in Second Life.
テクスチャの対応
スカルプテッドプリムののポジションマッピングはUVマッピングの複合したもので、テクスチャがどのようにメッシュに貼り付けられるかを指定するものである。イメージはどの頂点がピクセルに対応しているかをあらわし、生成された頂点のUV座標を設定するために用いられます。これによってテクスチャマッピングをPrim製作の手続きで出来ることになり、Mayaといった3Dモデリングプログラムで全てまかなうことが出来き、ポジションマップをエクスポートすることでUV座標がSL内でも正確に一致するようにできます。
2008年03月04日
画素のフォーマット
Pixel Format
The alpha channel (if any) in position maps is currently unused, so we have 24 bits per pixel giving us 8 bits per color channel, or values from 0-255. Each color channel represents an axis in 3D space, where red, green, and blue map to X, Y, and Z respectively. If you're mapping from other software, keep in mind that not all 3D software will name their axes the same as SL does. If you have a different default orientation in SL than in your designer, compare the axes and swap where appropriate.
画素のフォーマット
アルファチャネルのポジションマップ（存在する場合）(詳細は不明?)は現在未使用で、24bit/画素によって、（RGBの）3チャンネルそれぞれに8ビット、言い換えれば0～255の数値を取ることができる。各カラーチャンネルは3次元空間座標系の軸、つまり赤、緑、青がそれぞれX,Y,Zをあらわす。
他のソフトウェアからの変換する場合は軸の名称が必ずしもSLのものと一致しないことを考慮することが必要となる。デフォルトの方向がSLと使っているデザインソフトウェアで違う場合は軸の座標を比較する必要がある。
The color values map to an offset from the origin of the object <0,0,0>, with values less than 128 being negative offsets and values greater than 128 being positive offsets. An image that was entirely <128,128,128> pixels (flat gray) would represent a single dot in space at the origin.
カラーの数値はオブジェクト中心となる<0,0,0>からのオフセットとなり、128よりも低い数値は負の方向、128よりも大きい数値は正の方向の位置となる。全ての画素が<128,128,128>（つまり中間の灰色）は中心座標の単一のドットになる。
On a sculpted prim that has a size of one meter, the color values from 0-255 map to offsets from -0.5 to 0.496 meters from the center. Combined with the scale vector that all prims in Second Life possess, sculpted prims have the nearly same maximum dimensions as regular procedural prims (9.961 meter diameter). The last 39mm is lost due to the fact that the maximum color value is 255, whereas 256 would be required to generate a positive offset of exactly 0.5.
1mのスカルプテッドプリムはカラーの数値の0-255が-0.5mから0.496mに対応する。SLにおけるPrim共通の倍率のベクトルの扱いと合わせられ、通常のプリムと「ほぼ」同じ最大サイズにすることができる（一辺9.961m）。10mに満たない39mmの分は色の数値が255が最大であることによる欠損であり、0.5のオフセットを生成する256という数値が必要だがそれができないことによるものである。
The alpha channel (if any) in position maps is currently unused, so we have 24 bits per pixel giving us 8 bits per color channel, or values from 0-255. Each color channel represents an axis in 3D space, where red, green, and blue map to X, Y, and Z respectively. If you're mapping from other software, keep in mind that not all 3D software will name their axes the same as SL does. If you have a different default orientation in SL than in your designer, compare the axes and swap where appropriate.
画素のフォーマット
アルファチャネルのポジションマップ（存在する場合）(詳細は不明?)は現在未使用で、24bit/画素によって、（RGBの）3チャンネルそれぞれに8ビット、言い換えれば0～255の数値を取ることができる。各カラーチャンネルは3次元空間座標系の軸、つまり赤、緑、青がそれぞれX,Y,Zをあらわす。
他のソフトウェアからの変換する場合は軸の名称が必ずしもSLのものと一致しないことを考慮することが必要となる。デフォルトの方向がSLと使っているデザインソフトウェアで違う場合は軸の座標を比較する必要がある。
The color values map to an offset from the origin of the object <0,0,0>, with values less than 128 being negative offsets and values greater than 128 being positive offsets. An image that was entirely <128,128,128> pixels (flat gray) would represent a single dot in space at the origin.
カラーの数値はオブジェクト中心となる<0,0,0>からのオフセットとなり、128よりも低い数値は負の方向、128よりも大きい数値は正の方向の位置となる。全ての画素が<128,128,128>（つまり中間の灰色）は中心座標の単一のドットになる。
On a sculpted prim that has a size of one meter, the color values from 0-255 map to offsets from -0.5 to 0.496 meters from the center. Combined with the scale vector that all prims in Second Life possess, sculpted prims have the nearly same maximum dimensions as regular procedural prims (9.961 meter diameter). The last 39mm is lost due to the fact that the maximum color value is 255, whereas 256 would be required to generate a positive offset of exactly 0.5.
1mのスカルプテッドプリムはカラーの数値の0-255が-0.5mから0.496mに対応する。SLにおけるPrim共通の倍率のベクトルの扱いと合わせられ、通常のプリムと「ほぼ」同じ最大サイズにすることができる（一辺9.961m）。10mに満たない39mmの分は色の数値が255が最大であることによる欠損であり、0.5のオフセットを生成する256という数値が必要だがそれができないことによるものである。
2008年03月04日
序論
Introduction
Sculpted prims are three dimensional meshes created from textures. Each texture is a mapping of vertex positions, where at full resolution each pixel would be one vertex, this can be less due to sampling (read below how the Second Life viewer treats your data). Each row of pixels (vertices) links back to itself, and for every block of four pixels two triangles are formed. At the top and bottom the vertices link to their respective pole.
最初に
スカルプテッドプリムはテクスチャから構築される三次元メッシュである。テクスチャは各画素がひとつの頂点の「不足のない座標系における」頂点の位置をマッピング(変換)したものである。これはサンプリングの際に劣化することがありえます（これについては「セカンドライフビューワーがデータをどう扱うか」で述べます）。
画その横の並びは（円筒の）後ろで繋がっており、4つの画素のブロックが二つの三角形を構成します。
上と下の頂点が円筒の上辺、下辺につながります。
Sculpted prims are three dimensional meshes created from textures. Each texture is a mapping of vertex positions, where at full resolution each pixel would be one vertex, this can be less due to sampling (read below how the Second Life viewer treats your data). Each row of pixels (vertices) links back to itself, and for every block of four pixels two triangles are formed. At the top and bottom the vertices link to their respective pole.
最初に
スカルプテッドプリムはテクスチャから構築される三次元メッシュである。テクスチャは各画素がひとつの頂点の「不足のない座標系における」頂点の位置をマッピング(変換)したものである。これはサンプリングの際に劣化することがありえます（これについては「セカンドライフビューワーがデータをどう扱うか」で述べます）。
画その横の並びは（円筒の）後ろで繋がっており、4つの画素のブロックが二つの三角形を構成します。
上と下の頂点が円筒の上辺、下辺につながります。
2008年03月04日
SculptedPrimの技術的考察
ちょっと技術的な考察。
SLWikiに「Sculpted Prims: Technical Explanation」という文章がありまして、
これを元に、内部処理に近い部分がどうなってるかやTweakの方法論をいくつかぶちあげてみたい。
SLWikiに「Sculpted Prims: Technical Explanation」という文章がありまして、
これを元に、内部処理に近い部分がどうなってるかやTweakの方法論をいくつかぶちあげてみたい。