GAMGI supports the following objects: Text, Orbital, Bond, Atom, Direction, Plane, 
Group, Molecule, Cluster, Cell, Arrow, Shape, Graph, Assembly, Light, Layer and Window.
Layer, Assembly, Cluster, Molecule and Group objects are containers: their purpose 
is to contain other objects. Light objects are modifiers: their purpose is to modify 
how other objects look. Assembly, Cluster, Group and Text are recursive objects: they 
can own other objects of the same class.
Text
GAMGI supports both wired (stroked) and solid (extruded) 3D fonts.
Stroked fonts are needed to show information (as measurements and object identification) 
on the screen, which needs to be three-dimensional because it will be linked to molecules 
and other three-dimensional objects. Stroked fonts are relatively simple, so characters can 
be drawn fast. Measurements and object identification must work in both manual and automatic 
modes. In the automatic mode, measurements of distances and angles must be recalculated and 
the results updated in the text objects in real time, while the user manipulates the objects.
Extruded fonts are designed to provide the highest possible visual quality to text objects.
These fonts work well with lights and can be very complex, so they are much slower than
the stroked fonts. Links for free libraries providing this kind of font support include
Freetype,
GLTT,
OGLFT
and 
GLE.
Text objects can own other text objects only, so they are recursive objects. This gives 
the user maximum flexibility to manipulate different text fragments separately and 
compose them to obtain the final result. Text objects can be owned by any other GAMGI 
object except lights and windows.
Orbital
Only the low-level engine infra-structure of orbital objects is implemented so far. 
The goal is to describe: 1) simple hydrogen-like orbitals, s, p, d, f, etc., and its 
hybridisations, sp, sp2, sp3, etc.; 2) complex representations of the electronic clouds 
surrounding the nucleus, commonly provided by combinations of Gaussian, Slater and 
plane wave analytic functions; 3) combinations of numerical functions usually described 
by spline line coefficients; 4) pseudo-potentials electronic descriptions.
The main difficulty with orbitals is to collect the data from files with completely 
different formats, provided by Gaussian, ADF, DSolid, Plana, etc. and build a common way 
to handle all this information. This problem must be correlated with the way GAMGI handles 
input/output data.
Orbitals can own text objects, so for example the name of the orbital can be attached to it.
Bond
GAMGI handles bonds between atoms as objects owned by these atoms. Each atom can 
have an unlimited number of bonds. Each bond must have two parent atoms. Bonds 
can own orbitals and texts.
Atom
Atoms are the most important objects in GAMGI. They can own orbitals, texts and 
are the only objects that can own bonds.
Direction
Direction objects were designed primarily to handle crystallographic directions but 
they should provide useful functionality even in the absence of 3D or 2D cells. 
The low-level engine infra-structure required to handle direction objects is fully 
implemented but everything else is not done yet.
Direction objects must handle 3- and 4- (for hexagonal lattices) crystallographic 
indices notations, and all the related crystallographic relations provided by 
direct- and reciprocal-lattice representations.
Users should be able to choose directions of atoms in cells, clusters or molecules, 
automatically producing direction objects reproducing those directions, including 
the atoms and its child, bonds, orbitals and texts, and then handle these new direction 
objects as totally independent viewing and building tools.
Direction objects can own atoms, orbitals and texts.
Plane
Plane objects were designed primarily to handle crystallographic planes but they 
should provide useful functionality even in the absence of 3D periodic objects (cells). 
Plane objects can own directions, atoms, orbitals and texts. The low-level engine 
infra-structure required to handle plane objects is fully implemented but everything 
else is not done yet.
Plane objects must handle Miller and Miller-Bravais indices and all the related 
crystallographic relations provided by direct- and reciprocal-lattice representations.
Users should be able to choose planes of atoms in cells, clusters or molecules, 
automatically producing plane objects reproducing those planes, including the atoms 
and its child, bonds, orbitals and texts, and then handle these new plane objects 
as totally independent viewing and building tools.
Group
Group is an object container designed to handle a fragment of a molecule, a residue 
of a protein, a mero of a polymer chain, or other chemical species. Group objects can 
own an unlimited number of other chemical species as groups, atoms, and related objects 
as texts, orbitals, directions and planes. A group is therefore a recursive object, 
with unlimited nested levels, and its properties should reflect the child chemical features. 
For example, an amino-acid has amino NH2 and carboxylic acid COOH groups, 
the later in turn contains an hydroxyl group OH.
Currently Group objects can be created only from XML files. Mechanisms to measure length, 
angle and torsion measurements in groups of atoms are already in place and tested. 
Algorithms and tools to modify length, angle and torsion values, in both open and 
cyclic structures have been implemented and fully tested. Everything else is not done yet.
Molecule
Molecule objects are essentially containers, objects whose primary purpose is
to own other objects, as atoms and bonds. Molecules can own groups, planes, 
directions, atoms, orbitals and texts. Currently Group objects can be created
only from XML files. Mechanisms to measure the point symmetry in molecules
are already in place and tested. Everything else is not done yet.
Cluster
Cluster is an object container, designed to contain an unlimited number of chemical 
species as child objects, including other clusters, molecules, groups, atoms and 
related objects as texts, orbitals, directions and planes. A cluster is therefore a 
recursive object, with unlimited nested levels, and its properties should reflect the 
child chemical features.
Currently Cluster objects can be created only from XML files. Mechanisms to
determine the Voronoi tesselation of a cluster are already in place and tested. 
Everything else is not done yet.
Cell
All the GAMGI functionality related with atomic structures with periodic boundary 
conditions is handled by cell objects. Crystalline structures can be created indicating 
either a crystalline lattice and a motif or a space group and an (TODO) asymmetric unit.
The 14 Bravais lattices can be represented by Conventional, Primitive and Wigner-Seitz 
cells, plus Rhombus and Sphere volumes. Users can choose the number of cells, the 
volume size, the cell positioning, the type of cell borders, solid or wired cell 
representations, and the cell color.
Any Cluster, Molecule, Group, Atom or even Orbital, Text object can be used as a 
valid motif to construct a periodic structure. GAMGI provides powerful yet simple 
pattern rules to indicate which lattice nodes should be filled, this way allowing 
users to create complex mixed structures that can be used to study liquids and other 
non-periodic systems. In particular, these pattern rules can be used to build 2D and 
1D periodic and non-periodic structures.
Arrow
Arrow objects include different types of 2D and 3D arrows, which are not text objects 
but are very useful to prepare images containing atomic structures, graphs, text, etc., 
for presentations at seminars or school teaching, or for producing printed images for 
articles or books.
Arrow objects can own text objects (only). This is useful for example to add an equilibrium 
constant over a double arrow symbolising a chemical equilibrium.
The low-level engine infra-structure required to handle arrow objects is fully implemented 
but everything else is not done yet.
Shape
Shape objects describe backgrounds, boxes, circles, ellipses, diamonds, etc. designed 
to make an image for a presentation more clear and pretty. The aim is therefore to fill 
the gap between text and arrow objects. Shape objects can own text objects only. This is 
useful, for example to include a message in a box.
Nice functionality to have in GAMGI shape objects includes: 1) several styles should be 
provided for shape objects, including solid, contour, partially transparent, etc.; 2) 
mechanisms should be provided to allow users to choose and apply OpenGL textures, in 
2D and 3D shape objects; 3) mechanisms should be provided to allow users to make textures, 
namely profile gradients, as in the GIMP.
The low-level engine infra-structure required to handle shape objects is fully implemented 
but everything else is not done yet.
Graph
Graph objects will be used to describe all sort of graphic information usually related with 
atomic structures, including for example radial distribution functions and electron density 
maps. In particular, graphs will be used to represent the copious amount of data often 
provided by ab-initio and molecular mechanics calculations. Graphs can own text objects 
only, which will be used for captions, titles, labels, etc.
The low-level engine infra-structure required to handle Graph objects is fully implemented 
but everything else is not done yet.
Assembly
Assembly is an object container, designed to be fully flexible. An assembly can own any 
GAMGI objects, including other assembly objects, except lights, layers and windows. An 
assembly object is therefore a recursive object, with unlimited nested levels. For 
example, an assembly can be used to associate a graph with a molecule and a cell, to 
manipulate all of them at once.
Currently Assembly objects can be created only from XML files. 
The graphic interfaces to properly link Assembly objects are not done yet.
Light
Everything related with lightning in GAMGI is handled by light objects. GAMGI lights 
implement all the functionality provided by the OpenGL specification. This includes 
directional, positional and spot lights, ambient, diffuse and specular light components, 
plus axial and radial light attenuations.
The maximum number of lights that each layer can own is fixed by the graphics library 
used with GAMGI. In Mesa this number is currently 8, the minimum required by the OpenGL 
specification. However, as the number of layers that each window can own is unlimited, 
the same is true for the total number of lights per image. Lights are the only objects 
in GAMGI that cannot own other objects.
Layer
GAMGI supports multiple, unlimited, layers for each window, allowing users to move and 
copy objects between different layers and see multiple layers simultaneously, if they wish. 
A layer can own all kinds of GAMGI objects, except bonds, windows and layers. In particular, 
layers are the only GAMGI objects that can own lights.
Most of the layer functionality is already in place, including perspective and orthographic 
projections, full control over projection and model view (like a photographic camera) 
parameters, inside and outside visibility, background color, plus undo and save history 
mechanisms to keep and recover the whole contents of each layer, for as many levels as 
previously defined.
Perspective projection is better to simulate realistic views but the orthographic projection 
(mostly used in architecture) is usually preferred for most work related with building 
and viewing structures, because these are not distorted by perspective. The projection 
parameters, that control the matrix transformations related with the projection of the 
3D space on the screen, are fully controlled by the users.
Window
GAMGI supports multiple, unlimited, windows, and (TODO) users can easily move and copy 
objects between them. Each window in turn supports multiple, unlimited, layers,
and (TODO) users can easily move and copy objects between them. Windows can own layer 
objects only, each one describing a completely independent graphic environment.
Window objects are truely independent: if GAMGI starts with window A and then 
window B is created, these windows have exactly the same priority, so removing
window A will leave GAMGI running normally with window B.
The low-level engine infra-structure required to move and copy objects between 
windows is fully implemented but the high-level interfaces are not done yet.