Oblong Sculpties: Collect Information here, please

I have to confess that I lost overview between this thread
/8/9a/278017/1.html
and the Jira here
http://jira.secondlife.com/browse/VWR-9384
where the final implementation of oblong sculpts has been discussed with Qarl (the Linden Lab programmer of sculpties). Also, I frankly admit that part of the discussion there went over my head.

So here comes my humble request to collect and clarify the information about oblong sculpties. Particularly I’m interested in the topics below, but I’m sure there are more topics of interest.

- What are recommended aspect ratios of sculpt maps and which quad ratio do they produce in which LOD level?
- What is the most oblong ratio that still works? (4x256?)
- How does the aspect ratio of an oblong sculptmap relate to the resulting polygon ratio? (a 16x256 sculpt map doesn’t seem to produce a 8x128 quads sculpty in the highest LOD).

And lastly I’d be especially grateful if there are Maya users here that work with oblong Sculpties that would like to share their experiences with me. Same questions as above, just in the specific case of modelling and exporting oblong sculpts with Maya. My specific current goal is to get the most oblong sculpt possible out of Maya. Currently, I produced several plane type Sculpties that have oblong quad ratios, but they are never exactly the same as in Maya. For example: a 16x64 NURBS plane turns into a 12x64 quads sculpty in the highest LOD. What am I doing wrong?

Thanks in advance,
-L

The NURBS sections & spans do not determine the number of polygons in the sculpty. They've got nothing to do with that, directly. The NURBS model itself is merely an interpolated surface. The isoparms that appear to divide them into a mesh-like structure aren't the same thing as the edges which likewise divide poly model. There's no direct correlation between the two, other than they sort of look alike.

The Maya sculpty exporter operates by sampling your selected surface(s) at intervals. It's the sample points that determine the values on the sculpt map, not the isoparms. The positioning of the ispoarms matters only in that it is they that dictate the shape of the surface to be sampled. The resulting polygnal edges in the sculpty will not match up exactly with the isoparm positions of the source surface. They'll be wherever they need to be in order to create a good visual match between the 3D shape of the sculpty and the the 3D shape of the source, while preserving relative UV positioning as predictably as possible.

If your source surface is a simple enough shape, the sections & spans could be 1x1 or a million by a million, and the resulting sculpty would come out exactly the same. The only reason to put limits on the number of sections and spans you use is to keep the surface shape simple enough that the sampling process can't miss any of its detail. If all you're talking about is a flat plane, then it really shouldn't matter how may sections & spans you've got. But if you're making something more complex, then best practice is to limit each surface to 16x16 or less. If a surface needs more than 16x16 sections & spans to hold its shape, it's likely it won't sample well enough to translate to good sculpty. The sample resolution is only so fine. Make sense?

So what does determine the number of polygons in a sculpty? The simplest answer is nothing. They're all pre-determined. The aspect ratio of the sculpt map determines which type of sculpty is created. If it's square, then you've got 32x32 quads, and that's that. If it's oblong, you might have 16x64 or 8x128, etc., depending on the aspect ratio.

Or at least, those were the poly counts we all pitched to Qarl. How exactly it's been implemented since then, I haven't checked. I got busy with work, and kind of lost track of things.

I can offer a likely explanation for the 12x64 count instead of 16x64, though. One of the things Qarl mentioned in our discussions was that the powers that be at LL long ago dictated that lowest LOD for sculpties must be 6x6 instead of 8x8. The rationale was that the majority of visible objects in SL are always at lowest LOD, since only a small fraction of what you can see is ever right up next to you, with most objects off in the distance. 6x6 cuts the poly count of all those distant objects nearly in half, from 64 to 36. When a lagtastic million+ polygon scene was transformed into a no-lag 300,000 poly scene, simply by going with 6x6 instead of 8x8, the brass at LL was forever sold on 6x6, end of discussion.

I'm guessing 12 is in the mix because it's multiple of 6. The rationale may very well have been that 12x64 cuts the poly count by 25% from 16x64, and who the heck is really gonna care about a piddly little 4 quads per column? I don't agree with that philosophy -- I care -- but I can understand why they would have thought that way, if indeed they did. Again, I'm just guessing here, so don't put too much stock into it. The best way to know for sure would be to ask Qarl directly, of course.



In any case, the fact that a sizable percentage of the population won't be able to see oblong sculpts (and mirrored sculpts) properly at all, since they stubbornly cling to older viewers, keeps me from using them for the time being. I have little motivation to experiment with anything that I know so many people will see incorrectly.

Thanks, Chosen, for the explanation. These are all good points. Given the original design goal of sculpties, I know that 100% precision can't be expected. For my regular sculpties, which I keep at 16x15 (for spheres) and crank down Maya's NURBS display curve precision to 0, I usually get a _very_ close appearance in Maya to the result in SL. That's why I wondered why things seem to be so much more off with oblong sculpties.

Now, I have the impression that there's a faction of builders out there who figured out how to get sculpties under a much more precise control than they were designed for (I'm thinking about the tricksters who build 1 prim trees and seemingly multiple objects out of 1 sculpty). I wonder if you guys have made any forays into oblong sculpties. If so, what have you learned?

/8/60/203571/22.html#post2238500

To calculate the image size, double the faces and round up to a power of two..

According to latest intelligence reports from Area 55, vwr-9384 sizes should be supported in the 1.23 client.

Thanks, Domino.

So it's fair to say that the details of the implementation of oblong sculpties are not yet cast in stone?

It's not so much a faction as a division of the types of tools available that users can choose from. Quite a few 3D applications have sculptie authoring tools (3ds Max, Blender, Wings3D,) that read vertex positions of the mesh being used as the model proxy when generating sculptie maps. This allows for a high degree of accuracy in the final the vertex points of the sculptie mesh in SL. Within the limits of using color channels to as coordinate values, it is equivalent to assigning sculptie vertices to x,y,z positons. If you are meticulous enough you can even do this right in Photoshop.

Others, like Maya, use a surface approximation system that samples arbitrary points on the surface when generating the sculptie map. Using these tools modelers can't precisely determine where the vertices of the sculptie mesh will end up in SL. Modelers using this scheme are pretty much giving suggestions as to where the sculptie vertices will end up by creating a topology to sample points from, rather than assigning actual vertex coordinates.

Oblongs are great for modelers who use the vertex position system to twist sculpties into trees with branches, fences, ladders and seeming multiple objects such as guns. The high length to width ratio gives you more detail rings to work with in cases like these.

I did make my single sculpty with 128 separate solid pieces Could only get 102 before oblongs. You can see it in my garden in Tiretta.

But this just playing. Chosen is right - it's not such a good idea to use them in earnest until there had been a compulsory viewer upgrade that includes them.

Thanks, Pygora and Drongle. Things are getting clearer and clearer for me now. Looks like I would have to dig my teeth into Blender for the specific trick I'm attempting to do.

And by the time that I've learned _that_ user interface, oblong sculpts will have made it into an compulsory viewer

So... is there any viewer that shows oblongs right now? I see a "Release Candidate" available for download, version 1.22.x.foo.etc, but not a 1.23.... If one exists for Macs, please point me to it. I am excited to try some oblongs.

@Leben: I began using blender solely because of Second Life, and Domino's tools for creating sculpties. I found the video tutorials at Machinimatrix.org very helpful with the complicated stuff, and the Essential Blender book was good for getting me started (it should be called the Blender Newbie book, but that's another story).

8x128 is great for folding balloon pets like this:
1 prim torterra

Problem with 8x128 is that a texture with 1:1 tiling displays only 4*32 pixel on a 2-polygon-UV-square, and youd only use 4x4 pixel for a rectangular texture anyways.

Another Problem with 4x4 textures is, whatcha gonna do with that long but very thin road/river?

-

Oblong sculpts are new, many converters have problems with intermediade converting.
Intermediate converting of sculptmaps with less polygons in total, like 16x32 are possible, but not fully supported by anything.

SOLUTION for genrationg:
I just generate ANY cylinder or plane in 3dsmax (or nurbs?) , then make it any oblong sculptmap that works for me as a result, then import that one back to 3dsmax and do my vertex-manipulation.
That ensures that I have no errors in my uv map and no further errors in further exporting (as long as i stay away from that damn "converge-verticles" button)

Oblong sculpties have a big problem due the SL pixels smoothing.
This smoothing in the upload changes a bit of the RGB (XYZ) values, and degenerates the sculpties
I found a easy trick.
I use TGA 8 x 128 pixel but I resize it to 32 x 512 pxl.
You have to use PAINT because the better programs use the smoothing in the resize and so the problem is the same.
When the new TGA 32 x 512 is loaded in SL the smoothing is really minor because each color has 16 pixel instead of one, so the XYZ points are better preserved.
Details about this trick in my posts in Second Life Italian forum :

http://www.secondlifeitalia.com/community/viewtopic.php?f=14&t=21421&start=19

Soldatino, the "smoothing" you are describing sounds like JPEG compression artifacts. A better way to handle those is to make sure to check the "Use lossless compression". In the early days of square sculpties, what you are suggesting was the only way to get decent results for "geometric" sculpties, but it shouldn't be now.

If you have examples of oblong sculpts where lossless uploading doesn't work, that's a bug that should get into the JIRA.

I would have responded the same way. Except that I haven't fully tested oblong sculpties with different aspect ratios.

Omei,
Can you confirm that "lossless" upload works with the new aspect ratios in 1.22.x?

Yes I checked now a file TGA of mine 8x128 and you are right.
But the last week I had bad results even if I used the "lossless compression" option.
I am sure but it is possible that the file was 4x256 instead of 8x128.
Anyway many thanks, the 8x128 works fine. I see the ascii files in irfanview and they are identical.
49a1f26f-66ac-48b8-2c01-2395d346e626 ExtremeOblongCubica.
Later I will check other size of files.

Wait up, you're uploading the same size TGA as the mesh size? I'm afraid it isn't quite as easy as that, I recommend you at least double it. I use a 16x256 map for 8x129 mesh (it would only be 8x128 if it were a torus). I doubt anything smaller would rez in a satisfactory fashion.

Lossless is essential.

Also, you can't use nurbs for oblongs in any useful way.

Yes, in your way each face (of 128 polygons divided by 129 points) has at least 2 pixels...
very good the option sphere, torus etc...
In the old sculpties I used 128x128, the step was 4, but the first vertical step had 1+3 pixels, the first was for the pole, so the mesh was 32x33. Now it is not necessary with the pole option... right?

What you're saying is correct in essence, but falls down in practice. If you want to rez a 1:1 ratio map of anything more complex than a curly tube is going to prove a bit difficult.

It would be nice to cut rez time, but it just doesn't work. Or at least not in any way I've managed to accomplish.

I would generalize this advice to say you should avoid, for the time being, any sculpty bitmap size that doesn't have exactly 4096 vertices (e.g. 64x64, 32x128, 16x256, 8x512). Using more vertices buys you nothing. If you use fewer vertices, SL will render your sculpty somewhat differently once the changes worked out in http://jira.secondlife.com/browse/VWR-9384 are integrated into the viewer.

We tried to get those changes on a fast track, so we wouldn't have this period where some sculpties made for the current viewer will soon look different, even at maximum LOD. But the Lindens didn't deem it to be an important enough issue to fix before version 1.21 was released to the main grid. So now, all we can do is to periodically warn people away from them.

Omei. Didn't they make it into the 1.22.11 release though? I was assuming they would and was going to start making sculpties again.

I guess not - "This was committed to maint-viewer-11 a while back, which I believe puts it on track to be in the 1.23 release when that comes out" - can't believe they have delayed this. Ridiculous. I give up.

The exact correspondence shape-skin (tga sculpty - texture) is consequently the type of the sculpty.
I find a right correspondence using the sculpty cylinder type with the north pole closed (very important because the bitmap starts here) and the south pole opened.

7c782c43-4890-a1e0-a324-c8a72cc31e9f tga sculpy (shape) 8x128
5a03e851-eb5f-bb1f-5c1e-5eceeac69b1c tga texture (skin) 32x512

You can check this easily with
default
{
state_entry()
{ llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_SCULPT, "7c782c43-4890-a1e0-a324-c8a72cc31e9f", PRIM_SCULPT_TYPE_CYLINDER]);
llSetTexture("5a03e851-eb5f-bb1f-5c1e-5eceeac69b1c", ALL_SIDES);
llSetPrimitiveParams ([PRIM_SIZE, <5, 5, 5>]); }
}

At this moment I don't know as the sphere type works...
I apologize for my bad English...

I can't tell if you're agreeing with me or not... You're mixing things up a little by calling the pixels verts, which I suppose they are in some way. But other than that, I do agree that a map has to be not less than 4096 pixels due to jpeg compression.

Here's an example of what I mean http://i41.tinypic.com/30kzgud.jpg

The first lamp's map on the left was downsized from the original that you can see on the right from 32x128 to 16x64, the second was converted straight to 16x64. Not pretty. Might possibly be the way I'm converting it, but I'm not unfamiliar with different methods and not had any success with those either.

You're more than welcome to downsize the map from 16x256 to 8x128 and rescale it back up with nearest neighbor to optimise the pixels, but most of the time you won't need it, and I haven't found a good enough reason to bother. The don't rez any faster and I don't personally have a problem with things poking out where they don't belong.

Ok, now I am absolutely sure. I am working about a tool, dxf converter to sculpty and I had a lot of waste time because I use many vieweres and all load my sculpties with a very fine look.
In SL the sculpties have problems that I dont understand, and unexpected because I tested pixel over pixel, and the pole, etc etc.
Tonite, desperate, fnally I resized the sculpties again from 8x128 to 32x512 and all works fine also in SL.
Now is really late for me. Tomorrow I will post some examples.

07fcb892-db93-41aa-44f7-2b98e4db7a4b small chair shape
53f88854-ecfd-dac7-2d41-137201a970b1 skin

Did you also try 16x256? The extra pixels in the 32x512 should be ingnored*, and the results should be different only if either (a) you are uploading with lossy compression or (b) your resizing is introducing interpolation artefacts.

*If I recall correctly, the rendering code just samples the pixels at appropriate intervals to get the numbers of vertex coordinates defined for the current LOD value. It does not interpolate. That's why sharp-edged sculpties can work at all.

From what i understand about oblongs, the number of faces keeps constant at 1024 but the ratio x-faceCount vs. y-facecount may change. So is it true that the following general rule applies for ALL sculpties:

x-facecount * y-facecount = 1024

Is that correct ?

Further from a long discussion about standard sculpties i finally understood, why it is optimal to use a 64*64 map. When extrapolating to oblongs i would expect the optimal map size of an [x-facecount,y-facecount] sculptie to be

[2* x-facecount, 2*y-facecount]

Is that correct ?

so in your case a sculptmap of 16*256 should be the optimal size...

Or can you explain in more detail, why 32*512 images do work better for you ?

regards,
Gaia

Ok. I actually use the 8 x 128 pixel = 1024. (1024 is for all the sculpties)
If I upload a TGA file, also using lossless option checked, SL change it.
I attempt to explain better
First line (8x12:
xyz1. xyz2. xyz3. xyz4

In horizontal and in vertical also SL modifies the xyz in order the rgb color before and after each pixel.

But if I use:
First line (32x512)
xyz1. xyz1. xyz1. xyz1. xyz2. xyz2. xyz2. xyz2. xyz3. xyz3. xyz3. xyz3. xyz4. xyz4.xyz4. xyz4.
Many adiacent pixels has the SAME COLOR in the left and right pixel, so they arent changed by SL.

When SL is working the render steps by 4 pixels and it find a color identical original mesh (8x12.
My english is bad, I hope to explain...