Avi Bar-Zeev has written up an interesting post in relation to some of the XBAP viewer work I’ve been doing, for those who havnt followed his CV, he originally wrote the procedural renderer that Second Life still uses today, and has graciously volunteered some of his time to help us document it (potentially getting around our persistent problem with it’s licensing).

One of the choice quotes from his piece however is this:

If anything is going to be standardized, I’d much rather see the broader language of procedural geometry become more widely used, rather than SL’s very shallow cross-section of that field.

He’s bang on. 40 bytes in fixed positions with no versioning or expansion capabilities does not a good standard make.

Expansion - Paths, Profiles, Deformations.

Right now, from my understanding of how primitives are generated (something we learnt via libsl before the viewer was open sourced) is that SL makes a base path (ie say a 2D circle), then sweeps it in a certain manner (say in a straight line) to produce a shape (ie a cylinder). You can tweak the sweep or original shape to create cuts, twists and other deformations quickly and easily.

It works very well for a simple set of shapes - but it doesnt lend well to complicated patterns, even if they can be generated procedurally. Consider the Butterfly Curve - it’s expressed very simply as follows

x = cos(u) (e^cos(u) - 2 cos(4 u) - sin(u / 12)^5.0)
y = sin(u) (e^cos(u) - 2 cos(4 u) - sin(u / 12)^5.0)

The total size of the above in ASCII is 103 bytes. You can see a rendering of the resulting curve over here (the above algorithm has been lifted off that page too).

Supporting this kind of algorithm in addition to the ones we above should be crucial to doing this properly - because it’s going to lead us in directions for greater efficiency and artistic creativity.

Bytecode for Procedural Generation?

It strikes me personally as better to instead send along bytecode for the mesher as part of the protocol - much like Javascript is relatively sanitised and ideal for running scripts on webpages, a simplified language for building procedural generation would strike me as relatively intelligent - because it leaves the door open for smart folks(tm) to come and build their own meshing algorithms that may be better (or worse) than the ones provided by default.

Such a bytecode would probably need only to support the base set of mathematical functions (such as perhaps those defined in <math.h>

Layers and Deformations.

One of the other things we should be looking at is a way to combine mesh generators and deformers in sequence, such as we can say “Take a sphere. Squeeze from the middle 50%.”, in this case, we use an inbuilt mesh generator, then apply a deformation to it.

This would also allow special cases to be worked in much cleaner. “Flexible path” functions and “Sculpted primitive” functions simply become: “Generator + Flexible Path + Sculpted Distortion”. A simple sculpty becomes “Sphere + Sculpt” - greatly simplifying the way things are represented currently from an algorithmic standpoint.

There is no reason for this to be “one plus the other” either, it should be possible to apply a large number of deformations ontop of the base generator - the number of complex shapes that could be represented simply in doing this would be near infinite.

A sidenote

I’m going to be in London this week (until the 11th), so my availibility is somewhat lessened, but I’m going to be aiming at producing a 0.1.0 rewrite of Xenki while I’m here. We’ll see how far I get, source will be published over on the OpenSim Forge as it appears.