Capabilities of this Framework
Usually, when programming using SPAD, I try to use a functional programming style as much as possible, for instance making objects (representations) immutable. However I don't think it would be practical to implement the scenegraph in this way. A design requirement is that the scenegaph needs to hold a large amount of information, A 3D scene might be made from thousands (perhaps millions?) of polygons. For the sake of efficiency we need to be able to modify it without copying the whole thing into a new object for each change.
The object oriented style of programming would seem to be ideal for a scenegraph. Each type of node in the scenegraph could be a different object all inheriting from a common object. Unfortunately is is not easy to do this in SPAD because it does not support polymorphism.
So what I have ended up with is perhaps the worst of both styles of programming?
This scenegraph framework currently exports to file formats like: SVG,X3D, VRML and Wavefront(obj) but currently there is not the capability to interact directly in a graphical way, that is, there is no xwindow support. The existing graphics framework allows user interaction in a very limited way in that the graphics can be displayed in an xwindow and there is then the ability to do simple transforms like pan and zoom. However this is not suitable for the new framework because the existing framework builds a data structure to represent the graphics using SPAD and then passes this to 'C' code. The 'C' code then does the pan, zoom and so on and can then save to a file format.
Apart from being very messy trying to mix different languages, this would not work for the new framework because:
- We want to use non-linear as well as linear transforms.
- I would like to be able to work with discontinuous (fractal) shapes.
- I want to use different algebras such as vector, matrix, complex numbers and Clifford algebras and I would not want to implement these algebras using 'C'.
I can't see a way to implement this as I would like, possible options might be:
- Implement an OpenGL canvas in SPAD which allows SPAD to directly output to OpenGL (a thin wrapper for OpenGL calls) and also to read and process mouse position.
- Implement Axiom/FriCAS as library code that can be called from other languages or a GUI.
- Implement some form of two-way API which allows other programs to use SPAD algebra.
User Interaction - Option 1 - OpenGL canvas
Bill Page mentioned that there is an OpenGL binding for lisp.
Would it be possible to create a thin wrapper to allow these functions to be called from SPAD?
OpenGL consists of a couple of hundred function calls but this would only need a small subset of those (because transforms would be done by SPAD and not OpenGL).
We would also need the ability to read mouse movements from SPAD to allow user interaction.
User Interaction - Option 2 - GUI
An interesting option would be to operate axiom as a server for another program such as a GUI front end. This was discussed on the axiom forum in 2006:
One change since the forum discussions in 2006 is that perhaps now most computers have hardware graphics acceleration and so it makes sense to do output through OpenGL. So I think this eliminates the issues raised then about the need for graphics libraries to draw lines, control text fonts and so on.
I guess this could either be done using the OpenGL binding for lisp mentioned in option 1 or using a one-way API which could send this information to another program which could then make OpenGL calls.
User Interaction - Option 3 - two-way API
Here I am trying to work out what sort of API would be required to allow the user to interact graphically with the scenegraph using an external program to support the xwindow:
|SPAD||proposed API interface||other language||input-output libraries|
|calls equivalent of existing draw function|
|request to open 'xwindow'||
|listening for response on API||
|passes back graphics resource ID|
|draws geometry structure to resource ID||---->||thin wrapper to openGL||---->||openGL|
|draws buttons, sliders and so on to allow user to manipulate transforms and so on.||---->||adds these to xwindow||---->||draw buttons and so on.|
|listening for response on API||<----||user operates mouse to modify say a transform.|
|program detects this and realises that the geometry structure needs to be recalculated.|
|<----||passes back new transform information.|
|recalculates scene graph re-draws geometry structure to resource ID||---->||thin wrapper to openGL||---->||openGL|
|listening for response on API||<----||user hits button to export to SVG say.|
|<----||filename dialog .|
|writes scengraph to file.|
|listening for response on API||<----||user hits button to close xwindow.|
|openGL and other resources released.|
|resumes command line interface.|
This requires that SPAD can suspend itself waiting for a message. Arthur Ralf already has some code here so that axiom can listen on a socket:
The more that I investigate this the more complicated that this method appears. It seems to me that the algebra, geometry and graphics and it would be simpler if the whole thing were written in SPAD or a single high level language like it (i.e. option 1).
Transforms in scene graph STransform
Existing transforms in Axiom (such as dhmatrix.spad.pamphlet and moebius.spad.pamphlet) are stand alone chunks of algebra which don't interwork with each other and it would be a lot of work to incorporate them into other code especially graphics and geometry.
The aim of STransform is to make a completely general template for transforms so that specific transforms like a Möbius transform could be implemented so that the slot directly into the geometry/graphics framework.
We have not achieved that aim yet. STransform does work with the various implementations of the SPointCategory such as SCartesian, SConformal, SArgand.
What I would like to do is to have a transform category which could be implemented by domains like dhmatrix.spad.pamphlet and moebius.spad.pamphlet, then they could be used in the geometry/graphics framework anywhere transforms are appropriate.
The most general form of transform would be represented by PT->PT where PT is any implementation of SPointCategory. So ideally all transforms should be defined in this way. The usual way to transform a vector is to use a matrix like this:
So what I need is a way to curry it into something like this:
I don't know how to this? that is, how do I create an anonymous function where a variable (in this case def:Matrix) is a constant in the function?
- define and transform shapes using Clifford algebra as well as vectors, matrix and complex numbers used at present.
- show union and intersection (join and meet)
- slice through shapes and show sections.
- represent 4 and higher dimensions using various methods like colour or time animation.
- Support interaction with the graphics, possibly by using a OpenGL
canvas which could be called directly from SPAD
Bill Page mentioned that there is an OpenGL binding for lisp.
SPointCategory defines a type that can represent either a point or a vector. It is important to make the distinction between a point and a vector (and not just treat a point as an offset from the origin) because a point and a vector will transform differently. Pure rotations will act on points and vectors identically but pure translations act only on points.
SPointCategory has various implementations depending on the algebra and type of space that we are dealing with:
- SCartesian - n dimensional space defined by x,y… and 0 for vectors and 1 for points. Translations are defined by (n+1)×(n+1) matrix.
- SConformal - Clifford algebra based on n+2 dimensional space where the two extra dimensions represent point at origin and point at infinity.
- SArgand - two dimensional space defined by real and imaginary parts. Translations are defined by general function of a complex variable C->C.
This category and its implementations are implicitly defined over DoubleFloat, the user is not given given the option of specifying any other type, I did consider this but decided not to because:
- We require an ordered number system (that is we require '<') to support features like clipping.
- In most cases the functions and transforms would be continuous.
- User Tutorial on this page.
- Tutorial2 - conformal space.
- User Reference on this page.
- Examples of scenegraph structure on this page.
- The code is in file: scene.spad.pamphlet which is available from here.
- Existing Axiom graphics framework on this page.