• 10Sep

    The Build window should have a tab for controlling a prim’s particle system.

    That’s simple enough, yeah? But I like to hear myself type, so I’ll go into more detail.

    Continue reading »

  • 03Sep

    Textures take a long time to download, even on the asset servers’ good days. The fact is, they use a lot more storage space and bandwidth than the actual prims they cover. While moderately-sized textures will weight in at several kilobytes, a prim takes perhaps a hundred bytes (the exact figure does not matter at this point, only its relative magnitude). How can a three-dimensional object take less space to store than a two-dimensional image?

    The trick is in how prims are created. Every single prim is parametric‘ or procedurally generated. Second Life has functions (i.e., procedures) which take certain parameters (e.g., size, twist, taper) and generate the three-dimensional mesh of, say, a torus based on those parameters. So you don’t have to transfer the 3D mesh, just the parameters; the mesh can be constructed by any client locally.

    Textures, on the other hand, store pixel data for the image. Of course, image compression is used, and varying levels of detail are generated (so you only have to transfer the lowest level of detail needed), but it still requires much more data than a prim.

    But, just like it is possible to procedurally generate 3D primitives, it is possible to generate 2D images, i.e. procedural textures. Procedural textures are common in 3D computer animation as an easy and storage-inexpensive way of creating high-detail textures. Most animation packages come with a number of texture procedures, and although the complexity of the procedures varies, they all have something in common: one procedure can generate a (seemingly) unlimited number of similar (but not identical) textures, based on the procedure’s parameters. In addition to the “standard” texture procedures which come with the program, many packages allow knowledgeable users to create their own procedures.

    Continue reading »

  • 20Aug

    Consider the following LSL script:

    default
    {
    state_entry()
    {
      llSay(0,"Hello, Avatar!");
      llOwnerSay("Hello, Avatar!");
      // edit: fixed erroneous argument in previous line. Thanks MP!
      llInstantMessage(llGetOwner(),"Hello, Avatar!");
    }
    }

    Drop that script into a prim and run it. Three lines of chat will appear for the owner:

    Object: Hello, Avatar!
    Object: Hello, Avatar!
    Object: Hello, Avatar!

    Three forms of chat available to scripted objects show up exactly the same! (The other two, shout and whisper, can be distinguished from all others.) But of these three forms of chat, only one can be heard by other people. What gives?

    Continue reading »

  • 19Aug

    There is an alpha (testing) version of the Second Life Client on Linux. And I appreciate it. I wouldn’t be a part of Second Life if it had not been available. It has let me participate in a thriving community, build beautiful objects, and write useful scripts.

    But it’s missing some important features which put a damper on my creative ability.

    Continue reading »

  • 18Aug

    Suppose for a moment that you are a builder of detailed houses within Second Life. In a typical house, you might have ten window fixtures, eight decorative columns, four doors, and two statues in the garden. Each of these items is identical to the others of its type, and is constructed of, perhaps, ten prims each, with the exception of the statues which are 100 prims each.

    You’ve just spent 420 prims of your parcel budget to make twenty-four objects, and we haven’t even added furniture! That’s 420 prims which must be saved to the sim, and 420 prims which must be sent to every Second Life client which wants to view your magnificent houses.

    What a waste, when each item is exactly the same as the others of its type, with only a different position, rotation, and possibly scale!

    With object clones, which I am herein proposing, you could build the exact same house, but the above-mentioned 420-prim figure would be reduced to a mere 130 prims.

    Continue reading »

  • 17Aug

    When it comes to flexible prims, size does matter. A small prim just won’t bend as much as a larger prim with the same flex settings. So if you want your lop-eared pet rabbit’s ears to lop just the right way, you may have to scale him up to 5 meters on a side!

    If I ruled the Grid, flex would be independent of size. Depending on how Linden Lab has implemented flexible paths, this would likely involve subdividing the path into the same number of parts when it is big as when it is small—that is, a number of subdivisions per path, not per meter of the path’s length.

    Since flexible prims have already been implemented, and that change would “break” a huge number of existing objects (not to mention cause plenty of embarrassment for flexi-skirt users who go without the luxury of “glitch pants”), Linden Lab could instead add a new attribute to control the scale used for subdividing the path. The default setting would be equivalent to the current scale, so that existing flexible prims would not behave differently.

  • 16Aug

    Yesterday evening before logging off, I was invited to the Instructors group. Today, I encountered my first example of chatter in the Instructor group IM channel. Someone couldn’t figure out a scripting-related issue for his own project, and so they decided to ask in the Instructors channel.

    Do not do this. This is wrong.

    Continue reading »

   Next Entries »

Recent Comments

  • The feet and hand control bones can be used for inverse kine...
  • thanks! It's woahking! However I have a problem...someho...
  • it is very nice.i can easly understood for animation work.th...
  • I just want to thank you very much!...
  • Sorry, the exporter only works with Blender 2.49 and earlier...