Result of an experiment: The single face sculpty ...

[Gaia Clary]

The following 2*2 pixel sculptmap renders correctly as a single face (2 triangles) in Second Life (the little dot on the next line):

 

However i could only import it as a 4*4 pixel image. I used "Kirstens S21 2.7.8 (7)" for this little experiment.
Here is a snapshot in World:

Cheers,

Gaia

[Josh Susanto]

I think that even if it did load as 2x2, it would rez as 1x1, so it would occupy a single point and appear not to be there.

Try shrinking to 2x2 and then increasing to 4x4 and you should get the same result.

 

[Imnotgoing Sideways]

With such a low poly count, is it still subject to LOD loss? ()

Mostly curiosity since I'm already accustomed to clustering LOD culled vertices in order to visually avoid distortions. ()y

 

 

[Void Singer]

I'm actually surprised you managed to get it in at 4x4... the last time I tried I couldn't upload anything below 8x8... I dunno if that was a view restriction or if something changed since then (was trying to do basic white and clear 1x1's and test pattern 2x2's)

[Drongle McMahon]

Interesting. When the small sculpt maps were being implemented by Qarl, the smallest considered was an 8x8 map that specifies 4x4 quads, or 5x5 verts with planar stitching. That should not shrink further on LOD switches (see this table). If I make an 8x8 map with continuous red and blue gradients along U and V axes, I get the expected plane which is the expected 4x4 quads when you inspect it in wireframe view. If you make it just the four extreme colours in the four 4x4 quadrants, the vertices are squished and you see only a 1x1 quad wireframe. Making a 4x4 with just the four quadrants also makes a single quad, but that doesn't say much about how the code reads such a small map, because of possible squishing. But when I made a 4x4 with continuous gradients, I got a tryptich, three quads along the red (x) axis and one along the blue (z) axis. That's certainly not what I would have expected. I would have to go and look at the source code to find out why that happens.

 PS. I was also able to upload a 2x2 and it gave a single quad (I'm on a mesh sim in Aditi, with the mesh viewer from yesterday)

[Gaia Clary]

From the "theory of sculpted prims" a 2*2 pixel should give a perfect quad, because:

 

1. A face is defined by its 4 corner vertices and the sculptmap stores the vertex locations. So if you want to store a map containing 4*4 faces, you will need an image of size 5*5 pixels.
2. There is one constraint on image sizes for sculpted prims: their heigth and width must be power of 2 numbers. Hence in order to store a sculpty with 4*4 faces, you need 5*5 pixels distributed on an 8*8 pixel image.
3. This implies that a sculptmap of size n*m (where n,m are power of 2 numbers) can store  n/2 * m/2 faces (quads), in our example the 8*8 pixel image can store 4*4 = 16 faces. (Yes, i know there are exceptions from this rule, for 128*64 pixel sculptmaps the face count is 46*22=1012 faces...)
4. The used pixels are distributed (almost) evenly over the image as follows:
   each secnd pixel of the map is used as container for a vertex location,
   starting at the bottom left pixel of the image. But we have one extra row/column of pixels to populate (remind we nee 5*5 pixels to store a 4*4 faces map) And we use the rightmost column and the topmost row for this.

The following images show the sculptmaps for 8*8, 4*4, 2*2 and 1*1 faces from left to right. For easier display i have zoomed all images by a factor of 16, so the real image sizes are 16 times smaller than shown in the image below. The black parts in the sculptmaps are unused areas:

The rightmost image contains 4 used pixels stored in a 2*2 pixels map (enough data for one Quad). And according to what i just explained above, this is a perfect map and it obeys all rules ;-) However i also have read about "the smallest possible sculptmap is of size 16*16 pixels". But as curious as i am, i tried the smaller maps too and ended up with what i report here.

I have been testing on Agni (the main grid) but there when i upload an image of size 2*2, it seems to be automatically converted into a 4*4 image. Nevertheless i saw only one face (2 triangles) in wireframe mode after applying the map to a sculpty.

[Drongle McMahon]

"...upload an image of size 2*2, ... automatically converted into a 4*4 image ... only one face (2 triangles) in wireframe mode after applying the map to a sculpty."

Yes. Mine is too. At least it says so in the texture viewer, which could be wrong. But it is not interpolated. The pixels are just quadrupled. That means pixels 2 and 3 (numbering 0..3) in each dimension have the same RGB values and so the last two vertices (in planar stitching) are collapsed.

(edit - At least that's what I would expect, but since the 4x4 is clearly not working as expected, that is not exactly what's happening although the effect is the same.)

Here is a picture. The uploaded images inworld, shown on the tri-panel below are, from left to right, 4x4 with interpolated (gradient) colours, 2x2, 4x4 not interpolated, with four identical pixels in each quadrant. You can see that the uploded 2x2 image is the same as the uninterpolated 4x4. The sculpties using these as scupltmaps are shown above the tri-panel. The middle part shows the same scene in wireframe.  The images before upload, with pixels expanded 16x, are shown at the bottom.

(edit - note: you can see the vertex squishing effect in the difference of the texture stretching on the sculpties. I guess this shows that the uploaded 2x2 does indeed make a 4x4 texture and it isn't an error in numbers in the texture display floater).

 

[Gaia Clary]

Is there a way to proof that the faces are NOT sqished ? Are the meshes realy made out of 6 tris and 2 tris ?

Domino states that the viewer code contains a hard coded constraint that the minimum supported sculptmap size is 8*8 pixels...

[Drongle McMahon]

Yes. That agrees with my recollection and is why my table stopped at 8x8. But I don't think the wireframe can lie. I'm going to peer at the latest code for a bit.

[Domino Marama]

The hard coded constraint is a minimum of 4 x 4 quad faces.. That needs 5 x 5 pixels to describe on a sculpt map. As SL doesn't support non power of two textures, that means we need to use an 8 x 8 sculpt map. Using a 4 x 4 map is only enough for 3 x 3 faces, but the 4 x 4 faces will still be mapped to this smaller image, resulting in one compressed face and the three you can see. The 2 x2 example has 3 compressed rows in U and V, so you only see a single quad of the 4 x 4 quads. You can test this by applying a UV Grid image, or even a simple black and white checkerboard and seeing how much of the texture is used on the visible faces.

[Gaia Clary]

I tested a cube made out of  4*4 faces (8*8 sculptmap). It does not suffer from any LOD effects. I set my renderVOlumeLOD to 1.25 and went far far away until the cube was no longer visible (because it became too small to look at). i could not see any LOD jumpings while moving the camera forward/backward. So it IS LOD stable...

Now it would be realy cool if we could get fractional costs ;-) 

a 16 faces sculpty -> 0.0156 Primcosts

well, just an idea ...

[Gaia Clary]

ok, it IS squished. But somehow its different from what i expect to see. So the constraints imply that i can not go below 16 faces. (8*8 sculptmap...). That implies to me that when i SEE only one face, then only 1/16 of the texture should be used when it is scaled to <1,1>

But i see the full texture in U and 1/4 of the texture in V. And that implies that my object has actually 4 (squished) faces instead of the expected 16 faces...

How can that be explained ?

 

[Drongle McMahon]

Checked out the code, all in llvolume.cpp. I think saying 8x8 is a hard coded limit overstates it*. Rather, the code only works as expected for images 8x8 or bigger, It still works for 4x4, bt doesn't do what you might expect.

Firstly, in sculpt_calc_mesh_resolution, there is a sequence of divison and max statements that ends up with the resolutions 4x4 for an 8x8 map, but 1x4 for a 4x4 map. That explains why there is only one quad in the vertical dimension.

Secondly, in LLVolume::sculptGenerateMapVertices, the mechanism that setx the map coordinates for extracting the "extra" vertex in an unstitched plane converts the (out-of-range) last one, 8, to 7 for an 8x8 map, giving [0,2,4,6,7]. However, for a 4x4 map, the rounding (type conversion to integer) makes the last one 3, giving [0,1,2,3,3]. So the last two are the same and the last quarter of the texture is squished out of existence.

This fits with an in-world observation with that sculpty and an 8x8 grid texture. All 8 squares seen in the single vertical texture (because the vertical resolution is 1 fitted to the whole texture) and only 6 squares of the grid horizontally, confirming that there are only three quads in the wireframe becasue the last one is squished, while the texture is stretched over the visible three and the squished one.

* just semantics. no argument implied.

[Drongle McMahon]

Gaia, see the above. The code makes it have only one quad in the vertical dimension. So it stretches the texture exactly over that and you see all of it. Horizontally, the 4x4 expanded without interpolation from the 2x2 has identical values at 0,1 and at 2,3. So the vertices end up as [a,a,b,b,b] and only the second 1/4 of the texture is unsquished.

[Drongle McMahon]

Hi Domino. Very pleased to see you back here. Looking at sculpty code brings back old memories. :matte-motes-grin:

[Domino Marama]

Yeah looking at the sculpt code does bring back memories, and having to say "this is how it should work" and "here is how the LL code does it" is positively deja vu