You can create new graphs within XiStrat™. A spring embedder (see [VRMLGraph], that's where this functionality was taken from) is used. Please refer to Appendix A, Installation and Usage for some installation and usage description.
In general it is possible that faces (except the triangle case of course) are not flat (being in one single plane). The triangulation (needed because natively only trias and quads are supported having drawing primitive type support in OpenGL implementation) is done using poly elements and takes thereby care that later on pieces can properly be drawn by using special points (center, …) of the polygons.
Sometimes (actually quite often if the graph gets complex) the spring embedder will return data which represent suboptimal solutions. Then simply try again. We can't ignore the fact that in general this sort of graph layout falls into NP-complete, see Chapter 19, Complexity Theory. The algorithm is non-deterministic. It is random Monte Carlo (may return an incorrect answer with probability of error bounded by user) and not Las Vegas (i.e., guaranteed correct output) so far. Besides there are cases where multiple results should be regarded as allowed solutions, that is rendering without unnecessary self-cutting (and little stress aka energy in the springs).
The general procedure needs two files:
The infiles' syntax is similar to the specication in VRMLGraph™. You simply tell pairs of connected vertices (please start with the vertex id 0). But since we have to deal with some corner cases as well, we allow loops (edges connecting a node to itself) and multiple edges with the same ordered pair of nodes (moreover at the same time possibly connecting thereby the same set of faces). Only the full information consisting of both ordered pairs (of points as well as faces) specifies the edge label later on.
A modest warning now: Internally we look after the highest used vertex (node) label (so the labels should be integers) to estimate how much memory for vertices, colors and so on to allocate. In case you get strange rendering results with faces half-dead or dark, then perhaps you have used too high labels and left too much space unused in between. For big scenes this can happen and be useful to keep the overview, so perhaps our Create 3D Data Tool should be rewritten to avoid using the labels but instead the actual index of the vertices. At the moment just use the resources with care. A sort of soft limit is reached at about 2000 vertices so far.
The CreateData tool must be told the expected number of vertices respective edges a regular polygon has got. This can't easily be figured out automatically (girth and face-valence are not always the same). And because then we have property files anyway, we tell about the number of overall polygons (invalid included) as well. In principle the polygons might be found out by machine itself though.
A possible improvement could be to directly specify in the input file what vertices form a face, because at that time one probably already has those faces in mind, and this way the faces don't have to be reconstructed again later on by looking at nothing more than the vertex adjacencies.
The "Rubik" cube variant with intermediate states need a lot of topologically different graphs, and the needed infiles are autogenerated.