[sldev] Sculpted prim works in progress

Erik Anderson odysseus654 at gmail.com
Wed May 2 09:42:42 PDT 2007


Bah, forgot to cc the list, lol.  Everyone's looking at "sphere topology"
when it comes to sculpted prims, but I believe it is also possible to use a
"torus topology" and come up with sculpted prims with one hole in them.  I
doubt that you could use the same algorithm for both, but it does add some
additional flexibility to the feature.

On 5/2/07, Andrew Meadows <andrew at lindenlab.com> wrote:
>
> Here's a idea.  I'm sure it would work, but it seems
> much easier to describe than to actually implement.
> Since this is a pre-processing computation and only
> has to be done once for each model, it doesn't really
> matter if the algorithm isn't super fast.
>
>
> (1) Prune the model (vertices and line segments) to only
> those on the outside surface.  The sculpted prim algorithm
> only works for objects with the same topology of a sphere
> anyway, so this is possible to do for any model you could
> successfully sculpt anyway.
>
> (2) Simulate the model as a collection of 3D points
> attracted and repelled to each other by soft springs along
> the line segments, but relatively tightly constrained to
> move to the surface of a sphere.  This is a tricky step,
> partly because naive implementations of springs tend to be
> unstable, but also because the best choice of spring constants
> along the line segments will vary depending on the topology
> of the model.  In some cases you would want tight springs
> for short line segments, but in other cases (such as your
> character's neck) you would actually want loose springs
> else the neck points might compress those on the head
> to a disproportionally small area at the pole.
>
> (3) Let the points relax into a stable configuration on
> the sphere.
>
> (4) Correlate the points to the nearest pixels that
> would texture map to the sphere and colorize those
> pixels accordingly.
>
> (5) To fill in the pixels between you could blend the colors
> between the control points.  For more accuracy you could add
> some subdivision points along the line segments of the
> original model and interpolate those along the spring lines
> to get more colorization control points.  That is, the
> subdivision points wouldn't contribute to step (3), but
> would only help guide the color blending.
>
> - Andrew
>
>
> John Hurliman wrote:
> > You will need Windows XP or Vista, and the XNA Game Studio Express
> > (available at http://msdn2.microsoft.com/en-us/xna/default.aspx). That's
> > just the main code file so you'll have to setup a new "Windows Game"
> > project and copy paste the code in to Game1.cs or whatever the generated
> > file is called. I didn't put too much effort in to packaging up a full
> > solution package and binaries because I'm still poking at it, adding
> > normal calculations for lighting and UV coords for texturing, and will
> > probably switch to using WinForms so you can open new files and add an
> > export to OBJ option.
> >
> > I actually only created this previewer program to try out my other
> > program, a generic OBJ to position map converter. It seemed like a good
> > idea on the whiteboard but in practice it only works for certain shapes
> > that would be much easier to just create with NURBS in the first place.
> > Maybe some clever programmers can help out with it or offer tips on
> > improving it. The basic idea is shown in this screenshot of the program:
> > http://www.jhurliman.org/images/positionmapper01.png
> >
> > An OBJ file is loaded, a bounding sphere is created around it, and 4096
> > (64x64) points are iterated over on the surface of the sphere. From each
> > point a ray is drawn towards the origin and collision tested with mesh,
> > and the point of collision is converted to an RGB value in the output
> > image. It worked great for a simple cube (although there was some
> > interesting distortion taking a spherical sampling of a cube), but the
> > blockhead example highlighted obvious problems. The inner ring
> > projecting towards the origin shot up between his legs, almost to
> > <0,0,0>, but the next ring outwards hit his legs, and two or so more
> > rings out hit way up on his legs, so he ended up with very distorted
> > spiky legs and way too many points near the origin. Basically a sampling
> > problem as 1) only 4096 total samples are taken, and 2) the spherical
> > mapping puts a heavy bias near the poles and thins out near the equator.
> > It would work decently well if the mesh was a ball of clay or something
> > like that, but then why not just work on an exporter for the program you
> > created it in instead? It was a fun experiment at least, I will revisit
> > it if anyone thinks up some ideas on how to improve it.
> >
> > John Hurliman
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070502/a9a888a0/attachment-0001.htm


More information about the SLDev mailing list