| Table of Contents | ||
|---|---|---|
|
Virtual Human Architecture
The Institute for Creative Technologies (ICT) Virtual Human Toolkit is based on the ICT Virtual Human Architecture. This architecture defines at an abstract level what modules are needed to realize a virtual human, and how these modules interact. The basic functionality of each module as well as its interface is well-defined, but its actual implementation falls outside the scope of the architecture. The architecture dictates the implementation of a distributed system where communication is mostly realized using message passing. This allows for multiple implementations of a certain module and simple substitution of one implementation for another during runtime. It also allows for distributed systems, where different modules run on separate computers.
...
Figure 1. The ICT Virtual Human Architecture.
Virtual Human Toolkit Implementation
The Virtual Human Toolkit is a set of components (modules, tools and libraries) that implements one possible version of the Virtual Human Architecture. It consists of the following modules:
...
Every module has its own messaging API. In addition, each module should at least implement the basic messaging protocol that allows modules to request and share whether they are online:
- vrAllCall, pings all modules.
- vrComponent component-id sub, response by module to 'vrAllCall'; should also be send on start-up by module.
- vrKillComponent {component-id,'all'}, requests a single module or all modules to shut down.
- vrProcEnd component-id sub, send by module on exit.
...
The components that are available will announce their availability with the vrComponent message.
Parameters
No parameters are used.
...
All components except libraries should implement listening to this message and send a vrComponent message on receiving it.
Related messages
vrComponent
vrComponent component-id sub
...
The vrComponent message announces the availability of the given module to all other components. This message should be send at start-up and in response to vrAllCall.
Parameters
- component-id, contains the ID of the particular component. This can be a module type, like 'renderer' or 'nlu', or a specific module, like 'npceditor'.
- sub, is required, but not strictly defined. One can use it to specify the actual implementation of the module type, for instance 'ogre' for the renderer, to specify a subcomponent, for instance 'parser' for the Non-Verbal Behavior Generator, or simply use 'all' when no additional information is useful to provide.
...
All components except libraries should send this message on start-up. In addition, each component except libraries should send it in response to vrAllCall.
Components that receive message
All components except libraries should implement listening to this message.
Related messages
vrExpress
- vrExpress char-id addressee-id utterance-id xml-messsage
...
Requests either a specific or all modules to shut themselves down. Each module and tool should listen to this message and when the parameter matches its component ID or 'all', it should shut itself down, after sending vrProcEnd. Note that, unlike vrComponent, no second parameter is present, therefore all submodules should exit when receiving the kill request.
...
All components except libraries should implement listening to this message.
Related messages
vrProcEnd
vrProcEnd component-id sub
...
Modules that need to be aware of available services should listen to this message.
Related messages
vrSpeak
- vrSpeak char-id addressee-id utterance-id xml-messsage
...