new sculpty mesh sizes?

I just came across the following on another forum, and was wondering if anyone here had heard anything or could comment?



Just added to the SL beta grid viewer is the ability to make sculpties with different aspect ratio meshes such as 32×128 map makes a 16 x 64 mesh

Yes, different aspect ratios is just one of the things Qarl's done lately. He's done mirror/invert as well, but those are taking their time to get into a client release. The aspect ratios are, apparently, automatically recognized by the latest beta client. All you have to do is use a sculpt map that's a different aspect ratio and it'll try to match up as best it can. Qarl offers the warning, "Don't assume your sculpt maps will be pixel perfect."

ok, I totally missed when these happened. how will it affect sculpties other than giving half the amount of vertices in one direction?

It's not just half in one direction. It's also double in the other direction. This allows for much better utilization of polygons for certain types of shapes. For example, if you're making something elongated, like a long curving rope, you no longer need to spend so many polygons on the relatively simple minor circumference. They're much better spent along the length such an obviously non-uniform object.

They way sculpties have always been up until now, lots of polygons have often been wasted, since uniformity has been mandatory. Now that oblong aspect ratios are allowed, a much wider range of sculpted shapes is possible, with much greater efficiency.

I *so* can't wait to play with non-square sculpties. There are quite a few things that I've had on hold because of the squareness. Hopefully I'll be able to do the door jams and railings that I've been itching for. And the ends of beds the way that I've been wanting to do them. And various other furniture pieces and trims. Not to mention being able to keep the textures a bit more 'legible' at a glance without stretching and interpolation kicking in too hard.

~does a happy dance

double chosen?

with the 16x64 size I assumed it would just of reduced the mesh along one side.

now that you mention ropes and things, I can start to see a point to them

I'll put it on my list to update the OpenNurbs converter.

Blender users with my scripts can already create oblong sculpties. I'll be relaxing the max face counts to make things easier for non-multires meshes, but otherwise just do add - mesh - sculpt mesh with settings like:

X Faces = 32, Y Faces = 2, Multires = 2 to get a 128 x 8 sculptie.
X Faces = 16, Y Faces = 4, Multires = 2 to get a 64 x 16 sculptie.

You will need to create the destination image and assign to the "sculptie" UV Layer before baking. This should be double the face count, so 256 x 16 and 128 x 32 for the above examples. Remember the final sculpt map images should be powers of two so 4, 8, 16, 32 etc

hooray for higher detailed sculpted sausages, rails and rings.

The old sculpties are 32x32 quads. 16x64 quads is half in one direction and double in the other. 8x128 quads is 1/4 in one direction and 4x in the other.

It sounds like maybe you were thinking of the pixel count of the sculpt maps, not the poly count of the sculpties.

It may not be immediately apparent, but this will completely revolutionize sculpts. Firstly, there are so many objects that are elongated which will benefit from this. Secondly, this will make the technique for making multiple objects on a sculpt available to everyone, and it will be better in every way than what I do now- better texturing, LOD retention, and shape definition (no seams). Just think what this can do for furniture, landscaping, architecture, low-lag avatar attachments, props, vehicles... pretty much everything.

When the RC client goes live, there's going to be a ton of wonderful stuff released from all the sculpt designers.

Great news, but I'mstill confused. What about the stitching? From the numbers discussed, there is no magic "33rd" row/column. Is that right? Are they plane topology only? That's 65 less vertices available.

Chosen said 16x64 and 8x128 quads - does that imply 17x65 and 9x129 pixel maps? Or are they liek the old 64x64 : 32x128 and 16x256 with the last row/column doubled up?

There is a lot I donn't know about 3D modeling and LOD is completely new to me. Only in my last builds am I getting LOD under control.

I am completely missing how a long skinny thingy will have less LOD problems. Also, how texturing will be any easier.

Can you explain why LOD retention would be better?

The plane type is always the maximum number of vertices available. Generally these days most people will talk about the number of faces (as quads) as this is a convenient simplification to give counts which are consistent across all the sculpt types.

The number of pixels is double the number of faces to allow for that one extra row or column of vertice that different mappings make available. So a sculptie with 8 x 128 faces has 9 x 129 vertice (with planar mapping) and is on a 16 x 256 pixel image. The same sculptie with torus mapping only has 8 x 128 vertice as the last row and column are the same as the first ones.

Just a quick word of caution to all intending to take advantage of this: anybody using the 1.20 or lower SL viewer will not see your sculpties the same way. This also applies to the mirror and inside-out functions as well.

That means if somebody makes clever rope with the new mesh sizes or a pair of shoes by mirroring the left shoe into a right shoe, anybody looking at it with older viewers will see the rope without the right details, and only be wearing two left shoes.

That doesn't seem quite what Karl actually implemented in 1.21.0 . See http://www.flickr.com/photos/21635604@N05/2798158009/, for example. From left to right, the sculpty bitmap sizes are 8x512, 8x256, 8x128 and 8x64. Each successive bitmap was made by removing every other row from the previous bitmap. The sculpty topology is torus, and all four are seen at maximal LOD. All four are textured with Chosen's test patttern.

At 8x512, we can see that 4 of the 8 columns are used, which is what I think you expected. But when the number of rows is cut in half, Karl's formula decides that it should use 5 of the 8 columns. Cutting the rows to 128, all 8 of the columns are used. With 64 rows, it looks to me like the columns are doubled up to make 16, which results in tearing the texture.

I think I understand why Karl might implement things this way, given that I believe he thinks of the sculpty values as specifying a control surface rather than vertices. But I hope this generates a lot of discussion before it gets in a release viewer. Personally, I would like to see more emphasis on giving the content creator explicit control over the results.

We should have warning labels on these shoes

You may appear to be Misshapen

LOL!

/me sighs..

Well with them planning a short test cycle for the next viewer due to the mono stuff I guess I'm going to have to put my avatar work on one side and go back to sculpties for a bit. They didn't listen with the original sculptie implementation when I tried to explain why adding an extra row for end capping (and thus doubling the map size) was a hacky solution, so I'm not going to hold my breath that they will do it right this time.

I'll grab the viewer source and take a look at what's wrong now. Hopefully a simple check on sculptie map size to adjust the formula is enough to sort it out.

Update:

I've had a look at the code and the sculpt_calc_mesh_resolution in llvolume.cpp is where this is calculated. I've written a quick python script to show an alternative, which I'd much prefer to the current implementation.

http://dominodesigns.info/downloads/second_life/size_test.py

Here's the output for comparison:

W x H x LOD	Current	Proposed
--------------	-------	--------
64 x 64 x 3: 	32,32	32,32
64 x 64 x 2: 	16,16	16,16
64 x 64 x 1: 	8,8    	8,8
64 x 64 x 0: 	6,6    	6,6
32 x 128 x 3: 	16,64	16,64
32 x 128 x 2: 	8,32   	8,32
32 x 128 x 1: 	4,16   	4,16
32 x 128 x 0: 	3,12  	3,12
16 x 256 x 3: 	8,128	8,128
16 x 256 x 2: 	4,64  	8,32
16 x 256 x 1: 	3,21  	3,21
16 x 256 x 0: 	3,12  	3,12
8 x 512 x 3: 	4,256	4,256
8 x 512 x 2: 	3,85  	4,64
8 x 512 x 1: 	3,21  	4,16
8 x 512 x 0: 	3,12  	4,9
8 x 256 x 3: 	5,181	4,128
8 x 256 x 2: 	3,85  	4,64
8 x 256 x 1: 	3,21  	4,16
8 x 256 x 0: 	3,12  	4,9
8 x 128 x 3: 	8,128	4,64
8 x 128 x 2: 	4,64  	4,64
8 x 128 x 1: 	3,21  	4,16
8 x 128 x 0: 	3,12  	4,9
8 x 16 x 3: 	22,45	4,8
8 x 16 x 2: 	11,22	4,8
8 x 16 x 1: 	5,11  	4,8
8 x 16 x 0: 	4,8    	4,8

TIP: quote this post to see proper layout of table

I'm not I completely understand how this works, I'm much more right-brained and not at all a 'techie" lol.
For example how can I take advantage of this when making sculpties in Zbrush? What would I do differently now that I couldn't do before? Say if I was making a tree or something, what new options does this give me?

Omei and Domino, I am fascinated. I'm not sure I understand everything you're discussing in this thread (yet), and I'm not asking for any explanations yet, but I wanted you to know I appreciate that you're discussing this in an open forum. It's interesting reading that might lead me to make fabulous sculpted objects. Thanks!

Domino, I certainly prefer your proposal. For sure, not creating degenerate faces just to make the face count quota (my interpretation of Qarl's algorithm -- he would probably word it differerntly) has got to be the right choice.

There's a couple of corner cases it gets wrong which I need to investigate. The main difference between mine and the original is in reducing the long side first, which I think leads to more useful shapes. It does have the disadvantage of quite a big reduction in the long side from LOD 3 to LOD 2 in some cases, but it's worth it to get reductions which allow non organic shapes in my opinion.

For comparison I've also done a fixed version of the original:

http://dominodesigns.info/downloads/second_life/fixed_size.py

This uses the same algorithm as the original but with the addition of clamping at image width / 2.0 and image height / 2.0 for the maximum face count.

16 x 16 x 3: 	32,32 	8,8
16 x 16 x 2: 	16,16 	8,8
16 x 16 x 1: 	8,8    	8,8
16 x 16 x 0: 	6,6    	6,6
16 x 32 x 3: 	22,45 	8,16
16 x 32 x 2: 	11,22 	8,16
16 x 32 x 1: 	5,11   	5,11
16 x 32 x 0: 	4,8    	4,8
16 x 64 x 3: 	16,64   	8,32
16 x 64 x 2: 	8,32   	8,32
16 x 64 x 1: 	4,16   	4,16
16 x 64 x 0: 	3,12   	3,12
16 x 128 x 3: 	11,90 	8,64
16 x 128 x 2: 	5,45   	5,45
16 x 128 x 1: 	3,21   	3,21
16 x 128 x 0: 	3,12   	3,12
16 x 256 x 3: 	8,128 	8,128
16 x 256 x 2: 	4,64  	4,64
16 x 256 x 1: 	3,21  	3,21
16 x 256 x 0: 	3,12  	3,12
16 x 512 x 3: 	5,181 	5,181
16 x 512 x 2: 	3,85  	3,85
16 x 512 x 1: 	3,21  	3,21
16 x 512 x 0: 	3,12  	3,12

Thanks Domino. That will be very useful. I will steer well clear of things like "16 x 32 x 3: 22,45". That is quite revolting ... how on earth do they interpolate 22 from 16 and 45 from 32? Presumably quite useless for anything accurate.

I made some steps with a 128x32 (ie 64x16 quads) and they worked very nicely. All strange problems with normals and shading from joining two half-flights disappeared. Hoorah! Did Quarl have anything to say about when these might appear in the RC viewer?

Domino, a couple of more thoughts on some of the "awkward"cases.

1) When working with a topology/dimension where edges aren't stitched (the plane and one dimension of the cylinder), 2 is a perfectly reasonable number of faces. So I suggest that when reducing 4 even further for LOD, we specify 2(3), which means 2 or 3, depending on the stitching in that dimension.

2) For handling LOD, I would think dividing the faces by some factor of 2 each time (except maybe the last, where you can't expect much shape to be retained in any case) is more important than anything else. So instead of

16 x 512 x 3: 5,181 5,181
16 x 512 x 2: 3,85 3,85
16 x 512 x 1: 3,21 3,21
16 x 512 x 0: 3,12 3,12

it could be

16 x 512 x 3: 5,181 6,176
16 x 512 x 2: 3,85 3,88
16 x 512 x 1: 3,21 3,22
16 x 512 x 0: 3,12 3,11

or perhaps

16 x 512 x 3: 5,181 6,168
16 x 512 x 2: 3,85 3,84
16 x 512 x 1: 3,21 3,21
16 x 512 x 0: 3,12 3,10

if Qarl considered 1024 quads to be an absolute upper limit.

The same rational suggests to me that

16 x 32 x 3: 22,45 8,16
16 x 32 x 2: 11,22 8,16
16 x 32 x 1: 5,11 4,16
16 x 32 x 0: 4,8 4,8

would give better results than

16 x 32 x 3: 22,45 8,16
16 x 32 x 2: 11,22 8,16
16 x 32 x 1: 5,11 5,11
16 x 32 x 0: 4,8 4,8

Of course, an algorithm that handles the awkward cases well might be a little more complex than one that doesn't, but that doesn't seem like a very big issue compared to sculpties turning more distorteded than nessary at lowered LOD.

The minimum of 3 is a carry over from the original (to avoid degenerate faces). Personally I can see cases where a strip of single faces could be useful ( rivers and waterfalls for example). Though I've also got one eye on sculpties being able to support cuts etc. There's no reason I can see why a cut from 0.25 to 0.75 shouldn't just use the middle of the sculptie for example. Well, apart from the current end cap implementation of course



I agree, that was the major goal in my alternate method, to give some predictability to the LODs and to make more useful reductions. I really can't see when reducing a square to a triangle is going to be a nice thing to have



Yep, I've not done any performance tests, but with eyeballing my alternate implementation, I don't think it'll be vastly different to the original. There's more code but the if conditions on the execution path reduce each pass to something comparable to the fixed original I think.

Update:

After a quick update to my Blender scripts to support non square sculptie maps, I think the LOD issues are far more of a problem than I realized. Basically it is pushing sculpties to be nurbs only and destroys all the work done so far to get manageable LODs into the creation pipeline. Even my alternate sizing code has this problem and there's only three solutions I can see.

1) Use nurbs
2) Forget trying to manage LODs and just model at highest detail level
3) write an application specifically for sculpties to allow for the crazyness

I can't see me doing any of these and I'm pretty annoyed that zero consideration seems to have been given to the sculptie workflows that people have been developing since their introduction. I hope a better solution can be found as I see little point continuing the development of my scripts when a significant part of their usefulness will have to be stripped out to support this change.