Potential for UUID ripping from system layers and consequent use with appliers

[Coffee Pancake]

We all get that materials on BoM would be a good thing, but you're preaching to the choir.

Go to LL. Go to the meetings. Make a JIRA.

.... and try really hard to come up with a use case that isn't fetish wear or bodily fluids, because at the end of the day, your shiny ass isn't going to sell this.

[Kyrah Abattoir]

7 hours ago, Callum Meriman said:

My skin has normal pores, it has normal veins, it has normal musculature, it has specular body oil, it can have specular water drops, it can have specular sweat.

Baked-on-fail will have none of that, it would need a seperate applier... And if you have a seperate applier... may as well put the diffuse in it too.

I still believe Baked-on-fail should be dropped until it's feature complete or better, just shelved entirely and the development effort put into projects that are more important.

Sweaty, skin, pores. *shivers uncontrolably*

SL still looks dreadful compared to even Half Life 2, but now we have glistening skin pores clogging our vram.

When will people understand that it's not how many pixel or polygons that matter, it's how they are used. You can put cream cheese on a turn, it's STILL a turd.

Edited May 29, 2018 by Kyrah Abattoir

[Coffee Pancake]

5 minutes ago, Kyrah Abattoir said:

SL still looks dreadful compared to even Half Life 2, but now we have glistening skin pores clogging our vram.

Ironic ... as so much of Second Life is still textured with maps ripped from HL2

[Kyrah Abattoir]

They are becoming rarer now that home creators favor baking shadows and AO into absolutely everything clogging your VRAM with 200Mb of texture per house.

They don't KNOW how to make a texture that looks good. So they do that instead and label it quality.

Edited May 29, 2018 by Kyrah Abattoir

[Theresa Tennyson]

8 hours ago, Klytyna said:

I knew that over a year ago, when I told you and the other Bake-Fail propaganda spewers that bake-fail was a bloody stupid idea.

It's STILL a bloody stupid idea, thats only supported by those tech-illiterate enough to believe the propaganda, and by those who think it will resurrect their failing "system clothing and skins" businesses, by allowing them to sell their 10 yar old back-catalog to future generations of tech-illiterate noobs.

Is there no end to your hypocrisy and cluelessness...

One of the "advantages" of bake-fail that YOU specifically have been so keen to stress, is doing away for the need for meshed layers close to the skin, but a translucent latex catsuit for example, that was MODELED, in 3d, would basically be a copy of the body, with the minor modification of spanning arous the cleavage, and butt crack, just like ...

The clothing layer on your materials applier friendly mesh onion-layer body. So, you are basically saying, wear an onio layer... And then you make the mistake of calling for MESHED seams and fine wrinkles, apparently oblivious to the massive increase in poly could resulting from this, and apparently oblivious to the FACT that much of the mesh based clothing these days, USES NORMAL MAPS to add such details rather than modeling them.

I'd suggest you turn on Advanced Lighting Model, wear a Maitreya body, and try a demo from one of the materials based latex applier vendors, there are several, so you can see just how WRONG you are... Again...

Here's a product shot from ONE of the materials based applier makers, not the fine wrinkles and seam lines in the suit, the kind of detail that NOBODY would try and model into a mesh, unless they were completely ignorant of the technical realities of mesh-making and rendering costs.

...

Let's sum up YOUR position so far.

1. Bake-Fail uber alles, because onion layered mesh is EVIL (PS. You can wear all your 10 year old system rags again)

2. Matte finish flat 'body paint" looks better than spec/normal mapped materials.

3. Appliers for materials on onion-skin bodies are obsolete because... You could wear a 3rd party skin tight mesh suit with a massive poly count and rendering cost, that uses materials, in stead of simply applying materials to a layer on your body...

...

Facts tend to disagree with YOUR opinion. Hmmm, so...

Fact free Pro-Bake-Fail Propaganda Materials Hating SL-Fossil Hypocrisy much?
 

Theresa Tennyson smiles at you condescendingly.

Yes, dear, your bargain-basement gimp suit looks just looooooveleigh.... Those other girls are just being so mean... Would you like some nice tea and a biscuit?

[Kyrah Abattoir]

This shouldn't be an applier tho. It being an applier means you're hauling around your onion skin mesh all the time instead of only when you're wearing your catsuit.

At least with MOD mesh bodies you can make optimized versions by delinking the parts you don't need for outfits you use often.

Oh right, no mod body, no one knows why.

[Theresa Tennyson]

10 hours ago, Callum Meriman said:

My skin has normal pores, it has normal veins, it has normal musculature, it has specular body oil, it can have specular water drops, it can have specular sweat.

Baked-on-fail will have none of that, it would need a seperate applier... And if you have a seperate applier... may as well put the diffuse in it too.

I still believe Baked-on-fail should be dropped until it's feature complete or better, just shelved entirely and the development effort put into projects that are more important.

Tell me what's wrong with this specific proposal that I made earlier and not some straw-man argument. (Oh, and you might as well just use Klytyna's "zippy" sarcastic name for the project instead of trying to improvise - "baked-on-fail" sounds like the English on a Japanese T-shirt.)

Why'd you want to wear a shirt spray-painted to your skin? Bakes-on-mesh is not a good solution for clothing. (Whether applier clothing is a good solution in itself is another story.) I have never said that it is.

This is my spec for a day-zero avatar, using only features that are available right now and bakes-on-mesh in its current state (hands, feet and head separate as is the common practice):

Main body of avatar: a single 8-face mesh that supports bakes on mesh, used for skins, tattoos/body detailing and alpha masks to wear under mesh clothing, and a possibility of underwear/hosiery worn as layering. Put on using system assets. With 8 faces, you could have an upper body, lower body, dimensional nipples that can be turned off individually, a "crotch cover" that can be turned off and three additional faces for a choice of neck sizes, etc. [Materials would be handled the same way mesh bodies are now]

Clothing layer: a single 8-face mesh divided into 8 sections - right arm, left arm, front torso, back torso, front pelvis, back pelvis, left leg and right leg. All these faces could be turned on/off and textured individually (including materials) with appliers. This would let you simultaneously wear a bra-and-panty set, stockings and a one-arm tattoo [this was written before the new channels being added for the left arm and foot - the layer will no longer need to do this], all from different makers and all with their own materials settings. The "three layers" of the typical mesh avatar is really a fiction because you can't reliably wear two alpha-blended layers on top of each other and alpha masking makes anything with complicated edges or transparency look like it was cut out by a six-year old with those little round-pointed scissors.

You'd have a complete avatar that can do 90% of what the current avatars can do using two meshes instead of 119 meshes like in a Maitreya Lara body. [Oh, that's not including the 87 additional ones in the HUD] In some ways it would be more versatile. And if it doesn't work for you? You wouldn't have to use it. Just use your old one. Of course if people snicker at you in a couple years because you're still in pieces when everyone else has arrived that's your choice.

Edited May 29, 2018 by Theresa Tennyson

[Kyrah Abattoir]

Actually assuming we had some sort of linden endorsed "system" body, ankle and wrist cuts would be all that is needed, creators could simply copy the piece of the arms/legs that they need to fill the gap of their clothing and use bake on mesh to have those parts automatically match textured to the body.

It's exactly how games like skyrim handle clothes incidently, the clothing "mesh" typically includes the parts of the body it doesn't cover (up to standard minimal cut points) instead of using 40 something slicing points.

Oh yeah did i mention that separate mesh "faces" even with the same texture not only are annoying to make but aren't actually free from a rendering standpoint?

Edited May 29, 2018 by Kyrah Abattoir

[Bitsy Buccaneer]

12 hours ago, Blush Bravin said:

....

My apologies for intruding in your thread then. I'll remove my name from your subscriber as soon as I'm inworld. I have no idea how it ended up there if you're not the Blush who used to make lovely flapper-inspired dresses and one of my favourite cloches so it must have been a mistake. Best wishes.

[Blush Bravin]

25 minutes ago, Bitsy Buccaneer said:

My apologies for intruding in your thread then. I'll remove my name from your subscriber as soon as I'm inworld. I have no idea how it ended up there if you're not the Blush who used to make lovely flapper-inspired dresses and one of my favourite cloches so it must have been a mistake. Best wishes.

Oh, that is my work but that was many years ago when I wasn't using a vendor system. I haven't made any system clothes or flexi skirts in many many years. I'm sorry Bitsy but classic clothing just doesn't sell anymore. It's even super hard to sell applier clothing unless it's in the form of stockings or undies. Time has moved on and we've had to adjust.

[Bitsy Buccaneer]

Strange isn't it, that I would have a lingering sense of loyalty to your work after all these years? But please don't misunderstand that I'm looking for flexi skirts. For all that it's harder to find, system is still useful, especially for layering. I really hope there's less segregation by body choice when Bakes on Mesh arrives.

Anyway, good luck with your endeavours. I'm off to go bash my head against the Blender again. Hunt prize needs finishing.

[Nalates Urriah]

On 5/1/2018 at 11:31 AM, Blush Bravin said:

I agree system layers are safer, but if the applier system being requested goes into effect we will likely find ourselves in the position that we have to provide both system layers and appliers.  Thus creating a situation where the UUID numbers will be easily obtained from the system layer, and then those UUIDs can be used to make appliers. I hope to get ahead of this to think of safeguards prior to release rather than play catch-up after a slew of original content has already been ripped.

Any texture the viewer can render can be stolen. 

Textures run through the bake service are composite textures, which are a long term temporary texture. They can be stolen too. But, the source textures for the composite are much harder to find. So, there is some protection in using the bake service.

The applier code I've been using reads the texture ID's from a note card that is deleted automatically from the applier. The UUID's exist only in script memory, which lives on the server side. Safe so far. (But, if the applier is reset, it is dead, ID's lost.)

But, when the viewer renders the applied texture the texture is pulled from server assets and stashed on your computer then used by the video card to render the scene. At that point anyone with the knowledge can take a copy of the texture from the hard drive. The entire 3d gaming industry has found no way to get the texture on your screen and prevent it being stolen.

My impression of where the Lindens are on this point now is that adding complication and reducing performance in a futile attempt to prevent theft is counter productive. So, I don't expect any grand plans along that line. I suspect as the cache is redone (in progress) we may even see it get a bit easier as performance is improved. The Lindens are aware of the problem. I can't see them deliberately making it easier. But, performance is their goal in the face of impossible odds against protection ever working.

Understand. If the video card can use the texture, I can take a copy of it. That is completely independent of the viewer or whatever game is sending a texture to the video card. No matter what the Lindens do or what complications, obfuscations, or protections they might build into the viewer or a game, eventually the texture has to be sent to the video card in a usable form and that can be snatched out of the video card. So, what is the point of trying to protect the unprotectable?

[Blush Bravin]

1 hour ago, Nalates Urriah said:

Any texture the viewer can render can be stolen. 

Textures run through the bake service are composite textures, which are a long term temporary texture. They can be stolen too. But, the source textures for the composite are much harder to find. So, there is some protection in using the bake service.

The applier code I've been using reads the texture ID's from a note card that is deleted automatically from the applier. The UUID's exist only in script memory, which lives on the server side. Safe so far. (But, if the applier is reset, it is dead, ID's lost.)

But, when the viewer renders the applied texture the texture is pulled from server assets and stashed on your computer then used by the video card to render the scene. At that point anyone with the knowledge can take a copy of the texture from the hard drive. The entire 3d gaming industry has found no way to get the texture on your screen and prevent it being stolen.

My impression of where the Lindens are on this point now is that adding complication and reducing performance in a futile attempt to prevent theft is counter productive. So, I don't expect any grand plans along that line. I suspect as the cache is redone (in progress) we may even see it get a bit easier as performance is improved. The Lindens are aware of the problem. I can't see them deliberately making it easier. But, performance is their goal in the face of impossible odds against protection ever working.

Understand. If the video card can use the texture, I can take a copy of it. That is completely independent of the viewer or whatever game is sending a texture to the video card. No matter what the Lindens do or what complications, obfuscations, or protections they might build into the viewer or a game, eventually the texture has to be sent to the video card in a usable form and that can be snatched out of the video card. So, what is the point of trying to protect the unprotectable?

My issue isn't trying to safeguard any texture from being ripped. I know there is no way to stop that. My issue is having UUID numbers readily available through the developer menu for anyone to grab and use in any manner they choose regardless of the permissions set on the texture to make the clothing layers. My hope is that UUID numbers will be removed from the character to HML report. Several blogs wrote about how to use the report to find UUID numbers when the Omega system was first implemented. It didn't take long before people were sharing those UUID numbers with their friends and friends of friends and so forth. 

[Whirly Fizzle]

8 hours ago, Blush Bravin said:

My issue isn't trying to safeguard any texture from being ripped. I know there is no way to stop that. My issue is having UUID numbers readily available through the developer menu for anyone to grab and use in any manner they choose regardless of the permissions set on the texture to make the clothing layers. My hope is that UUID numbers will be removed from the character to HML report. Several blogs wrote about how to use the report to find UUID numbers when the Omega system was first implemented. It didn't take long before people were sharing those UUID numbers with their friends and friends of friends and so forth. 

They already fixed it
https://bitbucket.org/lindenlab/viewer-neko/commits/2d74d8ffe6bd39d541e1e42d881ef5afb82125f6

[sirhc DeSantis]

bool agent_is_godlike = gAgent.isGodlikeWithoutAdminMenuFakeryUnlessItsMe();

 

[OptimoMaximo]

On 29/5/2018 at 12:14 AM, Theresa Tennyson said:

Oh, and you do realize that in Second Life glossiness for the specular channel is set as a variable by face and not by texture, so your hott latex catsuit and your skin would need to have the same glossiness if bakes-on-mesh had materials support?

Already proved you wrong in the other thread about this BS you're saying. Glossiness map is inside the normal map's alpha channel and the parameter in the build tool is a multiplier to modulate it. PERIOD. BakeFail on MeshBodiesOnly is a crippled useless feature that shouldn't have come to life in the first place. Materials Layering is the answer to overall complexityy reduction, from polycount to texture load. BoM is BS.

[OptimoMaximo]

On 29/5/2018 at 2:35 AM, Klytyna said:

On 29/5/2018 at 12:14 AM, Theresa Tennyson said:

Oh, and you do realize that in Second Life glossiness for the specular channel is set as a variable by face and not by texture, so your hott latex catsuit and your skin would need to have the same glossiness if bakes-on-mesh had materials support?

I knew that over a year ago, when I told you and the other Bake-Fail propaganda spewers that bake-fail was a bloody stupid idea.

It's STILL a bloody stupid idea, thats only supported by those tech-illiterate enough to believe the propaganda, and by those who think it will resurrect their failing "system clothing and skins" businesses, by allowing them to sell their 10 yar old back-catalog to future generations of tech-illiterate noobs.

On 29/5/2018 at 12:14 AM, Theresa Tennyson said:

I also know that "raised seams and wrinkles" done with materials mostly say, "I'm too cheap to buy a modeled version so I'm wearing faky-jaky - am I not hott?" -- and the answer to that is... nott.

Is there no end to your hypocrisy and cluelessness...

One of the "advantages" of bake-fail that YOU specifically have been so keen to stress, is doing away for the need for meshed layers close to the skin, but a translucent latex catsuit for example, that was MODELED, in 3d, would basically be a copy of the body, with the minor modification of spanning arous the cleavage, and butt crack, just like ...

The clothing layer on your materials applier friendly mesh onion-layer body. So, you are basically saying, wear an onio layer... And then you make the mistake of calling for MESHED seams and fine wrinkles, apparently oblivious to the massive increase in poly could resulting from this, and apparently oblivious to the FACT that much of the mesh based clothing these days, USES NORMAL MAPS to add such details rather than modeling them.

I'd suggest you turn on Advanced Lighting Model, wear a Maitreya body, and try a demo from one of the materials based latex applier vendors, there are several, so you can see just how WRONG you are... Again...

Here's a product shot from ONE of the materials based applier makers, not the fine wrinkles and seam lines in the suit, the kind of detail that NOBODY would try and model into a mesh, unless they were completely ignorant of the technical realities of mesh-making and rendering costs.

...

Let's sum up YOUR position so far.

1. Bake-Fail uber alles, because onion layered mesh is EVIL (PS. You can wear all your 10 year old system rags again)

2. Matte finish flat 'body paint" looks better than spec/normal mapped materials.

3. Appliers for materials on onion-skin bodies are obsolete because... You could wear a 3rd party skin tight mesh suit with a massive poly count and rendering cost, that uses materials, in stead of simply applying materials to a layer on your body...

...

Facts tend to disagree with YOUR opinion. Hmmm, so...

Fact free Pro-Bake-Fail Propaganda Materials Hating SL-Fossil Hypocrisy much?

I MUST take back all i previously said about you Klytyna. This post of yours actually sums it all up. Please take a look at my video i posted in the feedback thread to add my points to yours, since they pretty much go well together. I HONESTLY no longer think you're a 3D/materials illiterate. These fanboys deserve that tile in your stead.

Edited June 11, 2018 by OptimoMaximo

[Theresa Tennyson]

1 hour ago, OptimoMaximo said:

Already proved you wrong in the other thread about this BS you're saying. Glossiness map is inside the normal map's alpha channel and the parameter in the build tool is a multiplier to modulate it. PERIOD. BakeFail on MeshBodiesOnly is a crippled useless feature that shouldn't have come to life in the first place. Materials Layering is the answer to overall complexityy reduction, from polycount to texture load. BoM is BS.

1) That doesn't change the fact that the multiplier is the same for the entire texture face, which was my point and will be a factor when materials for two different items are combined.

2) Polycount - what was the land impact of the test building in your video?

3) Texture load - in your video, when you layer two textures on top of each other, how many textures does the viewer have to load?

The entire point of using bakes on mesh is to take advantage of the pre-existing texture compositing system. If it can eventually be made to layer and composite materials as well that would be great - I'm not saying that it shouldn't. I'm saying to use it for what it can do now. And nobody has told me what's wrong with the mesh avatar with a single separate layer for texture (and materials) clothing which I've been proposing for months, including earlier in this thread.

Edited June 10, 2018 by Theresa Tennyson

[OptimoMaximo]

15 hours ago, Theresa Tennyson said:

1) That doesn't change the fact that the multiplier is the same for the entire texture face, which was my point and will be a factor when materials for two different items are combined.

The point is that the multiplier has to subdue to the map value to begin with. Black is zero gloss, you can set the mutiplier at 255 and still have no glossiness showing up on the zero gloss area defined in the map.

15 hours ago, Theresa Tennyson said:

2) Polycount - what was the land impact of the test building in your video?

Being the exploitation of a BUG, my dear, can you understand that i doubled the UV count and not the polygons? As result of a BUG, the final result IS BUGGY and therefore miscalculation is an obvious consequence. Reuploading the same model gives different LI, WAY different (higher and lower) because the mesh file fools the interpretation done by the uploader. Therefore, in that regard, this statement from you is non sense because i got the effect feeding "nonsense" to the uploader which, in turn, gave me that effect with a "nonsense based" calculation. What i'm advocating is a development in that same direction without tricks on the uploaded mesh data (read below)

15 hours ago, Theresa Tennyson said:

3) Texture load - in your video, when you layer two textures on top of each other, how many textures does the viewer have to load?

Five sets of materials, total 15 textures plus 1 AO for the whole build altogether. Now read intently, and don't skip what you don't like to hear: to have the same visual resolution with bakes, you should have each side of those cubes to get more than one texture faces, baked textures that, nowadays, are also coupled with their corresponding set of material textures to go with the bake in question itself. So in the end, to get the same visual resolution result, where i got away with a total of 5 sets of materials (logs, regular wood, stone blocks and 2 versions of the hay, plus 1 single AO for the whole build to layer on top) there would be the need for many more baked diffuse textures WITH their own corresponding material textures (normals and specular). Therefore, texture baking workflow always results in more maps than a layered system, which is why all platforms/engines/3D softwares fold over this solution rather than on pre-rendered textures: it looks dynamic for the materials used can be randomized in their placement, giving us less obvious repetitions and more variety using the same set of textures, higher resolution for the tiling approach, and less texture memory consumption. Example: to get a final visual resolution of 256 px/sqm, using baked textures require a ton of them, which in the end keep showing repetitions and blurring as opposed to the layering system that relies on tiling which COVERS obvious repetition by using different layers to result in more variated textures with the same set of materials, not more sets.

15 hours ago, Theresa Tennyson said:

And nobody has told me what's wrong with the mesh avatar with a single separate layer for texture (and materials) clothing which I've been proposing for months, including earlier in this thread.

The wrong thing is that it applies only to mesh avatars, neglecting all the rest of content types, while the approach i describe can be applied ALSO to avatars and can be flexible enough to allow different types of workflow, single tile textures as well as tiled textures. Moreover, BakesOnMesh(bodies) applies the same separations as per the default avatar, also limiting the available slots to what the classic avatar offers, forcing to recycle the skirt, for example, to allow left/right arms to get different texturing. This goes well, PERHAPS, for the mesh avatars that comply to the classic avatar's standards, but those that have proprietary UVs and/or different UV arrangements are being cut off from this anyway. Using the classic avatar's UVs "for compatibility" was and still is a draw back on the possibilities that mesh avatars have, and it was done just to be able to, again, recycle older content instead of making new and better (also higher rez if you will) content. 

After all this said, couple that with mip mapping being properly implemented, reducing the texture size as LoDs would, based on the view distance. Currently, also that is non-standard mipmapping, as it is right now, it's just a progressive increase of resolution while the texture is being downloaded, but then it stays at final resolution regardless of the viewing distance.

To conclude: the problem with bake on mesh is that it won't solve the performance problems that SL currently has. What i'm advocating is a DEVELOPMENT (= IMPROVEMENT) of the current system, making sure that the shader begins to work on a layering system base AND textures are being scaled in regard to viewing distance (materials are applied on a shader, which is a piece of code that defines the material per se and how textures should be interpreted; please don't reply that SL has no shaders. It's got only one that WE can't work on and WE get only the input slots to add our textures). I think it was Klytyna who was saying that mips should be included within the textures themselves and therefore not a viable solution because of the final texture compressed size; that was true in the past, there is no more need of mips inclusion in the main resolution texture nowadays as most of the games compute them on the fly because now hardware and code support this. You feed a final resolution and the resizing is automated without cluttering texture memory, which instead gets a relief by doing this, discarding the unnecessary allocated memory that the smaller texture version needs in comparison to the bigger ones, and just downloading the missing bits when a "scale up" is necessary instead of the full texture.

This is why BoM is a quick sop for you LL fanboys. You don't realize how this project's aim is to make a fool out of the user base and creators altogether to avoid serious development, and still being able to say "we're working for you and the platform improvement" and justify the latest increase on cash out fees, while there's NO proportion in regard of their increased income and the actual work they do in development. Because what they're doing is patching an old feature, that remotely resembles what is common standard anywhere else, to work on the newer content instead of DEVELOPING a newer base feature (materials) to include NEW functionality.

Edited June 11, 2018 by OptimoMaximo

[Theresa Tennyson]

1 hour ago, OptimoMaximo said:

The wrong thing is that it applies only to mesh avatars, neglecting all the rest of content types, while the approach i describe can be applied ALSO to avatars and can be flexible enough to allow different types of workflow, single tile textures as well as tiled textures. Moreover, BakesOnMesh(bodies) applies the same separations as per the default avatar, also limiting the available slots to what the classic avatar offers, forcing to recycle the skirt, for example, to allow left/right arms to get different texturing. This goes well, PERHAPS, for the mesh avatars that comply to the classic avatar's standards, but those that have proprietary UVs and/or different UV arrangements are being cut off from this anyway. Using the classic avatar's UVs "for compatibility" was and still is a draw back on the possibilities that mesh avatars have, and it was done just to be able to, again, recycle older content instead of making new and better (also higher rez if you will) content. 

 

1) They're adding channels for left arm, left foot and three auxiliary channels in addition to the existing ones. Do you mean that you didn't know that? You're commenting on the project so I thought that you'd know. You know far more about materials than I do, I'll grant that. But you don't actually know much at all about this project, do you?

2) As anyone who knows anything about texturing mesh should realize, since the project only composites textures it's completely UV-agnostic. The only items that have UV mapping issues are certain of the legacy clothing items and I've said repeatedly that this project isn't really meant for clothing. Tattoos, alphas and skins don't have any inbuilt preference for UV maps, nor will the new assets intended to take advantage of the additional channels.

I can bring the attitude too when I'm dealing with someone who doesn't know what he's talking about.

Your proposal requires completely new work that has absolutely nothing to do with this project. Why even bring it up here?

[Blush Bravin]

On 6/11/2018 at 9:24 AM, Theresa Tennyson said:

1) They're adding channels for left arm, left foot and three auxiliary channels in addition to the existing ones.

I had heard this but I can't find any official comment on this. Was this discussed in a content creators' meeting? If yes, which one? I'd like to find the video of the meeting and watch it. I'm trying to stay up to date on the project. Thanks in advance for your response.

[Whirly Fizzle]

First attempt was added in https://bitbucket.org/anchor17/viewer-release-baking-updates/commits/320ecbc5d47781e51038c596fea79d69b3717a27

Looks like this was backed out & they are going about it a different way now..

https://bitbucket.org/anchor17/viewer-release-baking-updates/commits/7613b07b54be5b7231e4e90571dabc037a0e40cb
https://bitbucket.org/anchor17/viewer-release-baking-updates/commits/11f9716bd9388f939dbf9c1caf15cabc4ab2da98

[Theresa Tennyson]

46 minutes ago, Blush Bravin said:

I had heard this but I can't find any official comment on this. Was this discussed in a content creators' meeting? If yes, which one? I'd like to find the video of the meeting and watch it. I'm trying to stay up to date on the project. Thanks in advance for your response.

Here's the meeting transcript with audio.

https://modemworld.me/2018/06/01/2018-sl-project-updates-22-2-ccug-meeting-w-audio/

[Vir Linden]

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.

[Tomaltach]

On 5/1/2018 at 4:00 PM, Blush Bravin said:

I stopped including system layers with my appliers because it was brought to my attention how easy it is to rip the UUID numbers of any worn system layer. So my question is if this project goes forward with an applier system in place what safeguards will there be to prevent use of a UUID# without actually owning the texture to make appliers?

You are aware that Omega literally sells the tools needed to copy UUIDs on their own marketplace store for L$999, right? https://marketplace.secondlife.com/p/LNL-Mesh-Maker-Dev-Kit/6525668

While it isn't intended for that use, it can be used for it because of how SL treats linkset permissions.

Edited June 4, 2019 by Tomaltach
I don't think the exact mechanics should be shared...