 |
VR-Forces 4.3 Class Documentation
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
|
VR-Forces 4.3 Class Documentation
|
Entity behaviors in VR-Forces are implemented using components.
Components are the building blocks that make up the sensor-controller-actuator architecture. VR-Forces supports three types of components:
The sensor-controller-actuator architecture is similar to that used in robotics. (For details, please see 4.2 - Components and The Component Manager.)
All components in VR-Forces inherit DtSimComponent (simCmpnt.h). DtSimComponent provides the basic infrastructure of the component architecture. Sensors are derived from DtSimComponent, controllers are derived from DtControllerComponent (cntrlCmpnt.h), and actuators are derived from DtActuatorComponent (actCmpnt.h).
Since components are created by the factory system, DtSimComponent provides the usual factory-specific member functions as described in 2.4.1 VR-Forces Factories. The constructor takes a const DtString name, DtVrfObject* owner, DtSimManager* simManager, DtComponentDescriptor* desc, and DtReaderWriterRegistry* parentRegistry as arguments. (Components are not currently read from or written to files – the registry pointer is included for future use.) The name of the component must be unique within the entity that it is part of. Component descriptors are described in 5.2.2 Component Parameters and Component Descriptors.
The type() member function of a component must be overridden if you create a new kind of component, reporting the DtString type of the component to be used by the component factory. The type string must be unique across all of the known types of components. The type strings used by VR-Forces components are defined in compTypes.h.
Component parameters, including the name and type of component, are normally specified as part of the component descriptor that defines the component, a DtComponentDescriptor (compDesc.h). Component descriptors contain the readable-writable parameters used to create and initialize the component in the object parameter database. Component descriptors are described in 5.8.1 Component Descriptors.
Components communicate with each other through ports. There are two types of ports: input ports (DtInputPort, in inputPort.h) and output ports (DtOutputPort, in outputPort.h). Ports can be used to transmit such data as a Boolean on/off switch, a list of target object IDs, or a range of floating point values. A component that produces data (such as an automotive controller that produces throttle values) will have one or more output ports. A component that consumes data (such as an automotive actuator that accepts throttle input) will have one or more input ports. For details, please see 5.9 - Ports and Port Groups.
Components have a close relationship with an entity’s state repository (DtVrfObjectStateRepository). Controllers often need to determine an entity’s current state information. Actuators may also need to examine an entity’s state and, typically, update it. When a component is created, the setEntity() member function provides it with a pointer to the entity that it is a part of. DtSimComponent caches that pointer, as well as a pointer to the entity’s local state repository, for convenience. If a component is used for a particular type of derived entity class and needs access to a derived entity or derived entity’s local state, these pointers can be cast to the appropriate type. Many of the VR-Forces derived classes override setEntity() to set a derived entity class pointer, so that this cast is not necessary every time the data is accessed.
Components have a tick() function that gets called each frame, or optionally, at some interval specified by the user. The DtSimComponent::tick() function does not do anything. Derived components implement the tick() function in various ways, depending on their purpose. Controller classes can implement the tick() function to generate new control inputs each frame. Actuator components use the tick() function to update the entity’s state. A component’s tick() function is called by the DtSimComponentManager.
Sensors are used to model the external simulated world. The DtObjectSensor (objectSensor.h) is the base class for all sensors. The DtSignatureObjectSensor (signatureObjectSensor.h) class is used to detect all objects that have a signature configured. The DtRadarObjectSensor (radarObjectSensor.h) is a special object sensor that also acts as an emitter. For details, please see 7 - Sensors.
Controller components typically provide control inputs to actuator components. They may accept sensor input and use this information to carry out their functions. Controller components must inherit DtControllerComponent (cntrlCmpnt.h) (which is derived from DtSimComponent). The DtControllerComponent overrides setEntity() so that it can cache a pointer to the entity’s radio, just as the DtActuatorComponent does. Access to the radio is necessary for those controllers that need to respond to tasks and set data requests, send tasks to other entities (in the case of aggregates), or generate reports.
Some controller components implement tasks. The Task Manager calls the controller component list, which then calls the task functions.
Actuators provide the physical model of an entity. All actuators in VR-Forces are derived from DtActuatorComponent (actCmpnt.h), which is derived from DtSimComponent. Since actuators may want to send radio messages (for example, a report), this class overrides setEntity() so that it can cache a pointer to the entity’s radio. The DtActuatorComponent also provides an accessor to this radio pointer.
Many actuators receive control inputs from one or more controllers. They can use this control information, along with the entity’s current state, to generate new state values for the entity. For example, in the DtAutomotiveActuatorComponent::tick() function, it checks the throttle, steering, and braking inputs, computes the new location, orientation, velocity, and acceleration values, and then sets them in the entity’s state repository.
VR-Forces provides many component classes for modeling entity behaviors. They provide you with a starting point when you want to extend the toolkit. Please see 8 - Entity Behavior Models and 9 - Entity Behavior Subsystems for high level descriptions of components and component systems. You may also want to use the OPD Editor or Entity Editor as a convenient way to explore the components and systems used on individual entity types.
[<< Introduction to Components] [Home] [Top of Page] [Component Systems >>]