Once you have it mapped to a manifold you need to determine how you are going to cut it up and turn it into a sculpty. This is the part that is complicated. With out doubt the input mesh is going to be more complicated then what SL supports, so the mesh will need to be simplified. How that simplification is done will need user input.

Additionally the user may want the manifold split into several sculpties so as to leverage the extra polygons. This is not easy to do; it changes the manifold conditions and complicates the process of distributing the detail.

After that you need to either convert textures the users supplies so that they can be converted from the old texture mapping to the new texture mapping format or you need to provide a way to export the converted mesh so the user can texture it directly.

Regardless of the mesh type it's an ugly problem.

What is usually used in 3D are plain meshes, which are represented as series of point coordinates. So that the same cube is represented as a set of triple numbers:
0.5 0.5 0.5
0.5 0.5 -0.5
0.5 -0.5 0.5
0.5 -0.5 -0.5
-0.5 0.5 0.5
-0.5 0.5 -0.5
-0.5 -0.5 0.5
-0.5 -0.5 -0.5
... we can add here any number of other coordinates, for any arbitrarian shape.
other numbers define faces, normal vectors, texture mapping, etc.
This is the same with all 3D formats, 3DS, OBJ, VRML, etc which differ just in some writing conventions.
This system allows for any arbitrary shape, eventually very complex, such as a whole building in only one prim, one texture..
NURBS (VWR-7678) are still more powerful, they are mathematical equations defining curved shapes, without mesh.

So, the very first thing to do before uploading standard 3D files formats, is to allow the SL viewer to deal with plain 3D meshes as above, and not just some parmetres describing a small set of shapes.

Once this done, we shall be able to load any plain 3D file format without distorting it. Otherwise, if we load a delicate chinese porcelain plate into our today prims, we shall alway obtain a locomotive wheel.

Technically, adding to the viewer the capacity to read full 3D meshes is possible. The problem is that this would need to rewrite large parts of the viewer, and also of the server side software, and asset database, to accomodate with the new type of prim (mesh prims, not to speak of NURBs).

This would also add some world useability problems:

• A mesh can consume much more resources than today simple prims, so counting prims to evaluate the load of a sim would no longer work. (perhaps meshes would count as several prims, depending on their complexity)
  -One of the force of SL today is the ability to build complex shapes with very simple tools, useable by anybody. We owe this to this simple prims system. Adding custom downloaded mesh prims introduce an elite of people able to do much better things than the others
  -users could load arbitrarily complex and tricky meshes. (again when downloading a mesh, and evaluation could be done), or meshes with defects, such as a cube with missing faces, a thing which makes no sense for the physics engine.

It would however have clear advantages:
-the freedom to create arbitrarian shapes, and many shapes impossible to obtain with just combining the classical prims.
-when people know how to optimise them, one mesh with one texture can be much more lag-efficient than many smal primitives, each with its own texture.

This is certainly a challenge, but I think it is to be considered.

Search the Library for the linden trees. They are complex shapes, which..are one prim. So, I think these are actually a form of imported meshes, as they existed way before sculpties did.

So the viewer is already able to handle meshes, true meshes described as meshes in the database.

Well, this makes much less rewriting to do than I stated previously. But still some work to generalize these two cases.

A beta system would be to be able to download our meshes as... Linden trees. Even if they are not trees at all. This would allow some users to test this feature, before making it more general.

Perhaps the Linden have some concerns about people uploading random shapes, for the reasons I spoke above. But a beta test system creatin our meshes in world as a defined prim type would allow fr some control.

So, with little rewriting, these tools could be made available to all.

it would be a nice gift, really, at a little cost, and a great increase in our SL experience. To be able to have complex and optimized shapes like in closed games.

after, it is not so important which format is imported: 3DM (VWR-858) .3DS (VWR-1111) .DXF (VWR-2527) .JT (VWR-1387) .OBJ (VWR-1110) VRML, X3D, autocad.... Some free softs like blender are able to translate formats (at least it is what they say) and provided they don't lose the texture map and normals in translation, this is OK. Keep in mind that 3DS files need a very expensive soft, so we need to allow for Gmax format too (the same, but for free, for making mods in games).

It is to be noted also that, despites all competitors of SL are still years late (even Google), if one comes one day with such a feature, Second Life would face a serious threat. So it is better to cope with this missing feature before it becomes a problem.

I would like to have a Linden Labs reply on this (making public the tools which were used to create the linden trees, in order to make residents able to import any mesh) and what could be the technical or policy problems against this.

what I propose about safety issues with imported meshes, would be a test, at first rezzing, for lag, physical integrity, etc. The mesh could be refused (with an explanation), or refused to be made physical, or tagged with an equivalent number or prim . For instance it would lag like 5 prims (knowing that it replaces 50). The kind of problem which may happen, are sprites meshes formed of flat surfaces (like trees) of non-closed shapes (a house with no bottom face, as it is never used in rendering) or meshes with 500 000 faces.

Personally, I'd recommend the .nif format, mainly because it's just what I've been working wiht. Although that might be a proprietary, closed source format, in which case it would be bad.

But if I can learn nif, I can learn anything. I'll be glad to spend a few weeks learning to work with whatever format is chosen.

There is no reason to impose a given format, as it is only a matter of simple parsing to convert any format into the system format. So the choice already made by Linden labs to a priori exclude the .obj format (VWR-1110) is just astonishing and completely unexplainable.
Professional artists will want the 3DS, engineers will ask for autocad, gamers will want the gmax, free soft people will want to export from Blender, and the ISO will recomment the VRML/X3D (W3C standard, used in Vivaty).
The only problem which prevents this is that prims are NOT stored as meshes into the inventory, but as a list of parameters. Storing and rendering meshes has to be enabled first.
There are some technical issues too, such as measuring the rendering cost of meshes, and storing a value for it, check for buggy meshes or griefing tools, etc.
This is discussed above in this thread.

I would avoid NIF like the plague, it's a proprietary format with 30 known versions who's public documentation has been written through reverse engineering. The assets weren't designed to be interoperable with each other so there is nothing to stop it's designer from making breaking changes to the format.

and yeah, it's a shame they simply closed the "OBJ" tread,... I mean 90% of the turbosquid meshes ? lol ... even with a 32*32 sculptie like vertex limits I'd be happy , and even some more limitations if they need to have more limitation I'd just go. And even more it's simply ridiculous, the more Obj file it can import, the more people will just steal other's creations and drop it on sl to make money about it. Nah, obj was fine, with 1k limitation stil fine, with whatever LL limitations they wanna add, still fine, as soon as we get something else than sculpties, I mean somethign precise, for me it's a go... And even more, if I'd have to re-learn how to create my builds to fit their needs on sl, still fine... since learning sculpties is plain pita, and even when you mastered them, you just understand that there are things that can't be done, ah, let me dream

-they can be compared, in short, to a sheet of paper folded to give a shape. This works fine for shapes of the potato or fruits family, but is a pain for most other shapes.

-They have an imposed number of vertexes (points). This makes that complex shapes cannot be sculpted, when simple shapes will add unnecessary lag with hidden or very small faces. All other mesh formats can have any number of vertexes, from so few as three (a trianglular flat object) to thousands (ane even millions in theory).

-They have a limited precision, due to the use on "char" values (steps of 1/256 of the total size) which often results into visible bumps into smooth shapes.

-there is no tool able to create sculpties with any kind of shape.

With my opinion sculpties were an overal awkward idea, from people who don't really know how 3D works... or from people who tried to do with a fundamental limitation of Second Life they were not allowed to question: the prims coding system which forbids meshes (see the discussion above).

Also above is discussed the problem of assigning a value to the rendering cost of meshes, which can vary between extreme limits, but is generally lesser than the equivalent prims.

Issues:

• Format - Will it be home brewed or an existing standard?
• File size - How big will the assets be? How long will they take to transfer?
• Physics - How will the physics engine treat the object? How will the shape be determined or specified?
• Features - What features will be support? All supplied by the format or a subset?
• LOD - How will it be calculated?
• Trust - Does the format require the asset creator to be trustworthy? Will the file need to be verified?

Sculpty solution:

• Format - Piggy back on image system, RGB to XYZ
• File size - Great compression levels.
• Physics - Ignored so far
• Features - Limited ~ Simple mesh only, 4 rendering modes, 2 rendering modifiers (inverse and flip)
• LOD - Handled by resampling the image at a lower resolution. Fast and easy.
• Trust - The format does not allow the file's creator to influence the LOD calculation.

The downsides of the sculpty solution are:

• Resolution limitations
• Strange format
• Polygon layout

The downsides are not minor but implementing something better requires finding answers to the above problems that doesn't break the bank. I've been looking at this problem for 4 years and the Sculpty solution was the best solution. It actually proposed solutions to the problems.

In general, procedurally generated content (which the Linden Trees are a sub-type of) would really allow for some awesomeness - but then again, there's issues as well, with not everyone seeing the same thing, because the procedure might even have random numbers thrown in. Things to be worked out.

Meshes really aren't the be-all-end-all so many modelers seem to think. They've got some advantages, but in the long run... they have some problems too, that will make things iffier.