Sculpted Prims: Importing

Template:Needs Translation/de Template:Needs Translation/es Template:Needs Translation/el Template:Needs Translation/fr Template:Needs Translation/he Template:Needs Translation/it Template:Needs Translation/ja Template:Needs Translation/ko Template:Needs Translation/nl Template:Needs Translation/hu Template:Needs Translation/no Template:Needs Translation/da Template:Needs Translation/sv Template:Needs Translation/tr Template:Needs Translation/pl Template:Needs Translation/pt Template:Needs Translation/ru Template:Needs Translation/th Template:Needs Translation/uk Template:Needs Translation/zh-Hans Template:Needs Translation/zh-Hant

Importing 3d models as sculpted prims

Currently there is a push to get the client to import models as sculpted prims from a variety of 3d modeling formats.

•	3dm	–	Rhino & MoI	VWR-858
•	3ds	–	3D Studio Max	VWR-1111
•	obj	–	Wavefront	VWR-1110
•	JT	–	Solid Edge, NX, CATIA, Solid Works, and other 3D Mechanical CAD	VWR-1387

The main method currently for doing this translation is to use UV mapping coordinates to retrieve positions on the surface of the mesh. There are three hurdles to this.

1. UV mappings may be missing or not continuous.
2. The object may be made up of multiple surfaces.
   • Distributing the limited LOD appropriately.
   • Stitching surfaces together. The UV mapping along the edges may not align.
3. The object may have holes.

Current importers & converters get around these problems by ignoring them and only allowing the user to import one surface objects with continuous UV coordinates.

The correct approach to this is to refactor the mesh and UV coordinates into a single surface. To stitch two surfaces together without complex math, the derivatives of the UV coordinates need to match on each side of edge.

Discussion

my concern here is that there is no one good way to convert an arbitrary mesh to a parametric surface. there are many partial solutions, which when used by hand and in conjunction with each other can do the job - but to automatically handle all OBJ files seems to be an impossible job. i guess i could be wrong - but i'm looking for proof in the pudding. my metric has been "if it can import 90% of the shapes present on turbosquid.com without too much error, then it's ok." --Qarl Linden 16:13, 26 June 2007 (PDT)

for an example of these partial solutions - i've seen a paper on "simulated pelting" - where an objects skin is peeled off and attached to virtual springs and stretched to a flat square shape. this is the level of absurdity involved... :) --Qarl Linden 16:23, 26 June 2007 (PDT)

Hadn't thought to read any papers on the topic. My thought was to let the user pick two arbitrary points on the mesh, then have the areas of higher complexity have a higher number of vertecies. Then on top of that there would be a preview window which the user could color to give areas more or less detail. Hadn't thought of it in terms of pelting... the spring approach sounds like a good idea; reminds me of summer camp and scraping hides. The main reason why I don't think this should be part of the client is so it can output an object that can be then imported into another app for texturing. The current approaches don't deform and remap the UVs, but to do arbitrary mesh you would have to. I think the UVs currently on the objects can help in the process of square pelting. -- Strife Onizuka 00:13, 27 June 2007 (PDT)

Looking at the second point, having multiple surfaces is the bigger hurdle to me. Most of the more interesting things in SL are multi-prim. So while a sculptie might be able to take the place of a few simple prims you will still want more. -- Burhop Piccard 18:40, 28 June 2007 (PDT)

I'm sure there is a great way to do it such as by pelting or by secondary uv-map mirroring, but when I saw the one prim cage I just knew such code would be very hard to fine tune and perfect for arbitrary meshes. It would be easier to allow the import to break up an arbitrary mesh and simplify the import with multi-sculpties. It would cost more than the L$10, but there would be better chances to get the expected appearance. The preview would have to say, "hey, this complex object would cost L$40 to upload." At that point, the user has the choice to either upload at that cost or pay for a few expensive packages to try to create the perfect, raw sculpt map. Dzonatas Sol 16:16, 29 June 2007 (PDT)

Which is why I'd eventually like to see a multi-patch sculptie. That is, a single image file with multiple 64x64 regions. For JT file (which is what I'm interested in), it can store both a mesh and a parametrized surface. However, mapping multiple paramterized surfaces to a single surface often breaks down. So what I'd like to do is create a single L$10 image with patches. This might also help with meshes since you might be able to break it down into multiple UV patches. Burhop Piccard 13:35, 1 July 2007 (PDT)

Now I understand what is wanted with the "patch" sculptie. It is very similar to the ideas thought about with a specialized DWT built for a OpenJPEG like codec. The array of patches wouldn't at all look right until the image is fully decoded, for example. The specialized DWT would, basically, understand not to cross patch boundaries in its transform process. There is already support to do this in the J2K standard, but it wasn't specially designed for such patchwork. Dzonatas Sol 19:58, 3 July 2007 (PDT)

What about his paper: http://research.microsoft.com/~hoppe/gim.pdf has an algorithm, Scouse Linden 13:23, 16 August 2007 (GMT)

See also

• Sculptie Dev
• Sculpted Prims: Current JIRA Issues