Best sculpty map size for quickest load?

Is 128x128 still the optimal size for quickest loading?

No and it never was. 64x64 is the recommended size although 32x32 is the maximum level of detail anyway, so no idea why, interpolation, I suppose. The smallest size is always going to load quickest, just because there's less to do, but below 32x32 you will necessarily lose detail.

If I remember correctly, Domino used to swear a 128x128 would load faster than a 64x64. I never quite understood the reasoning, but I believe it had something to do with the expected file size vs. actual size. I could be mistaken, though. I tried to reference some of the old threads that talked about it, but I was unable to find them.

All things being equal, the ideal size of course would be 64x64, just as Indeterminate said. But things aren't always equal with SL. I've learned not to doubt Domino on this stuff. He's just about always right. I don't have nearly the under-the-hood expertise that he does.

That said, I've always stuck with 64x64. I've never personally been able to measure any consistent difference in load time between 128 and 64, since SL is always so chaotic anyway. Practical experimentation is nearly impossible. Plus, I figure even if it's true that something in the programming is failing to recognize that a 64x64 is 1/4 the size of a 128x128, that doesn't mean that I have to make the same mistake. Eventually, whatever's wrong with the programming might be fixed, but a principle is principle, if that makes sense. Some may disagree with that line of thinking, and that's fine. At the end of the day, I don't think it's that big a deal either way.

I think that 128*128 maps loading faster than 64*64 maps is only a rumor. I know people have stated that it would go significantly faster and they all came up with explanations (which i never fully understood to be honest) and some even reported about upload time measurements. I myself could never find any significant difference between both map types. Neither in precision nor in upload time. And i never understood how the upload measurements could be reproduced reliably...

BTW: I am more than curious to get a pointer to where to find Domino's opinion on this topic.

The only point which i currently am aware of about map sizing is this one:

All maps smaller than 4096 pixels in size (with arbitrary ratio x:y) will suffer from a precision bug in the SL-viewer/server software where smaller images will never be imported lossless and thus sculpties will get garbled.

See

And by my own experiments: The smallest sculptmap i ever could import to SL was a 16*16 pixels map (which suffered from the lossless bug of course) as can be seen here:

It's possible I'm remembering incorrectly, Gaia. I've edited my post to indicate as much.

Assuming my memory isn't totally out of whack, I recall a discussion about how SL has certain expectations for file size when loading textures, and the closer a file's actual size is to the given expectation, the faster it will load. And due to a quirk of the lossless compression scheme for small images, 128x128 happens to fall closest to expectations out of all possible map sizes.

I didn't pay too close attention to it, since I was pretty set on using 64x64 anyway, so I'm afraid I don't remember much more detail than that. I could swear it was Domino who was doing the explaining on the subject. But again, I could be wrong. My apologies if I was putting words in anyone's mouth unfairly.

You know Domino better than I do. Care to ask him to step in and clear this up?

My memory agrees with Chosen. It was quite a while back, but there was some discussion on changes that LL made to texture loading priorities, and that certain sizes were assigned a higher priority than others, and would therefore get loaded 'faster', because they were not waiting for some huge laggy texture to load first. For example, the 512 x 512 size got a very high priority, since all skins and avatar clothing layer's used precisely that size.

I don't think we ever saw a definitive table of what sizes got that preferential treatment, or what the actual final benefit was, however.

I did an experiment. I set up three different sculpts with a 64 and 128 version of each. I cleared my cache and relogged. The 128's definitely went from spheres to a shape sooner. But as for going from the first visible sculptie shape to the final shape, it was not clear if either size was faster.

I'm sticking to 128's for my products.

Edit: just tried it again. 128s clearly loaded faster.

I made comparable tests with 32*32, 64*64, 128*128 and 64*128 image sizes:
i tried this scenario 5 times on an almost empty SIM and no objects except the sculpties:

- I placed the 4 sculpties near each other (one for each sculptmap mentioned above).
- i created a landmark to jump back to the build location.
- i logged off second life
- i cleaned the SL cache
- i rebooted my computer
- i logged in to an arbitrary SIM which does not contain any of the objects i just created before.
- i strolled around a bit to fill the caches
- i jumped to the landmark i created before.

the results: unpredictable

Once the 64*128 image took almost a minute to appear. The others where just visible without any latency. In most cases all sculpties where visible as soon as i landed on the LM.

Now i changed the setup and only cleaned the cache, rebooted the computer and logged in to the sculpties location.

the results: all sculpties where visible just when i arrived.

SOme thoughts:

- the upload time might be more dependent on the whole internet inbetween the server and the client ?
- Proxy caches on our local site might help us speeding up sculpty load times ?
- The order in which sculpties are created on a SIM might be significant ?
- The number of sculpties already on a SIM (and visible) may be a big issue

But at the end: I can not verify that "in general" 128*128 bit images load faster than others. I am curious to learn if my setup is faulty. Maybe i just see what i want to see... ?

Anybody can put some light here... ?

Yes, the recommended sculptie map size has been 64x64 since their introduction. For a quite a while sculptie maps uploaded in a lossy format so developers desiring higher map accuracy (for example: needing precise vertex positions for hard edges) would upload even larger maps (128-512!) so there would be greater amounts of sampling data available to counter the signal degradation. I guess in these cases the longer load times was acceptable. I know I have made that trade off in the past by going up to 128 for sculpties that would basically be highly instanced - window treatments multi-story building facade, for example.

Why have the image at twice (or more) the mesh resolution? In signal processing it's generally understood that it's necessary to sample at least twice the actual signal/image for best accuracy (Nyquist–Shannon sampling theorem). Both the 3d displacement and MIP mapping systems use the twice actual size to achieve better anti-aliasing and downsizing by oversampling this way from sculptie maps. This is also why a quality audio CD's sampling rate is 44.1 kHz when the upper range of human hearing is, at best, around 20 kHz (I'm sure mine is much lower), and the reason quite a few developers create textures at twice the target resolution then down-sample before uploading (although it might not be understood or expressed in the 'signal processing' terms I have used).

That's all interesting information, but none of it is the actual reason we NEED a 64x64 map to describe a 32x32 mesh. The real reason is far simpler than you'd think.

Sculpt maps describe vertices not faces. A mesh with 32x32 quadrangluar faces has 33x33 vertices. Needless to say, a map of just 32x32 pixels can't fully describe 33x33 points. For that, we need at least 33x33 pixels, obviously. But that's not an allowable texture size, as textures must be measurable in powers of two. So 64x64 is the next smallest size that can work.

Hey, this should be cut into stone

ah... And it reminds me about one more question: is the power of 2 constraint for texture sizes something unique to SL or is it a basic principle to use power of 2 image sizes ? I remember i have read about this a while ago

- This maybe related to how textures are processed in common graphic cards ?
- and maybe it's even a good choice for compression algorithms ?
- Also power of 2 image sizes seem to be an optimal choice for LOD

I made another experiment. This time i added a 64*64 and a 128*128 sculpty to an almost full SIM. Then i cleared the caches and relogged. Now the 128*128 image clearly wins the race for first visibility. But it is the last one to show the full LOD. So the situation seems to be dependent of what else is in the environment... All not so easy to understand

For a long time, OpenGL required that all textures be in powers of two. I think that requirement has been relaxed in the last few years, but powers of two are still the prevailing rule on most platforms.

The reasons you surmised are all good. It is true that not all graphics cards can handle non-power-of-two textures, even if OpenGL itself now can. Powers of two are definitely good for easy LOD culling. And I'd imagine it's also good for compression, although I'm not well enough versed on that subject to say for sure.

Ok, today things are different again... I tried it another time on the full SIM and what i see today is summarized in 2 words:

"unpredictable results"

Probably the whole thing is dependent on the environment, so you need to measure for your particular situation and decide what is best for you... (being aware that other visitors might face other upload situations...)

Another thing comes into my mind: If everybody would use 128*128 images to get their scuplties loaded faster... Wouldn't that mean that the whole effect is nulled at the end? since now all images are equal again and none is taken faster to the client over the other ?

So long...
Gaia

All interesting and helpful responses, thanks. This confirms my belief that 64x64 is NOT necessarily faster than 128 by 128.

I have two concerns here. I want to deliver the best scuptie map products to my customers. I also want to consider the "environmental impact" of texture size and system resources. Anyone care to comment?

For "standard sculpties": In terms of precision 64*64 images are the best you can get. 128*128 will never add to quality.

For oblongs: depending on the ratio 4096 pixel images or 8192 pixel images are supported. The 8192 images are for ratios like 22*46 faces (corresponds to 64*128 image size) The exact calculations about which face ratios and which corresponding image ratios are supported have been sorted out by Domino and cut to software in his primstar add-on for blender...

In terms of system resources i just had an interesting conversation on the blender group in SL where the common sense was: create as small as possible data chunks in order to minimize impact on bandwith and decompression time.

And as mentioned above: Currently smaller sculptmaps are allowed, but suffer from a lossless bug. So you better stick with the 4096 or 8192 pixel images which both produce precise results in SL.

You are right of course (about the size that is, I am not in a position to judge the qualifier you attach to the 'information'). So it's a good thing I never use the word you typed in all caps or otherwise state in absolutist terms that the information I posted was the sole reason for the size to allow me to weasel out like this

It was implicit in the post however, so thank you for the correction.

Somebody did claim that but it wasn't me. I never investigated as even if it's true, quadrupling the image size to hack the speed seemed like a very poor choice. Not to mention how much more difficult it is for LL to optimize the sculptie loading if everyone is using the wrong sizes