Jump to content

Vir Linden

Lindens
  • Content Count

    292
  • Joined

Community Reputation

417 Excellent

6 Followers

About Vir Linden

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. I was there 🙂 The latest on BOM is that there are three things required to get it out: appearance service update. The main affect of this is that it should fix the black textures issue. This change is now in testing, will be rolling out soon if all goes well. simulator update. This is only needed for one small scripting change, to add abbreviations for the latest BOM texture IDs so they can be used in scripts without giving the explicit values. Hoping that will go out by the end of May. viewer update. BOM viewer needs to be updated with the latest contents from the current default viewer and tested. That update will likely be going out as an update to the BOM RC viewer next week, and then going out as the default viewer once we have enough testing against it, and after the other two items above have been released. BOM will likely be the next viewer to be promoted to default, as it's currently closest to ready for release.
  2. In the Bakes on mesh project viewer update 6.1.1.525409, the default bake texture slot UUIDs were changed. The default textures had to be updated to include the alpha channel. We needed to create new default texture UUIDs instead of updating the original texture data, because the backend texture servers have many layers of caching all of which would be invalidated by a change to the existing assets. This means the texture ids will need to be updated on any older content that uses the bakes on mesh feature. If you now see default bake textures on your BOM avatar instead of bakes, please reapply the bakes on mesh settings to your meshes. Another effect of the UUID changes is that the LSL constants defined on the simulator (IMG_USE_BAKED_HEAD, IMG_USE_BAKED_UPPER and so on) need to be modified to reflect the updated UUDS. The simulator changes to support this have not been released yet, so scripts that try to use these constants will not work reliably until the server release process is complete. This will probably be a few more weeks. We are sorry that this change was needed; unfortunately it is often part of the Project Viewer process that things need to be modified along the way based on issues uncovered during development and testing. Bakes on Mesh is now flagged as an RC viewer, indicating that future destabilizing changes are much less likely, and hopefully also that it is getting close to release. The new UUID values are: const LLUUID IMG_USE_BAKED_HEAD ("5a9f4a74-30f2-821c-b88d-70499d3e7183"); const LLUUID IMG_USE_BAKED_UPPER ("ae2de45c-d252-50b8-5c6e-19f39ce79317"); const LLUUID IMG_USE_BAKED_LOWER ("24daea5f-0539-cfcf-047f-fbc40b2786ba"); const LLUUID IMG_USE_BAKED_EYES ("52cc6bb6-2ee5-e632-d3ad-50197b1dcb8a"); const LLUUID IMG_USE_BAKED_SKIRT ("43529ce8-7faa-ad92-165a-bc4078371687"); const LLUUID IMG_USE_BAKED_HAIR ("09aac1fb-6bce-0bee-7d44-caac6dbb6c63"); const LLUUID IMG_USE_BAKED_LEFTARM ("ff62763f-d60a-9855-890b-0c96f8f8cd98"); const LLUUID IMG_USE_BAKED_LEFTLEG ("8e915e25-31d1-cc95-ae08-d58a47488251"); const LLUUID IMG_USE_BAKED_AUX1 ("9742065b-19b5-297c-858a-29711d539043"); const LLUUID IMG_USE_BAKED_AUX2 ("03642e83-2bd1-4eb9-34b4-4c47ed586d2d"); const LLUUID IMG_USE_BAKED_AUX3 ("edd51b77-fc10-ce7a-4b3d-011dfc349e4f");
  3. As always, it isn't done until it's done. However, we're hoping the BOM viewer can move to RC soon. The only blocker was a needed update to the appearance (bake) service, which is deployed now. So now it's just down to how things go in viewer QA. Once BOM is out as an RC viewer, it's likely that new bugs will be found - that's usually the way it goes when you have more people testing something - so how long from RC to release just depends on how the process of finding/fixing bugs goes. Re: Cathy's proposal for supporting direct baking in LSL: for the initial release we will be using the existing wearables system to control layers. There are proposals for some alternative mechanisms - those may be considered in follow-on releases. For now we're just focused on getting BOM tested and shipped in its current form.
  4. 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.
  5. 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).
  6. Maybe at some point, but we won't be doing any kind of bake API for the initial release.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...