Vir Linden
-
Posts
332 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Vir Linden
-
-
Lucia, re: some of your items:
3. You can organize groups of wearables into outfits as well (historically that was what outfits were created for, before we had mesh). How is this more or less modular than the other approach?
4. For new channels, you can use alpha blending for the hole punch effect as Theresa notes, and as we mention in the KB article. Could either of you give examples of the kinds of glitches to look out for there? We'd like to make sure the docs are current. Longer term, we hope to add a "universal alpha" wearable which would allow hole punching in a consistent way for all channels, but this would be after the initial release of BOM.
Thanks!
-
4
-
-
1 hour ago, HunniHope said:
are you using the BoM viewer that Vir linked to in his original post?
Right, you need to be using the latest Bakes on Mesh viewer from https://releasenotes.secondlife.com/viewer.html for it to work. Also if you have older test content for Bakes on Mesh, it may need to be updated - the texture ids for BOM textures changed a few months back.
-
3
-
-
The current plan is to release Bakes On Mesh as the default viewer next Monday, August 26. The knowledgebase article is being actively updated, and contains new information about how the feature works and how to use it. If you get a chance, please test out the Bakes on Mesh Viewer (download here) before then and let us know about any new issues.
Thanks for sticking with us!
-
7
-
7
-
1
-
3
-
-
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.
-
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.
-
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.
-
2
-
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.-
3
-
6
-
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");
-
5
-
2
-
-
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
-
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
-
3
-
-
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).
-
Just now, CoffeeDujour said:
Please let us have some generic texture baking calls from LSL too.
Maybe at some point, but we won't be doing any kind of bake API for the initial release.
-
2
-
-
3 hours ago, SoniaVileva said:
Are these "BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR" texture UUID variables that we can access programmatically to apply texture to any wearable mesh ?
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.
-
2
-
1
-
-
16 hours ago, Theresa Tennyson said:
I had heard this but I can't find any official comment on this.
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
-
3
-
-
10 hours ago, Fem Darcy said:
Main suggestion: I think this could be used in a way more useful way developing it a tiny more further.
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 hours ago, Fem Darcy said:
there are 6 textures that will work with bake on mesh (BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR). So, for my understanding only 3 are useful since BAKE_EYES, BAKE_SKIRT, BAKE_HAIR can't add anything on top to bake it, since the only way to add is with tattoo layers, which will only cover BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, . Am I missing something?
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.
-
1
-
2
-
-
15 hours ago, Blush Bravin said:
Will that UUID be the only number shown on the appearance to XML report? If that's correct, I will be breathing one huge sigh of relief.
Although if someone really wants to steal the UUID number all they have to do is wear one item at a time and then get the report. So perhaps not as big a relief as I initially thought.
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.
-
1
-
3
-
-
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.
-
5
-
-
4 hours ago, Sachios Feden said:
Really? I thought BoM is not going to break anything that's already working and certainly not 'putting texture on a face'.
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.
-
6 hours ago, CougEr Vultee said:
at the: "import a mesh into second life", the weights are not available. greyed out.
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.
-
2
-
1
-
-
53 minutes ago, Blush Bravin said:
I may be wrong but I thought I heard Chey request in the last content creators meeting that was live streamed by Medhue that BoM not be released until the API was made available and the applier situation sorted. Again I may have misheard, but I thought Vir said doing so would delay the project.
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.
-
1
-
4
-
-
On 4/21/2018 at 3:12 PM, Chellynne Bailey said:
I have a couple questions about how things are currently stored. Are the attachments we see in appearance stored in one list? Or is what we see actually the compilation of several stored lists? There's been a bit of discussion about the best way to indicate where to put something in the stack, and it'd be nice to know how things are done now.
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.)
-
1
-
4
-
41 minutes ago, Theresa Tennyson said:
Except, of course, that avatar baking is done by dedicated servers
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.
-
2
-
1
-
-
On 4/14/2018 at 8:57 AM, Henri Beauchamp said:
Questions for the implementers:
- Will "bake on mesh" apply to "animesh" attachments ?
- Won't it be better to prevent bake textures on non mesh attachments (for speed optimization purpose and actual usefulness of the feature).
- Will there be some way to disable auto-hiding of avatar parts (I see a corresponding check box in the texture picker code, but it is currently not active and lacks any code for this kind of support). The idea is that you could wear, say, a rigged mesh calico which mesh won't cover the collar part around the neck neither the arms, and won't want the full upper body to get hidden as a result. Or, think of mesh "boobs" that could also use bake on mesh on SL avatars *if* it was possible *not* to hide the upper body part. As for how to implement it, the simplest way would probably be to affect a different pseudo-texture UUID for bakes without auto-hiding (e.g. IMG_USE_BAKED_UPPER_NO_HIDE in excess of IMG_USE_BAKED_UPPER).
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.
-
1
Facebook
Instagram
Twitter
YouTube
Flickr
Bakes On Mesh - Releasing Soon!
in Bakes on Mesh
Posted
Hi Teager,
We are hoping to add BOM support for animesh in the future. Not supported for the initial release.