X-Reyes

Friday, January 27, 2006

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!

Labels: , , ,

Wednesday, January 11, 2006

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.

Labels: , , ,

Monday, January 09, 2006

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!'

Labels: , , ,