 |
DI-Guy SDK Documentation
13.7.1
|
|
DI-Guy SDK Documentation
13.7.1
|
To explain how DI-Guy Author works, imagine an application called the FarScene IG that has DI-Guy characters and DI-Guy capabilities.
We will describe how the end user interact with the IG and accesses DI-Guy Author through it. Then we will describe what the developer has done under the covers to make this interaction possible. This imaginery implementation of DI-Guy Author is not the only way to do this, just one possible way.
An end user of the FarScene IG starts the program. In non-author mode the IG runs just as it would if DI-Guy were not present. All visual geometry is rendered by the IG, and all inputs do whatever they would normally do. No DI-Guy elements are visible in either the 3D display or in any dialog boxes or control windows.
The FarScene IG user decides to edit a scenario using DI-Guy. He selects a menu item that enables Author. A small window opens to show that Author is active and which allows the user to select Author input mode. DI-Guy menus and menu commands are added to the IG interface, similar to those used in DI-Guy Scenario.
Initially, DI-Guy editing is disabled, so other then adding some DI-Guy controls, nothing has really changed in how the application functions.
The user chooses Author -> Open Scenario, and loads a DI-Guy scenario file. The characters and other DI-Guy objects in the scenario are loaded and show up in the 3D window. The user navigates the camera to the scenario location.
The IG user uses the DI-Guy Scenario controls (PeopleBlitzer, CrowdBlitz, and various drawing functions) to add characters and give them actions.
The user exits Author mode, at which point all Author windows and editing visuals in the 3D window disappear. The IG GUI returns to exactly what it looked like before Author was enabled. The characters that were added using DI-Guy Scenario remain in the simulation and move through the IG terrain to act out the edited scenario.
The FarScene IG user starts it normally. Beyond the fact that DI-Guy Author has been integrated into the IG by a programmer, nothing is different.
When the user enables Author, a DI-Guy SDK function call gets sent. DI-Guy initializes some internal state to support Author editing. The IG modifies a native UI control, such as a checkbox or menu item, to show that Author is active. However, until the user changes DI-Guy’s input mode, the IG still acts as it would normally.
DI-Guy needs two categories of changes to the IG GUI:
Integrating these two components into the IG requires very different steps.
Native controls refer to controls in the IG GUI that are implemented natively in the IG. While they may query state from DI-Guy and change state appropriately, DI-Guy itself does not create them or change their state. Author controls refer to GUI controls created by and managed by DI-Guy. Author controls show up in subwindows and dialog boxes implemented and controlled by DI-Guy.
\note Many DI-Guy operations can be accomplished by calling DI-Guy SDK functions based on native UI events. For example, the input mode and playback mode can be set using DI-Guy SDK function calls. This means that if only a small set of DI-Guy operations need to be available, they could be implemented using native controls. If more advanced editing operations are required, the full DI-Guy UI can be enabled.
While DI-Guy can be used with strictly native controls, there is a lot more user interface available if the Author GUI is enabled. A majority of the GUI in the DI-Guy Scenario application is available in the Author GUI.
Once the Author UI is running, there are DI-Guy function calls that can be made in the IG that will show and hide 2D user interface elements of the Author UI.
The Open Scenario menu item uses DI-Guy function calls in the IG to load a previously created scenario.
When the user changes the input mode to PeopleBlitzer, the IG is responsible for sending most user input in the 3D window to DI-Guy. This input will mostly include mouse clicks and drags and keyboard activity. When the IG sends the mouse information to DI-Guy while in PeopleBlitzer input mode, DI-Guy internally decides how to handle that information. It looks at its current PeopleBlitzer settings, which include DI-Guy character type, appearance, action, and mind. It then creates the specified character and a path that begins at the clicked point, and ends at the mouse release point. The current character data is shown in the Author GUI so the user can see and edit details of the new character.
When Author editing is enabled in the 3D window, specialized 3D polygonal objects to represent DI-Guy editing visuals must be shown. These visuals are created by DI-Guy calling virtual functions that were defined when DI-Guy was integrated into the IG. In the PeopleBlitzer case, IG-native geometry for waypoints and paths are requested by DI-Guy. The IG creates these based on recommended geometry and material settings provided by DI-Guy, and positions and orients the visuals from data provided by DI-Guy. When DI-Guy determines that any of these visuals should be repositioned, re-colored, or destroyed, it will notify the IG of this.
When the user selects the CrowdBlitz input mode, mouse inputs will have different effects. When the user is painting regions in the IG 3D window DI-Guy will need to make multiple queries against the IG’s native terrain in order to set the points that comprise the region. These queries are made by DI-Guy calling virtual functions defined when DI-Guy was integrated into the IG.
When the user is done and saves the scenario, the current scenario state as it exists in the IG is saved to a .dss file.
When the IG user turns off DI-Guy, the Author UI is shut down, and most DI-Guy related native controls and menu items are hidden. The IG should once again run as if DI-Guy were not present.
[<< Introduction to DI-Guy Author] [Home] [Top of Page] [IG Integration >>]
1.8.9.1 
