4. PAEPOS Version 2

Peter Gould's MSc Dissertation at Oxford Brookes in 2004 was to extend the original PAEPOS system to one that could handle solid objects with lighting. The main activities were:

• Define the architecture
• Develop a 3D Pipeline as a set of XSLT Transformations
• Explore how best to achieve animation
• Construct some meaningful examples that stretched the implementation

The diagram below illustrates the problems. SVG draws objects sequentially as they appear in the file (the painter's model). So if faces are appearing and disappearing, the need is to continually reorganise the drawing elements in the file which proves to be difficult if not impossible. In consequence you have to revert to the tried and tested approach adopted by the animation industry since 1910. You cheat! If you draw frames at regular intervals, prefererably quite fast, the human eye will interpolate and believe that the animation is continuous and the changes required are taking place at the inbetween positions. The diagram below does not cheat. It draws all the facets making up the object making them visible or not as they appear and disappear from view.

Figure 4.1: PAEPOS Version 2 Initial Design

Animation Alternatives

The possible ways of doing full 3D animation are:

• Keyframes and Inbetweening: similar to the original Wireframe PAEPOS. It is quite difficult as object faces may disappear during an inbetween. Also the rendering order may need to change during an inbetween
• Modify Drawing Order via DOM: similar to above but use scripting to clone objects, adding and deleting nodes. This was tried but it could not achieve a reasonable frame rate even on a small set of objects
• Drawing on the fly via Scripting: possible on simple examples but was unable to render complex scenes
• Discrete Frame-based Animation: each frame is generated independently with only one displayed at a time. It can handle complex pictures due to most browser drawing speeds now being adequate. However it does produce large files. If it is possible not to redraw constant parts of a picture, this can improve both size and performance

The only option that really works robustly is resorting to discrete frame-based animation.

The PAEPOS Version2 File structure was similar to Version 1:

<svg3D>
  <duration>5</duration> <fps>16</fps>
  <camera>
    <initial>
      <x>0</x><y>100</y><z>-100</z><roll>0</roll><pitch>50</pitch><yaw>0</yaw>
    </initial>
  </camera>
  <lightsource>
    <x>500</x><y>500</y><z>0</z>
  </lightsource>
  <object>
    <translate>...
    <rotateyz>...
    <part colour="rgb(2555,255,0)">...
    <part>...
  </object>
<svg3D>

The two main additions are the need to define the frame rate via the fps element and to define the light source. The basic primitives were ones more appropriate to solid objects as shown below:

Figure 4.2: PAEPOS Version 2 Primitives

A major addition was to add a bi-cubic patch primitive. This had been tried in Version 1 but was much more effective in Version 2. Spliiting bi-cubic patches is much the same as splitting cubics in 2D so the objects could be refined to have as many patches as required.

Figure 4.3: Patch Set