Mesh Bodies Dilemma

[duLuna Bosatsu]

Hello everyone. I wanted to toss this concern/discussion-loaded query to you:

I'll start by mentioning this recent forum post: Jo Yardley - New Virtual World

I've been creating in SL, like many of you, since day 1. It's been my joy to offer what I make to the world in every available format (under layers & over layers seperable both in design and all system clothing types.) When mesh started to evolve in body-object design, I was hesitant to buy in (literally, the prices for an all-mesh avatar were and are worth their costs in arms & legs.) I started to make appliers for my clothing for the more popular parts brands (at the time), but as I've come to check-in on the status of TMP and individually made full bodies, I realize... texture-based clothing makers are having to purchase between 3 and 10 types of appliers for every article of clothing they make in order to keep up with the market/other creators- to the point that the SL body itself and clothing layers are becoming obsolete. (see the aforementioned post for the new-found reasoning)

I was thinking, "Why doesn't SL just update it's body so we're not forced to pay-in to several new body types that we're limited on dressing anyways?" and "Does this not create a kind of market-based racket for those who simply want to look good, enjoy the game, and not have to buy new mesh bodies to accomadate a skirt or shirt they like?" It's quickly solved if the article in question was mesh itself, but the texture-based clothing is a whole other consideration. I asked a current popular mesh body creator, "Why has LL made it impossible to copy the UUID off a clothing layer to apply to an object, removing the hassle of multiple appliers and creating the universal ability to wear everything you have, without having to sacrifice body-quality for clothing-quality?" It's especially difficult for older players with hundreds of dollars invested in their wardrobe they no longer feel comfortable in "their defualt body" to wear. Their reply to this, clarifying the confusion, albeit adding to the frustration, are the copyright laws involved, by allowing such a thing it creates susceptibility for theivery to happen. I have no further reccomendations on the matter after realizing/hearing this and am slightly saddened that the texture-based creators are now forced into buying multiple creator kits (even if their shop isn't one of the more popular ones) in order to accomodate their customer base. The context of this sadness is feeling pigeon-holed when there's a legitimate work around and the complexity added to incoming new residents who want to explore the game and it's beauty but are met with this debacle. 

I'm very curious to see how this new virtual world will playout and how the "non backwards compatible" yet "not obsolete original SL" will work... 

[Lisette Seranno]

Just a couple of corrections. Not sure how old that article is, so here goes. Most kits for mesh bodies and body parts are free from mesh body makers. Most people have adopted the Omega system which applies the uuid to any part as long as the user has the omega relay or had installed the omega script into the part.

 

Sure making appliers was a pain in the past because you had to make them separately. Some mesh body makers even have the omega system already installed. It's much easier to create now with the omega system.

 

As for the default body, I agree it would've been easier to just come out with avatar 2.0, but LL never did. I think if they did, people still would've complained in some way about it. I think it all comes down to LL making money off the MP transactions, which is a small percentage every time someone buys something, but those little transactions have to add up.

 

The default avi isn't all that bad. A couple of weeks ago, I helped someone do a default avi and I thought it turned out nice. It didn't look as good as a mesh avi, but the difference between a default avi and a mesh avi is definitely noticeable.

[Sassy Romano]

---

duLuna Bosatsu wrote: "Why has LL made it

impossible

  so easy to

copy

find the UUID

off

of a clothing layer to apply to an object.. 

---

Fixed that for you.  Not related to mesh in particular, it has always been somewhat trivial.

[duLuna Bosatsu]

here's the response I was given to put that sentence into perspective:

"The catch is that while a clothing layer and an applied texture are exactly the same texture, when they were made into a clothing item, they were flagged and cannot be used in any other way.  And yes, LL says it was done to prevent theft from some exploit that probably happened 10 years ago but we still have it with us."

[ChinRey]

---

duLuna Bosatsu wrote:

here's the response I was given to put that sentence into perspective:

 

"The catch is that while a clothing layer and an applied texture are exactly the same texture, when they were made into a clothing item, they were flagged and cannot be used in any other way..."

---

Whoever told you that was wrong. As Sassy said, ripping a texture off a piece of clothing is a relatively easy. No nearly as easy as ripping a texture from an applier though. Those textures are stored as UUIDs in notecards and notecard text can't be protected from reading and copying in Second Life.

[Sassy Romano]

---

ChinRey wrote:

---

duLuna Bosatsu wrote:

here's the response I was given to put that sentence into perspective:

 

"The catch is that while a clothing layer and an applied texture are exactly the same texture, when they were made into a clothing item, they were flagged and cannot be used in any other way..."

---

Whoever told you that was wrong. As Sassy said, ripping a texture off a piece of clothing is a relatively easy. No nearly as easy as ripping a texture from an applier though. Those textures are stored as UUIDs in notecards and notecard text can't be protected from reading and copying in Second Life.

---

For a hud for one of my items, I hard coded the UUID's into the script, for entertainment, I encrypted the communications between the hud and clothing object but it was just for fun because:-

a) The textures are kinda useless for anything else given that this was a mesh piece of clothing with a specific UV map and more importantly

b) No matter how they're sent in world, when you view a texture, they're downloaded to your SL cache, the file names are the UUID.

[Theresa Tennyson]

---

ChinRey wrote:

---

duLuna Bosatsu wrote:

here's the response I was given to put that sentence into perspective:

 

"The catch is that while a clothing layer and an applied texture are exactly the same texture, when they were made into a clothing item, they were flagged and cannot be used in any other way..."

---

Whoever told you that was wrong. As Sassy said, ripping a texture off a piece of clothing is a relatively easy. No nearly as easy as ripping a texture from an applier though. Those textures are stored as UUIDs in notecards and notecard text can't be protected from reading and copying in Second Life.

---

So, have you tried either of these? As far as I know you never actually recieve the clothing texture UUID's, only the UUID's of the bake files. As far as appliers, have you tried opening a no-mod, no copy notecard you're not the creator of, which is how they are set up in an applier? Report back to us.

[ChinRey]

---

Theresa Tennyson wrote

So, have you

tried

either of these? As far as I know you never actually recieve the clothing texture UUID's, only the UUID's of the bake files.

---

Hmmm. Good point. System clothes and skin textures probably aren't cached locally anymore. Not after SSB. Didn't think about that.

Shouldn't be that hard to work around that problem though. I can think of one method right away but I don't suppose you want me to post a detailed description here

---

Theresa Tennyson wrote:

As far as appliers, have you

tried

opening a no-mod, no copy notecard you're not the creator of, which is how they are set up in an applier?

---

I've certainly run scripts to read no copy/no mod notecards, yes. Such a script is child's play for any half decent scripter and what else can you do when that thing you bought on MP came with a notecard named "READ ME! VERY IMPORTANT!!! (no copy, no modify)"?

I have not tried using a notecard reader script for an applier nc but I have the development kits for all my mesh bodies and body parts so I know the syntax. There's nothing fancy there at all, just a few lines with the UUIDs and alignment vectors.

There is only one way to make data in a notecard unreadable for a script. That method would have made it unreadable to the applier script too so it won't work in this case. And anything a script can read, it can say out loud in local chat or in private to the owner. Once it's done that, all you need to do is copy, remove time stamps and paste into a brand new card.

[Sassy Romano]

This is about an applier of a texture to a mesh body, ssb has no play here.

Reading a script from a notecard, no problem, intercepting a channel, not always a problem either.

[Bobbie Faulds]

Actually, Omega/Belleza/Maitreya/Slink, etc appliers use UUIDs in scripts now. I think only the actual Tango appliers and PhatAzz still use notecards. 

[ChinRey]

---

Bobbie Faulds wrote:

Actually, Omega/Belleza/Maitreya/Slink, etc appliers use UUIDs in scripts now.

---

Oh. So they finally closed that security gap then. Maybe we'll see the end of those no copy appliers too then. They can be a real nuisance but many clothes designers use no copy notecards for their appliers apparently because they believe that makes them harder to copy.

[Theresa Tennyson]

---

Sassy Romano wrote:

This is about an applier of a texture to a mesh body, ssb has no play here.

Reading a script from a notecard, no problem, intercepting a channel, not always a problem either.

---

The OP and Chin's reply were about applying legacy clothing to a mesh body and getting the texture from a piece of legacy clothing,

[Bobbie Faulds]

You cannot legally get the UUID of texture templates from legacy clothing. The best you can do is ask the original creator. They may be willing to give you a copy of the clothing if they are no longer in SL. 

[Sassy Romano]

Yes I realised that after my reply but on a phone, couldn't be bothered to edit. I'm going to have another look but am away from home at the moment, I can't remember when I last looked at this, whether it was pre or post ssb to be honest.

 

One thing though, depending on the clothing item and the texture, a baked version would still work anyway, just fine. Think about it, wear just the clothing, you end up with skin plus clothing bake, which you then apply to the mesh, which would also have the same skin texture.

 

 

[ChinRey]

---

Bobbie Faulds wrote:

You cannot legally get the UUID of texture templates from legacy clothing.

---

Legally is the key word here I suppose.

But, oh well, I just had to check this out and right now I'm actually in shock. I already knew ripping textures from SL was easy but I didn't realize how easy it was.

It took me about two minutes of Googling to learn how and once I had done that I was able not only to read the UUID of every single texture and sculpt map that had been anywhere near my avatar recently, I could also open them with an image editor and do anything with them that I can do with any other image file I have on my harddisk. There was even a handy function to automatically remove alphas from sculpt maps!

System clothing or mesh body clothing? It didn't matter. All the textures were readily available. I didn't even have to wear the clothing myself. It's enough to spend a minute in the vicinity of somebody who does. System clothes and skin textures are still downloaded btw even though there shouldn't be any need for it after SSB. (Textures for mesh bodies and clothing obviously are downloaded since they're not included in SSB anyway.)

I thought at least you had needed some sort of sinister hacked "copybot" viewer but I used a prefectly standard official viewer. Then I tried with Firestorm, with Singularity and with that obscure one that is my personal favorite and it was all the same. All textures were already there on my harddisk, identified by their UUID and available for me to do anything I wanted with.

I suppose we're a bit outside the topic of this thread now but this is really serious. Seems the only way to protect you IP rights here is to keep a close watch on every new listing on MP and in inworld stores and keep filing DMCAs. But then there'd be no time left to actually create anything.

LL isn't going to do anything on their own initiative of course and even when they get a DMCA, there doesn't seem to be any real punishment. I checked some of the older posts at some on the blogs dedicated to revealing copybotting in SL. Then I looked for the MP stores of the repeating offenders. The items listed in the blogs were gone but the stores were still there and full of equally suspicious looking merchandise.

Right now I just don't feel like making anything for Second Life anymore.

[irihapeti]

---

ChinRey wrote:

Right now I just don't feel like making anything for Second Life anymore.

---

can be a bit depressing for sure when first realise the full extent of the futility of DRM systems. That they dont work bc they cant actual work in practice. That they a waste of space pretty much

however, I think is best to remember the words of Pamela, who is a veteran of this environment. Pamela's words are:

"I dont make stuff for dishonest people. I make stuff for honest people. Is honest people who get me up in the morning and who I go to work for every day"

[irihapeti]

just about DRM 

 

more specific, encoding strings (which UUIDs are)

 

can easy enough make a inworld/web public-private key encoder/decoder. The prim/mesh model has its own private key to decode the string encoded with its public key. A public key which anyone can have. Applier makers, etc

 

for channel transmit then can further size encode it (the UUID) down to a 9 char (18 byte) unicode string

 

altho when it (the resource pointed at by the UUID) hits the user computer then the inworld/web DRM is broken

 

 +

 

eta 9 char. UUID

[ChinRey]

---

irihapeti wrote:

can be a bit depressing for sure when first realise the full extent of the futility of DRM systems. That they dont work bc they cant actual work in practice. That they a waste of space pretty much

---

 You have a point there. Even so, there are a few simple things you can do to make it a little bit harder to rip cotnent without interfering with legitime use. The most ridiculous part of this is that LL actually seems to have made a half hearted attempt to include some sort of copy protection. The cache files are actually re-encoded in a special proprietary file format. That's simple, basic DRM. Adds a little bit of extra processing time and isn't nearly enough to keep hardcore copybotters away. But at least it'll keep everybody and their uncle from ripping content. But then the made that file format public. In other words, they locked the door and put up a big sign telling every casual bypasser where the key is hidden. That makes no sense at all.

---

irihapeti wrote

however, I think is best to remember the words of Pamela

...

---

 Or to put it simpler: "Don't argue with the weather".

You either learn to live with it or move to a better climate. I don't have to like it though.

Come to think of it, this means I'll have to correct a post I made in another thread a few days ago...

[irihapeti]

---

ChinRey wrote:

---

 You have a point there. Even so, there are a few simple things you can do to make it a little bit harder to rip cotnent without interfering with legitime use. The most ridiculous part of this is that LL actually seems to have made a half hearted attempt to include some sort of copy protection. The cache files are actually re-encoded in a special proprietary file format. That's simple, basic DRM. Adds a little bit of extra processing time and isn't nearly enough to keep hardcore copybotters away. But at least it'll keep everybody and their uncle from ripping content. But then the made that file format public. In other words, they locked the door and put up a big sign telling every casual bypasser where the key is hidden. That makes no sense at all.

---

---

public obfuscation systems (which is what this is) serve the same purpose as a sign. We either respect it or we dont. Most people do

 

those who do respect signs tho dont even need a sign really. They know what is theirs and whats not. They know what they have licensed as well and the purpose for which they have licensed it. So they respect that as well

 

sometimes can seem that everybody in the whole world is a thief. specially if you own stuff gets hit by thiefs. Is not true this tho about everybody. Most people dont ever pinch anything

[Sassy Romano]

Thanks for checking that, saves me the bother. I didn't think it had changed since the introduction of SSB. That really was a half hearted and huge fail as far as I'm concerned. Especially since it arrived when mesh was really starting to take off. The need for SSB diminished and the problem of floating heads, transparent bodies, failed downloaded mesh, slow to download mesh textures arrived and SSB didn't even deliver only a single baked result but still seems all textures.

 

[Sassy Romano]

A private key known only to the receiving script does nothing since my original statement was that the texture would still end up in cache with the filename being the UUID.

 

Obscuring the communication inworld adds no security.

[ChinRey]

---

Sassy Romano wrote:

...

and SSB didn't even deliver only a single baked result but still seems all textures.

---

I don't think those textures are actually used for anything. They're just downloaded for the benefit of copybotters and to fill up spare bandwidth and texture cache.

SSB did improve the rendering of system avatars considerably so it was a genuine improvement. But as you said:

---

Sassy Romano wrote:

... Especially since it arrived when mesh was really starting to take off.

---

Yes but how could they have known? This was before they started listening to their customers, remember.

I'm looking for an old post by Meduhe Simoni but I can't find it right now. It was a lengthy explanation of some features he thought was essential to the Sansar avatar and at the end he said that although those features would cost a lot in lag, not having them just meant that others would come up with even costlier workarounds. That is of course exactly what happened when LL failed to listen to the countless suggestions and requests for an SL avatar upgrade.

Outwards Ebbe Linden is always positive and very, very diplomatic. But sometimes I can't help wondering, what do he and Oz really feel about the mess they inherited and have to clean up? I guess we'll never know the answer to that.

[irihapeti]

---

Sassy Romano wrote:

A private key known only to the receiving script does nothing since my original statement was that the texture would still end up in cache with the filename being the UUID.

 

Obscuring the communication inworld adds no security.

---

yes

i just show how people typically go about this when they try to make DRM systems somehow

the fail point is that the transmitted message cant be kept secret from the receiver, for the message to be understood by the reciever. Which is your point and I am agree with that

[Sassy Romano]

---

Bobbie Faulds wrote:

You cannot legally get the UUID of texture templates from legacy clothing. The best you can do is ask the original creator. They may be willing to give you a copy of the clothing if they are no longer in SL. 

---

Well... here's the question, how will you NOT legally get the UUID of texture clothing if you log in because I wasn't going to respond to this at the time as I hadn't confirmed what I still believed to be correct.

Merely by logging in and wearing or even viewing textures around you, by undertaking not surreptitious activity, you have legally obtained the UUID, it's sitting in your cache.

As far as claims, lets think about it, if the original creator does not provide an applier and the end user uses the UUID they have been given by the viewer, there's no loss to the creator either.  Pretty pointless the orginal creator having a hissyfit about claiming for damages (NONE) for something the end user has not done anything underhand in being given.

Now, if this fabricated applier was to be sold and profited from then I have a different opinion but in the context of the OP's question, my personal view is that as long as LL force the UUID into the customers possession then one has to question the security and implementation of the viewer first and foremost.  This is not exactly a new problem!

[Sassy Romano]

---

ChinRey wrote:

---

Bobbie Faulds wrote:

Actually, Omega/Belleza/Maitreya/Slink, etc appliers use UUIDs in scripts now.

---

Oh. So they finally closed that security gap then. Maybe we'll see the end of those no copy appliers too then. They can be a real nuisance but many clothes designers use no copy notecards for their appliers apparently because they believe that makes them harder to copy.

---

Presumably the scripts contain the UUID's which are accessed from a main script which does the comms by using link messages?  Otherwise there'd be absolutely no point in this whatsoever since anyone could just read the script and pick out the channel (or derive the channel algorithm) and then create a listener for it and any other.

However, as I pointed out earlier when I mentioned the HUD I created (where I encrypted my comms for fun while knowing it was somewhat pointless), it STILL does nothing to protect the UUID, nothing at all.

*shrugs*