Lossless Sculpts: how to get it to work

As of current, lossless compression is semi-broken. This is because of the way that the client and server handle image downloads; it "expects" a certain size, and only downloads the amount of data it expects. Thus, for some lossless images, it will lead to only partial downloads client-side, resulting in sculpts that are horribly mangled even more so than compressed images!

Thankfully, there are some workarounds.

When working with sculpt, I usually start off with a 128x128 image; this is the size that most reliably works with lossless uploads. However, the resulting JPG2000 image size is variable depending on the variation between pixel color values, in a way vaguely similar to gif.

First Download the program SL Image Uploader located at http://wiki.secondlife.com/wiki/SLImageUpload. It is a must for any sculpt designer.

now, select lossless and load an image. It will tell you the resulting jpg2000 image size, which is invaluable. Here are the rules to follow to get lossles to work every time:

1) if the image is less than 5kb in size, upload using the standard lossless feature in the official client. This will give you an inventory texture, which is very preferable.

2) If the image is between 5-6.5 kb in size, upload using SL Image Upload. This won't give you an inventory texture (only a UUID) but it will allow you to use 128x128 images. SL Image Upload is a bit more efficient than the main client at compressing losslessly, so you can use this range.

3) If the image is larger than 6.5 kb in size, resize the image in an image editor to 256x256 using nearest neighbor sampling. Then upload using SL Image Upload, because the main client doesn't allow lossless images this large. Unfortunately such sculpts are slow to load, so use sparingly.

Very useful, thanks Aminom.

I'm waiting until the lossless upload is fixed. Hopefully with the next client release it will be sorted out, and 64x64 will be as large as anyone need upload.

I don't like the idea of products of mine going out into the world, working less efficiently (16 times less efficiently if it has to be 256x256...) than they could.

Thanks, I was always wondering why some sculpt maps uploaded fine in SL, and others required SLImageUpload...

Is anyone using this? I can't seem to get it to work. I can get it to run, and apparently access the SL client as I soon see my account minus $10L for the effort. Unfortunately, the file is nowhere to be found in Inventory.

I've mostly been uploading 64 or 32s, but have done some 128s as well. All under 5kb as I recall.

Forgive my ignorance, but what does UUID stand for?

UUID is a universally unique identifier... http://en.wikipedia.org/wiki/UUID

Basically, its a way to tag an 'object' in SL with a unique key that it is statistically very, very, very unlikely to ever be shared by another object.

That said, you have to hold onto your UUID key if you use the lossless uploader. You *won't* get an inventory item (I'm not sure why this hasn't been accomplished yet, but maybe someone can explain who knows more about it than I do)

But once you have the UUID, you can set your sculpt map via a script. Create a new script and put this in state entry:

llSetPrimitiveParams( [PRIM_TYPE, PRIM_TYPE_SCULPT, "d99d09c4-27fd-5907-7f4e-75250daca706", PRIM_SCULPT_TYPE_PLANE ] );

the d99d909c4 business will be the UUID that the lossless uploader gives back to you.
The PRIM_SCULPT_TYPE_PLANE could be PRIM_SCULPT_TYPE_SPHERE if you want the default wrapping mode.

Unfortunately, if you don't write this down, there's no retrieving it. It's lost in asset server wonderland and you've wasted 10L

I have done this using SL Image Upload, and most times has given great results.

But I have one shape where my database lost the asset UUID for the texture. When I tried to repeat the process all I got was an apple. I uploaded the texture again, and got a new UUID which worked OK. However, when I started a new session it no longer worked.

This happened a few times, also sometimes the sculptie was inside out. I eventually gave up on it and used a prim with that texture already loaded to replace the existing prims. (The ones I had changed previously are fine - all three UUIDs.)

I don't seem to have that problem with any other shape, but this the one I use most often so not 100% sure on that.

Did I miss something in the instruction? This texture is the same size as all the others.

Pink the minimum script requires a default state, and a state_entry condition. For example, try making a prim, creating a new script, deleting its contents, then pasting this in:

default
{
state_entry()
{
llSetPrimitiveParams( [PRIM_TYPE, PRIM_TYPE_SCULPT, "8c48855a-9554-6c9a-d3bb-c647a9b1af73", PRIM_SCULPT_TYPE_PLANE ] );
llSetTexture( "d56de183-ad22-e27f-4df6-5282a87aedf0", ALL_SIDES );
llTargetOmega(<0.0,1.0,0.0>,1.0,1.0);
}
}


default state is the state your script starts in, and state_entry is the function called when you enter that state, so, for simple scripts, usually everything is stuck in there.

the llSetPrimitiveParams line sets the sculpt map, the llSetTexture line sets the texture, and the llTargetOmega sets it spinning around and around

Well, this is incredibly helpful. I only wish it had been posted on the wiki. I would have saved a few hundred Linden and several frustrating hours.

Thanks a bunch Daniel. It works like a charm and the improvement in results is striking

Anyone?

Sorry Xi, I haven't had the problem with losing textures. If your sculpty is inside-out, you need to reverse the normals - you can do this by flipping your sculpt texture horizontally usually.

Very odd - have just confirmed this is the only shape that loses the connection to the uploaded UUID. And it was the only one that had the uploaded UUID reversed on a couple of occassions. A lot of the other sculpties are edited versions of this blender shape and they are fine.

The sculpties that the several different versions of the UUID were previously loaded into haven't reverted back to the original texture.

I tried it with my alt and had the same result, seems to be related to the session, once I logged out the UUID was lost.

Now that I have updated most of my stuff I suppose it doesn't matter. I'll just use a prim with that UUID like a building block for future stuff.

I have to say the results using Image Upload are amazing. So smooth....

Any chance we can get a version of this tool to use the beta grid, so we can check out our sclupties before paying the $10 upload fee per image?

Thanks!

Beta Grid money is play money. You're supposed to start with a fixed amount I believe, did you spend it all?

I got the idea elsewhere on the forum -- uploading trial textures to beta grid to avoid wasting $L if they're not suitable. Once the texture proves usable, upload it to normal grid. This way we don't get charged for all the trial runs with textures that don't work out.
I've spent a fair amount of normal-grid $L on textures that didn't pan out and wish I'd known this trick earlier!

It would be nice to be able to do this with lossless textures for sculpties as well.

I still(!) can't get SLImageUpload to work. I get an error-message as soon as I click the "single layer lossless" checkbox (srceenshot attached).

Maybe something with XML-parsing... Has anybody an idea?

Thanks in advance
Mic

edit:
....ups, ok, if I first select a texture it works now, but I'm quite sure that I have tested it before... and that I got another error after trying to Login in the past... well, the Login don't work now at all, I will try it later again... hopefully... I will tell you...

I'm currently using the Second Life release candidate and testing my sculpties on the betagrid first I don`t use the imageuploader, just these SL-clients;

- 1.18.4 (1) SL - Release Candidate
- 1.18.3 (70780) SL - Beta Havok

To get most of my sculpties working:
- Make sure you scale your sculptie to 128*128 nearest neabour.
- You can use an empty alphachannel (against printscreen-theft) But putting a logo in the alphachannel can trigger the current lossness bug, it seems.
- ofcourse enable lossless uploads when uploading them

But I must say, almost all of my sculpties are below 5kb I think? I tested out today and the difference between 64*64 sculpt uploaded (looks blobby) and the same; scaled nearest neabour to 128*128 (looks like it should be) really makes a difference.

Thanks for the hints but maybe some of my sculpties has just a too complex shape. I always use the 128x128 but sometimes...

I've searched the web for the error described above and here is what I found even in the jira though it's not about SLImageUpload itself:

http://jira.secondlife.com/browse/MISC-754

So it seems that some ava's are just not "compatible" with 3rd-party programs because something's going wrong with their profile on the server or XML or both... I didn't understand much of that stuff but this problem depends obviously on "libsecondlife" as code base..

voting is welcome of course

Mic

after trying the external image upload to see if i could glean some more detail from my sculpts , i determined that the current release candidate has has the same quality as the external uploader . BUT, uses the sculptie preview to upload .the lossless option in plain texture preview borks the maps.

Hmmm...a bit confusing to me. I'm afraid to even try it. But hey, I'm just getting into sculpties, so ignore me, which most of you do anyhow.