nexus Servers

Luxology’s application architecture is called ‘’nexus’’ (tm). All the applications we build are based on this same structure. Our flagship application ‘’modo’’ (tm) is created using nexus.

As its name implies, nexus is structured like a hub. It has a set of core functionality and systems common to many potential apps, with specific features and options arranged like spokes around the core. This extensible set of features are called servers, and are implemented as plug-ins. By way of example, here are some common types of objects that can be implemented as plug-in servers.

Loaders & Savers

See Also: (./Saver: Server basics)

See Also: (./Loader: Server basics)

Loaders read external files, recognize their contents, and translate that into an object inside nexus. Savers do the reverse, storing the contents of a nexus object as an external file.


See Also: (./Command: Server basics)

Every change of state of nexus model data (and a lot of non-model UI data as well) is done through a command. Commands are complex objects with arguments, enable/disable state, default UI behaviors, and optional value queries.


Tools provide an interactive method for editing meshes, doing transforms, or altering items. They support 3D handles and other input methods, and can communicate with other active tools through the tool pipe.

Item Types

Items represent the scene state in nexus, and can perform a wide range of different functions. Plug-ins can also define new partial item types called packages.

Other Objects

In addition to servers there are a wide variety of other object types in the nexus system which play a part in the SDK.

  • Services – not to be confused with servers, services are the interfaces that the plug-in uses to query and manipulate global nexus state.

  • Images – these play a large role in the nexus SDK and can be created and accessed in multiple ways.

  • Meshes – these are complex objects composed of points, polygons and vertex maps, accessible through enumerators.

  • Instances – in SDK terms an instance is the object associated with each sub-type of each item, and allow rich options for interaction.

  • Wrappers – these are not nexus objects as such, but are C++ abstractions that make it easier to access the raw power of the SDK.

Plug-in modules extend a nexus application by implementing some new set of servers. A plug-in may consist of a single server, such as a Loader, or it may consist of a whole set of related servers. A single binary will often contain item types, commands and tools in order to provide a complete implementation for a given feature.

A plug-in will also typically require a set of resource configs and images. An item type, for example, needs item icons and names and help for all its channels. A command needs error messages. By placing all these into resource files the text can be translated into any language that nexus supports.

A related set of modules, resources, help and content can be combined into a kit. When nexus loads a kit its features and UI are seamlessly integrated into the application according to the instructions of the developer. The user also has the option to disable kits when they are not wanted.

Next Steps

If you want to develop a plug-in through the SDK, your first task is to work out the servers that you’ll need to implement your idea in the nexus framework. There may be multiple ways to approach an idea, with varying levels of difficulty. Start with a small, easy piece and work from there. Good luck!