[sldev] Sculpted prim works in progress

Frans mrfrans at gmail.com
Wed May 2 11:58:33 PDT 2007


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070502/087ba020/attachment.htm


More information about the SLDev mailing list