Software Architecture Considerations

Tool software architecture includes foundation features, framework, extendibility, and data format. Fundamental features should be listed during the technical design stage -- that can be critical to the software tool's architecture.

These may include Undo, Redo, Cut, Copy, and Paste, which require serious technical design considerations because they may apply to most parts of the software. Fig. 3 diagram shows data flow between components of the application.

In the framework category, these are some of the key application components. The user interface drives the application and may be kept as much decoupled from other components as possible. This may not be as simple as it sounds, but it will have advantages in maintenance down the line.

The current UI state such as dialog sizes, positions, and control states can be stored in an XML definition. This definition can be stored on disk so that the application can maintain its UI state when launched the next time.

The Undo and Redo state stores the state of content data, difference in content data, or command history. Again, this state can be stored on disk or in memory so that Redo and Undo actions can be performed.

The Content Data module manages the attributes data to include load, store, and conversion. The Live Update module is responsible for sending the data over to the remote target or game application when a change in the data occurs.

Fig. 3

As for extendibility, it is all too often that new features need to be added to the software, and it may not be done by the original authors. In some cases an open architecture or external module plug-in based architecture can be highly beneficial.

Ideally the attribute data format would not require a conversion to reflect object display. In other words, the data directly maps to content attributes. This may not be possible for all attributes, but data that is directly mapped will make real time update of the attributes easier.

For example, the color of light in the scene modified from the user interface will directly update the data field in the asset attributes data state without a conversion process.

Implementation

Content attributes data has to be mapped directly to user interface controls and data update has to reflect the change immediately. Ideally, the real time engine will be using the data and therefore, change in the data will be reflected automatically. Care must be taken when modifying data that has resources associated with it such as textures and geometry data.

The new resource may need to be newly created and the old resource disposed of. There will have to be checks on use of resources that are being disposed of in the tool source code to avoid unwanted results while new resource is prepared. A safe method would be to halt any display and not use the disposed resource until new resources are ready.

Let's go through a simple example to show implementation of user interface controls mapped directly to an object attribute. As shown in Fig. 4, we have a slider that controls the spin speed of an object being displayed in the viewport.  I use pseudo code (I'm keeping it similar to C++) to demonstrate data structure and code implementation.

Fig. 4

The slider mapping information is kept in a searchable database or a simple array, which has the structure shown in Fig. 4a. The Slider ID is a slider control resource identifier and pAttribute is a pointer that points to the address of the object attribute.

Fig. 4a

In the Fig. 4b example, the object attribute Spin Speed is kept in a separate data structure. This data structure is used directly for object display. Here the SpinSpeed field is the angular rotation speed of the object in the viewport. Since this field is being used in every frame cycle to retrieve the rotation speed of the object any changes to this field will result in instantaneous update in rotation of the displayed object.

Fig. 4b

As shown in Fig. 4c, when an object is selected or becomes editable, the searchable slider mapping information database is initialized or updated to reflect the current mapping. The pAttribute field is assigned to the address of object's spin speed field. This way the attribute value can be updated by using a pointer to it.

Fig. 4c

When the slider control changes its update, event updates the value of the attribute it is mapped to, Fig. 4d. The slider value is assigned to the object attribute by using the mapped pointer. The object data structure is decoupled from the slider database. Yet, the attribute update is reflected in the object attributes and onto the object display in real time.

Fig. 4d

Resources like device objects such as textures and geometry and other properties' data that requires additional processing cannot be directly mapped to the UI control.  Those controls may only update reference information such as file name or unique identifier which is then used to prepare the resource associated with the object.

For example, if a new material is assigned to the object then the previously assigned material is freed and the new material is created and prepared to be assigned to the object. Once assigned, the material is reflected in the viewport.