Prim Preview / libprimrender

I got excited when I figured out enough OpenGL code to demo off libprimrender, here it is:



The Funkbot 9000 on libsecondlife's plot in Hooper was exported to XML using TestClient, and opened up in Prim Preview. Nothing really useful at this point other then demoing off the first (100% complete) standalone implementation of the prim rendering system that Second Life uses. If you think this could be useful for something (saving prims as .OBJ format, previewing how different LODs affect objects, etc) let me know.

Oooooh! This should come in handy for the folks that want to move their stuff over to another virtual world that supports .obj files. That's when we get another virtual world that's worthy of the trouble.

Allthough I think a lot of SL content isn't really worth the hassle and any world that supports meshes will probably deserve better than SL prims. This of course doesn't include sculpties, because we already have those in .obj format.

That's the great thing about prim builds. Nobody outside of SL really wants them and so copyright is rarely an issue. If somebody is wanting to steal content then there's far better 3D worlds to go steal it from.

We're all safe in our crapness.

arnt they talking about SL hopping VR worlds. If this is the case taking your content wil be simple to copy and save. without breaking copywrite laws.

Export as .OBJ, .X, or .3ds would be swell.

Eddy, would the results of saving prims in .OBJ files be significantly better than what OGLE can do? If so, I would be very interested. See my post Exporting SL models to RL design tools (/8/73/231170/1.html) for the context.

Incidentally, I was talking with a RL academic architect today and he said that among many of his colleagues, Active Worlds is viewed as superior to SL, solely because of its I/O capabilities.

Significantly better, yes. You get laser-precise accuracy on what you want exported with no post-export cleanup, and you can specify the level of detail to use in the final mesh when going from PrimXML->OBJ.

There is also the possibility of maintaining a correlation between the .OBJ file and the PrimXML that generated it to setup a texturing workflow through professional software like Maya or BodyPaint3D. That's the idea I finally settled on and this is the direction I'm taking it:

Eddy, this is fantastic. You rock, man!

This will solve so many texturing problems. I can't wait to see how you progress on this.

So where is it?

svn://openmetaverse.org/libsl/libprimrender/

When things get a bit more interesting (OBJ export, face support in libprimrender, texturing support in the interface, etc) I'll look at compiling binaries for general purpose consumption. Unfortunately the holidays are just getting started here and I'll be out of action for a week, but I'll be back on this in a week to get something going.

Simple OBJ export appears to be working now, per face rendering is done and simple texture mapping in the interface works. Adding texture export from Second Life is needed before I can get any fancier with the texturing side of things, but once that happens I can finish the OBJ export and do an early release.

so I have to d/l something just to get to see this then?

Yes people , there is a world that does not makes the mistakes linden does. I don't mean linden is not that bad, but they are going to slow. I have seen a test on Multiverse with 3000 avatars running on the land , fully build and Lagg is a word they don't know over there. Not only that, setting up your own server on multiverse cost 1/3 of the price you pay for 65Sq sim from linden. I have to admit, building in SL is more easy, and some other things are more easy to in SL. But that is soon going to change with multiverse to. Being your own linden on your own land is what people seek, not paying a lot of money for you land is also what people don't want. Well , Multiverse is the answer. Linden is going to make it possible to set up your own server on there nework (as I heard) but it is expected the soonest as 2009, and I think that is to late for competition.

umm...lag isnt only caused by the platform you know. To do that, every one of those 3000 need internet capable of it. Period.

You can't just build a faster world and have it stream all of that with no lag no matter what your internet is, I'm sorry but.. it doesn't work that way.

Have fun in your imaginary world

And in SL, you're paying more for a sim because they set up the server, they do the support for it. Setting up your own server actually means you can have more space (Assuming its a server equal to the ones at linden labs, which have 4 sims each). However, if it is your own server, and you're just routing it through their IP or something well.. they arent going to offer a damn bit of support when you do something stupid. They aren't setting it up for you, you're doing basically everything we pay LL to do when we buy a Sim, and then you're also doing all of the support for it. No wonder its cheaper : people have jobs just running servers for websites, try troubleshooting a fully resident-run and set up server with the speed (Yes, speed!) and knowledge LL has... you wont have much time to build.

\o/

Eddy, this looks like it is going to be really useful, and your timing is perfect from my point of view. I'll try building it and doing some tests this weekend. I presume your svn source is compatible with the 0.3.2 release of libsecondlife. If otherwise, let me know.

So let me be the first to ask the obvious, looming question:

Is this going to be used to steal content?

What?

When?

Shakes fist!

I got the the code from the libsecondlife svn, tried it out on one of my objects, and lo and behold, it worked! Not perfectly, but the model was recognizable. The two problems my simple test showed up are that cylinder caps are missing, and even vanilla torus and rings aren't being converted quite right. But this is going to be a boon for architects. Great work, Eddy.

Would you like bug reports filed on Open Metaverse, or is it too early stage for that?

I think the question is quite simple. I build something in SL, and someone comes along with this and converts it into an OBJ and starts selling it on TurboSquid or something. It's called theft.

Or takes something from Turbosquid and sells it in SL.

Darien, you seem to assume that the tool won't respect SL permissions. While it is perfectly possible to make one that doesn't, I haven't heard Eddy say that is his intent.

There are very legitimate uses for tools that can move content from SL to RL. In my case, it is in support of architects using SL to collaborate on designs and then actually using the models they create. Can you imagine an architect working without a photocopier? Even though photocopiers can be, and are, used to make illegal copies?

Sorry there, I overlooked the mention of OBJ export
Seeing as how render code could be one of the greatest things to ever happen to libsl, I think maybe the discussion of obj export should be separated >_<

I respect what it can do. However I'm also concerned with what it can do. I'm not a luddite by any sense. Truth is if anyone wants to steal something from SL, it's remarkably easy. I figured i'd bring up the issue, because sooner or later, it will be brought up. If it's going to respect permissions, thats great. I didn't see anything to indicate it however. If it was said I must have missed it.