SecondLife: Texture upload sizes reviewed, Part 1

– Note that you can find part 2 here. This link is displayed again at the very end of this essay, so you can just click through to the next part! –

When I came to SL several years ago, I was already able to texture stuff (with a background of texturing for other 3D applications – Poser, mainly).
What I had to learn about, however, were texture sizes. I was used to texturing *large* (meaning working with textures that were up to 10,000×10,000 pixels large) – and SL, at that time, offered maximum texture sizes of 2048×2048 pixels (which was eventually cut down to 1024×1024). I made many tests, figureing out which size worked best, and stuck to 1024×1024.

Now, I’m perfectly aware that about 99% of all tutorials that are dealing with texturing avatar skin, clothes etc. will advise you to work in your image editing software at 1024×1024, but they’ll also advise you to resize to 512×512 before uploading. Their reason for that advice? „Well the SL server will resize all textures that are uploaded in 1024×1024 to 512×512 anyway when rendering them out on the SL avatar.“
The reason I’m writing this is that I strongly disagree with that advice, and I’m here to actually show you why you shouldn’t only texture at 1024×1024 but also upload at 1024×1024. And while it’s true that the SL servers do resize the textures when rendering them to the avatar, SL does a much better job at this than any image editing software (like Photoshop, Gimp or PhotoImpact) could ever do.

Don’t believe me? See the evidence in pictures.

Here’s what I see in my texturing software – DeepPaint3D. See a video of how I use that software to texture an SL skin here, just so you know what I’m seeing here and *why* I’m seeing it the way it’s displayed here. Note that you can click on all the images to see a larger version of them!


What you want to pay attention to are the lashes, which is what this tutorial is about. I’ve textured two different pairs of lashes here, one version on the left, the other on the right eye. Just to be really clear what this is about, another picture without the skin background of the very same picture…:


As you can probably see, this is NOT the texture itself you’re seeing here. It’s a projection of the aforementioned lashes on the avatar face. Just thought I should clarify that once more, in case you didn’t look at the video which I linked above 😉

Of course the inworld result can never be as detailled as the above shown preview of my software, but I can always try to get as close to that preview as possible.

Now, if I’m merging that projection down to the texture in my software, the result looks like this inworld – just to explain it, I am wearing a tattoo layer with the lashes shown above; so don’t mind the skin beneath, just the lashes:

  1. Merged down on a 512×512 pixels small texture, uploaded as 512×512:
  2. Merged down on a 1024×1024 pixels small texture, uploaded as 1024×1024:
  3. And just for the records, merged down on a 1024×1024 pixels small texture, then resized in Photoshop and uploaded as 512×512:

As you can probably see, the best result is the one achieved with a 1024×1024 pixels large texture which was then uploaded at 1024×1024. The results of the 512×512 texture as well as the resized-to-512-before-uploading 1024 texture are pixellized and not desireable. The worst result is, actually, the one that was textured in 512×512 and uploaded at 512×512.

This, and many other tests that I made before, still make me believe and claim that textures which are to be used on any part of the SL avatar – be it tattoos, skins, system clothing and everything else – should be textured at 1024×1024 AND uploaded at 1024×1024 to provide the best results.

In case you need more evidence, I’m always willing to provide it. Then again you can always do your own tests with 512×512 and 1024×1024 sized textures and temporary texture uploads.
Note that this only applies to all textures that are rendered on the avatar itself (system clothing, skins, tattoos and alphas). It doesn’t apply to textures that are used on prims and sculpties – be they wearable attachments or buildings and things that aren’t worn by avatars. For those textures, even different texture uploading sizes apply. In case you have any questions, don’t hesitate to ask!

Best wishes,

– Part 2 of this essay can be found here. Click to read the next part! –

Comments (4)

Tanarian DaviesJuli 22nd, 2011 at 1:25 pm

We’ve all been told repeatedly to make building textures in general as small as possible to improve loading time and reduce client-size lag as well as server load. How is a skin or other avatar/system product with 10242 textures going to affect lag?

rarelyobscureJuli 22nd, 2011 at 1:38 pm

Thanks so much for taking the time to write this!

N. WunderlichJuli 22nd, 2011 at 3:39 pm

As I said, the 1024×1024 textures which are used on the SL avatar (system clothing, skin, tattoo, alpha) are rendered inworld (by the server) as 512×512. As I also said, SL is doing a *much* better job at this kind of resizing than any kind of off-world image editing software.
So in other words, the 1024×1024 textures on the avatar (read last paragraph for definition) are ‚displayed‘ inworld as 512×512. So it doesn’t matter if you upload those textures as 1024×1024 or 512×512; as soon as they displayed on the avatar, they’re rendered as 512×512 by SL, so there’s no lag-wise difference between the 512×512 and the 1024×1024 textures if they’re rendered on the avatar.
I also wrote that yes, there *is* a difference if it’s about a texture on a *prim*, be it a regular, a flexi or a sculpted prim; and be it that this prim is attached or not. The textures that are shown on prims are rendered in their actual size. So, in that case, there *is* a difference between a 512×512 and a 1024×1024 texture – not just ‚less detail‘ but also ‚rendering faster‘, the smaller they are.
Hope that helps 🙂

N. WunderlichJuli 22nd, 2011 at 3:39 pm

You’re welcome 🙂

Leave a comment

Your comment

Math test (actually, this is spam protection ;-) ): * Time limit is exhausted. Please reload CAPTCHA.