Basically, a sculpt map, like any geometric representation or compression scheme, must exist relative to some coordinate system. For the case of sculpties that are not based on prims (the implemented case), that coordinate system would have position, rotation, and maybe scale. And since there’s no underlying volume, the map must also form a closed surface to define its own volume.

For the case i’m talking about, the sculpt map would probably inherit the coordinate system normal to its underlying face. In some cases, that could imply a curved space to deal with. But it’s not that hard, given the information known during each prim’s construction.

What is hard is aligning the sculpt map deformations from adjacent faces and maps to match up without cracks. Still, it’s entirely possible. Some virtual globes, for example, have forms of geometry compression that encode X,Y,Z for terrain, but that information is always stored relative to a coarse elevation per tile. There are indeed solutions to these sots of problems.

My point is that the assumption that a single map define a single enclosed volume is not necessary, if those other issues are handled properly. And at worse, the normal-to-face+warping method could even be used to warp space for a single prim-wide scuplty map, with interesting results — like working cut and twist, for example.

A more sophisticated procedural geometry system with basic displacement maps on top would actually be a much more effective way to go. And by leveraging the two together, you can give much easier editing tools to manipulate complex objects once they’re imported.

All you’re arguing for now is a limited case of geometry import and compression that makes some heavy assumptions about best he distribution of samples.

actually – they’re not. rather than a height map – they are a position map – which is a subtle but important difference: they allow for arbitrary shapes, not just star-like shapes.

and once you realize that – you’ll see that it makes no sense to apply them to underlying prims. they ARE their underlying shape.

K.

After that, I hope to write another post about where I think procedural geometry should go in the future. But I should keep the two topics separate.

I have had some success creating prims for use as physics proxies in Opensimulator (see the above comment from John Hurliman) and I can duplicate any shape to a high degree of accuracy for all of the prim parameters, but when combined, some minor inaccuracies become evident as prims are resized beyond the normal 10×10x10 meter limits. My prims also use far fewer vertices than the equivalent viewer prims as an attempt to save server memory. There are some fundamental bugs in the profile generation that need to be addressed before all profile cut angles are available, but I’m designing a new profile generator that should fix that.

I was able to assume many of the properties of prims by carefully noting the changes in size and shape as I varied the parameters in the object editor. I’m not 100% certain that all my assumptions are correct but I believe I am quite close for most of them. I have noticed some interesting inconsistancies such as nonlinearity in some profile cut parameters which I haven’t yet accounted for, but for now I am close enough range for a believable collision mesh for all prim shapes tried to date.

My code is available under BSD license in the Opensimulator SVN. It is a work in progress and changes should be expected. I would be quite interested in your insights into how prims work if I could use them to implement BSD licensed code. I would also be interested in your thoughts on a more comprehensive definition of procedural geometry. Please contact me at the email address I supplied if you would like to discuss this further.