This document is not meant to cover every single detail of a ScenomePlatform application's workflow. It's meant to provide a basic understanding of workflow so that you can extend ScenomePlatform in a way that best fits its current design.
Fundamentally, ScenomePlatform application workflow is designed to facilitate craftsmanship, or iterative design. We understand that the first version of something is rarely perfect. So instead of designing a tool that emphasizes the "creation" process, we designed a tool that emphasizes the "revision" process. This makes sense to us because most of the modelers with whom we speak tend to spend a lot more time refining their work than actually creating objects. You won't find very many dialog-based object creation functions in ScenomePlatform.
Interface layout suggests core workflow and workflow design criteria. The main menu has four key categories in its center: Create, Draw, Select, and Modify. This is the foundation of iterative workflow. 1.] Create/draw something, 2.] Select something, and 3.] Modify the selection by invoking a command. Basic application and workspace management functions are located to the left and right of these core categories. Modeling in ScenomePlatform is a circular series of select and refine operations with occasional creation operations and application/workspace management operations. Adherence to these principles has two effects: 1.] all revisions are implemented in the same manner, making it easier to use ScenomePlatform, and 2.] the process is very consistent.
Now it's one thing to talk about emphasizing the revision process, but what have we actually done about it? Quite a lot actually. ScenomePlatform's mesh modeling is parameterized; basically it uses a mesh construction history, along with a lot of abstraction, to make it easy to engage and implement many kinds of major and minor revisions. The drawback here is that ScenomePlatform's scene graph structure and mesh modeling are somewhat complex in their implementation. The benefit, of course, is fast revisions that are almost effortless in many cases.
ScenomePlatform also has a simple workflow that relies heavily on the object-action metaphor. This software development metaphor requires the user to select an object before he or she can engage an action. In ScenomePlatform, actions are performed by script-based or C++ commands.
Another key concept in ScenomePlatform is its highly granular command architecture. This concept is simple. Rather than emphasizing the create process, ScenomePlatform has very few create commands and many, many commands that instantly modify objects. ScenomePlatform is extensible via scripting and this makes it very easy to write many of the commands that implement revisions. This gives ScenomePlatform a much more natural, artistic workflow than most products in its category.
The granular command architecture tends to require the user to invoke a series of commands to complete a complex operation, rather than trying to make a complex, dialog-based command that handles lots of permutations.
There is a small price to pay for this flexibility; you have to implement a lot of commands, although this does tend to keep C++ and script functions smaller. We think it's well worth it. Would you rather have your work interrupted for a few minutes while you write a script or have your work interrupted countless times daily while you deal with dialog boxes and constant, complex iterations? [If you prefer dialog boxes, ScenomePlatform lets you write dialog-based commands with scripts or C++!]
User level commands that implement revisions should terminate immediately whenever possible. Sometimes immediate termination is not advantageous; in those cases, a specific mode-based tool can be implemented. For example, when you wish to draw a curve, you enter a modal context called Draw. The software remains in this mode until you tell the software you are finished drawing the curve. Select is another modal context and ScenomePlatform tends to spend most of its operation time in this mode while the user to applies commands. Select mode separates into numerous revision contexts, depending on the current selection.
A revision context is entered when the user makes a selection. If you select a group or group-set, the software can apply commands designed to modify groups. Similarly, if you select a face-set, the software can apply commands designed to modify faces.
Keep this in mind as you extend ScenomePlatform.
Another key area that warrants discussion is ScenomePlatform's support for paged content. Again, we simply leveraged ScenomePlatform's directed acyclic graph and implemented generic paging services via a node called a Link node [and some associated infrastructure]. Furthermore, the Link node has other uses. It can be used to link content in different databases - different memory blocks - and control how that content is streamed off the disk. This addresses several key issues in scene building: data structures that are good for runtime performance often make modeling very difficult. For example, a large terrain mesh is easier to texture and modifier than an analogous representation that uses several meshes. This is mainly because there are no edge homogeneity, texture coordinate, or lighting homogeneity issues with a single terrain mesh. ScenomePlatform does not directly address the issues of edge homogeneity but low-level virtualization does allow the modeler to create data structures that make sense for a human reader and perform well during machine interpretation.