Axiom - Scengraph - Programmers Reference

Capabilities of this Framework

  • draw plots
  • define shapes.
  • show scales and grids
  • combine many graphs/shapes in one view
  • transform graphs/shapes of groups of shapes.
  • apply properties like colour, line thickness to these nodes or groups.
  • add text annotations.
  • export to SVG, X3D, VRML and Wavefront(obj) files.

Further Information

Programming Issues

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?

User Interaction

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:

I can't see a way to implement this as I would like, possible options might be:

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'

---->

 

creates 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:

transform(in:Vector,def:Matrix):Vector

So what I need is a way to curry it into something like this:

transform(def:Matrix):(Vector->Vector)

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?

Future Enhancements

SPointCategory

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:

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:

Further Information

 


metadata block
see also:
Correspondence about this page

This site may have errors. Don't use for critical systems.

Copyright (c) 1998-2023 Martin John Baker - All rights reserved - privacy policy.