Second Life News 2013-24 #3

The Server Beta meeting provided more insight into new Linden Scripting Language (LSL) functions, but no rollout surprises. Server rolls were as planned, see: Second Life News 2013-24 #2.

Server/Scripting Meeting 2013-24

Server/Scripting Meeting 2013-24

Kelly Linden posted in the Deploys thread about the new LSL functions for returning items. (See: post) Kellz provided some basic guidelines and thoughts on exploits. 

  • There are no cases where one of these new LSL calls would return an object that you could not manually return yourself.
  • There are some cases where these new LSL calls will not return objects that you could manually return yourself:
    • To prevent severely damaging accidents the mass returns by owner (llReturnObjectsByOwner) will not work for your own items, items owned by an estate owner or manager or items that are owned by the group the land is ‘set’ to.
    • To protect some of our back end systems there are some fairly generous throttles in place. These functions should be able to return everything on your land within a region in one go, but not necessarily more than once an hour for such a large return.
    • There is a required runtime permission.
    • This is not a solution to griefing or ‘grey goo’ attacks. These calls can help with sandbox cleaning and automated rental property management. In some limited cases it may help with griefing cleanup, but the throttles mean it will only be effective after the cause is cleaned up or stopped. It is also not great for dynamic content (alife etc) because objects are returned to their owners inventory – there is no way to return to an object’s contents or ‘delete’ an object with these methods.

I suppose the idea is if you can return something using land tools in the viewer, then the new LSL function allows you to automate that task. You don’t get any new powers.

Kelly made clear in the post and at the meeting that these tools were not intended as anti-griefing tools.

There have been questions about the return throttles. These throttles are limits set to protect the servers from high loads. Basically, if your parcel has 100 prim limit, your script can return 100 prims per hour. If your land has a 500 prim limit, you script can return 500 prims per hour.

Also, the throttles are per owner, not per script. So, you cannot put 3 scripts in your object or 3 objects with one script each on your 100 prim parcel and expect to get a 300 prim/hour return rate.

Interest List

Andrew Linden told us the Magnum package got two additional fixes; the excessive Avatar-Appearance packets, and his final fix for Meeroos, which is the fix for slow viewer updating of animated objects. The bug happens when you turn your back on any animated object. The new Interest List processing cut back on updates of the item. The viewer then had to catch up when the item came back into view. The result being the animation appeared to be broken.

Andrew has been working on get this fixed for a couple of weeks. Each iteration of the fix has gotten better.

LSL HTTP

There has been a problem with scripts that use HTTP functions losing connection with their remote hosts. That apparently was related to the Mass Disconnections people experienced, a network problem. It was thought to be fixed with the release of this week’s rollout to the main channel.

Users are reporting it was not a complete fix. Maestro and Kelly Linden are looking at the problem. It is a confirmed bug the Lab can reproduce, so they are working on a fix.

Texture Lag

The subject of texture induced viewer lag came up at the meeting. As the viewer only allows the video card to devote a max 512mb of VRAM to texture storage the excessive use of 1024×1024 textures is creating excessive viewer lag.

It is possible to turn on texture compression in Preferences. (Preferences->Graphics->Hardware->Enable Texture Compression (requires restart)). This feature is for those with video cards that have small amounts of VRAM on the video card. It causes the textures to be compressed when stored in VRAM. It does degrade the quality of the rendered texture. You have to try it and see if the speed improvement is worth the loss of quality. If you have 1 or 2gb of VRAM, you’ll probably lose performance and quality if you use texture compression.

The SL Wiki describes the setting as:

Texture Compression (also called ‘lossy compression’ in other viewers) – switching this setting can drastically change the graphical performance of the viewer. On slower graphics cards it can give a huge performance boost, as texture compression reduces the amount of video memory used by the graphics card. It can also reduce the performance on computers with some faster graphics cards, because the computer needs to do some extra calculations to compress the textures.

See an example of the result in the SL Forum post: Bad Graphics.

I find it amazing that so many want more limitations imposed on Second Life just to save them some inconvenience. Whatever…

Refer to Penny Patton’s article: Building Better.

I think something that would be a big help is getting Render Advanced->MetaData->Render Complexity working again. Some tool that is easy for builders/creative types to use that easily shows the render weight of everything in a scene would be a big help.

14 thoughts on “Second Life News 2013-24 #3

  1. The updating problem for animated objects has been fixed completely by Andrew Linden? I thought it was just for distances <10m for now?

  2. Greetings
    It seems that the problem that affects my GPU dropping my framerates to the point that be in SL is unbearable for me, is caused by the abuse of textures.. or by a bug.. or maybe a combination of both. If the only way to mitigate the problem is limit the texture resources i 100% agree to limit it. And that’s because, to me, this is not just an inconvenience, it is a showstopper.
    In any case, i think that tie texture usage in content to the new LI count introduced by mesh could be a good way to prevent the abuse of this resource. After all, an inefficient use of textures can affect you GPU performance as much as a unnecessary high poly mesh………. or even more in my case.

    • Well, you are one of those willing to give up everyone’s freedom to resolve your inconvenience…

      • If you are assuming that i am one of those willing to make the LI count a bit more consistent than it’s now in order to prevent the abuse of it, even if that means to limit it more than currently it is, then you are right.. half because my own selfishness (i am extremely frustrated because my SL experience have been drastically degraded for over 3 months now), half because the reasons i stated above (I do think it would suppose an overall gain to SL performance and all it inhabitants). As builder and consumer, that would a prize i would be willing to pay if that means be able to enjoy my SL experience again… but obviously i would be willing to do it just in the case there is no other way to do it.

        If you like to call it that i want to limit everyone’s freedom.. do it, but i don’t see it that way. I think i am not claiming nothing different than Penny Patton’s article does, and you featured a couple of times in the past.

        Ok, grant you that my reasons are probably sound more driven by the selfishness and the frustration than for the good of the community. I am not usually that way. I made an huge investment, on a new machine, more than i could afford to tell you the true.. and i can’t entirely enjoy it now.

        • OK… you are entitled to your opinion. You confirmed what I said.

          There is a difference between what you want and what Penny proposes.

  3. VRAM is one of the stupid thing Linden Lab can not do. They need to hire a real programmer that can make this flexible for any computer. Stupid hard limit. >:(

    I got 3GB of VRAM waiting to scream.

  4. The VRAM usage is not an issue (and the texture compression is useless for all modern cards: only the 5+ years old cards would have issues dealing with 512Mb of textures, and among them, almost none support texture compression).

    No, the problem is that all the textures that are used by the viewer must also be stored in the normal (CPU) RAM, and in several places (as a raw texture, as a “LOD” texture, as a bound texture…), and the virtual address space (mappable contiguous memory) available to a 32bits application is limited to 3Gb (or 4Gb when the 32bits application runs on a 64bits OS). If you set your “texture RAM” setting to 512Mb, the viewer will typically use up to 1.2Gb for textures in the CPU RAM, and it also must find room for the objects data structures, the animations, the sounds, the UI elements structures, the inventory data, etc, etc, etc…
    Since mesh viewers have been out, the 3Gb memory limit is often reached in crowded sims, and while it would perfectly be possible to raise the 512Mb texture memory limit (which is just a constant in the viewer code) to take benefit of newer graphics cards, it would also cause the viewer to slam into the 3Gb address space wall and crash as a result.

    With the new materials support (which adds even more textures and data structures to store in memory), my guess is that it will soon be a necessity for LL to consider providing 64bits builds of the viewer to overcome the memory limits…

    • Lots of people are hoping for 64-bit. The apparent holdup is with the various libraries that the viewer depends on.

      • Exactly… But it will also force many people (me included, because 32bits(+PAE) Linux was just perfect for me so far and most 64bits Linux distros still got glitches, especially when running 32bits apps) to upgrade to a 64bits OS and 64bits capable CPU (though, since SSE2 is already a requirement for current viewers, it would only exclude Pentium M and Celeron M CPUs, which are SSE2-capable but not 64bits enabled)…

    • LOL oh god…

      Yes, that would solve some other problems but that’s something else Linden Lab can not do. I don’t even think Windlight and Voice system have 64bit source ready for use… that means redoing from scratch, mostly.

      That would just take forever to get it done by Linden Lab’s coding standard.

  5. The throttling doesn’t appear to be working properly. After about 30-40 successful tests, i suddenly started getting throttle warnings on my parcel. I left the script running (which returns prims every 15 minutes), but after 24 hours it has not had even one successful return.

    From what I can tell, It appears that attempts to return prims that result in a throttle failure may also be counting against the throttle limit (so for example if you try to run it every 30 minutes and every time it comes back throttled, it will continue to re-throttle with each call). If anyone gets a handle on this let me know.

Leave a Reply

Your email address will not be published. Required fields are marked *