[sldev] Sculpted prim works in progress

Andrew Meadows andrew at lindenlab.com
Wed May 2 08:55:22 PDT 2007


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


More information about the SLDev mailing list