Sharp Sculpties - Not deformed balloons

Fine for logs and barrels, where the last row specifies coplanar vertices, but in the general case this could make very ugly caps, including possible intersecting faces etc. Still, I suppose it would be up to the sculptor to avoid these; so it's not really an objection. It's easy enough to produce ugliness anyway. I have done plenty of that.

That's assuming the conclusion. You can fabricate the 33rd row by duplicating the 32nd if you make the sphere 32 rows of vertexes (31 rows of faces) high.

Yes, and then you get the problem with LOD. That's what I was trying to say.

As it is now, the stitched edges do indeed fabricate the 33rd row from the 1st. The 33rd was originally required only for the top pole, as all sculpties were spheres.

(But I don't see how you can fabricate the second pole of a sphere... it is not the geometric centre of the preceding row, even in an unaltered perfect sphere, certainly not once you distort it.)

I don't see the problem with LoD.

You're not fabricating it, you're simply using fewer rows. Row 31 is the pole, instead of row 33. Row 32 is not used.

LoD 3: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
LoD 2: 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31
...

33 rows of faces with the implicit end caps

Plane would be 31 x 31 faces
Cylinder 32 x 31 faces (extra faces drawn from 32 to 1 on X)
Torus 32 x 32 faces (cylinder with extra faces drawn from 32 to 1 on Y)
Sphere 32 x 33 faces (a cylinder with end caps)

All from a 32 x 32 pixel sculpt map and 32 x 32 vertex points.

Note: for anyone coming into this late, this is a discussion about what could have been. Don't try to use this info in your sculptie making

Errmm... see what you wrote.Now you have only 31 vertices, not the 32 I thought you wanted originally.

And, I invite you to add the next two rows....(!!).

My last word (I hope). I have said all I can usefully (???) on the subject.

OK, make it:

LoD 3: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 ,21,22,23,24,25,26,27,28,29,30,31,32
LoD 2: 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,32
LoD 1: 1,5,9,13,17,21,25,29,32
LoD 0: 1,9,17,25,32

Exactly. It requires different subsampling somewhere (at the end for this scheme, but why not the other end? why not the middle?), and different from step to step: everywhere omit alternate one each time, except at the end - omit two, omit none, omit one. So the end behaves differently from everywhere else. To me that is a problem. Each to his own I suppose.

D**n, and I promised to shut up!

Because it's simple, and because the end-points already behave differently from anywhere else anyway.

From what I remember from when I looked at it, the trick was to request the same LODs as currently, so 32, 16, 8, 6 faces rather than vertex points. So you end up with a plane type with LODs of 32, 17, 9, 7 vertex points. The difference comes with seams, as the seam faces are a constant size with this method, so the texture UV mapping is more complex - and probably the reason things are the way they are.

No they don't. Exactly every second vertex is removed at every step all the way along.

isn't there a deviation when switching from LOD1 to LOD0 ?

LOD3 = 32*32 = 1024 faces
LOD2 = 16*16 = 256 faces
LOD1 = 8*8 = 64 faces
LOD0 = 6*6 = 36 faces

The end cap of sphere are handled specially even if there is *no* LoD.

* The UV map is cut, not scaled: half the texture at a given LoD is simply not used.
* Only a single vertex is used out of the first or "33rd" row.

When you add LoD, you have to deal with the fact that different amounts of the UV map are discarded at different LoD.

The result is that the best thing you can do with the end cap of the sphere is to fold it inside the sculpt, hide it behind another prim, or accept the fact that it looks like ass.

Marginally improving the end cap at the cost of quadrupling the amount of data that has to be downloaded is a false economy.

I agree that the poles are horrible, but not that this has any bearing on the desirability of regular subsampling, at least keeping both ends treated the same! We will just have to disagree there. I don't think 4K is too bad. Same as an equivalent mesh with 32 bit float coordinates (not as good, of course). I do agree the waste is distasteful....I blame the power-of-two upload requirement, not the design decisions for sculpties.

I'm sorry I have to disagree:

How can we apply these ideas to the study of the Bell number? Since measurements in the space-time region R1 do not disturb measurements in R2, it follows that a1 and a2 are compatible, so [a1,a2] = 0. In the same way, we deduce all these relations:

[a1,a2] = 0, [a1,b2] = 0, [b1,a2] = 0, [b1,b2] = 0
(6)

However, measurements carried out in the region R1 will in general disturb each other, so a1 and b1 will in general be complementary rather than compatible. Thus

[a1,b1] ¹ 0, [a2,b2] ¹ 0
(7)

We're now ready to apply this ``quantum algebra'' to the study of the Bell number. We can express the Bell number (1) in quantum theory in a way similar to what we did earlier:
bell = áa1a2ñ+áa1b2ñ+áb1a2ñ-áb1b2ñ = ácñ
(

where c = a1(a2+b2)+b1(a2-b2)
(9)

Let's now calculate c2, being careful to remember which quantities are compatible and which are complementary. We'll also use the fact that a12 = 1, since a1 can only be ±1, and the same identity holds for the other quantities:
c2
=
[a1(a2+b2)+b1(a2-b2)][a1(a2+b2)+b1(a2-b2)]


=
a12(a2+b2)2+b12(a2-b2)2+a1b1(a2+b2)(a2-b2)+b1a1(a2-b2)(a2+b2)


=
(a2+b2)2+(a2-b2)2+a1b1(a22-b22+b2a2-a2b2)+b1a1(a22-b22+a2b2-b2a2)


=
a22+b22+a2b2+b2a2+a22+b22-a2b2-b2a2+a1b1(b2a2-a2b2) +b1a1(a2b2-b2a2)


=
4+a1b1[b2,a2]-b1a1[b2,a2]


=
4+[a1,b1][b2,a2]




This computation has resulted in the following useful formula: c2 = 4+[a1,b1][b2,a2]
(10)

Of course. I give up. You are right. Why didn't I see that. Now please ask Argent to let go of my ankle. His teeth are too sharp.

I think it's insane. I'm already working to use stretched versions of the same sculpts to reduce the number of distinct sculpts in avatars I'm wearing, to reduce the loading time for people around me. Decreasing that loading time by a factor of four is well worth a minor change in the appearance of degraded sculpts that most people won't even notice.
It's a simple application of quantum immortality to number theory, and the use of quantum suicide to create a metric in which P=NP.

I always thought that the sculptmaps are uploaded with "lossless compression". This implies (to me) that they will also be downloaded to the SL viewer by using the same method. If that is true, you can not derive the data size from the image size, but only from the image content. Now there was a rumour that 128*128 pixel sculptmaps would be better compressible than 64*64 maps, which in turn would lead to faster loading times... Well it is a rumour, but who knows if it contains a quantum of verity...

I do know a bit about lossless compression... I was on the team that designed the PNG file format... and in general if you reduce the size of a file by a factor of four you will reduce the size of the compressed file by a comparable factor, whether you're using lossless or lossy compression. Now I've been out of the loop for a good few years so I won't say it's impossible there might be pathological cases where padding the image will reduce the final size of the file, but I've never heard of any real images doing that. If it was at all common the same transform would be incorporated in compression routines long since.

I think that was based on a jpeg2000 compressed 128 x 128 compared to a lossless 64 x 64. In that situation the compressed file could be smaller, but not as accurate.

Good point. I did some experiments with the png and jpeg2k(lossless) compression in Infranview, using one of my 16x256 maps. To cut a short story even shorter, you are both right. The doubled-up image is substantially bigger than the subsampled one, but less than 4 times (2.8x for jp2k, 1.7x for png*). I must find more useful things to do with my time.

*the png was much better for both unless the redundant pixels were interpolated isnetad of duplicated ... I thought png was always lossless. Is that right, Argent?

PNG is always lossless. It uses the "deflate" compression mechanism from the pkzip family of compressors, on top of a variety of interlacing schemes. The same image data can be encoded in deflate format in pretty much unlimited ways, so the quality of the compressor and the strategies it uses have a huge effect on the outcome. If the compressor you're using implements the zlib-rle (run length encoding) strategy that would explain why it does a better job with images containing more repeated pixels.

I consider 2.8x to be of the same order of magnitude as 4x. It's a pity they don't use PNG internally... it's designed to be lossless and I would expect it to beat out Jpeg 2000 most of the time.

Ah, that makes a lot of sense.

concerning the amount of data transported with sculpties, each sculpty (well almost each sculpty) gets compressed to something < 4 KBytes for sure. But most Sculpties also use a texture. And such textures are typically much bigger than 64*64 pixels. 256*256 sounds "normal". So isn't the whole discussion a bit academic at the end ?

If it was then LL wouldn't have reduced the priority of sculpt textures.