Jump to content

Vir Linden

  • Content Count

  • Joined

  • Last visited

Community Reputation

384 Excellent


About Vir Linden

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Vir Linden

    release date ?

    Update to that update: the simulator and inventory work is deployed now. Getting the appearance (baking) service updated is the main remaining issue. We are still tracking down some bugs and performance issues there, will get them sorted out as soon as we can. Once that's done we will be able promote the BOM viewer to default.
  2. Vir Linden

    Can bakeonmesh be used with firestorm?

    Bakes on Mesh requires updates to back-end services as well as the right viewer. We're still in the process of getting those services updated, so even if you have the updated viewer you will also need to be in a supported region. Currently the only place where everything should be fully supported is the "Bakes on Mesh" region on the test grid (aditi).
  3. Vir Linden

    Bakes on Mesh Feedback Thread

    Maybe at some point, but we won't be doing any kind of bake API for the initial release.
  4. Vir Linden

    Bakes on Mesh Feedback Thread

    We will be adding these as constants in LSL, so you can use them in setting texture ids for mesh faces. As Wulfie notes above, the baking service generates new textures each time. However, those aren't the values that are stored for bakes on mesh. Instead, we store certain "magic" values that the viewer interprets as "use the current baked texture here". So that's why it's possible to define reusable constants that can be accessed in LSL.
  5. Sorry, I had planned to do a post about this. We are adding 5 new baked channels, called left arm, left foot, and aux1, aux2, and aux3. The left arm and left foot channels are specifically intended to help with the case that you want to make limbs that don't match left and right, although of course you can use any channel for any purpose. Originally we had planned to add the new channels to the existing tattoo wearable. Unfortunately old viewers get very unhappy when they see new channels being added to their old familiar wearables, and tend to crash. So instead of modifying the tattoo, we are creating a new wearable type called universal. Universal wearables will include all the channels old and new. They basically work like a super tattoo. Like the tattoo, they have slots for textures, but nothing else - for example, there are no associated sliders, no automatic alpha masking, etc - by contrast with more complex wearables like the shirt. Universal wearables will layer above the current tattoo wearables and below all the other clothing. Old viewers of course won't know how to handle these new wearables, but they will just ignore them rather than crashing. Adding a new wearable type will also require changes to the simulator, baking service, and inventory service. After the next project viewer update, all these things will be working in supported test regions on Aditi. We will update you when it's all ready to try out.
  6. Vir Linden

    Bakes on Mesh Feedback Thread

    Thanks! For feature suggestions I'd also suggest filing a JIRA. JIRAs are much more persistent, so for example if we flag something as "possible future work", JIRA is where we're going to find it later. At least for the initial release of bakes on mesh, we are not planning to add a general baking API.
  7. Vir Linden

    Bakes on Mesh Feedback Thread

    That is indeed a problem. We are looking to add additional channels to the tattoo wearable so you can use tattoos to build up layers of textures for any of the bakes. We may also add additional channels to the current 6 - still looking into that one. Unfortunately tattoos with extra channels are confusing to older viewers, so we'll also probably need to release a fix to prevent crashing.
  8. Using bakes makes it harder to access the UUIDs of other avatars, because all you know is the UUID of the final bake. For your own avatar, you still have all the system wearable UUIDs available - the viewer has to know all the UUIDs, because when you're editing your appearance the "baking" is being done locally using those textures. And as you say, with your own avatar you can control exactly what items are worn as well.
  9. The baking service uses textures from your system wearables (skin, tattoos, shirts, etc) and composites them into 6 baked textures. The way this works is that you and the baking service know what all those individual wearables and textures are, but observers only see the result of the baking process. So in that sense the textures are a bit more secure - an observer has access to how the textures look when combined, but doesn't have access to all the individual textures that were used in the baking process.
  10. Vir Linden

    Bakes on Mesh Feedback Thread

    Bakes on mesh won't do anything to break the ability to apply a texture to a face via scripts (using the llSetTexture() call). If someone wants to continue doing things exactly the way they do today then they can do that without problems.The difficulty is that BOM isn't compatible with the existing mechanism for putting textures on a face, so if you want to take advantage of the capabilities of BOM and switch a face over to use it, then you can't also set its appearance the old way. So various proposals have been made to help with the transition process, allowing applier-based texture manipulation to coexist with bakes on mesh.
  11. Vir Linden

    Making clothes for inworld Blender avastar and MD -What a mess...

    This is almost always caused by one of two things: either rigging a single mesh to more than 110 joints, or rigging to a joint that's not part of the recognized avatar skeleton. Unfortunately Second Life does not always give you great feedback about the causes of such problems - however, if you look in the SecondLife.log file, you will often see messages to help show what the problem is.
  12. Vir Linden

    Bakes on Mesh Feedback Thread

    This was discussed at the last meeting. Basically anything in software development takes time - the more features we need to get done before release, the longer it will take to release the project. So any discussion of features needs to be looked at in those terms; there's always a tradeoff between less stuff sooner and more stuff later. Of course, there are always other projects that need resources too, so sometimes the decision on what gets included in a project is going to be influenced by that as well.
  13. Vir Linden

    Scripting Info

    As the previous reply mentioned, the appearance info is stored in the current outfit folder. The somewhat detailed description of how this works is: Current Outfit Folder is a special folder in your inventory. It doesn't contain items directly, but rather contains links to items that actually live elsewhere in your inventory. The main reason we store links rather than just copying items into the current outfit folder is to allow you to have multiple outfits that all use the same no-copy items. You can also have any number of other outfit folders, so you can save your current appearance to an outfit and then restore it later. These also contain links to items. An outfit can contain various things. It should contain exactly one of each of the "body part" wearables, which are skin, shape, hair, and eyes. It can contain several each of the "clothing" wearables, such as shirts, jackets, tattoos and so on. There is a limit of 60 on total number of wearables in an outfit (I think this does not include the required body part wearables). The outfit can also contain objects, which are non-wearable attachments. Fitted meshes are objects, but objects could also be sculpts, simple prims, etc. Ordering of wearables is first done by type. For example, skin is always below tattoos, which are always below shirts, which are always below jackets. For wearables of the same type, ordering information is stored for each wearable, and the ordering can be changed using the outfit management UI. (Internally, the ordering for a wearable is stored in the description field of the link, which is normally invisible. So the order of an item is a property of the outfit, rather than a property of the item; you could have the same item in multiple outfits, with a different ordering in each one.)
  14. Vir Linden

    Scripting Info

    It's true that baking is done on separate servers, but the question of load on them is still relevant. If baking becomes far more expensive, or far more frequent, then those servers will bog down. It's possible to add more servers (as we will need to do for the 1024 resolution change), but there are going to be constraints on that, like any hardware expense.
  15. Vir Linden

    Bakes on Mesh Feedback Thread

    Applying to animesh attachments has been discussed. Of course the problem is that animesh objects don't have an associated avatar, so there's no natural source of baked textures for them. To allow this we would first have to have a way of defining what is supposed to be included in such baked textures, and then modify the baking service accordingly. So it's a fairly big project. Something we might consider in the future but that won't be part of the initial bakes on mesh release. Prevent baked textures on non-mesh attachments: I'm not sure if we would want that limitation. How about something like a rigid piece of armor, which might be defined in the same UV space as the system avatar, and where you might want to apply a texture derived from a clothing item? I'd be curious to hear if anyone plans to use bakes on non-rigged meshes. Disabling auto-hiding, or more generally giving the user more control over what gets hidden, has also been discussed. No final plan on that yet.