Ubigraph - 3D graph visualisation environment

What Ubigraph actually is

Ubigraph is a 3D graph visualisation environment that splits the work between a viewer and whatever program is generating the graph. The viewer renders nodes and edges in three dimensions and reacts to instructions in real time. The program on the other side adds vertices, links them, changes attributes, and removes them again. The viewer is not asked to know where the data came from. The program is not asked to know how the layout is computed.

That split is the part most people remember. It is also the part that makes Ubigraph feel different from a normal plotting library. You are not drawing a static picture once. You are streaming changes into a viewer that keeps adjusting its layout, and you can watch the structure of a graph as it grows or settles.

The site keeps a careful tone here. Ubigraph appeared in the mid-2000s and was actively discussed in graph drawing circles. Some of the original distribution material is not easy to verify on a modern system. Where pages on this site describe behaviour, they describe what the tool is meant to do based on visible historical material and on common patterns in graph visualisation environments of that era. Where a page is uncertain, it says so.

The two-process model

A graph visualisation environment that listens for instructions over a network port is doing two related jobs.

1. It maintains an internal graph model with vertices, edges, and attributes.
2. It runs a layout and a renderer that turns that model into something you can look at.

Anything that can speak the protocol can act as a client. A short Python script, a simulation written in C++, or an analysis pipeline writing out partial results - they all use the same interface. The viewer is just a viewer.

That model has practical consequences:

• The client never blocks on rendering. It sends an instruction and moves on.
• The viewer can keep redrawing while the layout is still settling.
• A long-running program can keep adding to the graph for hours and the viewer keeps showing the current state.
• Removing the renderer does not invalidate the client. The client just does not see anything.

If you want to follow the conceptual lineage, the topic this sits inside is graph drawing - the long line of work on how to lay out graphs so they can be read.

How to move around this site

The Ubigraph section is organised around the same shape the original distribution used, with modern landing pages on top.

• The demos index explains what each example is meant to expose.
• The docs index covers the client side - graph creation, edge updates, and XML-RPC style control.
• The downloads page is honest about what runs today and what does not.
• The papers section is a small shelf of reference texts that show up repeatedly in conversations about scientific C++ and generic programming, with companion notes for each PDF.

The exact historical URLs all still resolve. /ubigraph/index.html is a real page. So are /ubigraph/content/Demos/RandomGraph.html, /ubigraph/content/Demos/random_binary_tree.html, and /ubigraph/content/Demos/Animation.html. Older bookmarks land where they used to land.

The demos, in plain terms

The demos are not screensavers. Each one is built to expose a specific behaviour in a graph viewer, and they are most useful when you read them with that intent in mind.

• Random graph. Sweeps edge probability from sparse to dense. The interesting bit is the change in layout behaviour, not the picture at any one moment. Sparse random graphs tend to spread out and look almost like rings. Dense ones collapse into a tight cluster where the layout struggles to find a stable shape.
• Random binary tree. Builds a tree by repeatedly adding a node to a random existing leaf. Useful for thinking about layered vs force-directed layouts, and for showing where common layout strategies start to fail as the tree grows.
• Animation. Adds and removes nodes and edges in motion. Helpful for understanding what a graph viewer does when the underlying structure is changing while you are looking at it.

There are conceptual write-ups for each on the relevant page. They are written to teach the demo, not to flatter it.

The client side, briefly

The client side in Ubigraph is small on purpose. The interface is XML-RPC style, which means a client sends a named call with arguments and receives a response. The set of calls is short and predictable:

• create or remove a vertex
• create or remove an edge
• set or clear a style attribute
• change the colour, label, size, or shape of a node or edge
• clear the graph

In Python, the standard library provides everything you need to talk to a server like this through the xmlrpc.client module. In other languages the same idea applies, with whichever XML-RPC client the language ecosystem makes available.

The docs page goes through the call surface in more detail and discusses what to expect when you point old example code at a modern Python interpreter.

Layouts, and where they bend

A 3D graph viewer that recomputes layout while data is changing has to make a sequence of small choices. Most of those choices are invisible until they are wrong.

The two failure modes worth naming:

• Over-jitter. The layout responds to every change with too much movement, and the viewer becomes hard to read because nothing settles.
• Over-settle. The layout damps so quickly that important structural changes do not register visually, and a meaningful change in the graph looks like a small wobble.

Good layouts in this kind of system tend to balance those two pressures and let the viewer reach a stable shape between bursts of edits. Random graph and animation demos are useful precisely because they sit on the line between those failure modes.

Modern alternatives, honestly

A page that talks about Ubigraph would be incomplete without a fair note on alternatives. The decision to use Ubigraph-style tooling today is rarely a question of nostalgia. It is usually a question of whether a workflow that depends on streaming graph updates is worth maintaining, or whether a modern equivalent serves the same purpose.

If you are starting today, three categories of substitutes show up in conversation:

• Graph drawing libraries that produce 2D or 3D layouts on demand and let the host program decide when to redraw. These are common in research code.
• Visual analytics tools with built-in support for graph data, where you spend less time wiring up the viewer and more time on the question you are trying to answer.
• Browser-based renderers that consume a graph as JSON, run a layout in the page, and let you embed the result anywhere a web view fits.

None of those are a one-for-one replacement for a graph server you control directly. They are, however, often the more practical option. The Ubigraph approach still has value when you specifically want a long-running viewer that mutates as your program runs, because that pattern is awkward to reproduce on a stack that expects a static input.

What this site is, and is not

This site exists to keep a useful set of Ubigraph-related pages alive and to write down what is known about the topic without overclaiming. It is not an official product page. It does not represent the people who built Ubigraph. It does not promise that any binary or source archive published in the original distribution can be obtained here.

Where original PDFs and reference material can be verified, they live on the site at their original paths. Where they cannot, the corresponding page says so and links to a careful companion note rather than presenting unverified files as originals.

If you came in looking for a specific demo, the demos index is the right next step. If you came in looking for the client side, start with the docs index. If you came in looking for the paper shelf, it lives on the papers page.