A smile2 document can be seen as a database that stores a list of entries called nodes, plus the relationships between these nodes. Technically, these relationships form a non acyclic graph. In fact, a lot of the functionality in smile2 is expressed as a set of relationships between properties of nodes, where each property (eg. the position) of a node (eg. a shape) forms an entity in this graph. For Example a regular polygon is a node, that produces output geometry. This output can be connected to one or more polygon shapes. Some of these polygons can be again the input for modifications (eg. applying an offset). The following image shows the node graph for this:
This form to represent a structure has many advantages. It provides high flexibility, additionally a dependency system, and a “construction history”.
Usually, users do not have to care too much about nodes and graphs. However, it is important to know about this system, in order to have a better understanding on how eg. attributes (in fact plugs) are organized in the Attribute Editor or how to use relationships between different elements in a document.
As already mentioned, in smile2 all structure elements are build up from nodes. Each node has a type and can have several attributes. Since connections can be established between these attributes, they are called plugs. Some of them have inputs and outputs, others may have only outputs. For example adding a rectangle, (eg. with the Create Rectangle Tool) creates three nodes:
- A node that generates the rectangle [→ RectangleNode] (left).
- A node that holds the geometry [→ Shape] (middle).
- A node that positions the geometry in the structure [→ Transform] (right).
As you may have noticed, smile2 separates the geometry of an object (shape node) form the placement of the geometry (transform node). More information about this can be found in the Objects and Instances section below.
A node contains the following main building blocks:
- A type
- A node has a static type. It cannot be changed after the creation of the node. The type determines the plugs that a node has and its role in a document. A list of node types can be found in the Node Quick Reference.
- Plugs are properties of the node. Each node type has a fixed set of plugs.
Plugs have the following elements:
- A name
- A plug name starts with a letter (not a number) and may not contain spaces or other special characters. Examples for plug names are width, nodeName, holes. The name is displayed in the node representation in the Node Editor.
- A descriptive name
- A descriptive name can contain any character, including spaces, and is supposed to be more “descriptive”. Eg. the descriptive name of width could be Rectangle Width.
- A data type
- A plug has a static data type. This type is fixed at the creation of the plug and cannot be changed. Eg. the width plug might have a double type.
- A plug type
- The plug type determines if a plug as an input, an output, or both. For example, a plug that computes something (eg. the points of a rectangle) might have no input.
- A state
- The state of the plug indicates if it has an input connection or if it is locked. Depending on the state, a plug might be read-only. The state of a plug can be changed.
- A value
- The plug value is the “core information” of a plug. It might be set from outside, or computed “inside” based on other inputs (called dependency inputs).
Working with plugs¶
The main place to edit values of plugs is the attribute editor. The attribute editor contains special controls (→ Plug Controls) that can not only be used to edit values of plugs, but also to establish connections between plugs. Consult the Attribute Editor chapter for more information.
Objects and Instances¶
As already outlined in the Nodes section, visible objects (or structure elements) are not “monolithic”, but built up from several nodes.
One visible element consists of at least two nodes:
- A leaf node. This node holds the geometry (eg. outlines and holes for a polygon).
- A transform node, holding all transformation information (like translation, rotations, scale and shear), layer membership and a visibility state.
Transforms can have other transforms as “children” (and can be itself a child of other transform nodes) and build a hierarchical structure. Transform do not necessarily have a leaf. Transforms without leaves (without geometry) usually act as groups.
All (potentially) visible elements are held by a Transform node. This node is responsible for two things:
- Managing attributes that control the “location” of the object (in detail: position, rotation, scale, shear)
- Keeping track of the hierarchy. Each Transform node can be placed as a “child” in other Transform nodes and can itself again contain other Transform nodes as children. A Transform node also keeps track of its parents.
The following figure illustrates a simple dag hierarchy:
A transform node can have more than one parent. This makes it possible to place the same transform node in different groups as “instances”.
- Visible elements in a structure can be:
- Non exposable
In summary, each visible element (ie. element with some shape) consists of at least two nodes, a Transform node and a leaf node. The transform has the following attributes:
- Placement (position, rotation, scale, shear)
- Layer membership
The leaf has the following attributes:
- Exposure Settings (including a link to an exposure map or a special pattern generator)
Layers are an important concept to organize your work. With the help of layers you can
- Group objects together that belong to one exposure step
- Quickly hide/show or enable/disable objects
- Control appearance of objects in the document view
Currently, one transform node can be a member of exactly one layer.
This documentation is not yet complete.
|||As a (negative) consequence of this concept, the global placement of transform node cannot be found by knowing just the node, but a path to that node is needed.|