Sharp Sculpties - Not deformed balloons

Does ANYONE have an explanation of why it does this, thus wasting 1/4 the pixels and so quadrupling the size of the file?

Thanks, Gaia.

Glimmerings of comprehension creeping in. I'll get it all eventually.

I was only joking really

Mind you, I probably to have quite a few weird shapes in my inventory by now

Time is helping, Mists are clearing and all that kinda thing.

I believe it's because there's always an odd number of vertices, but an even number of pixels. For example, on a non-oblong, there are 33x33 verts. Since textures have to be in powers of two, the smallest size that can work for that is 64x64.




Nope. The Maya sculpty script does not have those features. All it does is export sculpt maps, baked textures, and primscripts. I keep putting up money offers for improvements, but I haven't been able to find any MEL programmers who understand SL well enough, or any SL users who know MEL well enough.

SLTK for Maya does all that and more, but it's pricey. I'm leery of handing so much money to an overseas company, with no guarantees as to what kind of service I'll be able to get.

In the mean time, for previewing sculpts locally, Blender is probably the best option.




In object mode, Discrete Scale (J) will snap to grid rather easily. However, in component mode, it can be a little tricky. If I have time, I'll put together a write-up of do's and dont's for making it work. It's pretty hard to explain with just text, so it will take a while to write it all out in an understandable way. For now, all I can say is just keep playing with it, and be mindful of how your selections cross the center of the object. The key to it, really, is to work around the center instead of through it.

Maya is an absolutely fantastic platform, but it does miss the boat on a small handful of simple things. Readily intuitive snap-scaling of components is definitely on that list.

If you have trouble figuring it out, you'll find snap-movement to be a hell of a lot easier than snap-scaling. It's a little less convenient, conceptually, but it works well. Also, if you enable mirroring, movement works very much like scaling, as long as your selection object is symmetrical.

Doesn't that depend on the way they stitch them? I would have assumed they'd make spheres 31x32 faces, toruses 32x32 faces, and planes 31x31 faces.

I generally make organic shapes, so this kind of detail really doesn't matter much, but it does seem a rather odd design if that's the way they do it.

Technically, yes, the stitching does change the vertex count when the object is created in 3D in-world. But from a 2D mapping standpoint, they're all there. For spheres, cylinders, and planes, that 33rd column exists on paper, as an exact duplicate of the first column. The two end up combined by stitching, rather than simply co-existing in the same spot in 3D. But just like with UV'ing, when you unfold the mesh into a flat map, those duplicates do have to be there.

Probably a few fuzzy reasons:

As Chosen said, it's partly because there needs to be 33 pixels to store 33 rows of vertices. Although originally sculpties only came with sphere stitching and so the 33rd row of vertices probably wasn't thought to be that important, so I doubt this is the reason alone.

Another reason will be that sculpties originally used compressed images only, and so small 32x32 sculptmap images wouldn't survive the compression very well. When dealing with compressed sculptmaps the larger the sculptmap the better the sculpty.

32x32=:

A column that only exists on paper, that is an exact duplicate of the first column, doesn't need to be stored in the texture and transmitted over the network.

The generated mesh doesn't need to be 32x32 before stitching. It can be 31x31 before stitching. There's no reason the number of *faces* has to be a power of two.

Yes, I get that, but there's no reason that this needs to be carried through to lossless maps.

Yes, it does, because the stitching type is an in-world decision, which is made AFTER the mapping of the original source model has been done.

This is how it works in your local 3D modeling software as well. In most progtams, a sphere is constructed by sweeping an arc around a circular path. If you unstitch a 32x32 sphere, you end up with 33x33 verts. And whether it's stitched or not, when you unwrap it as a UV map, you're looking at a 33x33 grid. Sculpt mapping is directly tied to UV mapping, so the behavior is going to be the same.

Imagine trying to send a UV map over a newtwork, and leaving out that 33'rd column because you want to save file size. Obviously, your texturing would be borked beyond belief. The same thing would happen to the shape of your sculpties if you left out that last column on the sculpt map.



I'm not sure where you're getting 31x31. A 31x31 grid would describe 30x30 faces. What are we supposed to do about the other 2x2?

Remember, the grid points describe the perimeters of the faces, not the centers.

The UV map can still be a power of two, you would just ignore the last N columns of pixels for mappings that aren't stitched. So for a sphere you have 32x32 points, 31x32 faces, and the last row of faces on the raw UV map would be unused. If you took a texture map intended for a sphere, and selected a plane mapping, you would just have a pie slice missing from the resulting sculpty.

A 32x32 grid describes 31x31 faces without stitching.

Yes, that's my point.

Well there's another reason in that I don't think SL supported 32x32 lossless images. I'm still not convinced it supports 64x64 lossless images. It looked like LL had to do some serious hacking to get them make to "work". The last I heard was that they're going to rewrite the whole texture cache handling code. So maybe when they've rewritten the code and SL can handle small lossless images then they may add 32x32 support for lossy sculptmaps.

Although I suspect the 32x32 will understandably be a hack as it may be difficult to add support for both 32x32 and 33x33 meshes, one for lossy and another for lossless. So it's more likely that the 32x32 sculpties will really be 33x33 sculpties with the last row and column of polygons still present yet not visible (33rd vertex from 32nd pixel). Still, shouldn't be too much of an issue.

But who knows, incoming mesh support may make sculpties redundant.

Long overdue. The texture cache has been completely broken for years.

Yeah, I think they once tried to improve the texture cache and we had a grey world for several weeks. So I can see why they're afraid to "improve" it again.

Hi, all;

So here is what a few of the technically affine people taught me . The following was true when only one sculptmap size was supported:

1.) Since SL originally dealt with power of 2 images only, it was consens to also use this for sculpties. And as far as i was told, any map is always scaled to a power of 2 size before it is rendered as sculpty. So better directly use power of 2 sculptmaps in first place to avoid unwanted derivations from the expectations due to downscaling...

2.) The anatomy of sculpties is just like this: It is a single face, 6 times subdivided in x and y. All possible sculpty shapes are achieved by bending and scaling the plane to the target shape and possibly stitched (for cylinders, spheres and Torusses). Probably for optimization reasons and surely due to LOD reasons the number of faces in x,y was originally choosen to be Power of 2. A reasonable resolution was 32*32 faces. less (16*16) would be too bad, more (64*64) to heavy.

3.) Since sculpties have 32*32 faces, they need 33*33 vertices to define them. Hence we always need to transport images of size 33*33. But because of point 1. above the next supported size was 64*64 so was it chosen as the standard. As far as i was told, any images was always scaled to 64*64 and then fed to the sculpty renderer.

3.1) As a matter of fact, only torus shaped sculpties were able to be transported as a 32*32 image without loss due to their special stitching properties. (I tested that this was true when only one sculpty size (32*32 faces) was supported )

====

Nowadays there are some more rules to be taken care of:

4.) The inworld mesh size (mx,my) is calculated from the size of the sculptmap (ix,iy) as follows:

(mx,my) = ( ix/2, iy/2 )

5.) Sculptmaps may have no more than 1024 faces and no less than 16 faces.

6.) If a sculptmap would define more than 1024 faces, it will be scaled down to the next power of 2 image size. In this sense a 128*128 sculptmap would be scaled down to a 64*64 map before it is forwarded to the sculpty renderer. hence (for all i know) it does make no sense at all to use such a map (64*64 is sufficient)

I will add more to this list as soon as i remember

That's what I'm trying to understand. 31x31 is clearly a better size, and I can not think of a good reason to select a power of two for the *faces* rather than the *vertices*.

Oh, they've made minor changes to the texture cache on several occasions. The problem is that fixing the texture cache isn't possible with minor changes.

Perhaps sculpties were originally mapped to a regular SL sphere, which is 32x32.

I'm sure you realize that programming is evolutionary. You don't want to rock the boat too much when adding new features. Add tons of code and you add tons of bugs.

Gotta take baby steps!

...or prim baby turn grey!

Personally, I find the idea of 31 faces in either dimension quite repulsive. It's a prime number ... Yuk!

More practically, it would have made the LOD changes horrible, as either a whole new set of vertices would have to be interpolated, or they would be sampled unevenly. As it is, at least for many cases, the LOD reduction just omits alternate vertices. Without this, LOD-proof sharp-edged sculpties would be impossible (or at least very hard and limited).

The vertices would remain a power of two. In fact LoDding works better, the number of vertices would go from 32 (31 faces, 32 on a sphere or torus) to 16 (15 faces, 16 on a sphere or torus), and the actual pixels used for each vertex would remain unchanged.

If that's the case then they must already be using the scheme I'm proposing, and the question of why they require 2x the pixels remains open.

No. I think you are forgetting that the two end ones have to remain identical to stop bits of the sculpty from disappearing...holes would otherwise appear, for example, at one pole of the sphere. So the current scheme works like this (unstitched dimension(s))...

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,33
LOD 2: 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33
LOD 1: 1,5,9,13,17,21,25,29,33
LOD 0: 1,9,17,25,33

Leave off vertex 33 and it becomes a mess!

But they don't have to be transmitted to the client, because they are always identical to either the first row (for the torus and for the "seam" of the sphere) or the last (for the pole of the sphere). For the planar sculpt and for the end of the cylinder sculpt they're never used.

I'd have preferred a one pixel, one vertex solution too. I argued long and hard for it when sculpties were first introduced. I never did get a straight answer as what problem the 2 x 2 layout fixed. The only benefit I can see is that a single UV map works for the sculpt map and texture, where the one pixel, one vertex solution needs separate layouts for the sculpt map and the texture.

The problem with the forced constant 32 x 32 faces is the adverse effect it has on end capping. In a pixel per vertex solution, we wouldn't need to draw the last row to a point to make a cap, we'd leave it open and the faces created to the mid point of that same row would close it. This would mean the pole faces would be constant across all LODs making things like barrels that kept their shape during LOD changes a lot easier. It would have been even better if the caps showed up as separate texturing faces on the primitive.

Oh, god, yes, yes, yes yes yes.

They are used. The "top" pole of the sphere comes from the middle point (16|17? I'm not sure which) of the 33rd row of pixels. The 33rd pixel of both dimensions of the plane, one of the cylinder, is used so that there are 33 vertices=32 faces each way.