Sharp Sculpties - Not deformed balloons

I do not know how the compression algorithms work in detail and i do not know which compression is used in SL, but i see that compression typically does a much better job for bigger files. So after reading your post i did a little bit of experimentation (as i love to verify everything that attracts my attention ) and i found that:

32*32 sculptmap stored as bitmap -> 3126 byte of data
64*64 sculptmap (same sculpty) stored as bitmap -> 12342 byte of data

This is roughly what i expected from calculating the sizes by hand.
Now i put that into a zip folder:

32*32 sculptmap -> 36% reduced (3126 -> 2007 bytes)
64*64 sculptmap -> 78% reduced (12342 -> 2683 bytes)

So apparently the quadrupling of the image size does not necessary lead to a quadrupling of the compressed file size. The example above states a difference of file size of only 30%, but this may be a matter of the content (as i stated before i believe that the content has a high influence on the compression factor)...

Zip uses the same algorithm as PNG. Linden Lab uses JPEG 2000, which has relatively poor lossless compression because the lossless option is kind of an afterthought. But apparently there's still some controversy:

I'm confused why your diagram compares PNG with JPEG, when neither of those are used in SL. JPEG2000 is NOT JPEG. It's an entirely different animal. The only reason the two formats have the same four letters in their names is they were both created by the Joint Photographic Experts Group, whose initials are J.P.E.G.

In any case, a typical 64x64 sculpt map saved as a lossless JPEG2000 comes out to around 2.3 KB. A 32x32 at the same settings comes out to about 1.4 KB. So is it really worth having this much concern over a matter of 900 bytes?

We've all got broadband here. The difference in transmission times between 64x64's and 32x32's is tiny fractions of seconds. Even if someone needed to load hundreds of sculpt maps at a time, the difference would be just a few seconds at most, for the entire load.

And if you want to talk active memory, the difference is still negligible. Uncompressed, there's only a difference of 9K between a 64x64 at 12KB and a 32x32 at 3KB. Put a thousand unique sculpt maps in memory, and you'd consume less than 12MB of RAM. That's obviously not enough to make any modern computer even blink.

Of course, I wouldn't recommend having a thousand sculpts on-screen, since the poly count would put your SL framerate into the toilet, but that's another matter. The maps themselves are not a significant source of overhead.

Because it's funny.

Qarl apparently thinks so. He deliberately lowered the priority of sculpties below surface textures, because of the time taken to load them.

I wish I had your Internet link. It typically takes several minutes before the sculpties around me finish loading when I go some place like the Lusk platform.

A sculpt has no more polys than a torus, according to Qarl. So you get that kind of poly count on just about any busy sim. 40 avatars with 20 twisted toruses on each head... that's 800 high poly prims right there.

I do not understand that If i compare typical texture sizes ( i assume that 256*256 bytes is typical, if not even the lower end) with typical sculpty sizes (64*64 bytes) it appears to me that there is a factor of 16 in size between the 2. ANd even when both get compressed, textures are still by far bigger than sculptmaps. So why should the size of the sculptmap be considered so important ?

Maybe it is the way, how sculpties are processed ? Or maybe it consumes much more computer power to render a sculptie than to render a texture ?

Me either, really, but we've been around and around with them on this and they're adamant that giving sculpties a higher priority caused problems.

Guess you are talking about exactly what was going through my mind last night.

How come a 512x512 new texture only takes a few seconds to rez on a prim, whist a 65x64 sculptie texture can take ages before rezzing.

Was puzzling me too.

It's not the size of the maps that's at issue there. It's the fact that SL always has been and always will be unpredictable in the order in which it delivers assets. It makes sense to give surface textures higher priority, so we don't have to stare at gray while we're waiting for some random sculpty to rez in the periphery of the scene. That in no way means a 32x32 sculpt map would come in significantly faster than a 64x64 one. It's a totally separate issue.



I'm not saying it doesn't take several minutes to load all the sculpt maps (and other assets) for a busy scene in SL. What I'm saying is it wouldn't go significantly faster if the sculpt maps were 32x32 instead of 64x64. Once you get past SL's chaos, which is the real issue, the actual difference in transmission time between a 64x64 and 32x32 is a fraction of a second.



Yes, and that's why that kind of hoochie hair is almost always problematic.

Just for the sake of accuracy, though, let's be clear about one thing. A sculpt has as many polys as a twisted torus, not an untwisted one. An untwisted torus has 1152 tris in it, compared with a sculpty's 2048. With the exception of hair, I'd bet there are more untwisted toruses in the world than twisted ones.

Completely backwards, it makes sense to give geometry information higher priority, because a grey sculpty of the right shape is better to look at than a ball with a texture that makes no sense laid down on it, while waiting for some random prim on the periphery of the scene to rez a texture that's not even facing you.

And we're talking about scenes with hundreds of sculpties in them. Go visit Luskwood some time to see one.

Not much of a difference, hair is probably 90% of the toruses in the world.

Taken individually, a gray sculpty with the right shape is better to look at than a ball, yes. But you have to take all things in context. I think most people would feel that a gray everything else while you're waiting for that ball to straighten itself out is not an acceptable trade.

Most people just don't think about shape and color in the way you seem to want them to. Consider this. Do people recognize stop signs because they're octagonal, or because they're red? Try painting an octagonal sign blue. Do you think people would stop at it? Probably not. But paint a square sign red, and they almost certainly would. Color is much higher priority than shape, for most people.

From direct experience, I can tell you the vast majority do not have whatever special type of internal vision it takes to look at an untextured object, and see it for what it is. They just see that it's wrong. For this reason, I've had to learn over the years never to show my clients untextured work. Because almost without exception, whenever I have shown something untextured, the client has gotten uncomfortable as a result. Nowadays, if someone asks for a progress update, and all I've got are untextured models, I simply tell them there's nothing to see yet.

As you and I have discussed before, there is are significant differences between the way techy people like us think, and the way most other people think. It's foolish not to accept that, even if it flies in the face of what we might consider to be common sense. If our sensibilities were in fact common, everyone in the world would do what we do. But most poeple don't. We're uncommon, by definition.




I've been to Luskwood. I don't want to badmouth anyone, but ever since sculpties hit the grid, that place has been a prime example of how not to use them. When sculpties are used appropriately, performance is fine. But just like with any other resource, when they're abused, there are problems.




Probably. But that still doesn't mean it's a good idea to make or wear that kind of hair.

Ups... What i am not understanding is this:

On one hand you say, that reducing the sculptmap size would gain substantial faster load times. This implies that the slow sculpty rendering is due to size of the sculptmaps.

On the other hand you say, that LL has reduced the priority of Sculpted prims below the priority of Textures. The (your?) main argument was "because they are to big in size". This argument made me asking about if that(!) can be true. And meanwhile i doubt that the sculpty size is a problem at all.

Hence the argument "faster upload due to smaller sculptmaps" is not substantial to me, because apparently it is not the data size, which makes the rendering of sculpties so slow, but the priority order.

Thus i still want to understand what problems could possibly occur when sculpty rendering would be raised in priority. Even Chosen's argument that textures are by far more important than sculptie shapes does not convince me, as you(Chosen) say elsewhere that sculptmap size wouldn't make the upload significantly slower (which tend to agree too).

But i doubt that we will find the true reason for the LL decision here ... Except if a Linden would sniff into this thread and answer to this question ...

Why would you have a grey everywhere else while waiting for the sculpty to straighten itself out? You keep insisting that sculpties are so small anyway that it doesn't matter.

It's a simpler problem than looking at a pile of textured spheres and telling what it is. An unloaded sculpty is MUCH more disturbing than a grey sculpty of the right shape. Try showing raw UV maps to your customers and see how they react.

It's not my argument, I argued against it.

According to Qarl (NOT ME) it's the data that made them change the priority order. That downloading sculpties was annoying whatever FIC talked them into changing it.

Here's the crux of it, as I see it. Delivery time for assets in SL is unpredictable at best. Priorities can be set categorically, but there are no guarantees. It's herding cats.

Textures are going to take a while to load, no matter what. Putting sculpt maps ahead of them can make them take even longer. This is equally true whether the maps happen to be 64x64, 32x32, or any other size.

The reason for the ordering does not directly have to do with size. It's about consideration for what most users need to see first in order to enjoy the experience.

For an individual sculpty, Argent's right that shape is much more important than color. But since 99% of the world is made of regular prims, not sculpties, the textures have to come first. People don't enjoy staring at gray prims while they're waiting for a sculpty to load. It's better to see 99% of the world fully textured while waiting for the other 1% to form, than to see 99% as gray during the same waiting period, even if the waiting wouldn't be quite as long.

I'm not sure how else to put it.


But once again, the ordering is a separate issue from whether or not a 64x64 takes significantly longer to transmit than a 32x32. All we're talking about is a difference of 900K. That's literally a split second per transmission. By the numbers, it would take hundreds of them before the time difference could add up to any significance.

Argent, sorry to blow your conspiracy theory, but it's not FIC people who tend to trigger these kinds of changes. Most of us who have been around that long don't like it when decisions like this are made, even if we do understand that it's probably what the general public does need.

What happens is LL watches what people complain about. And most of the complaints come from relatively uneducated users, who expect it all to operate on magic. People bitch about "sculpty lag", and LL reduces sculpt map priority (as well as LOD culling distances, which royally pissed me off at the time, even though, as I said, I understood why they did it).


Also, for whatever it's worth, there really is no FIC to speak of anymore. Almost all the old guard at LL are gone now. If any of us ever had any significant influence over LL (which I never thought we did anyway), it was only because of the friendships and mutual respect we'd developed with those specific people. So relax. Everyone's on equal footing.

I've watched it happen. It's not a conspiracy, it's simply human nature. People who have the ears of a Linden get results. Happens in every company.

To my surprise I found myself the FIC in question on at least one occasion.

From my perspective, the easiest way to speed up the downloading of sculpties would be to allow sculptmaps to be combined into larger textures. 4 regular 64x64 pixel sculptmaps could be combined into a single 128x128 or 16 could be combined into a 256x256 pixel texture.

It is well known in website development that one of the quickest ways to speed up the loading of a webpage is to combine small images and other files, thereby reducing the number of requests.
http://developer.yahoo.com/performance/rules.html

If we, as content developers, were allowed to combine our sculptmaps in this way, it would dramatically lower the number of asset requests as well as the number of images that need to be transmitted and cached.

If the analogy to web development is valid, then there would also be significant performance gains as well.

I still want to know a door in my room (my home position so I see it very often) is one of the last things to rez.

I stare there looking at an empty doorframe, whilst thru the doorframe I see buildings in the plot next to mine (80m away) being rezzed whilst I still have no door to click on to open.

So much for this occusion thing that's supposed to rez things to can see before things you cant.

The door is only 1m from my nose and has been there for over half a year.

I suggested that, and the use of simple frame animation (like llSetTextureAnim), but Qarl was all about animating sculpties with a quicktime stream (SRSLY).

Because objects are presented to the client in order by the local SIM object ID, which is allocated sequentially.

So basically, it's in order they're rezzed in the sim until the internal object ID overflows and starts getting re-used.

What would be wrong with delaying the rendering of sculpties until both map and surface textures have completely loaded? (I know, some would never appear, but that's another problem). I loathe the messes you get with a half-loaded sculpt map even more than the spheres. As for huge spheres with 1-prim tree textures on ... Ugh!

I've been making stuff like this from one prim for so long I'd completely forgotten that we all started out with deformed balloons.



It's really, really simple so long as you have a program where you can pull the verts about. You're on the right track though, Piggie, and there's some great advice in this thread that I can't really improve on.

Very nice and I'm getting there gradually.

As I'm learning things, I'm kinda (as with most things) finding out bits and bobs which others are perhaps taking for granted.

I might struggle for 2 weeks to understand something, then I just notice something or see something new that totally turns my understanding on it's head, and then I feel like shouting..... why did nobody actually say this !!!!

I guess people who know just take it as the obvious, and don't grasp that the obvious is not obvious when you don't know

Like for example your excellent example above.

For the beginner (I'll use myself as an example) I might look at that and think how on earth can that be made from a simple starting shape.

Yet, I sit next to you at the PC, you show me the item in your modelling program and roughly how it was made and instantly the "Penny drops" as we say, and it suddenly becomes clear.

Without seeing that, you are left puzzled and wondering and grasping for snippets to find out what sitting next to you would show me in seconds (or minutes) anyway.

One thing is for sure, I know I lot more than I did a week ago and a LOT more than I did 2 weeks ago. So, we're getting there gradually

This rezzing time difference was made clear to me this morning.

A 512x512 surface texture ON a sculptie, rezzed fully way way WAY before the 64x64 sculptie rezzed fully.

Funny huh.

Chosen, I have to thank you SO much for mentioning Xeniversity. I had never known of it, but after seeing your post a little over a week ago, I slid into his Maya 101 classes the day before, grabbing the last spot in the class. I am learning SO SO SO much. I LOVE his classes, and they are so well done. I am an alt account so you wouldn't know it, but I have been tinkering around with Maya for a LONG time trying to figure out how to use it for Second Life and had no luck, but now I am creating QUALITY work out of Maya for Second Life that I never dreamed I'd be able to do! Using Maya for Second Life isn't the same as normal, and no matter what books I bought on Maya, it didn't help me figure it out for Second Life as I had hoped. Now I'm getting VERY good with doing it for Second Life, and it's all thanks to Xeniversity and YOU for mentioning it! THANK YOU!!!