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...

Not so clever now are we, aye?

I need to explain here that this image was supposed to be an orange square, half the size of the blue one, placed in the middle of the image.

Now at first glance it would seem that I've either got my buckets muddled up, or else the tiles in the TIFF image, which coincidentally are the same size as the buckets (16x16) have got jumbled. Well not so.

It so happens that I didn't realize the importance of Occlusion Culling. My buckets contain samples for all the micropolygons for each of the primitives covered by the bucket. What I need to do is only keep one sample, the first, (seeing as the micropolygons have been depth sorted) for each sample position in the bucket.

I'd better go and implement the occlusion culling before I go any further.

Getting there...

It seems a bit of a leap from my previous posts to this one that announces results of the first tests of this implementation of the Reyes pipeline. However, above is a JPEG of the first TIFF image produced.

Yes, blue isn't it!

Now, don't all rush at once, it is a simple image but it proves that I can get an input SVG graphic through the pipeline, in the processes splitting it into smaller primitives, create grids, bust the grids into micropolygons, sample them, wrap the rendered sequence of pixel values in a TIFF image format before running it through a Base64 encoding and out to the file system (all in XSLT I might add). Of course I have to Base64 decode the resulting file in order to view it, but that's trivial compared to what has gone on previously.

Catching errors and confirming results...

The XSLT pipeline processor that I created in order to apply the multiple transforms necessary to generate a rendered result is in need of two things:

1) It needs to report that an empty sequence from a process is an error, and a fatal one at that. Fairly obvious really!

2) Secondly, it would be nice if one could declare what the expected result should be.

Of course if I knew, in great detail, what the result was going to be before hand, then you have to ask yourself why have I created all of this mechanism in the first place. It's a bit self referential.

No, what I'm thinking of is declaring some pattern that can be applied to the result in order to provide some high level verification that the result is looking like what I'd expect. This is not comparing the differences, it's more of a case of 'have I got the right number of blocks?' or 'Does this node exist?'.

Now the obvious candidate for this is an XPath expression that is bound to a process and is evaluated against the result of the process. If the expression evaluates to true, then proceed, otherwise exit the pipeline gracefully and let me know what went wrong.

Now this sounds all very well and good, but, and there is one big but, the only easy way to evaluate an XPath expression is to use the saxon:eval() extension function. Now the thing is, I don't like using implementation specific extensions because they aren't transferable. Of course you could implement a simple XPath evaluator in XSLT by tokenizing the path expression, using regular expressions and recursively processing the path steps. I'll only do that if I'm ever so bored that I haven't got anything better to do!

Goals

The following list identifies the things I hope to achieve by undertaking the task of implementing the Reyes rendering architecture using XML and XSLT.

1) Extend my knowledge of and experience with XSLT 2 and XPath 2.

2) Learn some of the fundamental principles of building a Reyes renderer and 2D/3D rendering in general.

3) Better understand what can be achieved by using functional programming techniques, where recursion replaces conventional loops and there are no side-effects from calling a function.

4) Produce a renderer that can, initially, render simple SVG graphics as Base64 encoded TIFF files.

5) The longer term goal is to then extend X-Reyes to render simple X3D scenes with a basic lighting model. This is altogether more of a challenge as it really gets to the core of what Reyes rendering, and 3D rendering in general is all about.

6) Everything that is created should be as human readable as possible. I say this because there is one thing I cannot stand, and that is the anonymous list of arguments to a function. When reading someone's code, at a glance it is not possible to tell what the nature of those arguments might be. Now that XSLT 2 allows the passing of parameters to both matching templates as well as named templates it is possible to get a better idea of what parameters are expected at the other end. I know that the xsl:function element has anonymous parameters but then nothing's perfect.

Why would I do such a thing?

I do a lot of work with XML and XSLT. Since XSLT 2 came along my horizons have dropped away and all I can see is clear, deepening, blue sky and quite possibly the edge of space.

I have a deep love for and interest in computer graphics and love working with XML. So you'd be right in thinking that I'm also quite taken by both SVG (Scalable Vector Graphics) and X3D (XML encoding of VRML).

So how do you get from there to an implementation of the Reyes rendering architecture. Well, I'm keen to see if XSLT 2's tree and sequence processing abilities would enable me to apply multiple transformations to an input model that would carry-out the necessary processing steps identified by the Reyes algorithm. The end result would be a sequence of samples from the image that would represent the rasterization of the original vector graphic (SVG or X3D).

Now as you may know, XML does not support the generation of binary data. But, it doesn't stop you creating sequences of integer values (pixel values) that can be Base64 encoded prior to output in a file. If you create the right sequences you can decode the Base64 file to obtain a binary file, which in this case could be a TIFF image file, of the image you are attepmting to render.

If you are still asking yourself why, then all I can say is:

'Think how much you can learn from trying!'