3DS/MDL/OBJ support

This is probably not the first time this has been suggested so my apologies if it incites the urge to flame. Just try and resist.

Building in primitives is a great idea and makes construction accessible to a lot of people, but why is there no support even for uploading custom AV models? Ok I understand they probably wouldn't work with the resizing and clothing texturing, but they could fairly simply be incorporated into the animation system?

AV's I can see how there would be a fair few problems incorporating into the game. But basic Objects? Seems like that should be fairly simple.

Ok here are the problems as I see them, and my suggested solutions.

1. Custom meshes (3d models) would have to be uploaded, as opposed to taken from your hard drive presets.

Solution : this really isn't a problem in a game that already supports custom textures, by far the largest asset for a 3d model would be the texture anyway, by several orders of magnitude.

2. People would try and upload planet sized objects.

Solution : Simple. Just make it so the export tools or upload tools refuse to accept a model that won't fit inside a 10m x 10m cube. Want a model bigger than that? then break it into sections smaller than 10 x 10 and re assemble it in game.

3. People will try and upload a model with a quadrillion triangle count (triangle count is the number of triangles it takes to create the model)

Solution : Similar to the size problem, make triangles fit a prim budget, say for example 1 prim = 100 tris. so if you have a 5000 polly model, you would need 5000/100 or 50 prims. Try and spawn a model higher than the land will support and just like with prims you get a refusal. Level of detail (LOD) could be taken care of either by an auto lod system, or a method similar to games like BF1942 where each LOD is included in a single file and displayed on a by distance basis.

4. Collision detection

Solution. Either include a collision shape with the model or auto generate one from the model. This is not quite the rocket science some people seem to think

5. People will use no prims and import only objects.

Solution - If meshes count towards your prim count, what’s the difference?


So why use models at all, well, I've spent a few weeks now, looking at the kind of stuff people have put in game, and frankly some of it is out of this world, but to be fair, even the most skilled builds can't compete with a decent quality model. I mean no disrespect to prim build lovers, but the ability to import models, would make the visual richness and quality of this game so much better. Don't get me wrong, I like second life and I'll stick around whatever. but for me, it's creatively deeply frustrating to have to work with prims, it's like being asked to paint with your hands taped together. It's doable, but it isn't going to come out anywhere near as well.

For example this model is under 2000 triangles, using the system suggested it would cost 20 prims, no offence to anyones tallents with prims, but that just isn't going to be possible with 20 prims



Ok there are probably other problems and solutions, and I'd like to here folks opinions. I'm not trying to incite a riot from the prim builders guild. I'd just be interested to see how much call there would be for something like this.

one big problem i see rely on the use of copyrighted work

another is the weight, and yes, textures do not weight that much in sl, at least not bandwidth wise.

no.

I seem to remember a Linden saying that some time in the future it'll be necessary to allow meshes, but at the moment it's not technically feasible.

A lot of people want this for various reasons - I would welcome this functionality myself - but I just don't see it happening in any reasonable time frame.

Copywrite is exactly the same problem as with textures so if textures are used then why not models?

Models use far less bandwidth than textures. for example that 200 triangle tank is a 100k model. The The texture for it, a 512x512 dds compressed texture weighs in at 315k, tho few modern games would use 1 512 texture for a model this size. Texture loading is by far the bandwidth hog

Correction: collision detection is a bitch. Havok 1 solves that problem by usign cubes. On everything. Problem solved.

which is why collision detection need not be a bitch. There's no reason SL couldn't cope with it using the Havok engine. Even less so when Havock 2 is introduced.

Another problem/solution


6. 3D programs are complex and expensive, it would inhibity a lot of user creation.

Solution - Make the importer work with the free versions such as Gmax or maya PLE. Both of which have a huge amount of newbie style support, including tutorials and forums etc

... ... ........

I have officially lost track of the number of threads started for this feature. But it does beg the question: Why do we still have to ask for this? Isn't it par for the course?

linky
It takes too long to list the reasons, so i'll make a short one:

1. LOD is complicated (this is a requirement or the renderer will lag)
   
2. Require more bandwidth to describe the same number of polygons.
   
3. Difficult to transform in a truely dynamic on the fly fassion (unlike llSetPrimitiveParams for prims).
   
4. Memory Requirements (a sim full of unique mess could easily be 2GB).
   
5. Physics
   
6. You have to be a rocket scientist to be able to use Maya.
   
7. Commercial modeling tools are expensive. Nobody wants to shell out that amount of cash just to build a house.
   

Every month, without fail, someone points out another cool page on the scripting wiki I haven't seen. Thanks Strife!

I'm kinda surprised nobody's mentioned skeletons yet - that's gonna add another, what, four or five variables for every joint? More if you're using IK or any other kind of dynamics.

Custom Skeltons is a project of mine, the project has been mothballed till i have some time (and when i develop the ability to not be driven totaly insain by poser).

There are a number of hurtles in the way of such a project
1) AV mesh textures are hard coded, you cannot add more.
2) AV color groups are hard coded, you annot add more, despite the fact that it's easy as pie to define them in the XML file.
3) If you add custom morphs into the XML file it upsets the client, it gets confused as the number of attributes it expects from other clients doesn't match what it gets sent.

Basicly, you cannot provide a unique texture, you cannot change it's colors, and you cannot morph it (unless you hijack another morph).

This is the one part of the back end that is well structured and thought out. Of course after they spent all that time working out how it should work, they hard coded the entire thing; making most of the XML file moot.

Just to show you how much LL cares, take a look into the clients skeleton xml file, you will see that the skeleton isn't symetric. Can you say lazy?

The av back end has only been changed a few times since Beta. Mostly for bug fixes and adding skirts (no they did not have to change a thing to get animations to work for 1.4; the client already supported them).

Sounds fun. I often wish I'd kept up completely with my coding, rather than trying to go the half-assed "new media" route.

I'm guessing that your project would only be affecting local data, like hacking the mesh deformations does, rather than changing something everyone can see?

thats great but SL uses jpg 2k, so your 315kb image now jumps in the range of only a few kb

the problem is (from what i gather) not transfering them from point A to point B its fetching them from the central asset server, which in a common SL scene can add up to THOUSANDS of textures, add in thousands of unique meshes and the system would probally cry

While I usually agree with you, Strife, this time... well.

On LODs: I have in my possession a little research paper on how to fix that problem simply and effectively. I don't know if it's been published in the public domain yet, so... let's go with what we already know, shall we?

Meshes do allow for decomposition algorithms. If you would be working downward, you could effectively build one, or at worst two, levels down from the original mesh object. You could also throttle the maximum number of faces easier than you can with prims. This is a major asset when dealing with large, mesh-based structures.


On more bandwidth, this is also debatable -- especially when you include textures and several of the primitive params that have been added as "cruft" to the system (llParticleSystem anyone?).

Let's take a tree model that I have packed into MS3D format (binary, no compression). At 240 faces, it falls in the range of about 19kb, with one complete material definition, custom UV definitions for every face, and null bone structure. Make of that what you will.


Define "transform on the fly." Actually, from rewriting the prim code I can tell you it'd be quite easy to do transforms like twist, top size, top shear, and so on and so forth. Cut would be a tad odd... but uh... why would you want it?


Memory requirements? Again, a hard figure would help. Putting a detailed mesh against hoochie hair is a rather difficult comparison.


And uhh... Maya? Expensive modelers required?

Dude. I use Blender, which is free and comparable to Maya in a lot of ways. And if you want an easy way to break in and do 3D modelling? Anim8or works well and is, again, free. So this is just not true.


At the end of the day, the only bars I see against getting meshes into a world like Second Life are time and perceptions. Prims have one major utility, in that they are easy to understand.

This does not mean that prims should be the only means of developing content for Second Life. In fact, they alone provide a high barrier against bringing more professional content into the world. And that doesn't help anyone.

Exactly, Jeffrey. LOD isn't that difficult with mesh models - the only difficulty is in splashing textures on the reduced mesh. I've been doing the planning for a mesh decimator for another project, and I have to say, it's simpler than all the prim math.

yes but can you transform your tree into a motorcycle, without having to predefine it into the mesh?

The prim definition is variable in size, the smallest definition i've seen is 90 bytes and the largest is 250 bytes. For arguments sake, lets say it can grow up to 400 bytes.

A full 255 prim object would range from 23k to 102k. I've taken some time to look at how LOD can be done, some of the algs are pretty cool, like allowing different LOD across the mesh (and the math is mostly over my head). My understanding of all of them, is that they require alot of CPU time to do the LOD on the fly, and encoding LOD information into a mesh is not optimal (like tagging vetexs).

If memory serves, a sim can handle 30000 objects (15000 on the ground, 15000 attached). Or about 12mb to store a full sim.

Lets take your tree, Lets say we equate 10 faces as a prim. So your tree would be 24 prims. Fill a sim with unique objects just like it and you get 24MB.

Compression is a moot point, you still have to decompress the model before you can display it, and all that decompression can add to render time.

Theoretically, yes. But it would have to be done at the OpenGL level, and would involve "best guess" addition and subtraction of vertices when moving between the two models.


$195 a month for 12 megs... ... .... and a ton of bandwidth. Uh.

Now hold on there just a sec. Don't sims also cache textures? And, for that matter -- are names, descriptions, and UUIDs included in your byte figure? If so, I'd be interested in knowing just how much of that space they rake up.

If LOD is the problem then get rid of LOD. The current one in SL is godawful anyway. Or am I the only one tired of looking at shapes snap between LOD levels in a very slow and visible way as I move the camera around? And from watching fast timers, it's an expensive operation too. Maybe I would even get better framerates, or at least less hiccups, without LOD.

Not using LOD on meshes would give you an absolutely terrible framerate in SL, there's waaay to much stuff. Having pre-calculated LOD meshes would actually switch them a lot quicker than SL's dynamic LOD.

I've always thought a progressive thing for meshes like the way progressive JPEGs load would be good for SL, with the models streaming in and appearing first at their lowest LOD then scaling up, the vertices from lower LODs being used for the higher LODs or something.

My solution:

Limit the amount of polys & size of mesh.

Physics? Dont know.

Rocket Scientist to use Maya? Nope!! Got it. Use it. Maya PLE is available for many, Maya
is highly scriptable itself and there are tons & tons of online tutorials and books.

Expensive? Yep! It can be. You can either go with Maya PLE (free), Maya Complete (about $5000), Gmax is gone. There's Wings 3D and other free 3D modelers also. OR just go the warez route. 3D Studio MAX would be another useful 3D tool. Not as expensive as Maya either.

Use Blender. It's safer.

I believe it'd actually be illegal to use Maya PLE if you intended to sell anything in SL, but we'd probably have to wait for a court battle to be sure.

I reckon a lot of people would be put off by the complexity of a full 3D app, we'd need to keep prims still. Also, there'd be a huge outcry from all the people who make products to sell in SL but treat that as a game because it'd be putting a lot of them out of business and thus destroying the game (refering to SL) for them. Maybe that's the real reason meshes aren't being implimented - the worry of the effect on the number of users and the like. It's worth noting that a couple of the presentations I've seen made by Philip recently one of the points he's been pushing the number of items created.

I think this is precisely the reason it does not, and will not, happen. Simple greed and complacency in the system. Though holistically, this is not good for anyone.

I wouldn't say will not. It all depends on what people are doing in world, I'd say that as soon as providing entertainment in SL becomes a viable business for "big business" LL will look into implimenting meshes. There's a ratio that's important to this that I can see abstractly, but I've got my head too burried in code at the moment to figure out what it is.

You raise a good point. If the money can get on the other side of the equation, it will be more viable to them.

However, as point of fact, I do not see Second Life as viable to big corporate business. The Wells Fargo gig was questionable; the real problem is the lack of standards and relative instability (and lack of separability) of the system. If I were an investor, I would probably think to invest elsewhere today. Including building a platform from scratch.