My favourite bugs

Second Life has a lot of bugs, that much everyone knows. But some of these I would consider highly embarrassing if I was involved in making it, yet, they’re here, some are here to stay, and many have been around for years, known and apparently, ignored.

VWR-7957: The “boots to your waist” bug. Many video card manufacturers have stopped supporting palettized textures, because nobody was using them. Second Life was, even though it isn’t depending on them. In particular, it was using them for whatever unknown reason to cover baking clothing textures onto the avatar mesh, which results in texture parts that shouldn’t be visible covering the parts of your avatar they otherwise cannot. Since the baked texture is then on uploaded to the server, everyone else sees you this way. For three months the issue was blamed on the asset server eating clothes, on NVidia drivers being buggy, until they eventually caved in and said that it will be fixed in 1.22.

Update: It turned out that the reason for this happening was a single character typo in card feature detection code. Oh, the humanity…

VWR-1286: Whenever you try to alt-cam on an inner surface of a hollow or cut prim, the camera goes to great pains to stay outside the cut parts as if they’re still there. Makes it a very annoying to live in a house built with hollows, in particular, any cylindrical or spherical building. Been around for a year at least.

VWR-8920: Introduced in the latest release cycle, this causes prim attachments to vanish in certain camera positions. Instead of kicking at it until it was fixed, they labeled it as a known issue and released the new version anyway as a “stable” one.

SVC-472: Sim crossing. We now have warning lines to tell people about sim crossing. The issue has been around forever.

VWR-1298: Group chat delays. Never worked right, as far as I remember. There’s a whole bouquet of bugs related to group chat.

VWR-7331: Another arbitrary limit, which, incidentally, prevents me from putting up a Hands of Omega TARDIS in my skybox which is way above 1000m….

Update: How could I miss this one…

SVC-412: E-mail messages sent from inside SL do not contain correct header information, which results in all non-English letters horribly mangled. Been reported for a year. Estimated requirements to fix — one line of code, but obviously, nobody cares about people who don’t speak ISO-8859-1.

What are your favourite bugs?


5 thoughts on “My favourite bugs

  1. VWR-27 is pretty much unfixable unless object precompilation is implemented in some way that will subdivide surfaces. 🙂 Very unlikely.

  2. In plainer English…

    To determine which objects – or rather, which individual polygons – should appear in front of which others, Second Life uses a technique called “Z-buffer”. Very basically, every time a 3D-pixel needs to be drawn, it’s distance from the camera – per pixel – is stored in a special screen-like “buffer”, which, should it be drawn on the screen by itself, looks like a black-and-white image where closer surfaces are dark and more distant surfaces are progressively lighter. This avoids having to sort all those millions of triangles per scene (since each is part of an object, and stored this way, there’s no rhyme or reason to the order they get to the GPU in) and saves the time that otherwise would be spent painting things that will be covered many times over. (Which is called ‘painters algorithm’ where you first draw the furthest things and then cover them with closer ones. But that’s orders of magnitudes slower.)

    When it’s time to draw a new polygon, for every pixel of it that is seen, if it’s further from camera than what’s already in the buffer, (and thus, what has already been drawn onto the screen) it’s considered covered by other objects and skipped, otherwise it is drawn and the z-buffer is updated, so it goes from completely white at the start of rendering and becomes a black-and-white image as more objects are drawn. As a side note, this buffer can later be used to relatively quickly draw shadows.

    Unfortunately with transparent surfaces the trick doesn’t work quite as well. If you painted a transparent triangle, and then had to paint a non-transparent one that has to be behind it, it wouldn’t come out right. So SL does this by painting all the surfaces that are transparent last, after everything else has been drawn, while still obeying the Z-buffer for their distances — this way, pieces of transparent surfaces that are covered by opaque ones are not drawn, but all transparent surfaces cover something that’s behind them.

    But in cases of overlapping transparent surfaces, the trick also fails. To save having to tell the card about the texture data for every bloody triangle, (which would multiply the data sent to the card a hundredfold!) drawing has to be done surface by surface, and if one transparent surface comes in after another that should be in front of it, it will produce VWR-27.

    Normal 3D games deal with it by precompiling levels — it’s a process which takes several hours where surfaces that would never be visible are removed, (so that if one cube intersects another cube, they don’t have anything inside them, instead of pieces of each other that would still need to be drawn) and where a table is computed which can allow to quickly calculate which objects would be visible from any given camera position. During this stage, transparent surfaces can also be sorted in such a way that furthest are always the ones to get into the card first, so even if z-buffering breaks it’s teeth on two overlapping transparent surfaces, it will come out right. In case where two transparent surfaces intersect, they can be split at the intersection points into bits that don’t, and can still be drawn correctly if properly sorted, which is what’s done in precompilation anyway.

    But having all those precomputed data implies that all these things can never, ever, be moved, or the data becomes useless. And everything in SL can and should move… This results in a mathematically complex problem of how to do it without resorting to drawing everything back to front, and how to compute it quick enough so that SL doesn’t get even slower.

    It is conceivable that it’d be possible to ‘lock’ the object in some way so that it’s parts can no longer move. Then, a similar table can be computed for it and sent to the viewer so that it always knows what to draw first, or at least knows where the transparent surfaces intersect and can cut them into bits and sort them. For houses it would even make sense.

    But it takes some major effort to actually code. 🙂

  3. Many are not ignored, but in fact to fix them would break over half the scripts working around them.

Comments are closed.