Pedal

Procedural Environment Description and Animation Language

¹ped·al

('pe-d^&l) noun
Middle French pedale, from Italian, from Latin pedalis, adjective
circa. 1611

1 : a lever pressed by the foot in the playing of a musical instrument (as an organ or piano)
2 : a foot lever or treadle by which a part is activated in a mechanism

Essentially pedal is designed to allow the description of a scene as a sunction of time. The user writes a script, the interpreter compiles this code (OK, I really it might seem like Im confusing my terms there, I hope Im not, its an intermediate code thing), and then executes for the period of time the user gave on the command line at increments of time which are specified on the command line aswell.

In order to make this a more powerful concept, we introduce a few tools which are specifically aimed at CG animation. The first (and indeed the original idea that started it all), is interpolative arrays. When specifying an array (of anything) in pedal you can specify a blending functions , a useful B-spline based default is chosen, other options are also provided and it should be possible to allow users to define thier own blenders. When one of these arrays is accessed the blending functions are applied and rather than returning the modula element of the index a suitably interpolated value is returned. The original project release of pedal had this fuction ing well for individual values, for points, for general flat sub arrays of values.

I have done a reasonable amount of work, no code as yet, on expanding this principle to take advantage of any motion blurring features of the output format being used. This proves quite mathamatically challenging (for my brain anyway), since to do this well (certainly to do it adaptively), requires knowledge of the time dependence for any variable. This time dependance has been the focus of most of my thinking after my degree ended.

The generation of scene information itself, and the motion blurring related stuff, is abstracted out to an api for integrating with different renderers, the initial target for the first release will be RenderMan and OpenGL, both of these are stated based systems that fit in well with pedals view of the world. The original project version exported renderable .rib files, this was done by hard coding chunks of RIB into the interpreter, that sucked so hard its unbelievable, so this time I want to Do The Right Thing. The source tree also includes a direcotry for a POV exporter, this is just something to stir up a little trouble and make sure I keep on track with the whole portability betweens renderers thing, havent really done any thinking about it yet.

Aswell as abstreacting the output format, I will be abstracting a type API too, the idea being that advanced types could be written (such as dxf importers and the like) in libraries, I would like some form of negotiation between the types and the exporters to allow for negotiation in the presentation of the type, so that if a given exporter does not natively implement a type, a negotiation can occur to pick the best representation that the importer and exporter both understand. This is of course still all very sketchy. Of course, much of this is just musing, little code has been written, but then, thats what Im working on.