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

[Dale Mahalko]

This thread is now a week old but I should respond to this:


On 9/28/07, Kent Quirk (Q Linden) <q at lindenlab.com> wrote:
> So it's an interesting point of view you're expressing.
>
> To me, sculpties define a smooth mapping of the vertices of a
> well-defined closed mesh. After that, anything that happens is largely
> an artifact of the implementation and could easily vary between
> platforms or implementations.
>
> You, as you put it, "see optimization and untapped power." You're trying
> to find ways to extend sculpties to do things like change the topology
> of the prims.
>
> The architect in me wants to preserve the freedom to change the
> implementation of sculpties in the future as we learn more about ways to
> improve and design the implementation. If people start depending on
> implementation details to do things like drill holes in sculpties by
> abusing the way rendering works, it constrains our ability to extend the
> feature in the future. Of course, it'll probably happen whether I want
> it to or not -- but it's where I'm coming from.
>
> In any case, seems like you're asking for sculpties to be able to do
> things that are better suited to using separate objects. Could you
> explain your motivation for wanting to extend the definition so far?


I don't know who is in charge of the sculptie project, but it seems
like nobody has made an effort to describe the future direction of
scultpies. We as end-users are simply presented with the concept as it
functions now, but are not given insight into the future plans for
sculpties.

Perhaps there isn't any plan at all, and this is just a
seat-of-the-pants hack someone came up with one day, to exploit JPEG
compression for the totally off-the-wall idea of compressing
non-visual vertex data.

It's long been my impression that sculpties are an extremely
convoluted attempt to provide an equivelant to raw mesh data, while at
the same time capping the amount of data involved to some absolute
number of mesh triangles, and meanwhile also not needing to extend the
dataserver storage systems to implement a new raw-mesh datatype.


However, sculpties are generally triangle-inefficient to shape
anything more complex than a rough blob, since to shape extremely
complex objects like a chair it is necessary to overlap and "bunch up"
whole swaths of triangles because there's too many in this spot, while
then also weirdly deforming the desired shape because we can't get
enough triangles moved over to where they're needed in another spot.

One of LL's own initial sample objects demonstrate this useless
bunching up of unneeded triangles that cause unnecessary rendering
load, with the sharply curving "S" sculptie. A much simpler custom
mesh could do the same thing with far fewer triangles:

http://wiki.secondlife.com/wiki/Image:Sculpted-preview-04.png

Sculpties may be exploiting JPEG as a vertex compressor, but at the
cost of very sloppy detail-triangle usage and difficult-to-manage
triangle disitributions.



AFAIK, nobody has clearly explained why implementing sculpties is more
desirable than just using direct meshed-objects and allowing direct
triangle-mesh importing from 3DS Max or whatever.

- If data storage is the issue then fine, set some absolute limit on
the number of triangles a given freeform uploaded mesh is allowed to
contain.

- If compression is the issue, there's probably some way to optimize
freeform mesh data storage that doesn't rely on a flat blanket of
triangles as with sculpties.

- If supporting a new storage datatype within a massive legacy
database is the issue, there's probably a way to store it compressed
on notecards or something.

- If network load is the issue, make users of custom meshes pay for
the sluggishness that progressively more complex meshes will cause for
others. And I realy mean, make them pay more L$ to upload more complex
triangle meshes. Make the cost high enough to upload something with
many triangles vs something with few triangles, and people WILL make
their meshes efficient to conserve bandwidth. Perhaps bind such custom
meshes to a prim base as with sculpties and still limit the mesh to a
max 10.0x10.0x10.0 size, nonphysical.


If we can't have raw mesh importing directly, then people at least
want to make sculpties perform as closely as possible to how normal
custom meshes work. Already there's the demand for precise sculpt map
storage without compression artifacts, which allows for very sharp
edges and precise vertex control. This reduces the amount of "organic
smoothing" done by the JPEG algorithm, but has the side effect of
potentially increasing the size of the compressed data.

With my suggestions I am simply trying to work within and expand upon
the extremely constrained vertex-based environment LL has established
with the implementing of sculpties.

-Scalar Tardis aka Dale Mahalko