Jump to content

Create BOM assets by "unbaking" an applied avatar layer


Qie Niangao
 Share

You are about to reply to a thread that has been inactive for 1508 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Skin and other applier merchants have now had two years to plan and generate Bakes-On-Mesh variants of their products. We've all waited long enough to get the many benefits of BOM. The Lab, too, has been more than patient: by now, BOM should have reduced avatar rendering lag that drives away many new users in frustration; instead, the dearth of BOM assets has slowed adoption. The Lab is just not getting what they paid for with the investment of developer resources, even though the result is a tremendous technical success.

Compared to the many intricate changes necessary to develop BOM, an almost trivial to build functionality would automatically create a choice of system layers from the texture applied to an attachment layer. Obviously, illicit "copybot" viewers can do this, but why not the Linden viewer? Can anybody argue with a straight face that such a functionality would meaningfully infringe anybody's (theoretical) copyright?

Note that any such "violation" would be purely theoretical; the Terms of Service make everything in Second Life eligible for use within the service in any way the Lab chooses. They have adopted a policy of preserving the DRM of the permissions system (such as it is), but there's no legal requirement for them to do so. And anyway, I don't think this would violate that DRM in any but the strangest hypothetical edge-cases, if any.

To be concrete about how it could work, the feature would accept user input about which mesh surface of which wearable is to be converted to which system asset. It merely pulls the diffusemap texture UUID from that surface and uses it to create a fresh system asset (skin, tattoo, underwear, etc) with Copy/Mod/No-Transfer permissions. Obviously the UI would be a pain, although mesh avatar and head creators could make it much easier for their customers by providing an applier target (no need for a corresponding mesh) that invokes the "unbaking" feature and delivers the corresponding asset whenever an applier paints a texture on a "layer" of that target. We just need such a feature for them to invoke.

(The "unbaking" term might be misleading; it has nothing to do with the baking service. Instead it would be simple repackaging of existing textures into new assets.)

Is there any meaningful downside to this?

  • Like 2
  • Haha 1
Link to comment
Share on other sites

Yes.

Creating such a system layer would make it a system layer created by you, not by the original creator of the texture. It would also be  a full-perm system layer, as is normal with assets created by you.

This would circumvent whatever permissions the original creator intended, which are usually no-transfer.

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Good point. That would be true of assets created by a copybot viewer, but that's not the proposed feature. 

As for perms, as I said, the feature would always produce Copy/Mod/No-Transfer assets, which much match nearly(?) all the applier results. (I'm not sure about Mod; it seems like that makes the system layers more like the result of applier textures once painted on an attached mesh, but... not quite sure it's necessary.)

The creator thing is trickier, and it's why this couldn't be a purely viewer-side feature. If we adopted the "applier target" approach, the applier's creator could become the creator of the system layer asset; I don't want to constrain implementation details, but one might imagine the process to copy the applier asset itself, changing its asset class to the target system layer (skin, say) while overwriting the contents with the applied texture UUID.

I guess some texture-based creators might find that unusual, becoming the creator of something you didn't explicitly create. I mean, this happens to scripters all the time so it just doesn't matter to us anymore. And of course it would happen to Mod-perm prim builds, too, but I guess texture-based creators don't see it happen much... although that's not true either, now that I think about it. Anyway, I'm not seeing any practical reason to care about that.

 

Edited by Qie Niangao
  • Like 1
  • Haha 1
Link to comment
Share on other sites

I think it should be up to the creator to decide what happens to assets they created. If they choose not to go with the flow and don't create BOM compliant items that should be their decision and the market will determine how they respond to that. So i don't agree with the user or Linden Lab making this decision for them.

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

   Because there was never any kind of enforced creation standard for wearables, there are probably many of them out there that use a custom texture/UV scheme completely incompatible with BoM. This would create a lot of confusion and complaining (nothing new), when put into use. The average users may not know, or will be unable to discern whether texture layer X on wearable A is going to work on New Body Part layer B.

   Concerning making permissions requests of each creator, there are a lot of them, many of them having probably left SL and no longer active. This would entail a bureaucratic process beyond the capacity of Linden Lab employee hours. And realistically, this should be an all or nothing affair. As Qie pointed out, LL can do what they want, which is something to which every user agrees when they sign up. 

Link to comment
Share on other sites

1 hour ago, Ivanova Shostakovich said:

   Because there was never any kind of enforced creation standard for wearables, there are probably many of them out there that use a custom texture/UV scheme completely incompatible with BoM. 

For different creators' meshes on which the same (Omega) appliers can be used, wouldn't they necessarily share the same UV maps? Aren't they all basically identical to the old "classic" system avatar UV maps?

Among my alts I have three "mainstream" mesh bodies (Slink male, Signature Gianni, and Belleza Jake); before they had their own BoM meshes (Belleza still doesn't) I used a homegrown Omega applier to paint them with the system BoM-keying textures on the skin layer. They looked fine to me, wearing old-time classic avatar system skins.

Maybe head meshes aren't as standard? Dunno.

Incidentally, here's something I stumbled on that may be useful to other BoM fans: The Library outfits* include some surprisingly good skins. Of course the fingernails and toenails are horrid as-is, but I think the mesh bodies have custom fixes for that (at least Slink does; I haven't experimented so much with the others). Frankly, they seem better than the expensive system layer skins I bought back before mesh avatars were a thing. I haven't checked: maybe they all use 1024x1024 textures.

There's certainly a lot more variety in that Library than among the handful of male BoM skins the big creators could be bothered to put on their shelves. Maybe the situation is better for females, but for males, it's grim.

(Also in passing: those Library outfits include many alpha mask layers, too, relevant again with BoM. I generally make my own, and did even back when every mesh clothing item came with a corresponding alpha mask, but if you'd rather hunt through pre-made alpha masks, there are a bunch in the Library.)

______________________
*as well as the freebie SL16B avatars, if you happened to pick them up

  • Like 1
  • Haha 1
Link to comment
Share on other sites

11 minutes ago, OptimoMaximo said:

No materials support, no use. 

Oh I wish this were true. You have no idea. how much I wish it were the case that most SL users had ALM enabled, but the fact is, most don't even know why they want it -- not even for photos.

On the other hand, as I posted long ago (probably years ago now), there's no correct way to apply simple layers of normalmaps. Specularmaps are somewhat easier because their propagation upward through the layers might be simplified to track diffusemap transparency, but in contrast normalmaps should propagate based on the "flexibility" of the above layers, a metric nowhere defined for those layers. So, short of defining a wholly new "material" property, the only correct way is to create a single normalmap that propagates the bumpiness of all the layers. I know Slink offers a couple ways to apply one such manually summed maps; the others may as well.

  • Like 1
Link to comment
Share on other sites

10 hours ago, Qie Niangao said:

Oh I wish this were true. You have no idea. how much I wish it were the case that most SL users had ALM enabled, but the fact is, most don't even know why they want it -- not even for photos.

I think you will find more people than you think do use ALM especially given that it is usually activated by default now with very little impact on performance. OptimoMaximo has said what I believe is the answer as well, BoM doesn't support material and therefore the body effects/options aren't as limitless as onion bodies are due to this. Not having this support and also the nature of how BoM works it makes the skin, tattoo's etc. very flat looking and not to the standard and flexibility people have come to expect with over 8 years of onion layered bodies. LL were told this prior (I would assume, or at least hope, in their somewhat limited in-world meetings as well) that not including materials (even if it meant delaying for a solution to be looked into) would negatively impact on uptake but they didn't listen and instead said it will be a future possible feature, which is looking doubtful now.

It also comes down to money. Whilst body makers MAY provide a free update and generally will, there is no reason for skin makers to do the same. Why? Because the previous onion bodies are still there - and still provided by the body makers (in some way due to LL's policy of not breaking content) and therefore have a market and a far more established one at that. This means that skin makers are better business wise to create new skins for BoM and then charge for them separately to the un-updated ones. The consequence of this is that, due to the cost involved with some skins consumer wise or the variety people have already collected over the years, it can be cost prohibitive. Add to this body makers still making union layered bodies or variants of it that support/dont support BoM due to the lack of material support, the consumer will see very little need to update from an onion body to a newer different variation of one.

Additionally, due to the above, the skin creator would need to include multiple versions of their skin (irrespective of how easy or not it is) as part of the product to accommodate old and new or face loss of income due to people not upgrading. Add onto that then the farce of left arm only tattoo's not working and issues with AUX BoM layers for left arms etc having issues (unless these have been resolved) and it should be relatively clear the reason why the update hasn't had a better uptake (i.e. it wasn't a QA tested and finalised release but instead, a release that has bugs, issues, lack of already well established features and in general only support for one avatar community - humans).

Edited by Drayke Newall
  • Like 4
Link to comment
Share on other sites

I'll surely never buy another non-BoM, onion-layer skin, materials or not. Maybe their materials support is worth something to somebody, but it's surely not worth the hideous mess those stacked layers cause for blended-alpha textures under one too many colored projectors, never mind all the other problems for the consumer (alpha-sorting & alpha-mode layering, applier effects not represented in outfit contents, clumsy and inherently conflicting auto-alpha cuts, etc), and not to mention the rendering complexity which is what the Lab should care about and how we got here in the first place.

  • Like 1
  • Haha 2
Link to comment
Share on other sites

Some LL-sponsored method of converting appliers into personal system layers is on my "unicorn wishlist", of ideas that would be great if they could work out, but realistically will never happen for a variety of reasons. So yeah, while I'd love to have some way of using my existing content in the new (and more resource-friendly) way, I do appreciate the long list of issues that likely will never be resolved.

Link to comment
Share on other sites

13 hours ago, Qie Niangao said:

there's no correct way to apply simple layers of normalmaps. Specularmaps are somewhat easier because their propagation upward through the layers might be simplified to track diffusemap transparency, but in contrast normalmaps should propagate based on the "flexibility" of the above layers, a metric nowhere defined for those layers. So, short of defining a wholly new "material" property, the only correct way is to create a single normalmap that propagates the bumpiness of all the layers

What you describe is something done in film production and its animation/shader driven, while in general games pipeline that is not even remotely contemplated. There are basically 2 specific blending modes for Normal maps, detail and inverse detail, plus no blending and overlay. For the use that BoM has to do with them, using the same approach you describe for Specular maps works just fine in most cases but, aside from that, an overlay method would do most of the other minor cases, it's not an obscure or secret blending mode and it can be tied to a checkbox. The search for the extreme line, assigning such a property by "flexibility" of a material (and maybe changing it realtime as one moves) is simply something unrealistic to seek. Simply put, it is something that AAA games don't do because it isn't feasible to do in a realtime environment, at least it's not yet. Alpha cutting the normal map with no blending does the job in most cases, and the remaining cases just work fine adding the two normals together using an overlay blend mode so that an upper, more flexible material gets the underlying material's detail. Specularity would do the difference

Link to comment
Share on other sites

Well, y'all can argue with the Lindens about whether BoM needs Materials to get broader acceptance. Personally, I think that's silly; there's just so much wrong with how stacked-layer mesh looks under common enough conditions, affecting the higher end of the market where Materials might matter, and for beginners, its crazy-complex usability issues.

Rather than lack of Materials support, I see a simple chicken-and-egg stalemate: Merchants aren't offering product for a market whose adoption is slowed by lack of available product. Something needs to break that log jam or it could be another two years before we get the benefits the development investment paid for.

Another way to address it would be for the Lab to simply flood the market with free, very high quality BoM skins. At least that would spur adoption, although the merchants would go out of business instead of supplying the market they failed to serve for so long.

  • Like 2
  • Haha 1
Link to comment
Share on other sites

20 hours ago, Qie Niangao said:

I'll surely never buy another non-BoM, onion-layer skin, materials or not. Maybe their materials support is worth something to somebody, but it's surely not worth the hideous mess those stacked layers cause for blended-alpha textures under one too many colored projectors, never mind all the other problems for the consumer (alpha-sorting & alpha-mode layering, applier effects not represented in outfit contents, clumsy and inherently conflicting auto-alpha cuts, etc), and not to mention the rendering complexity which is what the Lab should care about and how we got here in the first place.

I am in no means in favour of Onion bodies. I think they are a plague and one directly linkable to the erroneous and lack of foresight thinking of LL upon mesh creation. They should be removed and I think most people would agree with this. That said, due to their favoured use over the years, BoM has and will always be seen as a back step in graphics quality and choice to many.

As I mentioned before, BoM is generally solely targeted to human avatars and this is the problem. By doing this it means that a large portion of the userbase, and those generally that want to use a lot less rendering complexity in some cases for more (and of which already do have FAR lower complex avatars than human avatars despite using onion layered bodies) are ignored or have to use poorer products to achieve things onion bodies can. For instance, as a human one would have generally a skin, hair, tattoo and makeup layer (seeing as clothing BoM is terrible). This works fine as the base layer of BoM on the new bodies allows for a skin pore normal map and so that works very well for human avatars. Therefore human avatars can use the multiple human skins etc available i.e. choice.

Conversely, if you look at non-human avatars then the problem with BoM becomes clearer in that it limits the possibilities/choice dramatically and stagnates creation. Take a mermaid. Current onion bodies allow for that person to be a mermaid by buying any nice looking human skin, add a separately created tattoo for gills (with normal map), add a separately created tattoo for scales (with normal map), add a separately created tattoo for shells (with normal map) to cover the nipples, add a separately created skin tattoo blend (with normal map) scale effect to blend the tail with human body and add a tattoo normal map for a water on skin effect. This cannot be achieved in the BoM method. Whilst yes, you can have any skin and tattoos, the definition and effects multiple normal maps provide isn't possible. This means that to get the same look using BoM a skin creator will have to make a mermaid skin with all the tattoo's and effects included on that skin and a single normal map to accommodate (which will also have layering issues). The same applies to androids, furries and any other non-human or semi human avatar.

The above means that it limits the choice of the person wanting to be a mermaid as they only have very select (few) skin creators to choose from rather than any human skin. It also stagnates the creation community as rather than having multiple creators creating multiple tattoos and letting the user choose, with BoM bodies it limits this to relying on only a few creators. That is to say, with the above mermaid example, 7 different creators could benefit from the mermaid avatar sales wise (whilst also increasing choice) whereas, with true BoM only 3 creators benefit (body, skin and tail). This is why it isn't popular and is also why we have now seen Matreya bodies come out with a BoM body and then multiple separate (optional) overlay bodies along with more scripts etc within them. I.e. more or just as much render complexity and drain on the servers and viewer as well as also meaning less attachment points for some.

There were possibilities for LL to look into or implement multi layered material support for BoM. Their previous suggestions of it being implemented later after release of BoM is evidence of this. The issue comes that LL put it in the to hard basket at the time rather than looking to issue the update as a complete package. The very same method in which LL is now looking to release EEP, as a non complete package with actual wanted features released later or not at all.

With Matreya being the most popular female body, I am sure more skin creators will change to BoM now that they have BoM bodies but there is the blatant downside mentioned above to this.

Edited by Drayke Newall
changed not to now in last sentance of post (bold)
Link to comment
Share on other sites

1 hour ago, Drayke Newall said:

There were possibilities for LL to look into or implement multi layered material support for BoM. Their previous suggestions of it being implemented later after release of BoM is evidence of this. The issue comes that LL put it in the to hard basket at the time rather than looking to issue the update as a complete package. The very same method in which LL is now looking to release EEP, as a non complete package with actual wanted features released later or not at all.

Okay, that's a situation. What might motivate the Lab to invest more in BoM again? Think that'll happen before it catches on in the human avatar markets?

  • Haha 1
Link to comment
Share on other sites

3 hours ago, Qie Niangao said:

Okay, that's a situation. What might motivate the Lab to invest more in BoM again? Think that'll happen before it catches on in the human avatar markets?

Nothing will motivate them. That's the point. It is the downward spiral of what happens when LL release new features and don't release them to their fullest. Sure, they cant envisage everything a person may or may not do with the released feature that's a given and an expectation that their planning would take into consideration, but they really do need to start releasing features to at least the same standard that is used that the feature is to replace/improve or, improve it beyond the later being the best solution.

The issue now comes as to whether they will update it. Ill put all my lindens on the table that they want update it to support materials. Why? Not because it would be to hard, but because they wont be able to. There are two main reasons.

Firstly, because as we have seen with many of their projects or features, from their original release to any promised update can be years. Windlight to EEP is the prime example of this. This has many negatives such as the code being too old and intertwined with other features that are introduced in-between to simply needing a complete re-write due to better ways of doing it. This is why EEP has been so hard to implement due to other newer features getting in the way of the older windlight system. The positive list of such an action would be one line simply showing "none".

Secondly, because the longer LL wait to update the feature the more likely such an update would break existing content and therefore per LL known rules of never breaking old content, they wouldn't be able to implement it. The mesh onion layered avatar is the prime example for this case. If LL updated the default body to a standard equal to the current mesh onion bodies when mesh was released (they could have even had a similar body system but instead have the actual layers auto togglable only when the appropriate layer e.g. tattoo was worn) but better optimised and restricted, then the debacle we are faced with as far as multiple incompatible bodies (needing different clothes sizes, skins etc) now would never have been. Instead they have wasted so long in actually looking at updating the default body that any attempt would break content and cause user backlash so they don't. This has eventuated to BoM, which is the fix that would never have been needed as the system default body would have been updated to work with the system materials from the get go. Meaning EEP or other improvements/features could have been worked on far earlier as BoM wouldn't have wasted development time.

This will be the outcome of any possible material support for BoM. So to answer your last question no it wont happen before BoM catches on for human avatars as it will never be implemented. This will mean that due to the non-human avatars utilising many of the human bodies and assets those non human avatars will be forced to downgrade until at least a better workable user made solution is created, thereby by passing any positives optimisation wise BoM intended to have.

Link to comment
Share on other sites

So worst case, scaly bodies stay onion-layered. I can live with that, and I bet they can, too. I'm not sure how it hurts their experience if some human avatars get easier to render.

Anyway, I see one of the big name male skin creators is slowly updating their body skins to BoM. They haven't yet done the one male body that actually got BoM right (and first), but they say "coming soon" so I'll keep watching. Unfortunately they aren't doing anything with head skins... which I can maybe imagine might need texture tweaking, especially for the most popular brand, which just might have been... "creative" with their interpretation of the system UV map. But on the other hand, it's facial makeup that most suffers from the blended alpha sorting problem solved by baking. Faces are probably also where the ALM limit on projected lights for blended alphas is most starkly evident. It's really too little, too late, but at least body BoM is a step in the right direction, if only the other creators would follow suit Real Soon Now.

  • Like 1
  • Haha 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1508 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...