Topology_and_Geometry

[Home] - [Architecture] - [Development_Strategy] - [Future_Features] - [Topology_and_Geometry]

---

Currently in Development:

Please propose specific functionality here: Topology & Geometry Discussion

Topology and Geometry are typically related but may be defined independently.

[Geometry] - geometric primitives; line/point graphs, surfaces, FFT...
[Topology] - topology types; cube sphere, torus, rod, n-graphs, cone, polyhedron...

It is important to understand this differentiation. You can think of a Geometry Type as the 3D display of the object, but NOT the 'physical' characteristics. The 'physics' of the object are defined by the Topo Type.

For example the Torus Topo Type allows for objects to be moved relative to the surface of a toroid and is typically displayed using a torus for the geometry. However, one can have a Torus Topo using a non-torus geometry for display, such as a sphere. In this case child nodes will orbit the sphere about the equator and there movement is relative to the torus topology and not the sphere surface.

In general we use the Google KML standard for a sphere as the base coordinates that all other coordinate systems are extrapolated from. This allows placing objects on a sphere and then dynamically mapping them to other topo types such as cube, torus or pin. Objects are distributed using the same underlying coordinates (translate_x/y/z) but with final position based on the parent topo type.

We would like to see all geometry types be made into topo types, (both hard-coded native-primitives and custom models loaded from file.) Native primitives should have a hard-coded set of operations. Where as models loaded in would need to be processed and/or utilize a plugin that defines the physics of the topology. Bare in mind that speed is of utmost importance. Typically this is accomplished by calculating the underlying position 'physics' in a standard 3D cartesian space for all/most topo types. The position 'magic' occurs in the GL code which takes advantage of matrix operations to translate, rotate, and scale based on the particular topo type(s), (at display time.) Some objects such as a paraboloid require a specific lookup table when a simple rotation does not suffice.

Future topologies should be expected. Ultimately we would like to see a hybrid architecture that allows for plugin topo-code to optimize performance with a backup dynamic topo algorithm for handling arbitrary geometries. That is an algorithm that ingests 'any' form/shape and generates a relevant topo-map lookup table. This in itself is a substantial task and will be even more difficult to make it work for an arbitrary n-Dimensional space and support non-rigid structures such as deformable objects and field or fluid based topologies.