Jump to content
Medhue Simoni

LL Announced a Project to BAKE Textures on Meshes

Recommended Posts

10 minutes ago, Theresa Tennyson said:

Show me where I ever said that clothing layers wouldn't be used. I said at least twice that they still are useful. They'll be a lot less of an issue when they're two faces rather than being dozens of faces. And when layers for clothing are still used all your complaints about materials not being bakeable are invalid. I did mention that baking on clothing would be a possibility, but that would strictly be for low-impact layering purposes.

So if a mesh body has clothing layers attached to it, those would be either additional faces or alternatively part of the same linkset as the mesh body, which then raises the question of how are we going to be able to specify which faces/parts of the linkset the clothing layers we wear will be applied to, unless you want freckles and tattoos on your shirts and jackets as well as your skin?!

 

16 minutes ago, Theresa Tennyson said:

In Second Life, materials are a completely separate thing. With most animals, the texture of their fur or scales is independent of their coloration. For instance, a horse's hair will generally have the same texture whether or not it has a blaze or pinto spots. Right now the Waterhorse rideable horse needs a separate layer for spots and blazes. With the ability to use baked diffuse textures that would be unnecessary, while the separate hair specular and normal layers don't even need to know that they are there.

I've already explained to you in this thread why that assertion is wrong, normal maps may be unaffected by colors in the diffuse map, but the same cannot be said for specular maps!

Share this post


Link to post
Share on other sites
2 minutes ago, Fluffy Sharkfin said:

So if a mesh body has clothing layers attached to it, those would be either additional faces or alternatively part of the same linkset as the mesh body, which then raises the question of how are we going to be able to specify which faces/parts of the linkset the clothing layers we wear will be applied to, unless you want freckles and tattoos on your shirts and jackets as well as your skin?!

 

The baking service creates a texture. Freckles and tattoos are never seen in the world as independent things. The texture that is created would be applied to a mesh just the same way as any other texture is applied to it. This is also why your idea of unlocking and tiling textures going into the bake won't be a significant improvement in performance - those tiled textures would never be seen by anyone else in-world, only the completed bake.

Share this post


Link to post
Share on other sites
On 5/27/2017 at 6:58 AM, Penny Patton said:

I wish I'd made it to that meeting. I'd have a lot to add to the comments at the beginning of the video about how adding bones would impact performance. They're not entirely incorrect, but I always find it agitating that people are willing to write off the addition of new features for fear of how it will impact performance, when the bulk of the SL community seems so adamantly against addressing the issues that are actually dragging down performance right now.

Textures, draw weight, and the general problem of unoptimized content. I'm not sure we need new bones or more attachment points, but whenever someone says we can't have a new feature because of the impact on performance it raises my hackles. Let's seriously address the performance issues we have now then we can talk about what features are or are not feasible due to their impact.

 

 Anyway, don't mean to derail too much. baked textures for mesh will be fantastic, if LL includes the ability to bake materials. Otherwise, people will either just not use the baking feature, or you can say bye-bye to materials on mesh bodies. Neither of which is an acceptable outcome.

That was your very first post in this thread. You said nothing about onion layers and lag.

I said that many people are phasing out their use of layered clothing because of what I've seen in the market. (In fact, the Belezza Light bodies don't have layers other than the tattoo layer.) I never said that  they won't be an option for use by the remaining people who have a use for them though.

Share this post


Link to post
Share on other sites
41 minutes ago, Theresa Tennyson said:

The baking service creates a texture. Freckles and tattoos are never seen in the world as independent things. The texture that is created would be applied to a mesh just the same way as any other texture is applied to it. This is also why your idea of unlocking and tiling textures going into the bake won't be a significant improvement in performance - those tiled textures would never be seen by anyone else in-world, only the completed bake.

I'm curious as to how you envisage these textures being selected for baking.  Currently for system avatars it's based on what clothing layers (i.e. the asset type clothing layers in inventory, not the mesh onion skin thing) we wear, but I just don't see that working for mesh bodies because there HAS to be some way to apply these to select faces rather than the entire object.  The UUID for the baked texture would have to be accessible via script in order for it to be applied, creators won't simply be able to provide a "layer" asset with mesh items that a user can wear and magically have it applied to the correct faces of the correct attachment.

Share this post


Link to post
Share on other sites
20 hours ago, Penny Patton said:

 Like Fluff tried to explain to Theresa, the whole entire point of this feature is to make it so people stop making onion-skin avatars, which both add an extra layer of complication to mesh avatars, and are obscenely inefficient for rendering. You want to talk about things that hurt framerates, there's a big one right there.

 

Okay, I found it.

Thing is, you were the one who declared that the point of this feature was to remove all layers. And it's a straw-man argument.

If you don't need a complicated alpha-cut system the clothing layer can even be completely separate object - that's how Chip Midnight made his mesh avatar in the early days of fitted mesh.

Share this post


Link to post
Share on other sites
31 minutes ago, Fluffy Sharkfin said:

I'm curious as to how you envisage these textures being selected for baking.  Currently for system avatars it's based on what clothing layers (i.e. the asset type clothing layers in inventory, not the mesh onion skin thing) we wear, but I just don't see that working for mesh bodies because there HAS to be some way to apply these to select faces rather than the entire object.  The UUID for the baked texture would have to be accessible via script in order for it to be applied, creators won't simply be able to provide a "layer" asset with mesh items that a user can wear and magically have it applied to the correct faces of the correct attachment.

Okay...

Let's start over.

All this project is intended to do is to take the three composite textures that the baking service creates when you bake your system avatar layers and to make them available to mesh avatars. To do this, the plan is to allow the default avatar to be blanked out using a system other than full body worn system alphas, and to increase the bake result to 1024 x 1024 to match the standard used by mesh bodies.

The components of these baked files will remain the standard system skin, tattoo and selective alpha wearables and possibly clothing wearables, although trying to use this for worn clothing will cause issues that have already been beaten like a pinata throughout this thread. They will be ordered in the viewer exactly the way system avatars are dressed now.

These composite textures are already assigned UUID's and information is included that currently tells the viewer to apply them to the system mesh. The system will be changed so that the viewer will be able to apply them to a mesh object instead of the avatar mesh. These textures could be routed to the appropriate faces of the mesh the same way applier systems do now.

Doing this will allow skin appliers, tattoo "onion" layers and alpha cuts to be retired. It will not be a good replacement for "onion" clothing layers. Any clothing layers for the mesh avatar could be textured by appliers, exactly how they're done currently. There is no plan to create any type of clothing-only bake that I know of.

Edited by Theresa Tennyson
Planted onions.

Share this post


Link to post
Share on other sites
1 hour ago, Theresa Tennyson said:

These composite textures are already assigned UUID's and information is included that currently tells the viewer to apply them to the system mesh. The system will be changed so that the viewer will be able to apply them to a mesh object instead of the avatar mesh. These textures could be routed to the appropriate faces of the mesh the same way applier systems do now.

The rest of your post made sense, but this part seems a little vague?  The viewer will be able to apply the baked texture to a mesh object instead of the avatar mesh, and will be able to route it to the appropriate faces of the mesh the same way applier systems do now... but who tells the viewer which faces are the appropriate ones? Are they going to present the user with a list of faces 0-7 and let them guess which one, or will the information about which faces to apply the baked texture to be somehow embedded in the system avatar layers that the user wears?

I think the idea of getting rid of multiple faces for alpha cuts and reducing the use of onion skinned meshes for tattoo layers etc is great and hopefully creators of mesh bodies will adopt the feature and change the way they make their bodies accordingly.  Having clothing layers for mesh bodies as a separate attachment would not only solve the issue of having to select which faces a baked texture is applied to but would also give us an easy way to reduce the number of excess polygons we wear, so that's also great.  However if their intention is to extend this to other types of mesh items (which seemed to be the case based on what was said at previous meetings) then they'll need to support things like linksets and multiple faces and in order to do that I think they're going to have to come up with something a lot more complex than what you're suggesting.

Edited by Fluffy Sharkfin
typo

Share this post


Link to post
Share on other sites
1 hour ago, Fluffy Sharkfin said:

The rest of your post made sense, but this part seems a little vague?  The viewer will be able to apply the baked texture to a mesh object instead of the avatar mesh, and will be able to route it to the appropriate faces of the mesh the same way applier systems do now... but who tells the viewer which faces are the appropriate ones? Are they going to present the user with a list of faces 0-7 and let them guess which one, or will the information about which faces to apply the baked texture to be somehow embedded in the system avatar layers that the user wears?

 

I can think of two ways - there may be more, I'm not really an expert in this.

One way would to have "placeholder" textures on the object that the viewer would automatically replace with its owner's appropriate latest bake. This would be the most similar thing to how system bodies work now but would require everyone's viewer to be updated, and would have little use for non-avatar applications.

The other way would be to have an applier-like object that would manually send the baked texture to pre-configured faces when clicked. The texture would then be treated like any other texture and be part of that object until deliberately updated. This would have the most compatibility with old viewers and be most useful for non-avatar applications but raises permissions issues. If this could be done the texture probably will have to be no-modify and no-transfer automatically - I don't know if there's any way for a baked texture to inherit permissions from its component parts.

  • Like 1

Share this post


Link to post
Share on other sites
14 hours ago, Theresa Tennyson said:

I can think of two ways - there may be more, I'm not really an expert in this.

One way would to have "placeholder" textures on the object that the viewer would automatically replace with its owner's appropriate latest bake. This would be the most similar thing to how system bodies work now but would require everyone's viewer to be updated, and would have little use for non-avatar applications.

The other way would be to have an applier-like object that would manually send the baked texture to pre-configured faces when clicked. The texture would then be treated like any other texture and be part of that object until deliberately updated. This would have the most compatibility with old viewers and be most useful for non-avatar applications but raises permissions issues. If this could be done the texture probably will have to be no-modify and no-transfer automatically - I don't know if there's any way for a baked texture to inherit permissions from its component parts.

I think the placeholder texture option would probably be ideal given the limited scope of what they're trying to accomplish with this feature,  I can even see it getting some limited use on other attached objects, despite the lack of material support.  

Honestly, on reflection, while I'd love to see some sort of support for layered textures in SL I wouldn't want to see them try and extend this feature much further than what they're already trying to accomplish simply because the use of wearable system avatar layers doesn't make nearly as much sense when applied to non-attached objects.  Of course it would be nice if they could find some way to support materials with this, but if they can't then the fact it will provide a way to composite wearable "alpha layers" and apply them to mesh bodies is still a notable improvement on what we currently have.

Share this post


Link to post
Share on other sites

So, how does this affect non SLuv mesh bodies? The Aesthetic body does not use the standard SLuv for its skin. Nor do many anthro ones.  

 

Share this post


Link to post
Share on other sites

So, from what i got out of that video, this will change how layers apply to third party mesh bodies? IE, Slink, Belleza, Maitreya and the rest? IS LL going to ask them to change their meshes or just hack them? I mean, it DOES say they own everything in SL so i suppose they can do what they like. Sounds shady to me. 

also, whoever the woman was in the beginning was talking about limiting things so low end computers can still run SL and then Vic jumps in with allowing 1024s to be applied to mesh?!? Yeah, that will help low end PCs run things better. 

Share this post


Link to post
Share on other sites
57 minutes ago, Drake1 Nightfire said:

So, how does this affect non SLuv mesh bodies? The Aesthetic body does not use the standard SLuv for its skin. Nor do many anthro ones.  

 

It could be used for them if people make skins using those UV maps. The baking system just makes a texture - it doesn't care about the UV map.

Share this post


Link to post
Share on other sites
57 minutes ago, Drake1 Nightfire said:

So, from what i got out of that video, this will change how layers apply to third party mesh bodies? IE, Slink, Belleza, Maitreya and the rest? IS LL going to ask them to change their meshes or just hack them? I mean, it DOES say they own everything in SL so i suppose they can do what they like. Sounds shady to me. 

 

The mesh makers won't have to do anything, just like they didn't have to rig their hands to Bento.

57 minutes ago, Drake1 Nightfire said:

 

also, whoever the woman was in the beginning was talking about limiting things so low end computers can still run SL and then Vic jumps in with allowing 1024s to be applied to mesh?!? Yeah, that will help low end PCs run things better. 

Does someone want to tell him? Okay, I will...

Mesh bodies already use 1024 textures.That's why they're increasing the limit of the baking engine - to give an equivalent resolution to what's being used now. Baking will allow what now is multiple 1024's to be combined into a single texture.

I did a little experiment. I set up a controlled test using a few mesh bodies. I compared a demo for Chip Midnight's CMFF body, which was designed to use alpha layers, to a couple of typical mesh bodies with toggled alpha cuts. The CMFF body is a single prim (not land impact, but a single mesh entity.) The Slink Physique is made up of 67 separate meshes, Tonic Curvy is 71 and the Maitreya Lara demo is 118. (Those three are without hands and feet, by the way.)

The CMFF body isn't an extremely low-poly body - in fact its draw weight and the number of actual polygons drawn per frame is higher than for the more typical bodies. However, framerate with only it in view is still a good 10% higher than for the others.

 

Edited by Theresa Tennyson

Share this post


Link to post
Share on other sites

When I see any new feature announced by LL I ask several questions which include:

  • What is the purpose/focus of this feature.
  • How well does what LL is doing accomplish that goal?
  • Is LL accomplishing this in an intuitive, user-friendly way? If not, are there better alternatives?
  • Is LL missing an opportunity to address an existing SL problem?

A few weeks back I was at a content  creation Office Hour where this feature was discussed and it really seemed to me, based on comments made during that meeting, that the purpose of this feature is to address the performance impact of onion-skin mesh avatars. Like Theresa points out, mesh bodies already tend to use 1024x1024 textures, and those textures tend to be spread across at least four layers, each layer being a complete body mesh model so we're getting far more polygons on top of the additional texture load.

 This also contributes to draw weight, which LL has been trying to reign in with the introduction of the "Jelly Dolls" draw weight cap.

 Not taking that extra step to support materials means that we're left with a feature that can only be used to combine skins with tattoo layer textures, and only those tattoo layer textures which won't look off combined with the base body materials. In short, this will work fine for tattoos, freckles, blush and most makeup, somewhat less so for dirt, shading enhancers and scars, and not at all for blending skins with textures such as fur, scales, etcetera. Clothing is also obviously out.

 Like I said before, this is clearly better than nothing. It adds new functionality and that's great. It will potentially help, a little, towards the performance issue by allowing people to bake multiple textures together so you can combine makeup with blush and freckles into a single texture along with the base skin.

However, and the reason I say it will only potentially help performance, since some tattoo layer textures will not work with this, one of two things will happen. Either mesh body makers, oblivious to this problem, will ditch their tattoo layers altogether and diminish people's ability to customize their appearance, or they will keep the tattoo layer, including its default textures,  in addition to the baking features meaning mesh bodies won't see any optimization benefit at all.

 That is why I take issue with not including materials support, which would allow us to do away with onion-skin avatars entirely. I hope we can all agree that unoptimized, inefficient content is a huge problem, arguably the biggest problem, facing SL and one of LL's biggest obstacles in making SL more appealing and profitable. If so you should be able to at least understand where I'm coming from on this.

Share this post


Link to post
Share on other sites
30 minutes ago, Penny Patton said:

 That is why I take issue with not including materials support, which would allow us to do away with onion-skin avatars entirely. I hope we can all agree that unoptimized, inefficient content is a huge problem, arguably the biggest problem, facing SL and one of LL's biggest obstacles in making SL more appealing and profitable. If so you should be able to at least understand where I'm coming from on this.

Then come up with a flow process for materials baking. You don't have to write the code, just the process.

Are you going to add materials channels to all the existing wearables? Of course, the vast majority of them will be legacy items and have nothing in these channels when the person wears them. What's going to happen? If there's no specular, will it be ignored, or will it be flat and use the diffuse texture as a mask? If it's ignored the skin specular will shine through clothing, and if it's masked tattoos will look flat against shiny skin. Will you have a toggle that the user will have to set? What if the wearable is no-modify?

Now normal maps - again, most things won't have anything here. Will you give clothing with no normal map an arbitrary thickness so that it will actually look like clothing? What happens when they're layered? What happens when an item that already has a normal map is layered on top of something else? What happens when something thin and smooth is layered over something bumpy? With real clothing some fabrics will telegraph the bumps and some won't. What will the layers do?

Or are you going to get around this by creating new wearables? Does this mean people then can't wear their old items with the new ones? How will you stop them?

It's quite a bit of work. And then you have to hope that the people you've put all this work in for have advanced lighting on, are near an appropriate light source and don't think it looks hopelessly cheesy, because much of it simply won't look like clothing whatever you do.

Share this post


Link to post
Share on other sites
6 minutes ago, Theresa Tennyson said:

Then come up with a flow process for materials baking. You don't have to write the code, just the process.

Do you see how my avatar's last name isn't "Linden"? I don't have to do any of LL's work for them. 

That said, I get where you're coming from, that it's more helpful to make detailed suggestions than just point out the problem. Fair enough. I think we've already established that I'm very happy to share ideas, thoughts, suggestions, and potential solutions to problems. If me from 12 years ago was sitting here, hell even me from 7 years ago, my second post in this thread would probably have been a full blown design doc on how the process for materials baking could work, probably including mockups for the UI.

But I've been here for 12 years. I know how this goes. If LL has already decided how they're going to proceed I know that someone could code the viewer with the feature fully developed and ready to ship and LL would probably still ignore it. If LL does change their mind, it's not going to be for several years. THEN they'll start looking at what the community has already done.

 Even with all that, if you honestly want to discuss how such a system would work, and you didn't post all of that just to point to and say "See? Look at all these things that would have to be figured out! That's way too much work!", then alright, I do have some thoughts and I do enjoy talking about these kinds of problems. For example, if the system is using actual system clothing layers then yes I'd add channels for the materials and a toggle for whether or not the clothing item would bake with materials or simply use the materials for the layer beneath. If no material is used I'd have the item default to bake blank, matte materials by default (rendering how non-material surfaces look now) and this is how existing system clothes would work by default with the option to add materials or change the toggle so long as the item is modifiable. This preserves the legacy content in the state it already existed. If the item is no-mod it would use the default and if that doesn't work for that clothing item, well this is just one of many reasons why you shouldn't buy no-mod. You cannot future-proof something that cannot be modified later. Nothing new there.

And yes, all of this would take work. The real question is "would this succeed in making SL less resource intensive and easier to use?" I think the answer is yes for both, with the caveat that there are of course many other issues LL needs to address when it comes to how content impacts performance. You have to start somewhere.

Share this post


Link to post
Share on other sites

Well, that's a start. It'll work well enough for the specular map, although I would have suggested setting the defaults to be transparent for tattoos and matte solid for clothing because of how they're used.

Now... normal maps?

Share this post


Link to post
Share on other sites
On ‎5‎/‎29‎/‎2017 at 0:40 PM, Fluffy Sharkfin said:

Yes I caught the overall tone of your post but opted to ignore the snark since I assume it's a product of some weird sort of virtual world Stockholm Syndrome.  I really can't think of any other possible reason for someone to suggest that it's the customers job to do the work of those employed by the company whom they're paying to provide a service!?  Or are you suggesting that the continued viability and growth of SL as a platform is purely of benefit to its users and in no way is LL profiting from its existence?

LL is doing the work, just not the work people like yourself want. Personally, I see no need, AT ALL, to include materials in the baking system. Theresa is just pointing out, that you don't have to except this, and you are perfectly welcome to try and make it happen, whether by writing the code yourself, or coming to the meeting and pleading your case.

Again tho, personally, I have no need at all to ask LL to include materials, as there is nothing stopping me from adding the dang materials myself.

Share this post


Link to post
Share on other sites
On 6/1/2017 at 4:10 PM, Medhue Simoni said:

Personally, I see no need, AT ALL, to include materials in the baking system.

As far as I'm concerned LL should leap on any opportunity to encourage better optimized content because it is, in my view, one of the three biggest problems that is hurting SL's ability to draw in and retain users. (The others being the lack of tools to create more interactive/engaging content, and the perceived cost of land.) Not including materials support for this feature entirely negates its potential to allow users to create better optimized content/avatars and since LL flat out refuses to update the system avatars they're actively pushing their entire userbase towards using framerate killing content.

THAT is why I see a need for this feature to include materials support.

Share this post


Link to post
Share on other sites
On ‎6‎/‎6‎/‎2017 at 8:49 PM, Penny Patton said:

As far as I'm concerned LL should leap on any opportunity to encourage better optimized content because it is, in my view, one of the three biggest problems that is hurting SL's ability to draw in and retain users. (The others being the lack of tools to create more interactive/engaging content, and the perceived cost of land.) Not including materials support for this feature entirely negates its potential to allow users to create better optimized content/avatars and since LL flat out refuses to update the system avatars they're actively pushing their entire userbase towards using framerate killing content.

THAT is why I see a need for this feature to include materials support.

Well, the reason I'm not for this, is because the current baking system doesn't do this now. It's 1 thing to get the current system to work on meshes, but it's a whole other project to get materials into the baking system. It would add another whole level of complexity to it all. And.... it would likely double or triple the development time, as well as introduce many more bugs to the whole system.

Now, after the baking project has accomplished it's stated goal, then LL could create a NEW project to accomplish adding materials to it.

  • Like 1

Share this post


Link to post
Share on other sites

 

On 5/31/2017 at 8:31 AM, Theresa Tennyson said:
  On 5/31/2017 at 7:33 AM, Drake1 Nightfire said:

So, how does this affect non SLuv mesh bodies? The Aesthetic body does not use the standard SLuv for its skin. Nor do many anthro ones.  

 

On 5/31/2017 at 8:31 AM, Theresa Tennyson said:

It could be used for them if people make skins using those UV maps. The baking system just makes a texture - it doesn't care about the UV map.

So, correct me if i am wrong and i know you will, but doesn't the Omega system already do this? Wouldn't this feature put them out of business? That's rather ruthless for a company, isn't it? 

Share this post


Link to post
Share on other sites
29 minutes ago, Drake1 Nightfire said:

So, correct me if i am wrong and i know you will, but doesn't the Omega system already do this?

No it doesn't. Omega is a standardized texture applier system for mesh bodies and body parts and only does the same job as product specific appliers do, the only difference is that an Omega applier works with lots of different brands, not just one.

  • Like 1

Share this post


Link to post
Share on other sites
16 minutes ago, Drake1 Nightfire said:

So, correct me if i am wrong and i know you will, but doesn't the Omega system already do this? Wouldn't this feature put them out of business? That's rather ruthless for a company, isn't it? 

Omega can't combine multiple textures into a single one. This means that there needs to be a separate mesh layer for every texture, and it quickly becomes a hot mess if more than one layer is alpha-blended. There's also currently no way for a mesh body to have an alpha mask applied to the skin texture so the body needs to be divided up into many separate patches that need to be turned on and off.

The Omega people are pretty sharp cookies and will probably find other niches to fill - there are a variety of other items that their knowledge of secure channels would be useful for.

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...