Sculpty exporter for Wings 3D

But you can control everything

On the left of the photo is my version of Omei's spiky sphere, using a 64x64 texture, on the right is the same on a 512 texture for better precision. The 512 texture is the other attachment. Notice there are 17 spikes and 16 "valleys", for a total of 33 vertices again.

Oooh nice!.

But you wouldn't have the same level of control if you were to start bunching lots of vertices together in order to create detail.

It's possible to create a decent looking human head from a 32x32 poly mesh. You can even model detail like the eyelids. But convert it into a sculpty and it transforms into The Blob.

I think we need each pixel to be mapped directly to the vertices.

We already have direct control over every vertex. Not every pixel corresponds to a vertex, but every vertex corresponds to some pixel (or group of pixels, in the case of the north and south poles). Maybe I'm misunderstanding what you're saying?

Well that's just it, you said "corresponds to some pixel". God knows which...

In order for you to capture the relatively low detail in the spikey model you made, you had to make a 512x512 texture. This was to ensure that you managed capture each vertex.

If the mapping was direct then you would have been able to use a 32x33 bitmap, with each vertex being mapped to just a single pixel, rather than the 16x16 pixels in your demo model.

I've been saying which pixels get sampled for quite some time...

Ok, in complete generality for the *cylinder* topology (the sphere topology is obtained by averaging the vertex positions for the top row, so glomming all of those vertices into a single one, then doing the same for the bottom row):

If we have a 2^n by 2^n texture, and we are making a grid of 2^m by (2^m)+1 vertices, then the (i,j)th vertex position (0 <= i < 2^m, 0 <= j <= 2^m) is determined by the pixel at:

(2^(n-m)*i, 2^(n-m)*j) if j != 2^m
(2^(n-m)*i, (2^n) - 1) if j == 2^m

No, this is only for getting around the jpg2000 compression making the colours on the pixels that are sampled be distorted from what I want them to be. The left spiky sphere in the photo I attached is from a 64x64 texture.
But (for one) the SL texture system only uses powers of two, and (for two), then you would want different sized textures for torus topology than for sphere topology.

I watched the video demo on sculpties and I also have tried to keep up with the details of this thread. All along the way I've been seeing what appears to be a bitmap or, perhaps, a jpg that looks like some abstract art rendition of a rainbow... all the colors swirled together in some kind of order.

How does that rainbowed texture in my 2D paint program become a 3D sculpty in SL? I realize that this is probably a really dumb question, but I'm just having trouble putting two and two together to get anything close to four.

Thanks!

Bartiloux Desmoulins

It keeps crashing on export for me. I got a few exported but now if I make even one change to the sphere it crashes.

I extruded a line, that's it.

It's not actually a rainbow texture, it's a UVB map.

The R, G, and B values of each pixel in the image contain the X, Y, and Z locations of each vertex of the sculpted prim. So you define the shape of the prim by defining the position of each vertex (obviously), and that position information is represented by the colors of the pixels. When that texture is sent to the client, it knows how to interpret it and make the shape that's encoded in those colors.

Start here, and read the links in the 'See Also' section:

http://wiki.secondlife.com/wiki/Sculpted_Prims

Edit: Not sure why it didn't make a link.

Extruding is illegal because it creates new vertices.

You're supposed to shape your object by rearranging the vertices that are present.

Well crap, I thought I had extruded before and saved it. I'll try again!

Thanks 2k!

The picture I posted is actually of partial screenshots from within Wings3D, not a hand-made diagram. I wanted to explain how the model in Wings relates to the map created by the exporter that Omei and Strife have been working on -- how it generates the 8x8 or 32x32 or 64x64 pixel maps based on the vertices in the original model, as is my understanding of Omei's initial post. It wasn't intended to explain what happens with the sampling of the map once imported into SL.

Once it's in SL, I understand the basics of how the sampling is supposed to create an extra 33rd row of vertices when downsampling a 64x64 map as documented in the wiki. Nevertheless, when I created a 32-segment/31-slice sphere in Wings, exported the 32x32 pixel bitmap, then uploaded it, SL appeard to not have created the 33rd vertex row. I counted 32 vertices around the circumference, and 32 vertices from pole to pole, including the poles, by setting the SL viewer to render in wireframe mode. I did this with both a smooth sphere and a spiky one with alternating vertices pulled out along the surface normal, from pole to pole. Viewing it in wireframe mode didn't seem to show any unexpected mid-spike vertices.

Here's the smooth sculpty sphere I created using that 32x32 map. I textured it with colored stripes to make it easier to count vertices from pole to pole. That green strip is roughly in the middle, and served as my counting guide as I rotated around the prim. In these views, can you tell if I'm missing counting a vertex somewhere?

So... I want to make sofa seat cushions that are basically rectangular but have rounded edges and corners. I have to make them by squeezing a sphere into that shape. I can do that. But in the game, people who go to sit on my sofa will be sitting up above it on top of invisible spheres because the cushions are still really sphere shaped?

As I had already said in a earlier post, a Wings sculpty has only 31 slices when in SL. This was the source of my initial confusion because I had assumed a sculpty had 32 slices.

I think we're all starting to see the light now.

You could always add a sit script to the cushions and set the sit position so that the avatar appears to be sinking into the cushions.

True... or have a couple of normal cuboid cushions with an invisible texture which you actually sit on. How does the game treat mouseslicks on a) an area of a sculptie which is displayed as being there but not really that shape, b) an area of a sculptie which is really there but not displayed that way, c) a regular prim which has an invisible texture?

That's very odd... what happens when you turn your object detail slider all the way down? The only thing I can think of is that somehow there is an extra row of vertices that are just all hanging out at a pole.

Yeah. I still think there'll be 32 slices in there somewhere.

A 32x32 bitmap will be converted into a 64x64 bitmap. When they give us an in-world editor, we'll be able to pull the sculpty apart and find the missing vertices.

I nominate this thread for a sticky - I keep telling people to come here to get the exporter.

Sticky sticky sticky sticky please?

you can solve this with a simple sit target script.

sorry didnt see the answer before -

I don't see the point of more prims on a furniture item when the script can handle it and save you prims. These scripts aren't even hard, and most use them to add a pose anyway If it was something meant to be walked on, it's a different story though

I'll have the experiment with the rest of it, good questions. I've already been wondering how to handle this especially in regard to terrain.

Woooot and Yay! Thank you _so_ much. Wings3d indeed has a much more intuitive interface and for someone who just wants to bang together a few vertexes to produce some sculpty, I think it is a much better match than blender (and it spares me the horrors of learning the blender interface for a bit longer ).

Thanks a lot!

I had another look at the wiki and found this description of how each vertex is mapped in a 64x64 sculpty map:

(0,0) (2,0) (4,0) ... (60,0) (62,0)
(0,2) (2,2) (4,2) ... (60,2) (62,2)
. .
. .
. .
(0,60) (2,60) (4,60) ... (60,60) (62,60)
(0,62) (2,62) (4,62) ... (60,62) (62,62)
(0,63) (2,63) (4,63) ... (60,63) (62,63)

Notice the last row, needed to get the 33rd row of vertices.


So the 33rd row of vertices seems to be a special case and is stored in the last odd row of pixels in a 64x64 bitmap.

...though I added that to the wiki, so if you didn't believe me before, don't believe the wiki either... ;P

I'm nowhere up to date with reading this thread, but ..

Omei, thanks very much for this plug in. You are the man!