Overview

Face-to-face dialog is accompanied by a range of nonverbal behaviors such as facial expressions, head movements, gestures, body postures, or eye gaze. These behaviors serve to augment, contradict, substitute for, complement, accent, or regulate spoken communication, as well as in the process influence the beliefs, emotions, and behavior of observers. The Nonverbal Behavior Generator (NVBG) is a tool a that automates the selection and timing of nonverbal behavior for Embodied Conversational Agents (aka Virtual Humans). It uses a rule-based approach that generates behaviors given the information about the agent's cognitive processes but also by inferring communicative functions from a surface text analysis. The rules within NVBG were crafted using psychological research on nonverbal behaviors as well as our own study of corpora of human nonverbal behaviors to specify which nonverbal behaviors should be generated at each given context. In general, it realizes a robust process that does not make any strong assumptions about markup of communicative intent in the surface text. In the absence of such markup, NVBG can extract information from the lexical, syntactic, and semantic structure of the surface text that can support the generation of believable nonverbal behaviors.

Users

Section aimed at users, especially how they can run and use the component, if applicable. Provide information on how to use the function mentioned in the previous section. Put each functionality in a seperate section.

Example: Launch the Component

For instance, what dependencies exist, what parameters can be chosen on start-up.

Example: Set up the Component

For instance, what settings are needed within a certain scenario, which are mandatory, which are optional, etc.

Example: Perform a Component Specific Task

For instance, how to send a text string to the agent using the speech client, how to kill all checked components using the launcher, etc.

Authors

Section aimed at authors. Authors can create new characters or adapt existing ones. Provide an overview of what data can be manipulated and how. Provide examples and mini-tutorials on who to perform specific tasks.

Developers

Section aimed at developers. Use to explain the architecture of the component, how to make changes, where files are located, what caveats exists, etc. Should at least contain a section on the messages received and send.

Message API

List here all the (ActiveMQ) messages this module receives and sends. You can use this section to explain how this module fits within the overall architecture.

Known Issues

Provide a list of known issues and peculiarities. Allow the reader to give feedback, probably by giving a link to the Support page.

FAQ

Probably just link to the appropriate section in the Main FAQ.