The Art Galleries of SL List is available at http://sasun.info/ArtGalleriesOfSL.htm.

New visitors, please read: About This Blog

Thursday, May 7, 2009

What SL bugs are interfering with art in SL?

Bau Ur sent me a request to broadcast a plea for help with a specific JIRA bug that causes textures to rotate "out of sync" with each other on different prims on the same object. I felt it was definitely a worthy cause, but wondered what other SL bugs fell into the same category; bugs that inhibit or interfere with the growth of the SL art movement. I think it would be great to make a unified list of these bugs and broadcast that widely to raise awareness of the fact that

  1. These bugs exist and are impeding a successful art movement in SL
  2. That anyone and everyone can do something about these bugs by voting on them in the JIRA database at http://jira.secondlife.com.
  3. Collectively we can raise awareness and voice support of these bugs being fixed to further the cause of creativity, design, and art in SL.

So! Please reply to this post with a link to a JIRA bug that you feel should be fixed that in some way interferes directly with the creation and enjoyment of fine art in SL and I will collect a list to be broadcast widely to raise awareness of these important issues that we as an art community would like to be fixed. Please do not submit JIRA bugs that are more general in nature claiming that "it affects art too". And if your bug is not important enough to file in the JIRA database, don't bother posting it here either. Only JIRA links!


  1. Could you post a link to the JIRA that Bau Ur sent you?

  2. Certainly: http://jira.secondlife.com/browse/VWR-13259

  3. http://jira.secondlife.com/browse/VWR-13259 addresses a bug that breaks art with multiple prims running texture animations.

    When you have a lot of prims all running the same surface animation as a prim property, some of them get out of phase with the others.

    In the past there was a workaround for this, but the workaround no longer works. The number of visible discrepancies varies with onlookers, presumably depending on differences among supported video cards.

    Texture animation ought to be robust and comprehensive enough to run right, and run pretty much the same for all supported cards. If there must be discrepant prims, they should occur according to some kind of consistent rule so that creators can work around them.

    -- Bau Ur

  4. https://jira.secondlife.com/browse/SVC-3058
    llSetSoundRadius( float radius ); fails to limit sound to radius

    If you visited some multimedia environments at Burning Life last year and were confused by a mishmosh of overlapping sounds, this bug is the reason why. We are supposed to be able to limit the distance that triggered sounds are heard. But the code is totally nonfunctional.

    So we have to limit the distance that sound "travels" by adjusting the volume. This is sloppy because the results depend upon how high the visitor's volume settings are adjusted. Sometimes the only way I can keep the sounds in my installation from intruding into your installation is to set the volumes so low that they can't have the desired effect in my installation.

    The result is that conceptually cool things become ugly aural mixups, neighbors in exhibitions and galleries become unhappy and quarrelsome with one another, and the number of sound-utilizing installations that can coexist on a parcel is terribly limited.

    I really hope LL fixes this before the next Burning Life.

    -- Bau Ur

  5. Above, I meant to say, "We are supposed to be able to limit the distance that *looping* sounds are heard".

  6. Also, obviously, a problem associated with the failure of llSetSoundRadius is that we cannot segregate different sounds within an installation, nor overlap them with any precision.

  7. https://jira.secondlife.com/browse/SVC-2126
    This is a new-feature suggestion for an additional way to limit the distance that sound can be heard: defining rectangular areas, essentially "bounding boxes" for sounds.

  8. Although you're correct to say that "llSetSoundRadius( float radius ); fails to limit sound to radius" there is already a command that allows you to limit sound to a bounding box. It's 'llTriggerSoundLimited( string sound, float volume, vector top_north_east, vector bottom_south_west );'. It works perfectly and allows sounds to be constarined to a very precise area. I have a 'device' that uses this. If anyone wants a demo just IM me inworld.