[Here are the Lindens!]

[Dear LL, or anyone else ... why is it called BENTO?]

At last, the inside story can be revealed! Why did we call it Bento? Err, unfortunately it's not very exciting, but here it is:

When we first started the project, it was being kept under wraps. We didn't want word to get out that we were working on the "Skeleton Extension Project" because we weren't sure how feasible it would actually be to extend the skeleton. We needed a code name so we could talk about the project internally and with a small group of content creators, but we didn't want the name to give anything away in case it leaked out. So I picked Bento as a an internal code name. There wasn't any particular reason for that name, although there was a sushi place near the office that we went to fairly often, so that might have been part of the inspiration. After that the name just stuck, even after it wasn't secret; by the time the feature shipped it had been publicly discussed as Bento for a long time, so we just continued calling it that.

[Outfits Management]

Following up on the discussion of nesting outfits inside folders: I mentioned above that this sort of works. You can make folders and store outfits inside them. However, it's not supported as well as it should be - there are are places where the UI gets into a strange state when you have nested folders, and possibly other issues we haven't identified yet. Ansariel's note above probably identifies part of the problem. We will be working on fixing these issues as we identify them.

The question of whether/how to allow for "partial outfits" like collections of hud-related content, or nesting things inside a given outfit, is a separate topic for future discussion.

[Outfits Management]

If you have an outfit folder that contains links to the items (which is the way it should normally work), then you can change the ordering of items within the outfit. This is in the edit outfit floater - in the Second Life viewer, you can right click yourself and pick "edit my outfit". Inside that floater, you see a list of worn items. If you hover over an item that can be reordered, there will be arrows next to it. Click the arrows to move the item up or down within the stack. (Details are probably different for Firestorm)

Reordering only applies to items of the same type, so you can change the ordering of different tattoos, but ordering between different item types is fixed - for example, shirts will always appear over tattoos.

[Outfits Management]

16 hours ago, Ansariel Hiller said:

the option to create normal folders underneath the (My) Outfits folder is actually wrong - the correct option would be "New Outfit" instead of "New Folder" here, which is the case in current Firestorm release

I don't think that really matches the intent of outfits. A high level container for outfits is not itself an outfit. For example, if you want to group together all your formalwear, you could create a Formalwear folder, and put your tuxedo outfit, and your spangly dress outfit, under the Formalwear folder. Formalwear should not be an outfit, because you would never wear it; you would only wear one of its children, which are actual outfits.

[Outfits Management]

I think you're right, Outfits and My Outfits are probably the same thing. Could you try with the default SL viewer and see if it works for you there? Can grab the viewer at https://secondlife.com/support/downloads/

[Outfits Management]

Could you give me details on what specific steps are not working for you? I'm testing with the SL default viewer, and can do:

• Right click on My Outfits, pick "New Folder". This makes a new non-outfit folder that can be used for grouping
• Drag an existing outfit into that new folder
• Right click that new outfit and pick "replace current outfit"

Is that enough to be able to manage groups of outfits? It's possible that these are more recent changes that have not been brought into Firestorm yet - if the issue only exists in Firestorm you would need to check with them.

[What is the .anim format?]

Sorry, it's a little confusing. anim isn't really a file format; it's just a binary dump of what the viewer uploads when it's creating a new animation. With bvh, you start with a file format and specify various options, and the combination of all that animation + option info gets sent up to create an animation. A .anim file is roughly equivalent to taking all the animation data out of a bvh, and then adding all of the various options chosen in the bvh floater - so you're bypassing the preview and option selection stages and skipping straight to upload. I say "roughly" equivalent because the bvh uploader also tries to do some optimizations on the uploaded animations, which using .anim skips.

It would probably make sense to allow the preview and option selection stages to be done for .anim as well, using the options specified in the selected .anim as the starting values. A possible feature for another time...

[EEP Finally Out!]

There are a couple of different issues here:

- The dark ambient on mainland is caused by an environment setting that's actually stored for each region. At one point the default setting had too-dark ambient lighting (which has since been fixed) and the mainland regions had their environment information set during that time. Unfortunately there isn't any simple way to change these settings for all the mainland regions. We are looking into options but the situation is likely to persist for a while.

- The mesh shininess issue is being worked on now, and we will get a fix out in a viewer as soon as we can. Hopefully this one can be resolved more quickly.

 

[Appearance Mode Texture bug]

The wiki article (actually knowledgebase in this case) is at https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/

 

[Universal Wearable, Left Arm/Leg, Tattoos, and Skinners]

On 11/7/2019 at 7:50 AM, Digit Gears said:

Personally, I kind of wonder just how old those viewers in question are, and how many people would it effect if they went with it anyways

Unfortunately, it affected everyone. The viewer was not originally written with the possibility in mind that new channels would be added to existing wearable types. I believe we've changed things so that this may be possible in the future (assuming a viewer based on the BOM codebase)

[Bakes on Mesh Feedback Thread]

On 10/8/2019 at 8:46 AM, Baldi McMillan said:

since the new BOM feature my once 0 complexity avatar is now showing a complexity of 1,000

This is a bug. We charge a complexity cost for active (non-invisible) channels on the system avatar, 200 per channel. With BOM we added 5 new channels but the logic for determining whether those channels are "visible" on the system avatar is not right. In fact those channels are never visible on the system avatar because the avatar doesn't even use those channels. So we wind up overcharging by 5x200 = 1000. I have a fix for this in the muscadine project viewer.

[Bakes on Mesh Feedback Thread]

Bloodsong, re: your questions:

1. You can set faces to use baked textures without using a script. Edit the object and go into the texture picker, then pick "Bake" and select which baked texture you want using the dropdown.

2. We've had a lot of requests for Bakes on Animesh, and it is a possible future project.

For more info about Bakes on Mesh, you may also want to check out the knowledgebase article:

 

[Bakes On Mesh - Releasing Soon!]

4 hours ago, Ai Austin said:

I wonder if you can get whoever looks after the Wiki to update the UUIDs for the BAKES channels/fallback textures to the up to date ones... and add the extra 5 added BAKES?

We'll take a look at that, thanks!

[Bakes on Mesh Feedback Thread]

57 minutes ago, Kitsune Shan said:

And it goes between the tattoo and the body layers.

Body layers isn't a very clear description, I'll see if we can tweak the wording there. As we've talked about in the forum, universals go right above tattoos and below other clothing.

We are planning to add more documentation about the clothing/outfit system in general too, since that hasn't gotten much coverage recently.

[Bakes On Mesh - Releasing Soon!]

On 8/30/2019 at 3:04 PM, Henri Beauchamp said:

There is a feature I already wrote about on this forum (it was last year, in the initial thread about BoM), that I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar.

Henri,

I think this is a good idea, and I've added it to our list of possible work for a Bakes on Mesh follow-on project.

We strongly encourage folks with these kinds of suggestions to file a JIRA about them; this gives the best chance of having the feature worked on. We will look through existing JIRAs when planning new projects, but it's much easier for us to miss something that's mentioned in a forum thread.

 

[Bakes On Mesh - Releasing Soon!]

On 9/2/2019 at 4:24 AM, Ai Austin said:

can you point us at the JIRA number?

It doesn't look like there's a public-facing (BUG-) JIRA for this. Two different ones filed by Lindens at different times, both in the SL- project.

[Bakes on Mesh Feedback Thread]

On 8/31/2019 at 12:38 PM, Thornotter said:

Anyone know if Linden Labs is planning a follow-up release to Bakes on Mesh that adds material support?

Material support for BOM is on our list for possible work for a follow-on project. We have no immediate plans to tackle it though.

[Bakes On Mesh - Releasing Soon!]

46 minutes ago, Ai Austin said:

Vir, I understand what you say, but the difference in behaviour I think is a bug.

I agree it's a bug, not sure what the right fix is.The standard behavior for BOM is that attached objects that use a given channel will cause the corresponding body region to be hidden. Standard behavior for HUD-attached objects is that other viewers don't know about them. We could change it so the avatar-hiding is not done for HUD-attached objects, which would make the behavior more consistent. Or we could discourage people from attaching rigged meshes to HUD attachments at all. Or some combination of those.

[Bakes On Mesh - Releasing Soon!]

On 8/27/2019 at 5:04 AM, Ai Austin said:

Can you enable the bakes radio button to apply one of the BOM textures to faces of objects in normal build mode , not actually attached at the time.

We are planning to change this in a future release, so you can flag non-attached objects as BOM.

[Bakes on Mesh Feedback Thread]

53 minutes ago, Babette Ultsch said:

i am not sure if this is the right place anymore but i am having trouble using the bake on mesh skirt texture.

Hi Babette.

There is some weirdness and bugs around how we handle skirt textures with Bakes on Mesh, and with how we handle skirts in general. We have some related issues on the "things to fix" list.

[Bakes On Mesh - Releasing Soon!]

Objects attached to HUD attachment points are only visible to yourself. This was originally by design - it's your HUD, why would anyone else see it? - but when the "HUD" object is a rigged mesh that displays on your avatar, the behavior probably isn't what most people would expect. We have a JIRA to look into this, probably by warning people when they add such attachments.

[Bakes on Mesh Feedback Thread]

2 hours ago, Gael Streeter said:

Thank you Vir for the answer.
So this means an Universal should NOT BE USED FOR SKINS (or other plain textures) or it will overwrite all the worn Tattoos (and Skin) below...

"for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets."
This order is very important to know (for creators and customers), I think. Is it possible to have it fully write down in the knowledge base ?

An exception would be for new channels. The only way to add textures to the new channels currently is using universals, so you might put opaque textures on the lowest universal in the stack, then transparent ones higher up.

I'll take a look at the docs. It's likely that wearable ordering is covered somewhere, since they've been around forever, but we don't really explain them in the BOM docs.

[How does BoM (and Omega) handle UV mapping?]

As Theresa says, baking doesn't really know anything about UV maps. You could think of it as just sticking images one on top of another like a stack of  pancakes. As long as all the images have the *same* UV map, things will work fine. If the images are intended to fit different UV maps, you could wind up with graphical inconsistencies. So in the most common case, all the textures in your various wearables will be using the standard avatar UV map, or something close to it, and that will work fine. But if you had an avatar for a snake that used a completely different UV map, you could make compatible tattoos or clothing for the snake as long as they all used the same UV map as the model was designed for. Whether snakes should have tattoos or clothing is a separate question...

[Bakes on Mesh Feedback Thread]

9 hours ago, Gael Streeter said:

I just made some tests with the new Universal, notably on the HEAD TATTOO slot and it seems the UNIVERSAL is always ABOVE the other SKIN or TATTOO clothes without taking into account the wearing order.
Is it normal ? Why is it so ? Is it a bug ?

That is normal. Between the various wearable types, there is a standard order - for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets. The ordering tool lets you change the ordering of wearables of the same type - say, put one universal over another - but does not let you override the ordering of wearables of different types - say, to put universals above jackets or below tattoos.