Jump to content

Vir Linden

  • Content Count

  • Joined

Community Reputation

424 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. Wulfie - What are some of the niche applications? I normally assume that someone has found an intentional use for any feature, but couldn't think of one in this case.
  2. This is somewhere between a bug and an unintended feature. To summarize what you've already figured out above: HUDs are visible only to the owner, and don't even get sent to other users. Normally HUDs are locked on the screen like other elements of the UI, so it's fairly clear that no one else can see them. But rigged meshes are displayed on the avatar, because they follow along with the avatar skeleton, so if a HUD includes rigged mesh, you get content that looks like it's on your avatar, but that only you can see. This behavior was never intended, but since we don't have anything to prevent using rigged content as a HUD, it's possible to do. We're going to look into adding some warnings about this situation so people can tell when it happens.
  3. Thanks for the comments! We currently have a project underway to improve some of the pain points with mesh upload. We could potentially tackle more things there, with a strong preference to anything that's well defined and limited in scope. As Beq says, the best way to get this kind of thing looked at is to file a JIRA; new bugs filed as feature requests get evaluated weekly.
  4. 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.
  5. In the Bakes on mesh project viewer update, 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");
  6. 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.
  7. 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.
  8. 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).
  9. Maybe at some point, but we won't be doing any kind of bake API for the initial release.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...