Thursday, February 28, 2013

Why Second Life Fails

 I love Second Life, I wouldn't write about it so much, or spend so much time playing around in it, if I didn't. Of course, loving something doesn't mean blindly dismissing it's flaws, and Second Life has many, many flaws.

 So, I recently rebuilt Milk & Cream with a focus on making it as efficient as possible. I cut down severely on sculpted prims, used tonnes of mesh content, separated the mall and club area from the more detailed play area so that they wouldn't be sapping each other's framerates, etcetera.

 However, there is one tiny spot in the Milk & Cream play area where framerates drop through the floor.

 Inside an enclosed building furnished almost entirely in mesh, precisely where framerates ought to have been the highest, I found my framerates dropping to their lowest point. Where everywhere else I was achieving 30-40fps pretty consistently, inside this building my framerates dropped to an abysmal 5fps.

Why was that?

I began removing elements from inside the furnished tavern and watched my framerates. As I began to remove mesh furniture my framerate began to climb far more substantially than I'd have expected. I selected all of the items from one particular mesh set and removed them all. My framerates soared to 50fps.

Why was that?!

It wasn't the model work, which was fairly efficient, for the most part. Enough that the land impact cost was satisfactorily low.

I had a thought. I checked the texture sizes on the furniture pieces. Almost every single furnishing and decoration in this set used 1024x1024 textures. And not just a single such texture, no, even where only one texture could have, and should have, been used, the creator had broken the items into multiple textures, each 1024x1024.

 There was a wooden cup with some coins inside and a "tip jar" sign leaning against it. The wood of the cup was a 1024x1024 texture. The sign was a separate such texture. The cup had three tiny metal rings around it, sure enough the creator had textured these with a separate 1024x1024 texture.

 Every single item in the set was like this. The furnishings used in the tavern took up more texture memory alone than the entire rest of the island combined.

I kept the furniture in place and removed the textures, using the default plywood texture instead. Sure enough, my framerates jumped from 5fps to 50.

 This illustrates the most obvious, and yet somehow most overlooked, issue in Second Life. Texture maps eat up resources. Larger textures eat more resources. Most of the lag and framerate issues in Second Life are, in fact, due to use of excessively large textures.

 I contacted the creator and tried to explain the issue.

 They replied that they are a gamer and therefore knowledgeable about how videogames are made. With complete certainty they assured me that it was thelimits of SL's technology that were to blame, that all videogames use texture maps the size of the ones they used AND LARGER. They sympathized with my problem but they simply couldn't bear the thought of sacrificing quality for framerates. They hoped someday that technology would progress enough that everyone could run SL as well as gamers run Crysis 3 and Skyrim.

 That disconnect from reality is why Second Life fails to catch on.

 Many content creators cling to this delusion that all of SL's problems are due to either people using underpowered computers or LL's own failings in crafting the code upon which SL runs. This mistaken, entirely unfounded idea that SL itself is so bleeding edge technology, when it's really not and never has been!

 To be sure, many people do try to run SL on underpowered computers and there is a lot of issues with the code upon which SL runs. However, my computer has an i7 core, 12GB of RAM and a high end video card. I run Skyrim at full settings with the HD texture set add on. My computer is more powerful than the average gamer's.

 Why can I run Skyrim so well?

 Well, one reason is that the artists who created the art assets for Skyrim did not, in fact, use 1024x1024 textures on the 3cm wide metal rings of a cup that textured with five other 1024x1024 texture maps! Let alone larger!

 That simply does not happen!

Now, before you slip into the trap of dismissing all of SL's problems as simply a fact of allowing user created content, I say to you that Linden Lab bears the brunt of the responsibility here. They do absolutely nothing to prevent people from creating content this way, or providing people like you or I the ability to avoid such amateurishly made content.

What can they do? Plenty!

First of all, texture maps should count towards Land Impact costs. There is no reason whatsoever why content using so many obscenely large textures should have such low LI cost. This sort of hit to performance is precisely what LI exists to prevent. That it doesn't even take it into consideration shows just how poorly LL understands their own product.

 Second, textures always cost 10l to upload, regardless of pixel or file size. That's ridiculous. Larger texture files should cost more to upload. Costs should be balanced in such a way where smaller files cost less, however a single large texture costs less than multiple smaller textures, encouraging people to combine textures.

 Third, SL's building tools should be designed with the fact that they're mostly used by amateurs. There should be many helpful tips and tutorials that are entirely absent. When someone is uploading a 1024x1024 texture, they should receive a notice popping up asking them if they understand what that means. If they're importing a model with many such textures, another pop-up should appear pointing out the issues they will run into.

 Hell, this kind of information should be in the text people need to take before they can upload mesh models.

 In addition, LL could seriously enforce truth in advertising. The spot where we list prim counts for items on the marketplace needs to be updated to Land Impact. People are listing 100LI mesh models as costing 1 prim. Some of them are just confused and don't understand what "prim" means as opposed to object. Other people are simply being deliberately dishonest. Combine texture use with LI cost and allow customers to flag content which does not provide an honest LI cost for their product.

 Most of Second Life's problems can be blamed entirely on this disconnect between Linden Lab's development teams and the realities of how Second Life works. Everything from poor framerates and lag, to how expensive land appears to be are all a direct result of this problem.

 LL has struggled for years to address these issues and make SL more relevant. This, right here, illustrates where the change need to happen if they ever want to succeed.

 Rodvik, hire an art director. Make sure your management team listens to them when assigning priorities to developers like Oz. It is not the responsibility of your programmers to understand these things, which is why they need direction from well informed management. Management cannot be well informed unless they have a good art director explaining these things to them.

It is really that simple.


  1. This comment has been removed by the author.

    1. Not sure you why removed the comment, but I appreciate the kind words.

      This post of mine was kinda ranty (I'd just blown a few thousand L$ on unusable furniture and the creator didn't seem to understand why using half a dozen 1024x1024 texture maps on a single cube was a problem.) but I hope to eventually clean this up and redo it as a more constructive and easier to follow article.

      Texture maps are yet another in a long line of SL issues that Lindens and SL users alike don't seem to even be aware of. With users I can understand, this isn't something people outside modding communities and professional game artists understand, but LL are supposedly professionals, they should have people who understand these issues. It's just so frustrating that they don't seem to have an interest in addressing these issues yet they spend so much time and money trying to turn around their abysmal user retention rates by doing everything EXCEPT addressing SL's problems with, predictably, no real success.

  2. Is this bit a mistake? Doesn't really make any sense, or I could just be slow today. "...however a single large texture costs MORE than multiple smaller textures, encouraging people to combine textures."

    1. The more textures wrapped around an object, the more textures SL, and your video hardware, needs to decode, process and render.

      Game artists tend to combine textures and wrap them around an object. So a sword would have only one texture, instead of one for the hilt, one for the blade, one for the jewels, etcetera.

      It reduces strain on your hardware, allowing for higher FPS.

    2. This comment has been removed by the author.

    3. So if you wanted to encourage people to combine textures. Why would one large texture cost MORE than several small ones. Wouldn't you want it to be the other way around? For a single large texture to cost LESS than several smaller textures.

      That's what I'm confused about, not the combining textures part.

      Oh, and I removed my older comment because I remembered what my initial confusion was about.

    4. D'oh!

      I corrected it. A single large texture should cost LESS than multiple smaller textures.

      This is why I shouldn't reply to posts when I'm just waking up.

    5. LOL i did about the same in my comment here and i dont understand what i was writing myself, sorry :O)

      Out there chasing mesh trees now but its impossible to know what texture size the creator have used. Trial and error is the only way? But expensive.... :(

  3. Great blogpost! I couldnt agree more. And it is so no necessary this texture mess as you explain here. I love SL but i have spent some time in Cloud party too. Cloud party has a warning like this. If you upload item with too many "triangles" as it is called in Cloud Party u get a warning and too high is not possible to upload. Cloud Party is a lot more efficient than Second Life in this aspect. Thanks a lot, this is a major issue for all of us....

  4. OK, good point.
    However ..... I use a lot of 1024x1024, though mainly on large sculpties. I have 20,000 sculpted prims on my sim ... yes, it's in InWorldz. This would not be possible in SL.

    So...while I agree that small textures should be used on small prims, mostly, ... the lag issue has to do with LL's laggy servers as well.

    I appreciate that LL has managed to get by, charging a fortune for a sim, and users have been careful not to use too many sculpties, poor textures and wear fewer clothes...etc etc .... but... the REAL problem is LL and not the end user.

    For the high priced tier, you SHOULD be able to do what you like (within reason) and not have to continually 'help' LL by toning down your prim usage etc.

    ....and sim crossings will never be as good as in Inworldz, again because of the server architecture.

    So, again, good post, but LL has some blame in this lag issue.

    1. "the lag issue has to do with LL's laggy servers as well."
      Latency and server lag, maybe. But not framerate/performance on your end.

      Larger textures will kill your framerates. This is why videogames, even modern, high end AAA titles like Skyrim, use much smaller textres, and far fewer textures, than your average SL environment.

      I do agree that the real problem is LL, for not providing the tools and information to curb bad building tendencies, but there is absolutely nothing LL can do to make SL run well if, even if they did improve the tools, people insisted on using multiple, insanely high-res textures on everything. It is impossible.

      Same goes for prim useage. SL actually pushes more polygons per avatar/object than you would see in, again, even a modern AAA videogame.

      LL has some blame, but I would blame them for the tools and lack of reasonable building restrictions (texture use really should count towards LI cost) more than I would an idea that LL could somehow make more polygons and larger textures render faster.

      That's not to say that there aren't issues with the server architecture, there most certainly are, but it's important to understand how each and every part of SL works. LL can probably improve region crossings on their end, but they can't make a set of furniture using a hundred or so 1024x1024 textures not kill your framerate. That is out of their hands. All they can do is try to prevent people from doing that through better tools and better resource costs.

    2. Any tutorials re: texture usage in builds and content?

      Ormand Lionheart

    3. @Ormand

      I hope to write something up someday, even this post was a spur of the moment venting session. I hope to revisit this topic with a better written article, with example textures and tips for builders.

      Generally, tho, the idea is that creating a CG world like SL involves weighing the quality of individual objects against overall performance.

      If you slap 1024x1024 textures on every face of a drinking cup, it's going to look much more gorgeous close up than it would if you used a single 256x256 texture.

      However, is the average visitor really going to care about that gorgeous drinking cup? Probably not. They WILL care about their framerates, tho.

      Generally, I would avoid using textures larger than 256x256 on anything smaller than a wall or floor surface. For instance, the largest textures on any avatar should be your 512x512 skin textures. You don't need textures that large or larger on hair, boobs, jewlery, etcetera. Maybe a single 512x512 for something like mesh pants that cover your entire lower body. But a pair of shorts? Go 256x256. A sword? A single 256x256 should be fine, maybe 512x512 if it's large and very ornate. A wrist bracelet? 128x128 should be fine!

  5. I have no doubt that on SL most lag problems are caused by inefficient content built not taking into account SL limits. But i seriously suspect that there is a viewer issue behind this inconsistent FPS drop with mesh objects using large amount of high res textures. I have several reasons to think this way:

    * Not everybody experiences it, meaning it depends on the hardware you use. I noticed some friends using ATI GPU, or bit older Nvidia GPU do not lag in places i do.
    * After testing some viewers, i found i have no lag in some sims using some viewers, and i die of it with others.
    * The behavior of the lag is very inconsistent. You can say by many factors. One of them: you zoom around a completely rezzed object and have no lag. You move around. You zoom it again and lag kicks in. Meaning, the problematic objects sometimes lags you, sometimes not, sometimes less, sometimes more.

    As Penny, i am the owner of a fairly recent "gaming machine", and i have experienced this bug. I really had bad time to believe a single mesh object could drop my nvidia 560ti to the knees because it used a couple of high res textures more that necesary, so i have been thinking in ways to collect consistent data i could report in a JIRA(BUG-2064). I found time to record a video showing the problem. It seems that someone at the lab have been able to repro it, as they accepted my JIRA. I hope i am right and this is bug, so they can fix it.

    1. There is an additional memory bug where FPS in SL drops sharply as the viewer runs out of memory. Large textures exacerbate the problem by causing memory to fill more quickly.

      If SL gets rid of the bug you'll probably experience fewer FPS drops, but don't mistake that for large textures not having an impact on performance.

      In creating realtime CG environments there is a performance cost for everything. Sure, you can pile on large textures, but you'll have to sacrifice geometry and effects to keep performance up.

      This is why even the best SL builds pale next to contemporary videogames yet run at much lower FPS.

  6. Thank you for pointing out this obvious problem, as well as the arrogance we get from people who 'think' they know how the game industry works.

    Yes, you can theoretically cram a 2048x2048 detailed billboard into a game. But will people be able to see the detail? no. They're not going to jump up there and stand next to it to read the fine print.

    The same goes for SL. There's a REASON that SL likes to default to 512x512.

    Whenever I'm making PNG's for signs, textures for clothing etc, I always resize to 512x512. I could probably reduce the color depth from 32 to 16 and still be fine. I'm not doing it to reduce lag explicitly, I'm doing it because that's what SL seems to want to work with, and it's easier on my end.

  7. Thanks Penny. This is exactly the kind of thing that makes beginners like me dangerous. I am guilty of using 1024X1024 textures because "that's what looks good". Thanks for sharing some more realistic dimensions. I agree that this is the exact type of information LL should work much harder at getting across.

  8. Honestly, I think LL should allow larger textures, I'll even agree they should cost more but a better fix I think, is that users are able to set the max res they can render, having textures when uploaded, re-sized to multiple sizes, so if this setting's slider is set to, lets say mid, only textures no longer then 1024 will render, so, even though a creator applied a texture 2048 by 2048 on an object, the person with the setting on mid, will only render that texture as 1024 by 1024 and other users that have the setting set on high or ultra, will render the texture at the 2048 by 2048 size, thus it will be up to the user if they want to run SL at lower frames per second, I don't have a high end rig yet the only times I lag is when I am in a server with 20 plus avatars in one building.

    1. I agree LL should allow larger textures, but only if they introduce a system which discourages unoptimized texture use. Otherwise, people will continue to just use the largest textures possible for the smallest details.

      Texture use should cost land impact. And avatars should have a similar resource pool textures would count against. This would force people to be smart about texture use.

  9. This comment has been removed by a blog administrator.