Vir Linden

Lindens
  • Content count

    230
  • Joined

  • Last visited

Community Reputation

280 Excellent

3 Followers

About Vir Linden

  • Rank
    Advanced Member
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.)
  10. 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.
  11. 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.
  12. Bakes on Mesh Feedback Thread

    I'm not sure why it's not responding. One recent change with the SL viewer is the addition of a separate launcher process, so instead of just starting the viewer, you're really starting a launcher, which then does things like checking for updates, handling crashes, etc, and is responsible for starting the actual viewer executable. So if you see something about python (a programming language used by the launcher), or Second Life Launcher, that's what it's about. Re: the crash, you may want to retry and just wait a bit while everything gets loaded and cached. If that all works correctly, you may get better performance the next time you log in with that account. If it crashes consistently, please try with the SL default viewer, and then file a JIRA to let us know about the problem. Please give any details like "only crashes with bakes on mesh viewer" or "crashes consistently with both viewers".
  13. Bakes on Mesh Feedback Thread

    For those interested in the history of the project, the first discussion I can recall was during the bento project. Cathy talked about it, and the first feature request filed was from polysail: https://jira.secondlife.com/browse/BUG-10980 aka "Option to "Unwear" the default SL avatar". That was created Dec of 2015. This eventually started getting called bakes on mesh and has been on our backlog since then, and has been a popular recurring topic at the content creators meeting. We've only been actively working on it recently, though, since Anchor picked up the project earlier this year.
  14. Bakes on Mesh Feedback Thread

    I see some discussion here about selling things in the marketplace based on bakes on mesh. To agree and expand on some of the discussion above: it's great that the project is working well enough at this stage that some people want to base products on it, but It's also important to realize that currently this is just a first-pass project viewer. That means that it is new and experimental code at an early stage of development. Like any project at this stage, it's possible that it will change substantially before release, and it's even possible that it could be canceled entirely. This would leave any products based on this stage of the feature in a tough spot, either working in an incomplete or incorrect way, or not working at all. For this reason we would strongly recommend waiting until the project is released before selling products based on it.
  15. Bakes on Mesh Feedback Thread

    Essentially, yes. The baking service (which has been around for several years) layers images on top of each other without knowing or caring what UV space they are in. The only requirement to get good BOM support is that all the visible textures in the same body region have to be in the same UV space. There are some possible complications if you're depending on system avatar textures behind the scenes, though - for example, a shirt has a sleeve length adjustment that's based on picking a threshold in a built-in alpha texture, so a shirt that isn't in the system UV space won't work with the sleeve length control.