[sldev] Sculpted prim works in progress

Erik Anderson odysseus654 at gmail.com
Wed May 2 12:13:04 PDT 2007


Bah, figures.  The "annoying questions" section wasn't there when I last
looked at it, lol.  Sorry for taking this thread off-topic.

On 5/2/07, Frans <mrfrans at gmail.com> wrote:
>
> Qarl linden already mentioned on the wiki scuplted_prim talk page<https://wiki.secondlife.com/wiki/Talk:Sculpted_Prims>that that is planned for rev 2.
>
> On 5/2/07, Erik Anderson <odysseus654 at gmail.com> wrote:
> >
> > 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
> > >
> >
> >
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
> >
> >
>
>
> --
> RL: Jeroen Frans / SL: Frans Charming
> http://www.thevesuviusgroup.com
> http://www.fransinnovations.com
> http://www.linkedin.com/in/mrfrans
> http://secondslog.blogspot.com
> _______________________________________________
> 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/1068b3b3/attachment.htm


More information about the SLDev mailing list