The Application Programming Interface (API)

1. The building blocks of the E3D library

The blocks in the following diagrams represent classes (C structures) with only the relevant fields shown. For the complete definition of a structure, please refer to the appropriate header file (e.g.: for E3dNode, see Node.h).
Names of E3D types, such as E3dNode, E3dMesh are capitalized with the E3d prefix omitted.

1.1. Data types

E3D uses a balanced combination of compile-time classes, runtime-typed classes and object-composition. For the impatient, here is the (compile-time) class-inheritance diagram:

The diagram is quite simple because most of everything else is runtime-typed. Runtime classes are typically registered by plugins (over 90% of EQUINOX-3D is made of plugins).
For example, there is no compile-time SkinMesh or SubdivisionMesh type. Skin deformation and subdivision are simply runtime-typed component objects that can be attached to Meshes.
Plugins can also register new renderer classes, operator classes and so on.

Most commercial 3D modelers allow an "attribute list" per node.
Component objects are a more powerful, "next-generation" version of this concept. They encapsulate the code and data per feature, rather than having a single "polluted" namespace.

For example, a Mesh may have a construction history (e.g. it was originally created as an icosahedron), skin deformation and per-vertex global illumination (GI) data without the overhead (and GUI clutter) of extra Nodes.

The parameters for each of these are represented in a "Resource list" inside component objects, so for example, it's perfectly safe for both the "icosahedron" and the GI data to have a parameter called "radius".
The components may be removed by the user (when safe / meaningful), by clicking the "X" button of the corresponding folder:

Runtime-typed object composition and the light-weight core also makes it easy to turn EQUINOX-3D into a graph-based XML schema editor, a Solar System simulator, a video game, or pretty much anything you can imagine.

Thanks to this high level of flexibility and modularity, EQUINOX-3D is more like a 3D operating system than a fixed application.

When the application programmer creates a new hierarchy, or changes the connections in an existing one, he/she will only have to set the Parent, Child and NextSibling fields and call the function: E3d_NodeHrcUpdateConnections() with the root of the hierarchy to update the other link-related fields.

A class derived from E3dNode is E3dModel.
Among other things, Models can hold Transformation values (Scaling, Rotation, Translation) and they may contain pointers to 3D Objects.
This is how Models instantiate Objects, such as Meshes, Splines, Lights etc.
One Model can hold multiple Objects (Polygon Mesh, Spline, Particles etc.) and all these Objects will share the transformation defined on that Model. Because of that, we sometimes refer to a E3dModel as a transformation-node or transform-node.
Also, each Object may be listed on multiple Models, which makes it appear, or get "instantiated" in the 3D scene multiple times (with a different location, rotation etc.).

"Above" the Models, there is a structure called E3dScene. This contains all the information about a given "3D world".
The root Nodes of the hierarchies are not connected in any way, but there is a flexible array of root-nodes (hierarchies) in the E3dScene structure, called RootNodes.
The functions E3d_SceneNodeHrcAdd() and E3d_SceneNodeHrcRemove() manage the above array.
The "active" scene in EQUINOX-3D is accessible through the global variable:

E3dScene*	E3d_Scene;