Sculpties, Copybot, and Prim Mirror scripts

Isn't it true that with even a very simple sculptie, various flavors of copybots and mirror scripts will not work? I don't believe there is any way to read the sculpture map texture off a prim any more than you can read any other texture (modulo permissions etc.).

Doesn't that kill all the copy methods as long as LL keeps the same protections on surface mapping textures as they do on coloring textures?

i'm unsure if it will stop copybots, after all it copies the textures on prims perfectly well.

however, they will have a much harder time with them as the textures will have id and permissions set to the creator. Textures, even if you can copy them, are still copyrightable, whereas prim settings can be argued to not have that kind of IP protection .

If the sculpted prims are handled client side, with textures being sent down as with normal textures, there's nothing to stop that texture being saved by the client. Even running the official client, it's possible to grab textures as they pass through a modified openGL32.dll

I don't know if that's happening, it seems like some of this stuff is being handled server side, and is just passing down the description for how to draw the prim, which is pure geometry.

you can capture the geometry, but I'm not so sure about the texture, as its not actually something you see.

copybots and prim mirror scripts don't work client side, so that's a different ball of wax. well, maybe copybots. But sure not prim mirror scripts.

I don't think that's correct, copybots may be able to copy textures as displayed, but the mapping texture isn't displayed as such, it just defines the surface.

Ah yeah, not being renderred could be a blocker to grabbing it that way. All depends on the implementation and whether it's processed by the graphics system.

Either way, I'm sure it wont be too long till we see new tools for ripping off sculpted prims

I should correct myself from "server side" to "sim side"

No prim comes down with its prim settings, they just come down as geometry. So that part I'm pretty sure hasn't changed.

It doesn't really matter if you can copy it, at least to me. I'm more concerned if you can "copyright" it, which is an utterly different ball of wax.

I don't think regular prims are copyrightable, given my experiences in other areas. Textures and mesh models are way more complex, and due to their needing the artistic process other than twiddling dials, have claim to copyright.

yes you're right.

you could I'm sure, rip off the geometry and then rebake its sculpt texture - but you would again run into the copyright issue, where a person can file a DMCA pretty easily.

something to bear in mind, none of the cheating methods are particularly easy, and if you have the skills to rip off geometry, you likely have the skills to have made it in the first place. Which tends to damp this kind of thing.

Right, but that's because the display system is actually displaying the texture, I don't think the mapping texture is used like that.

I'm not sure how the client will be displaying the sculptie, it depends on if the client side information is identical to or can be transformed into the texture needed to create the sculptie. That's really the question I'm asking, is enough sent over to create a copybot for sculpties?

It's not at all obvious to me that the format of the surface map sent to the client to define the sculptie should be the texture itself. I'd think you'd use something a lot more optimized for fast display, and while in theory it might be possible to transform that back into a texture, it might be pretty hard and likely not worth doing. The format could also be easily changed with new releases to disable any existing copybots if LL wanted to protect resident's IP.

It nevertheless has to be transferred to the client, since the mesh deformation that results from it is handled client-side. Anything and everything transferred to the client is susceptible.



.

Not sure I understand what you are saying exactly, but prims do in fact get transferred to the client as prim settings. I can watch and peek at the data for the scale, cut, particle effects, hover text, literally every possible prim setting. As a prim setting.

The client itself takes that data and converts it to renderable geometry.


.

ah, ok, so that works for copybot, but not for capturing off a graphics card.

If the textures are being sent to the client, could be susceptible in the same way textures on a prim are.

But IIRC, the texture on a prim copied via copybot is not making a new texture, it's using the texture already uploaded to the system. In which case you see who made the texture.

I disagree. The tools and skills required to copy other people's work are quite distinct from (and perhaps easier to acquire than) the artistic skills necessary to create original work.



.

That is partially true. A naive implementation would simply re-use the texture UUID, but since the texture data itself needs to be transferred to the client it's possible to re-upload that texture data as a new texture.

Even then, though, it's easy for people to visually identify both as identical, and to report it as such. Once identified, it would be fairly easy for software to verify, and now that we have creation dates stored with our assets we have better means of documenting original works than we had before.



.

couldn't you just use the UUID of the scluptie texture in your own prim to copy it?

Hmm... I wonder. That would require that the Lindens provide the ability to do so via script, or custom client-side tools that would do that.

Either way, theft of other people's hard work will always be something we as a virtual society have to fight against, and the fact that we don't see many more cases of things like CopyBot is probably a testament to the idea that there are more people that are basically honest than those that arent.

I've had people copy and outright steal from my products, but very rarely compared to the number of people content to just buy and use them. Even the people who copy my stuff are mostly the type that just do a "ground up" copy, I've yet to see a prim-for-prim and texture-for-texture copy of anything I make.

From everything I've heard, DMCA is not nearly as effective as we would like it to be, but I strongly feel that there will be better remedies available to us going forward.


.

I don't see why they would send the UUID to the client. It seems like a pretty minor optimization for a 32x32 texture to try to avoid reloading them.

I don't know what video cards like to get to render surfaces, but I suspect it's not textures, so whatever is being sent it may not be a texture anyway. Not to say it couldn't have a UUID of course, but as above, it's not a lot of data and it's not obvious that the same shape would be used many times to make it worth caching.

If they are sending UUID's though, that would be an invitation to IP violations that I would think would be very difficult to do anything about.

I vehemently disagree.

And this is the same argument that many tekkies/coders on these forums allude to in their egotistic efforts to prop themselves above, or atleast to the same creative level as the talented creators in SL. Creative talent/expression and technical knowledge/skills have nothing at all to do with each other. One can, of course, have both but they are not naturally inclusive of each other no more than one should expect for an artistically creative individual to be able to code and understand technical babble.

This isn't meant to demean the tekkies and/or coders of SL for they are talented in their own right. Its just that, like singing and painting, they are just simply two different types of talent. One has to do with technical know-how/expertise in combination with perhaps ingenuity. The other has to do with artistic vision and creative skills to carry that vision from imagination to creation.

In other words, Just because as a technically gifted individual you may have the skill to to "copy" a creation does not mean that you would have been able to "create" that creation had you not seen it.

What many people underestimate is that the actual thought process that goes into the concept creation thought process and the ability and talent to be able to bring that vision to tangible fruition is worth "considerably more" (understatement) than the creation itself. To assert that because someone who is possessing of the technical skills to be able to "recreate" a creation is likely to have the skills to have made it in the first place is preposterous, and dismissive of the talent and efforts of the original creator.

1) Prim geometry does indeed get sent to the client in the same form as you see it in the viewer editor. In fact, there is quite a bit more information about the prim that is sent than what you are seeing in the editor.
2) Sculptie geometry is just another texture, which is sent to the client to be loaded via UUID; the image data is not sent along with the prim data, which can result in inefficiency, since you could use the same sculptie image normal map for multiple prims.
3) Copybot-like mechanisms will be able to copy the sculptie image just as well as any other image.
4) Prim mirror-like mechanisms may also be able to copy the sculptie image, if there is an equivalent ability to retrieve the UUID with llGetPrimitiveParams or whichever function it uses.

Bottom line: don't expect sculpties to be any more resistant to technical copy measures than any other prim/image/sound/animation data. If the viewer can download it, it can be copied. Stick to the ability to determine bona fide copies, and zealous and judicious use of the DMCA process to put a stop to it.