Sculpts, and all that

[animats]

I'm working on my renderer, and I'm trying to get sculpts right. Or, rather, be compatible with the way SL does things. I'm close, but I have one main problem - how do sculpts indicate the difference between a smooth shaded edge and a hard edge?

I see a lot of "doubling" in sculpt textures I look at, where the same pixel is duplicated in adjacent rows or columns. This, I'm told, is to get better results at lower LODs. It implies zero-sized triangles being generated and discarded. The trouble is, I treat that as a hard edge when rendering, as you would in a mesh. So I don't smooth shade across a doubled row or column. Rows and columns that are not doubled work fine.

What indicates a hard edge (no smooth shading, separate normals for adjacent triangles) in a sculpt? Break angle? If so, what's the magic angle where things go from smooth to hard edge? Or is it done some other way?

Sculpt sizes are unexpected. Sculpts seem to be limited to 4096 (= 64 * 64) pixels. It's pixel count, not dimensions, that matters. I've seen 16 x 256 and 32 x 128 sculpts, and they need all those pixels to work.

I have a few full old perm sculpts to look at - cube, sphere, and barrel. They're not what I expected. For the cube, I would have expected 24 vertices, and maybe an 4x8 sculpt texture. But no. The classic cube is a 32 x 128 texture, most of which is the grey 128 value that puts a useless vertex in the center. What's with that? The sphere has doubled pixel rows, and I render it with hard edges, while Firestorm smooth-shades it. The barrel does not have doubled pixel rows, and renders with nice smooth surfaces in both curved directions in my own system.

This shows up in non-test objects. The Statute of Liberty holding a prim at the Ivory Tower of Primitives shows unwanted hard edges, for example. Not on all its parts, just some of them.

This is all ancient history, but there's a lot of legacy sculpt content still out there.

A sculpted cube, a full perm object from the past. That big grey area generates a huge number of zero sized triangles at the center.

[ChinRey]

4 hours ago, animats said:

I'm working on my renderer, and I'm trying to get sculpts right. Or, rather, be compatible with the way SL does things. I'm close, but I have one main problem - how do sculpts indicate the difference between a smooth shaded edge and a hard edge?

It's inherently all smooth normals, no hard edges. Except along the edges of the map of course.

 

4 hours ago, animats said:

I see a lot of "doubling" in sculpt textures I look at, where the same pixel is duplicated in adjacent rows or columns. This, I'm told, is to get better results at lower LODs. It implies zero-sized triangles being generated and discarded. The trouble is, I treat that as a hard edge when rendering, as you would in a mesh. So I don't smooth shade across a doubled row or column. Rows and columns that are not doubled work fine.

Yes, doubling of vertices is usually done to strengthen the LOD but also occasionally to emulate hard edges so you have the right idea there. I'm not sure why the standard viewers render the cube in your illustration with smooth normals, maybe @Beq Janus knows something about it?

Btw, the zero-sized triangles are not discarded, they are kept all the way through the rendering pipeline. With planar and cylinder stitching you even get zero-sized stitching triangles along one or two of the edges of the map. This is one of the major mistakes the Linden developers made when they created the sculpt system and if you fix that, you've done a great job!

 

4 hours ago, animats said:

Sculpt sizes are unexpected. Sculpts seem to be limited to 4096 (= 64 * 64) pixels. It's pixel count, not dimensions, that matters. I've seen 16 x 256 and 32 x 128 sculpts, and they need all those pixels to work.

Yes, a sculpt map needs a minimum of four pixels for each vertice. I'm not sure exactly why. It may be because of the backwards way the viewer proceses the map, it may be because the uploader always blurs textures or it may be both. Sculpt maps with more than four pixels per vertice are allowed. They add a lot of processing time and are depressingly common.

The original sculpt map system only allowed for 32x32 vertice matrixes. Later the system was expanded to allow for any number of vertices as long as the total number of vertices is no higher than 1024 and the number along each axis is binary and >2 (so 4, 8, 16, 32, 64, 128 or 256). However, sculpt maps with a reduced number of vertices can cause some rather weird results when reduced for LOD models. Here's an old post by Drongle McMahon about this. Drongle uses the "reversed" numbering system for LOD levels btw, LOD 3 is high, LOD 0 is lowest. (I wish Drongle or TheBlack Box was still here. They could have answered all your questions about sculpts. Unfortunately they're both long gone.)

Very few people are aware that sculpt maps with fewer than 1024 vertices exist and none of the sculpt map editing programs/scripts support it. This is why we get abominations like the 1024 vertice cube in your picture.

 

4 hours ago, animats said:

This is all ancient history, but there's a lot of legacy sculpt content still out there.

Yes and yes.

I'm still adamant that the basic idea behind sculpts - polylist meshes with a reduced dataset - is very sound and a potentially very valuable addition to any streamed virtual reality. But the way it's implemented in SL is flawed beyond repair.

Edited May 2, 2022 by ChinRey

[ChinRey]

40 minutes ago, ChinRey said:

Except along the edges of the map of course.

Maybe that isn't as obvious as I thought so I'll try to explain a bit better.

Here's the vertice matrix for a 4x4 vertice sculpt (8x8 pixel sculpt map):

The black vertices are the ones defined by the sculpt map. The yellow ones are the stitching vertices and their coordinates are defined by the stitching type:

• Plane: All stitching vertices are co-located with the nearest vertice on the map: X1Y5 with X1Y4, X2Y5 with X2Y4 and so on.
• Sphere: All stitching vertices are co-located with X1Y1.
• Torus: All stitching vertices are co-located with the vertices at the other edge of the map, the Y5 vertices with the corresponding Y1 ones and the X5 ones with X1.
• Cylinder: Y5->Y4, X5->X1. Or maybe it's the other way round (Y5->Y1, X5->X4), I can't remember.

The key word here is co-located. The stitching vertices are never merged with the ones from the map, they are just placed at exactly the same coordinates.

Edited May 2, 2022 by ChinRey

[animats]

9 hours ago, ChinRey said:

Yes, a sculpt map needs a minimum of four pixels for each vertice. I'm not sure exactly why.

Me either. My system works with one pixel per vertex, which is what the wiki says to do.

9 hours ago, ChinRey said:

Yes, doubling of vertices is usually done to strengthen the LOD but also occasionally to emulate hard edges so you have the right idea there.

Here's the hard-edge problem in more detail.

Bench, in Firestorm. Note the nice smooth curves on the bench arm. This is a very well made sculpt object. Each arm, and the slats, are separate sculpts.

Same bench with my renderer. It has doubled vertices, so it gets sharp edges.

Some sculpt objects I use for testing. Firestorm. That's the classic Linden fruit plate.

Same objects, drawn with my own renderer. Note the facets on the spheres. The near cube, the leftmost dish, and the nearer sphere are sculpts with planar texture projection, which is rarely used. Everything else has default texture projection. The barrel sculpt doesn't have this problem. Nor does the fruit plate. When I first got the fruit plate right, I thought I was done.

The sculpt sphere, in Edit. Texture is 32 x 128. You can see the horizontal doubling - 32 pixels, but only 16 different squares. Vertically, there are 128 pixels, so you can't see if there's doubling. But there probably is.

The question is, what, in a sculpt, says "This is a sharp edge?" Doubling the vertices does not always generate a sharp edge. Is it done by break angle? Something, more than 30 degrees difference between adjacent triangles means a sharp edge?

So I'm very close to matching the LL and FS viewers, but not quite there yet.

 

 

[arton Rotaru]

1 hour ago, animats said:

The question is, what, in a sculpt, says "This is a sharp edge?"

Well, it's about 12 years ago when I made sculpts, but they are smooth shaded no matter what. When you see sharp edges, then it's "open" edges. Back in the day, low Prim count was even more important than it is today. So we used rather radical techniques to get the most out of a single sculpt map. This was done by folding every single polygon origami-ish.

Edited May 2, 2022 by arton Rotaru

[animats]

5 minutes ago, arton Rotaru said:

When you see sharp edges, then it's "open" edges.

Hm. That cube sculpt above has hard edges. Its 32 x 128 sculpt map is nothing like what you'd expect, but it works. It's really the same layout as the sphere, but with the vertices pulled outward out to fill a cube. What makes it have hard edges? There's clearly some trick here, and it probably involves all those useless zero-area triangles in the center, represented by the grey area.

The Linden-created fruit bowl doesn't do any of this weird stuff.

(I appreciate the help. Reverse engineering edge cases in old data formats is not fun.)

[arton Rotaru]

18 minutes ago, animats said:

Hm. That cube sculpt above has hard edges. Its 32 x 128 sculpt map is nothing like what you'd expect, but it works. It's really the same layout as the sphere, but with the vertices pulled outward out to fill a cube. What makes it have hard edges?

That's probably just double/triple vertices superimposed. By pulling the inner edgeloops to the outer edges. Pretty similar to what is known as supporting edgeloops in subdivision modeling.
A cube can be folded from a plane sculpt with all open edges as well.

I don't know what the grey area is about, never seen one of those.

Edited May 2, 2022 by arton Rotaru

[ChinRey]

17 minutes ago, animats said:

...

and it probably involves all those useless zero-area triangles in the center, represented by the grey area.

No, those are just the pixels representing the superfluous vertices. Remember I said that sculpt maps with less than 1024 vertices/4096 pixels was an all but unknown feature. That means that nearly all sculpt maps are made for 1024 vertices even if only a small number of them are actually used. If the grey pixels were to have any effect on  the geometry or nomrals, they would have been intersperesed among the colored pixels, not bunched up at the bottom of the map.

As Arton said, sculpts always have smooth normals except of course at the edges. I may have been wrong here though:

12 hours ago, ChinRey said:

doubling of vertices is [...] also occasionally to emulate hard edges so you have the right idea there.

I haven't worked with sculpts for a long time and only for large objects where LOD wasn't a serious factor so I never really used doubled vertices myself. It's possible I misremember and that normals are smooth across the collapsed tris. If so, the sharp edges on the bench are done with the edge vertices using the origami method Arton mentioned. Speaking of that, you may want to contact Jubjub Forder in-world (he's never on the forums unfortunately). He's the one who came up with the origami concept and if anybody remembers, it would be him.

Smooth normals don't actually make any sense with collapsed tris. The direction of a smooth normal is of course defined by the direction from the vertice to the neighbor ones and the moment you have co-located vertices, the direction from one to the other is undefined. LL must have come up with some sort of workaround for this but exactly how is hard to say.

What I suggest you try is cull all collpased tris, then merge all the co-located vertices (except the stitching vertices of course). See if that works.

[arton Rotaru]

Yeah, you will have double verts when putting two open edges together. Without removing/merging doubles indeed. I also used the "half resolution" sculpting to make it more LOD stable. The medium LOD will look the same as the High LOD then.
There also used to be a trick to shrink the sculpty artificially. It had a bigger bounding box than the actual geometry, which pushed LOD swaps further out. Can't remember how it was done though. I believe it was by blurring the sculpt map in one dimension.

If there would be a threshold of when sculpts would have hard edges, we would definitively know, though.

Edited May 2, 2022 by arton Rotaru

[animats]

2 hours ago, ChinRey said:

What I suggest you try is cull all collapsed tris, then merge all the co-located vertices (except the stitching vertices of course). See if that works.

That makes sense. Not clear which UV values to use for a row/column of duplicated verts, but I'll test.

[ChinRey]

17 minutes ago, animats said:

That makes sense. Not clear which UV values to use for a row/column of duplicated verts, but I'll test.

Oh, I forgot to consider the UV mapping. You can't simply merge the vertices then since they will need different UV coordinates. But you have exactly the same issue with meshes where smooth normal vertices are split for separate UV islands and/or faces but still retain the smooth normal vectors.

[animats]

Thanks, everyone. Still have more work to do.

Today's discovery: 8 x 512 sculpts are a thing, and my UVs are off by one pixel, which really shows when there are only 8 pixels.

[ChinRey]

On 5/2/2022 at 11:23 AM, ChinRey said:

...

their coordinates are defined by the stitching type:

• Plane: All stitching vertices are co-located with the nearest vertice on the map: X1Y5 with X1Y4, X2Y5 with X2Y4 and so on.
• Sphere: All stitching vertices are co-located with X1Y1.
• Torus: All stitching vertices are co-located with the vertices at the other edge of the map, the Y5 vertices with the corresponding Y1 ones and the X5 ones with X1.
• Cylinder: Y5->Y4, X5->X1. Or maybe it's the other way round (Y5->Y1, X5->X4), I can't remember.

Not surprisingly, I was wrong. Something like this would have been way to simple and obvious for LL.

Here's a screenshot of a JVTEK ground sculpt with planar mapping converted to mesh:

A ground sculpt is a good test object since the vertices will always be spaced evenly along the x and y axises.

As you can see, there are 33 vertices along each axis even though the map only defines 32. What happens in this case is that the top and righ rows of vertices are extrapolated from the positions of the neighbor vertices. I say "in this case" because I don't dare say this is how sculpts are always handled. I'm fairly sure I've seen sculpts with collapsed rather than extrapolated stitching vertices. Maybe those are cases when the extrapolation algorithm couldn't come up with a sensible answer?

With cylinder stitching the x stitching vertices are co-located with the X1 ones while the y ones are extrapolated.

Sphere stitching is rather funny:

X stitching vertices are sent back to X1 just like cylinder stitching, Y stitching extrapolated along the Y axis and collpased onto X17 along the X axis. And then Y1 vertices which are all defined by the sculpt map are also collapsed onto X17 along the X axis!

Torus stitching seems to work the way I described although it's so messy with a flat sheet sculpt like this I'm not 100% sure I didn't miss something.

[animats]

Thanks.

I have the geometry right, but I'm still struggling with how UVs wrap.

Sculpt set of books. Firestorm. This is an 8 x 512 spherically wrapped sculpt.

Rendering with my renderer. UVs are wrong. U is OK, but V seems to be off by 1. Also, doubled rows in the long direction are messing up the UV spacing.

 

Classic sculpt globe. The globe is an ordinary sphere, but the rings are a sculpt.

New renderer. Not quite right. I copied the rings, which are a single sculpt with cylindrical wrap, to get a better look.

All the vertices seem to be in the right place. The UVs are slightly off. I tried some obvious UV adjustments, but that broke the barrel I've shown before. The seam at the back of the barrel overlapped.

Is everybody bored yet? I'm doing this publicly because it involves SL history which was before my time. Few make sculpts today.

I'm acquiring a small collection of strange objects like these, currently laid out around my workshop in Vallone. Most of these objects are from Marketplace, or are old freebies. About three weeks ago, it was shiny things. Fixed that. Then planar texture mapped things. Fixed that. This week, sculpt things. Maybe I can contribute all these to Bug Island, as additions to the permanent collection of objects that have given viewers trouble.

[ChinRey]

5 hours ago, animats said:

All the vertices seem to be in the right place. The UVs are slightly off. I tried some obvious UV adjustments, but that broke the barrel I've shown before.

Here are the UV maps for 32+1x32+1 (64x64 pixel), 256+1x4+1 (512x8 pixel) and 4+1x256+1 (8x512 pixel) sculpts/sculptmaps with the stitching vertices highlighted:

As you see, it's very simple, vertices spaced evenly along the axises with the stitching ones along the top and the right edge. I haven't tested the other map sizes but I see no reason why they shuold be different. I would guess the reason you get the offset is that you forgot to take the stitching vertices/tris into account.

[animats]

Turns out that "doubling" causes serious problems. Think about it. Duplicating a pixel means a two vertices at the same place, and thus a zero-area triangle. But that triangle had UV space assigned to it, and so, part of the texture never gets mapped to anywhere. That's where the bottom half of those book spines is going. That sculpt is 8 pixels wide, but the stripes are doubled. If it's used without any reduction in size, the first two pixels of the spine of the book going upwards are the same. So, that's a zero sized triangle which has the bottom half of the book spine assigned to it, and it disappears.

Now, if the sculpt texture is reduced in size before generating triangles, so there are only 4 pixels and they're all different, it works.

How much to reduce? 4096 (=64*64) is too big. 1024 (=32*32) is too small, and important vertices disappear. 2048 seems to match what SL does. There are still some problems, though.

Doubling vertices only works because of the very specific way SL reduces sculpt textures.

Getting closer.

[ChinRey]

6 hours ago, animats said:

Turns out that "doubling" causes serious problems. Think about it. Duplicating a pixel means a two vertices at the same place, and thus a zero-area triangle. But that triangle had UV space assigned to it, and so, part of the texture never gets mapped to anywhere.

...

Doubling vertices only works because of the very specific way SL reduces sculpt textures.

No, this is how collapsed triangles work for regular mesh too (except of course that we don't usually want them there at all). It't the vertices that have coordinates, not the tris and co-locating two of them in XYZ space does not alter their UV coordinates even if they happen to share a tri between them.

[animats]

3 hours ago, ChinRey said:

No, this is how collapsed triangles work for regular mesh too (except of course that we don't usually want them there at all). It't the vertices that have coordinates, not the tris and co-locating two of them in XYZ space does not alter their UV coordinates even if they happen to share a tri between them.

Each pixel in the sculpt has its own UV value, determined by its position in the sculpt image. It's not like meshes, where the mesh has stored UV values at each vertex. So, if you have, say, a block of four identical pixels in the sculpt image, that turns into two zero-area triangles which own some of the UV space. That part of the UV space will never appear in the output image. That's why the lower half of the row of books above disappeared. That's an 8 x 512 sculpt image, and the front of each book only has a top and bottom vertex, both doubled.

What's happening, I think, is that the LL sculpt builder reduces the dimensions of the input image, which prevents this. But I'm not sure how much. Some sculpts seem to need 64 x 64. Reducing them to 32 x 32 will break them badly. The book set works if the 8 x 512 is reduced to 4 x 512, but not if reduced to 8 x 256. There's some arbitrary size reduction scheme, I think, but I haven't been able to figure out what it is.

[ChinRey]

44 minutes ago, animats said:

So, if you have, say, a block of four identical pixels in the sculpt image, that turns into two zero-area triangles which own some of the UV space. That part of the UV space will never appear in the output image.

Yes and that's exactly how mesh works too.

Here's a mesh triangle with the UV map to the left:

Here's the same triangle collapsed, it doesn't alter the UV mapping one bit:

If this triangle had been part of a larger mesh, the UV space it takes up would never appear in the output, just like on a sculpt.

 

47 minutes ago, animats said:

...

in the sculpt image.

Do not ever use the term "sculpt image" because that is what 99% of the confusion and problems with sculpt maps stems from. Lindens, content creators and regular SL'ers all get this wrong all the time.

A sculpt map is not a texture and it's not an image. A sculpt map is a list of vectors defining the XYZ coordinates for the vertices, nothing more and nothing less. The only reason why it is stored as an image file is that a 24 bit RGB image just happens to have a data set and configuration not too unlike what the map needs. It would have been much better and less confusing if the sculpt mmap had been stored as a binary file or even as XML but that would have required some proper development work and this was back in 2008, right at the beginning of the Six Dark Years so proper development work was out of question.

[animats]

Here's LL's sculpt resizing code, in Firestorm, at sculpt_calc_mesh_resolution.

// this code has the following properties:
// 1) the aspect ratio of the mesh is as close as possible to the ratio of the map
// while still using all available verts
// 2) the mesh cannot have more verts than is allowed by LOD
// 3) the mesh cannot have more verts than is allowed by the map

What the code actually does, though, is divide the number of vertices put in by 4, and limits the reduced size to no more than that. Sometimes less.

S32 max_vertices_map = width * height / 4;

So 3/4 of the input data is always discarded, regardless of sculpt size. This is the mechanism underlying sculpt size lore. "Doubling" is a creator strategy to overcome that.

[Gabriele Graves]

I don't have anything to contribute here except to say thanks @animats  This and your other topics around the creation of your prototype viewer are fantastically interesting to me and incredibly impressive.  I love reading about your progress.

[animats]

Ok, to finish this up:

The Bug Island collection of troublesome sculpts. Rendered with Firestorm.

 

Same objects, rendered with my renderer. Didn't bother to match the lighting.

Here's how sculpt sizing and "doubling" really work:

• The limit on vertices used in generating a sculpt is 1024. This is 32 x 32, but it's the product that matters, not the individual dimensions. 8 x 128 works. Long and narrow sculpts were once popular, as people tried to do mesh things with sculpt tools.
• You have to provide 4x as many vertices as you need. That is, if you want 32 x 32, you put in 64 x 64. Only one vertex of every 4 you put in is ever used. It's the one nearest the origin. There is no averaging or smoothing. This is regardless of size. Even if you put in a small sculpt, you must "double". I suspect this is a legacy from when SL was storing sculpt with lossy compression.
• The only exception to the above is that the number of vertices along a side will not be reduced below 4. So if you put in a 4 x 32, that should not get reduced.
• Reduction tries to maintain the original aspect ratio for very asymmetrical meshes. 8 x 512 will reduce to 4 x 256.

There's also a lot of fussy stuff about rounding and adjustment for wrapping. If you want that info, send me a message.

Incidentally, mirroring is a simple X axis inversion. It doesn't create both halves of a symmetrical object, like mirroring in Blender.

Now I'm going to take some time off. Go out. Maybe make another video.

 

Edited May 8, 2022 by animats

[animats]

Oh, one more note. Normally, a sculpt cannot have more than 1024 vertices. But there's an exception, possibly due to a bug. Make a sculpt 512  x 8, and it will only be reduced to 256 x 8, not 256 x 4. So there's a trick to get double verts for 1 LI.

And, sure enough, that bug has been exploited.

The Albatross. From Jules Verne's "Robur the Conquerer" (1886).

The Albatross is permanently moored to a tower in Babbage Palisade, rotors turning. It's also available on Marketplace for L$0, with full permissions. It's flyable.

This model uses 512 x 8 sculpts to get 2048 vertices for one LI. If reduced to 256 x 4, many triangles will disappear and the model looks terrible. It really needs that trick.

There's a delicate balancing act here. Don't reduce the sculpt data enough during rendering, and you get unwanted hard edges as triangles drop out. Reduce it too much, and triangles disappear. There is some SL content carefully tuned to match exactly how the LL viewer renders it.

Spent a week on this. Huge pain to find. Which is why I'm writing this up, so the next person who needs this info can find it.

[Love Zhaoying]

Sculpties used to be notoriously slow to fully load/display, starting as a blob or sphereish shape. How's your renderer on the sculpty speed? 

[animats]

30 minutes ago, Love Zhaoying said:

Sculpties used to be notoriously slow to fully load/display, starting as a blob or sphereish shape. How's your renderer on the sculpty speed? 

Same speed as mesh. Fast. Not a problem. Now, JPEG 2000 image decompression, that's a problem. Long topic, not really relevant here. Sent a message.