sculpts + quad/vertex duality question w/ blender

OK, I've got the blender tutorials. No problem. I'm still a bit confused about how the mappings between mesh->sculp->texture work though

1) So.. a sculp map is 64x64 vertices, but a 64x64 UV map in blender is made up of quad cells, not vertices. When I bake my mesh to a 64x64 texture, am I not making a sculp map of the face locations of my mesh instead of vertices?

2) When textures are mapped to a prim, the mapping is face-based. But texture maps are vertex based. Let's say I have a 32x32 checkerboard pattern texture and I want each quad of the sculpty to be either black or white. Is there an offset that needs to be put into the texture so that the sculpt vertices don't fall right in the middle of each square? Or is there a default shift of some sort?

Damn good questions!

I've written a MAXScript sculpty exporter for 3ds Max and I don't know the definitive answers to these questions either.

A 64x64 sculpt map appears to be interpreted in the following manner for the spherical topology at the highest LOD:

- Pixel 32 of the top row (0) defines the "north" pole of the mesh.
- The odd-numbered rows (1-61) define the subsequent "rings" of the mesh, using only the even-numbered pixels(0-62).
- Pixel 32 of the bottom row (63) defines the south pole.

From this I am making the following assumptions:

- An axis which doesn't wrap -- vertical, in the sphere's case -- reads the first row/column and subsequent odd-numbered rows/columns. (63 total)
- An axis which does wrap -- the sphere's horizontal -- reads only the even-numbered rows/columns. (62 total)

If you mask off a sculpt texture so that all but those pixels are black and preview it as a sculpt prim in the upload dialog, it shows the same results as an unmasked texture. (However, don't upload it like that, since the preview displays the mesh *before* the texture is compressed, and the JPEG artifacts cause much worse distortion on a single pixel surrounded by black than it does for a pixel surrounded by more equivalent colors)

Ergo, I am further assuming that the yet-to-be-implemented topologies will behave thusly:

- Cylinder: Same as the sphere, but reads all even-numbered pixels of top and bottom rows.
- Torus: Reads even-numbered rows and columns. (wraps on both axes)
- Plane: Reads top/left row and column, then subsequent odd-numbered rows and columns. (doesn't wrap on either axis)

(Ok, what happened to text tags? I can't even *italicise* text!)

Had not seen this before though to get technical details you should check the Wiki. Everything is documented there: http://wiki.secondlife.com/wiki/Sculpted_Prims_Explained

In Deanna's explanation there's an unfortunate mistake:
In a 64x64 the even rows (2-62) define the rings, not the odd ones. The code will loop from 0 to 64, treating 0 and 64 special to generate poles.

If anything is missing from the Wiki which is needed to create exporter/importer/... use the discussion page on the Wiki so that it can be added. This should be easier to track than forum posts.

I did that a week ago, to no response by anyone in-the-know. If y'all know the answer (esp. to Q2 - I'm pretty confident that the answer to #1 is a big fat yes) please respond on the wiki!

The wiki is wrong. Try to upload the first attached image, cube_odd, to SL, and select "Sculpted Prim" from the "Preview Image As" box. (You need not actually upload the image) Other than row 0, all of the even-numbered rows in this image are black. You should see a somewhat rough cube in the preview window.

Now try uploading the second attached image, cube_even. Other than row 63, all of the odd-numbered rows in this image are black. You shouldn't see anything in the preview window. (But you do, only because the JPEG compression necessary to post the images here in a format that can be directly uploaded to SL causes the black values to be not true black.)

There cannot simultaneously be indexes 0 and 64 in a set of 64. It's either 0-63 or 1-64.

Ok, I figured it out. I should have done more tests We're in the end both wrong. The viewer counts the lines from bottom to top. So row 0 is the bottom line and the line at the top of your texture is row 63. So it samples the even rows but disagrees with us on what the even rows are. I'll update the wiki to clarify that it reads from bottom to top.



I was not talking about indexes. In more detail what it does for max LOD is:
Outer loop runs from 0 to 32 for the rows (33 steps), inner loop runs from 0 to 32 for the columns (33 steps). On the outer column you have 2 conditions. Within the loops it'll calculate the x (column) and y (row) coordinate from which to read the pixel and it will transform those into a 1-dimensional index on the picture. For y when it's 0 or sculpt_height (64 in our case) it'll set the x to sculpt_width/2 (32 in our case). Additionally it'll set y to y-1 when it's 64. Similarly for x it'll set it to 0 when it reaches 32 (it needs a 33th vertex equal to the 1st to do the wrapping).

Or, we're both right, just using different frames of reference.

Actually, that algorithm makes much more sense, reading every other line, and only reading the last line if that axis doesn't wrap.

I agree it makes sense. I just never tested if it read it in the order I expected it to. I created the explanation based on code and when I found the bug for 32x32 textures (by reading the code) I just did a quick test for that and wrote a patch. I didn't realise that it fixed a row of vertices different than the one I expected. After I saw your post I fired up my own client and checked which line was fixed and then I immediately understood how the code fooled us.

Thanks for the help Makes the Wiki a lot more accurate for those writing importers/exporters.

Like myself.

Now I just have to figure out what to do with the rows/columns in between those read for max LOD. Initially, I'd just averaged the pixels to either side, above and below, or diagonally, depending on which pixel I was filling, but then I noticed this caused the verts at lower LODs to skew, since apparently they read those in-between pixels, instead of just every other/forth row/column of max LOD pixels. So I then just started copying the pixel above, to the left, or diagonally, but now I'm not sure if I'm copying from the right direction.

I suppose I could just download the latest viewer code, since I'm not stuck with trial-and-error on the beta grid anymore.

Watermelon,

to be honest I'm not a 3D guru so I'm still considering whether I should've a stab at rewriting the explanation on texturing.

My personal understanding is as follows:
- If you create a sculpture using math and a paint program the end result is easy to texture. As a test I created an 8 sided cylinder. 4 sides having 5 faces and 4 having 3 faces. Total is hence 32. The top and bottom "cap" of my cylinder are made up by connecting to the poles so you that's 32 faces (in theory but not really visibly) on both caps. Leaves 30 for the sides. If I then make a texture that is 512x512 which contains a 32x32 grid of black and white squares this perfectly lines up with my sculpture.

That's the easy part Works fine for anything you create in for example Wings3D and which you then texture elsewhere (by exporting mesh using obj).

For the texture baking stuff I _think_ it works as follows:
When creating the texture map with the Maya exporter and many others you are not exporting vertices. You are sampling the surface. This is great because the complexity of your sculpture can exceed the SL mesh by far. Leaving you with a rougher version in SL but greater control on design. Texturing on the other hand is not as easy because indeed you have no true mapping. Yet I suppose that by sampling the texture similarly to how you sample the sculpture texture you can get what you want. This is I guess also how they sample textures that have light baked in. Sampling not only color but also light gives you the chance to get a better feeling of depth even though you have flat surface where your sculpture in Maya is more complex.

I haven't been able to try out the latter a lot. I've Blender and whatever else is free and can get access to Maya if need be but for now I'm still in the comfort zone of pure math which is done by either just drawing the R, G, B channels myself or by using something like Wings3D.

In theory this should be how to get the best result:
- Make a 128x128
- Make the surrounding pixels of the really used pixels the same color as the pixel itself.
- Average the remainders
That should eliminate JPEG compression.

For lower LOD it's still using the same pixels but skips half or 1/4. Off course for rows we start at the bottom. If you started from the top you probably got different results because you expected it to use a different pixel than it did. But it should not be because it was sampling inbetweens.

Hmm, good tip. It certainly reduces artifact skewing, but doesn't eliminate it.

Ugh, it's worse... The pixels are interpolated, then sampled.

Using the first attached image as a sculpt map, the following wireframe screencaps are the resulting meshes (white) at max, medium, and min LOD. The bounding box for the mesh is shown in yellow. At medium LOD, it shrinks to 1/4, and at min LOD, to 1/16, toward the negative corner. When I use a similar sculpt map masked in 128 grey, the lower LOD's shrink toward the center, and when masked in white, toward the positive corner.

Of course, such effects wouldn't be a problem with a sculpt map without the masking, this is obviously just a test to isolate how LOD's are determined.

How did you force it to a lower LOD and on what software revision? I haven't found any code that performs interpolation when it builds the mesh. I can only imagine that the code that loads the texture performs the interpolation depending on LOD and then different LOD's also use different textures. While this may have sometimes a pleasing effect for organic sculptures I doubt it has a real advantage compared to subsampling without interpolation.

I'll probably not be able to get a real good look at the code before this evening. Work comes first

By pulling back the camera, and zooming to compensate.


Latest beta version. (didn't feel like blowing main grid L$ on uploading test textures)

Ok, method is fine.




I know the feeling. It's the main reason I try to base all the research on the code. No upload costs and it can give definitive answers but it's not always easy to know what you're looking for.

I downloaded source at work and did a quick text search and I found the cause. As expected it does indeed have some sort of texture interpolation going on depending on LOD. This might impact more than just the result of LOD. I'll review the code tonight and see how to tackle it. Interpolation should've no bonus even for organic shapes (on the contrary I can think of many shapes that will be horribly deformed by it). So if that can be proven we can get it out as this is needed to create shapes for which you can easily predict LOD effects.

For now I'll update the Wiki so that it reflects what we know upto now.

also crank your mesh detail down all the way.

THe LODs are killing my stuff. I try to keep ever thing down to 1 prim. and make these complexe builds. But when you loose every other Row/Column in the mesh. Chair legs tend to go away. oh well they are not really ment to be viewed 40 meters away anyways.

I've found some spare time to read some of the code and it seems horribly broken to me. While I expected it to be used for sane memory management it's not the case. On the contrary the downside of the interpolation is that while in theory you could do with a 128x128 you seem to need a 512x512 to beat both JPEG compression and LOD interpolation.

I'll add some debugging code to my build tonight to verify my findings and will then try to come up with a suggestion for a patch. Though given the current JPEG compression it'll still be a tough trade off. I'm not keen on having textures of 128x128 for sculptures but at the same time interpolation will most likely ruin carefully prepared 128x128 textures.

Thanks for all the replies and insight! I ended up writing my own blender exporter that deals with sampling vs vertex locations, but there are a host of other problems that make it still not right!

I guess the long and short of it is that there's precision/accuracy loss every step of the way which together make the resulting sculpt NOT look the way it's supposed to:

1) Loss via sampling vs. direct vertex locations
2) Loss via conversion to ints rather than floats
3) Stupid lumping of pole vertices
4) Loss via image compression
5) Loss via LOD

Wot a pain. Every time I try new things I get more and more frustrated with how much potential there is, and how ridiculously hard it is to get things right. I'll add that it pisses me off no end that all this work is going on by a bazillion people - countless man-hours of reverse engineering, software development, testing etc etc, all because LL implemented something that's UNUSABLE on its own. I need a drink before my head explodes....

The Wiki now contains the explanation of how LOD affects texture interpolation. It should be sufficient to say that it has been implemented in a way that again punishes those who are using low resolution textures. As an end result if you make a sculpt using math and draw all the channels in a 32x32 texture you'll need to blow it up to a 512x512 to have a good chance at determining in advance how it looks at every LOD.

This while 2 changes could bring us to a point where nothing beyond 64x64 will give you improved results. Needed changes are:
- lossless JPEG compression for textures sized 64x64 and below
- no interpolation based on LOD for sculpt textures of 64x64 and below

The idea of sculpted prims is still magnificent but I'm convinced it should've never been put on live grid before these changes were done. Now we'll end up with lots of issues as after we have the 2 above changes implemented we'll still end up having sculpts with textures of 512x512 on the live grid. 512x512x4 is 1MB, 64x64x4 is 16KB ...

I totally agree. I was dumbfounded when they put it on the live grid so soon.

Anyway, Big Thank You to you and Deanna for fleshing out the details of how it works!

Great Work!

Hi there!

i trying to figure out where the actuals pixels used are.
looking at Deanna cube odd and even images was very helpfull thx a lot!
But i think u missed on column of pixels/vertices
If sculpties are 33 *33 mesh : then we need a 33th colum (0 2 4 .... 60 62 makes 32 vert per line) (we allready got the 33 vert vertically with the 2 poles witch seams good for LOD like 33 17 9)
So i guess there s another column of them on the last pixels (n°63 or 64th ) column.

i ll test this and tell here... (i m trying to make a template texture for easilly place the UVs in blender)

Please make sure you read the Wiki. It's all there and more. For the columns it wraps so the 33 vertices are taken from:
0 2 4 ... 60 62 0

i've been exporting 256x256 sculpt maps from blender and I think they look better.

The 33rd column is the 1st column, since the horizontal axis wraps around to the beginning. The 33rd row is necessary since the vertical axis doesn't wrap.