Vir Linden

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".

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.

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.

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.

Hey folks, It's been great seeing all the comments and questions about Bakes on Mesh. We're looking forward to continuing to work with the community on this feature. A quick reminder, please remember to keep it civil in the forums. It's fine to disagree, even disagree passionately, about this feature or any other topic, but let's keep the discussion focused on those topics rather than engaging in name calling or other types of personal attacks. Thanks!

We haven't specifically added any API for scripting yet. Do you have any thoughts on what you would want from one? It seems like using llSetTexture() with the appropriate special UUIDs might work, but I don't think anyone has tried it yet.

You know, I would have sworn that tattoos did have support for at least 5 texture slots. If you want to file a JIRA for this we can certainly take a look and see how feasible it would be. Normal and specular maps are not so straightforward, as I'm sure you've heard before. Not so much adding the slots, as getting the baking service to handle them, and getting them to render on the system avatar.

Materials support for bakes on mesh has been discussed at the content creators meetings several times. The conclusion is that while this would be a handy feature, it would also turn bakes on mesh into a much larger project. The baking service would have to be modified to understand materials, and we would also have to add support for materials-related textures to the various types of wearables that the baking service works with. Including all that additional work would increase the development time for bakes on mesh substantially. So the plan is to first release bakes on mesh with support for bakes in their current form (diffuse textures only), and then consider materials support as a possible follow-on project.

Our most-weekly content creators meeting will be happening this afternoon at 1:00 PM SLT. Anyone with questions about bakes on mesh is welcome to come by. Schedule can be found at http://wiki.secondlife.com/wiki/Content_Creation_User_Group

1024x1024 support is coming. It requires a change to the baking service, separate from the viewer work for bakes on mesh, so for now you will still see baked textures at a max of 512x512 resolution.

To clarify, a "bakes on mesh" object does not need to be released with modify permissions. The content creator just sets the object to use baked textures *once* at the time of creation. After that, the object can be distributed no-modify, and without disclosing any texture information. Any faces set as "bakes on mesh" will update automatically to show baked textures. Baked textures combine the effects of any avatar wearables you currently have equipped, so this could include (no-mod) items supplied by the original creator, tattoos obtained from other sources, etc, all of which get combined by the baking service. The effect should be that the creator has to give away *less* information, and does not have to make items modifiable, while at the same time giving the purchaser more flexibility in the final appearance. I know that it's a little non-obvious how all of this will work in practice. Would encourage everyone to jump in and give it a try with the project viewer.

Yes you could. The idea is that you're using the same textures that the system avatar would show, which include whatever tattoos or other items you're wearing. Then if you change your tattoos, your avatar would be rebaked, and the "bakes on mesh" object would update automatically. It's a new special setting in the texture picker that doesn't require you to know any texture IDs.

Hi Psistorm, Do you mean the fbx files listed on the Bento Testing page? I believe those are converted from the Mayastar reference models contributed by Cathy Foil - perhaps she can comment on the specifics of those. It may be our documentation on the teeth/jaw area is out of date. This was an area where the joint hierarchy was modified fairly late in development based on testing by content creators. I'll take a look at it. Regarding the issues with joint offsets, I would suggest filing a bug report and including test models and images showing the problem. This would give us the best information for diagnosing what might be going on there.

That's right, existing mesh content should work the same way before or after Bento. If someone wants to support hand motions, facial expressions, wings, tails, etc then they may want to update their content to take advantage of the new Bento bones.

The best documentation on the updated skeleton seems to be here: http://wiki.secondlife.com/wiki/BentoSkeletonGuide although it may need a bit of updating. The current Bento totals are: 133 conventional bones (up from 26), 26 collision volumes (unchanged), 55 attachment points (up from 40)

There is a limit to how many bones a mesh can be rigged to - more than 110 joints will be rejected. This is a per-mesh limit, not a per-file limit, so if you have a model broken down into pieces, the total number of joints rigged to could be higher than 110, as long as no piece exceeds that limit. There is no longer a lower limit - previously you needed to list at least 20 bones even if you weren't using that many, but with Bento you can list as few joints as you are really rigging to. Generally the recommendation is to rig to and list as few joints as possible, because this makes it easier to combine multiple meshes on the same avatar.

Well, bento itself is an extension to the default avatar skeleton, which means that it inherits any existing asymmetries from the default avatar (hopefully without creating any new ones). Supporting multiple skeletons or per-avatar skeletons would be a significant new project - not impossible but not something we currently have scheduled either.

There are some asymmetries in the avatar, both for the bone positions and the attachment points. I doubt that these were deliberate, but at this point we're stuck with them because there's so much existing content based on that behavior. We have tried to make sure all the newly added bento bones and attachment points are symmetrical - if you know of any places where that's not the case, please let us know right away.

This may or may not be relevant for the tools you're working with, but it might be worth mentioning how SL itself handles male vs. female skeletons. The skeleton you see in avatar_skeleton.xml is really the female skeleton when not influenced by any sliders. So how do we get to the male skeleton? It's controlled by a slider in avatar_lad.xml, the slider with id="32", name="Male_Skeleton". It's kind of a pseudo-slider, because you can only set one of two possible values. If the shape editor has female selected, the value of the slider is 0, and no alterations are made to any of the bones it references. If male is selected, then the value of the slider is 1, and the specified scale or offset values are applied to the referenced bones. Now in the case of the pre-mesh system avatar there are also multiple models, so picking male or female will affect the skeleton by way of slider 32, and will also affect which model is used: the male or female base model. In the case of rigged meshes, it's up to the user to pick a mesh that has any appearance of their choosing, but under the hood, the skeleton is still being driven by the same sliders.

Hi Polysail, Well spotted! There's a couple of reasons you might see "0 0 0" entries on the sliders. One is that the "scale" field is required, so a bone that has only an offset defined will always have a "0 0 0" entry for scale as well. If the definition had offset but not scale defined, then that bone would be ignored because it was missing a required field, so it wouldn't work as intended. (We've had a few bugs in the past related to that.) The other reason would be if there's an entry that doesn't actually do anything; if both scale and offset are "0 0 0", then there's no effect on the bone. These could have gotten in there because someone was editing the sliders and was planning for the slider to have an effect on the bone, but then wound up deciding it wasn't needed. We might clean those up at some point. In any case, it should be safe to ignore those do-nothing entries when working on your 3dsmax plugin.

There's been a lot of good discussion here on various alternative approaches to gesture support in outfits. I'm afraid a lot of it is going to be hard to find or keep track of in this forum; if someone wants to file a feature request JIRA, that would make a better home for the discussion, and would give us something to consider as possible post-Bento (or just outside of Bento) work.

Hi Medhue, For good or ill, we have a whole lot of different ways to add things to outfits currently. What specific process would you like to be able to use for adding gestures?

This isn't really a Bento topic, but it came up at yesterday's Bento user group meeting. Question was whether you could include gestures in outfits. The answer is that you can. What seems to work currently is: Drag a gesture into an outfit. This will create a link to the gesture in that outfit. Wear the outfit. The linked gesture will become activated Wear some other outfit. The linked gesture will become inactivated. Dragging into the Current Outfit Folder does not appear to work.

There's an error in the spine bone hierarchy of the male and female FBX files on the Project Bento wiki under "Current Test Content." In the FBX files, mSpine4 does not seem to be linked in sequence between mSpine3 and mChest.  The uploads of the 3DS max versions are correct. 

We have had some discussions in the past about possibly adding the ability to override the scale as well as position for joints in uploaded mesh models. A joint with both position and scale overrides would be effectively "slider-proof" - no sliders that affect the joint would have any effect on the model. This may be useful for content creators who want to control their avatar mesh shape exactly, without being affected by the standard customization options. A proof of concept build for this can be found here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/bento-box-scale-override-proof-of-concept/rev/319431/index.html When you upload a model using this test viewer, under the standard "Include skin weight" and "Include joint positions" check boxes, this build provides an additional check box for "Lock scale if joint position defined". If you check this box, then any joint that has a position defined will also have its scale locked. Scale locking will be enforced whenever a joint would normally be scaled by a slider. To make a bone truly slider-proof, you will have to pay attention to the joint hierarchy. Any change to the scale of a parent bone will also cause the child bone to move, so you will have to make sure the bone's ancestors also have joint positions defined. A joint position will be ignored unless it differs from the bone's default location by at least 0.1 mm (ie, 0.0001 m in the units used by the skeleton definition file). If you want to lock a joint without changing its position, use a very small offset that will not be large enough to have a visual effect (some fraction of a mm). If you get a chance to try this out, please let us know what you think! Any feedback about the design of feature or bugs encountered would be very helpful. Note that this is just a test build to help with discussion of the feature. It may or may not make it into Bento in this form, or any other form.