Of beginnings, endings and syncbases

Given that x-reyes will generate animated sequences, it is quite obvious that those sequences are a fixed set of frames. Therefore, the fancier interactive aspects of SMIL, like mouse events and/or wallclock times, will not be required.

To that end (no pun intended), the @begin and @end attributes will support syncbase values of the following form:

syncbase-value ::= ( Id-value "." ( "begin" | "end" ) ) ( S? ("+"|"-") S? Clock-value )?

The begin and end events of named animation elements (set, animate, animateMotion, etc) is a very powerful feature of SMIL that should be supported and for that matter utilised where possible. After all, everyday life is a connected sequence of beginnings and endings, that may be offset from each other, but they are all connected to synchronizing base events. Just consider a simple walk cycle!

The svg:set element...

On the face of it, the svg:set element does not seem to be as much fun as the others. In fact you can achieve the same effect by setting the @calcMode to 'discrete' which has the effect of not interpolating between the extremes.

Anyway, I now have support for svg:set.

I was supposed to be doing svg:animateMotion next but svg:set seemed easier by far than the whole motion path, keyPoints, keyTimes and keySplines scene!

The svg:animate element

As of this writing I have support for the following properties of the SVG animate element:

* @attributeName
* @begin = clock-value
* @dur = clock-value
* @end = clock-value
* @fill = (freeze|remove)
* @from = length without units!
* @to = length without units!
* @by = length without units!

I do need to deal with @from/@to values that decrease, and for that matter @by values that are negative.

After that I'll be looking at svg:animateMotion.

Drifted into the world of animation

One aspect of implementing a Reyes render would be that ability to render animated sequences. To that end I have 'branched-off' into the world of animation, or to be more specific SMIL - the Synchronized Multimedia Integration Language. SMIL (pronounced Smile) is a 'framework for incorporating animation onto a time line and a mechanism for composing the effects of multiple animations'. Although a W3C recommendation in it's own right it is also the animation component of SVG.

Given the work I have done to-date with X-Reyes you wont be surprised to here that I have started implementing a SMIL interpreter using XSLT. The idea being that the XSLT transform(s) take an SVG graphic, with inline svg:animation elements, and generate the 'inbetweens' for each animated primitive. There is an SVG/JavaScript test harness that allows you to run, pause, step forward/backward and stop the animated sequence using conventional video playback style buttons.

The next step would be to generate a sequence of whole graphics, one for each frame of the timeline that can be subsequently fed into the X-Reyes render to generate the required frame images. In an ideal world I'd by generating an animated GIF but X-Reyes only supports TIFF at present.

A little snip here, a little snip there

In order to pave the way for the next phase, I have done some trimming of the data structures used within the X-Reyes.

The chief culprit was the use of the svg:metadata element to store additional data (metadata if you like) about the primitives. I had used an:

<xr:bbox top="0" right="16" bottom="16" left="0"/>

element to store the bounding box of each primitive (and micropolygon). This, as I'm sure you can imagine is rather verbose. So I have done away with the svg:metadata element and now use an:

xr:bbox="0 16 16 0"

attribute instead. This has reduced the memory required to process an image by a third.

Sweet!

Add a bit of opacity can make things clearer

The addition of opacity makes things a bit more interesting. I used a simple equation:

I = k * I + (1 - k) * I'

where k is the opacity, I is the intensity (the value of each of the RGB colour channels) of the nearest of two overlapping polygons and I' is that of the one behind it.

That's more like it!

The square peg in the square hole. For the rather simplistic sampling strategy I'm using at present, the occlusion culling is quite straight forward. Find the first micropolygon who's top-left vertex matches the sample coordinates. And yes you're right, no multipoint stochastic sampling here. But then why would I? I'm working in pixel units only and there are no rotated primitives, diagonal lines or curves.

As yet...