primexport

Blog post about it here: http://www.jhurliman.org/index.php/2006/exporting-prim-data-from-second-life/

Post your thoughts and comments on security measures (or the lack thereof) that should or could be implemented, and what, if any impact it could have on SL.

When trying to comment....

Warning: mkdir() [function.mkdir]: Permission denied in /var/www/servers/jhurliman.org/wp-content/plugins/openid/openid-classes.php on line 101

Warning: opendir(./tmp/) [function.opendir]: failed to open dir: No such file or directory in /var/www/servers/jhurliman.org/wp-content/plugins/openid/openid-classes.php on line 401

Warning: Cannot modify header information - headers already sent by (output started at /var/www/servers/jhurliman.org/wp-content/plugins/openid/openid-classes.php:101) in /var/www/servers/jhurliman.org/wp-content/plugins/openid/openid-classes.php on line 360

Aheh... hoo boy. Guess I'd better get to work on textures quick, huh?

Thanks for the heads up, I think it's fixed now.



DXF, OBJ, 3DS, etc are mesh formats, not prim formats. They can store an infinite number of types of shapes made up of small triangles that have no direct way of being represented in Second Life. Second Life prims are a procedural style, where there is a set of instructions saying how to create the objects rather than describing all the faces of the objects themselves. You need a modeling program that supports the Second Life procedural instructions, of which currently there is prim.blender and a Maya plugin in early development.

I'm surprised there hasn't been more said here...

This is a tricky one. If you put in permission safeguards, how long before someone else with less scruples makes something equivalent without safeguards?

I think this is inevitable, but I think it will cause a lot of trouble. I guess its only a matter of time until someone comes up with a ripper that does prims and textures, and an importer for the same. Then all that's left technologically secure (at least theoretically) is scripts and avatar shapes/attachment locations.

The exporter/importer with texture support isn't really difficult at all. The libsl importer would just need to be polished up a bit, since libsl already supports uploading and downloading textures. The only roadblock is figuring out how to get texture support in prim.blender, and finalizing the xml format of texture storage.

Scripts will always remain secure unless LL changes something. Avatar shapes never were secure and there is a program to export those (along with the baked avatar textures) right now. Attachment locations are only secure because no one bothered to write an exporter for them, but it could be useful once the external tools have matured.

AFter spending a week and a half building a furry avatar, I have to say...

regardless of how easy it becomes to eventually import and export models, regardless of how easy it is to scrape OpenGL for textures as they download to your client... regardless of how easy it is to copy and modify stuff...

There will always be a market for well made avatars and objects....

Because if building my own furry taught me one thing... it taught me that $L900 is really a great deal.

Pretty much; the cat seems to be already out of the bag. Matter of time before someone puts the "grab yourself a copy of anything you see in SL" on sale to make themselves some fast L$ :/

Ah of course, the avatar mesh is just another prim.

People still pay for web design services now, but it's a custom market rather than a mass market. People pay for music, which is a mass market, but there is also a huge amount of music sharing. I think that's a better analogy for where prim and texture design will go in the future.

I agree, a custom designed avatar sets you apart from the rest of the world and that market isn't going away any time soon. What is worrying though is things like pre-fab homes in SL, where the same objects are sold in bulk. As Seifert mentioned, things might go the way of the music industry where the business model isn't destroyed, but it does have to account for IP piracy.

I doubt economy of scale is going to make SL anywhere near profitability of music industry, here. A few thousand/hundred/million people sharing the music they didn't pay for are a fraction of total market, in SL a few dozen lost sales can mean loss of profits one makes in month or more Add to it the environment where people can rip and then resell others' work pretty much with impunity... and it looks rather grim.

Well, the Limitation to use Prims and nothing else is the Number one Design
Mistake in Second Life itself.
A well done low-polygon Object pwns a 100+ Prim Sculpture any Day, it looks
better, its less Data to transfer and its less Triangles for the poor 3D Card to render.

Back on Topic : its a well known Fact, everything your PC can
Play / Show / Display can (and will) be ripped / stolen and
given away or sold.
What content creators really need is some Safety that Copyright Violations
are Dealt with. This might work more or less in the US, where even Kids are
punished hard for some illegal Music Downloads...
but in certain other places, People laugh about Copyright and there is no
real Market for expensive (better say overpriced) Original Media.
I remember visiting a CD shop in a certain eastern Nation, where they sold
100% CD-R... no Originals.. in the Middle of a City...
Do you think these People will respect Intelectual Property in SL ?

Actually thats not entirely true. Not everything stays low Polygon. A sphere for instance is a horrid horrid thing in a 3d program and if you cut down to much you end up distorting the shape of it badly. The things done in SL were done that way to make them cause less lag and pull less resources. To be able to do anything higher really would end up requiring SL to essentially be stored locally on everyones machine. We would then need an update everytime new content is added to the world and it'd create hell. LL were smart in the design of it in all honesty if you know a bit about 3d objects actually being inside SL's enviroment. The method your reffering to is what is commonly used in Locally stored games like WoW and FFXI or any other mmorpg you can think of. The problem there is you dont have the stuff streaming TO the person in these situations.

SL relies on streaming and the more data (please note most of the more complex things done with polgygons would be horrid for data compared to sl's) would end up causing more resources to be pulled on the sims end. While the client side may not lag as much the servers would.... Also im confused why would you export the 3d object to apply textures because its not going to make jack of a difference once its imported back into SL as quite simply it still needs the texture data which needs to be a uuid or the name of the texture itself inside a script or the texture applied directly to the prim.

I dont see a point to it other then having the build outside of SL. Which could lead to theft and other things.... Yes if your doing it security measures should be taken to retain someones rights to hold onto their build. You would have rampant theft otherwise. It's basically stealing from the original builder...

If you've used programs like BodyPaint and Photoshop alongside Maya and 3DSMax, you quickly see why the texturing in Second Life is a final step, "slap it on and call it done" process, instead of part of a content creation workflow. However, I enjoy creating objects in Second Life vs. prim.blender. Some people enjoy prim.blender more, it's a personal choice. And ideally, third party plugins and programs will leave Second Life in the dust as far as building tools go. But when it comes to texturing, Second Life isn't in the same league. So if you can build something in Second Life, export it and do the texturing process (painting right on the prims in a 3D painting program lets say), then reimport the prims and upload the final textures, I think that would really take content creation to a new level.



What sort of security measures do you think would be worthwhile to protect the situation you brought up (someone exporting objects they did not create)? Should you be able to export objects you have modify rights for?

Trusted platforms are comming where you won't be able to run stuff unless the drivers are signed by the all mighty MS.

LL will have to encript the data stream and the stored cache data.

Lib secondlife will have to change to a model where it uses a loopback port to the SL client. The client will then check permisions before passing the data on to lib second life.

Big brother is here.
Long live the DMCA

I give that all of five minutes if it even happens, honestly. No professional in their right mind likes that stuff. And if Microsoft et al alienate the talent, they're going to lose the market. Nevermind consumers hating it.

Besides. I do so love my linux box.

Err... right. Where were we again?

Way back when I passed the idea by the Lindens, this was their primary concern. I could even forward you the email, too.

Let me see if I understand correctly. This app. doesn't capture the post-render smoothing the client sees. Like if I capture a "sphere" , the object file would be the 12sided(or whatever) solid polygon you'd see if you set mesh detail to zero. Is that correct?

I ask because I'm looking into porting object data to a CNC machine to cut renderings into various materials. If I read the flow on the specs of your program correctly, then it would not be usefull for my project. I'm looking into the glIntercept OpenGL program pair as an option for now.

As to your question re. security: An ounce of prevention is worth years^N of grief.
IOW Security, Security,Security,first! ...
Bugs, and Bells, and Whistles later.

I think OGLE/glIntercept would better suit your needs, since you are looking for mesh data that can be loaded in a 3D program and eventually fed to a 3D printer/milling machine. The purpose of this program is to capture the procedural data that instructs the client on what to draw. So for example a sphere would be some information saying what size the sphere is, the position of the sphere, what rotation it has, hollow shape and size, cut, twist, whatever. This procedural information can be fed in to an appropriate plugin for modeling software like prim.blender, or back in to the grid through a libsecondlife program or an LSL script.



Security might be the wrong word here because at a fundamental level all of the data is there for the taking, and there is no way to prevent determined people from taking whatever data they wish. But that doesn't mean we have to write software that caters to people wishing to use it for illegitimate purposes. To throw some ideas out there, I could write the software so it only exports prims that have a special LSL script dropped in them, or with a bit of work modify the program so it checks the owner of every prim and will only export data that you create/own. This won't stop someone from editing the source, recompiling and going to town, but there's only so much you can do.