[sldev] Sculpties: Vacuum-Forming, Skittering, Zone Linking

[Kent Quirk (Q Linden)]

Dale:

You might want to look into Cosmic Blobs (or its free variant, CB Model 
Pro), which does not have an exporter appropriate to sculpties but has a 
lot of modeling ideas that I think apply to sculpties rather neatly. 
(But I might think that, since in a previous non-Linden life I was one 
of the developers.)

In any case, your ideas are an interesting take on the problem.

I've interspersed a few comments below.

Dale Mahalko wrote:
> 1. Vacuum-Forming
>  
> A sculptie is best defined as a balloon. It is a continuous shape that 
> is extremely flexible, and pliable, that can be poked and prodded and 
> molded into practically any shape. The difficulty in working with a 
> sculptie is finding ways to manipulate this balloon.
>  
> One of the easiest ways to make complex meshes and individual prims 
> translate into a sculptie, is to treat the sculptie as if it were 
> being made in a vacuum-forming machine. To do this, traditional meshes 
> and prims are placed inside a sculptie "inflated" to its maximum size, 
> and the sculptie is then programmatically "deflated" so that 
> it surrounds and conforms to the shape of the meshes/prims within.
>  
> http://video.google.com/videoplay?docid=8573678537143717206
That's an interesting idea for converting an existing prim-based model 
to a sculptie.

One algorithm that would get you partway there would be to create a 
"convex hull" around the prim-based model.

For those who don't know, a convex hull is the surface that completely 
surrounds an object without having any indentations -- sort of the 
equivalent of wrapping the balloon around it without the deflation part 
you've described above.

Such a technique might be an interesting way to get a sculptie to be 
approximately the right size -- but then you'd have to have a set of 
"carving" tools to start indenting the result.


> 2. Skittering
>  
> A sculptie has some special properties beyond traditional 
> vacuum-forming, in that it can be stretched without limit to the 
> maximum distance possible between points without tearing or pulling 
> apart. In order for a sculptie to best conform to the shape of an 
> object, and to optimize control point distribution, it would be useful 
> for the points to be able to move around the surface of the formed 
> shape to concentrate the points into areas of highest detail. This I 
> refer to as the Skitter function.
>  
> Across a large flat space there is relatively little detail and 
> therefore a need for relatively few control points to define the 
> shape. The control points can be allowed to stretch out and skitter 
> away from the flat surface to accumulate around the edges where higher 
> detail is needed. When modeling a skull as a sculptie, it is best if 
> the control points skitter towards and concentrate on the face and 
> ears, while also skittering away from the back and top of the skull, 
> so that the points are concentrated in the areas where higher detail 
> is required.
>  
> To assist in the shaping of the sculpty around the objects within, it 
> might be displayed as a transparent sheet draping over the objects 
> inside, with recesses that are not properly matched by the sculpty 
> given a highlight color so the user knows to skitter more points 
> towards that location.
>  
> Automatic optimized skittering is potentially an intensively 
> computational problem, but can be assisted by allowing the user to 
> manually control how points are distributed. A default sculptie mesh 
> is deflated around a set of target meshes or prims, and the user is 
> then able to "touch" the surface of the sculptie to define whether 
> mesh points should skitter away or towards the touch point. The editor 
> then programmatically distributes points towards or away from the 
> center of the location touched, based on the strengthening and 
> weakening of the elastic lines connecting the points together.
>  
> Direct repositioning of the surface mesh is also possible by allowing 
> the used to grab a point and then drag it across the surface of the 
> prims below, causing all other points to stretch or contract around 
> the point that the user is holding, and then setting a new "stretch 
> memory" for all the elastic lines between points when the user lets 
> go. In this way a mesh can be deformed, but then attempts to retain 
> the deformed shape as additional deformations are applied. Being able 
> to pin control points to the defined surface so that they cannot move 
> would further assist in the economizing of point distribution.

The problem with your statement about having points potentially very far 
apart is that you never want really big triangles in your rendering 
system. They tend to do nasty things with clipping, lighting and the 
like, so practically the "maximum" distance between points in triangles 
is pretty short.

In a system designed to be used by normal people (as opposed to 3d 
modeling specialists), I would not *ever* be inclined to expose 
individual triangles or vertices for user editing. It's just too easy to 
create whacky results by dragging vertices across triangle boundaries 
and the like. That way lies madness.

A guy named Hugues Hoppe, at Microsoft, ( 
http://research.microsoft.com/~hoppe/ ) wrote a mesh optimization paper 
that talks about something very close to this problem.

The general idea is that you create some sort of energy function that is 
related to how "unbalanced" (acute) a triangle is, as well as its size, 
and you minimize both the energy function per triangle and the number of 
vertices overall.

In the case of sculpties, we don't actually want to be creating new 
vertices, but we do want to move vertices around the surface. What I'd 
probably try to do is crawl the surface along the edges between verts 
and release each vertex one at a time, treating the edges as springs, so 
that each vertex would tend to minimize its own energy. But you also 
have to constrain the vertices to move along the surfaces already 
defined, though, since the technique I just described would also 
eliminate peaks and valleys.


> 3. Zone Linking
>  
> Because sculpties can overlap and self-intersect without any problems, 
> it is possible to create a hole in a sculptie by wrapping it around an 
> open space and having the sculptie self-intersect when it has wrapped 
> completely around the open area. Special handling is needed to allow 
> for the creation of overlaps inside a deflation-capable editor, and 
> one way to deal with this is to use Zone Linking.
>  
> The internal objects which build up the sculptie are linked 
> together to create zones of deflation. The sculptie deflation begins 
> with objects being defined within a single zone, ignoring all other 
> objects not selected as part of the initial zone. To extend out a 
> wrap-around tentacle from the initial zone, a new zone is defined that 
> links off from one of the objects within the primary zone. Points are 
> then skittered across the first zone to spread out across the 
> new, additional zone. The overtlap is formed by defining still more 
> links and zones that reselect objects from the previous zones, and 
> continuing to skitter the control points to spread out across the 
> expanding chain.
>  
> The key to making this work is that the base object from which a 
> self-intersecting sculptie is to be formed, needs to be built up using 
> separate meshes or prims so that each section of the object can 
> be split off into its own zone. This method cannot work with a complex 
> mesh that has already a hole cut through it, because the sculptie 
> vacuum-forming can only wrap completely around the outside of each 
> object within each zone..
I guess I think that this starts to show why modeling from prims + 
deflation might get problematic. I like the idea of being able to start 
a sculptie by starting with a prim, but I'd prefer to see a modeling 
system not based entirely in that mode, but with tools that allow a 
sculptor to add or remove material in a localized manner.

And yes, I'm interested in this stuff, but I'm not currently working on it.