Entities

An entity is a dynamic object, agent or actor that has a physical presence in the simulated world and typically has some movement and/or dynamic behavior. Depending on the application, it could be a vehicle or a person.

Entity metadata and life-cycle

An entity is owned by an application. That application is responsible for publishing messages when the entity is created, destroyed, or its metadata or state is updated. Applications can also request updates, upon which the owning application should publish an update. Entities are identified by an ID, generated by the owning application. Some metadata is associated with an entity and can be used by applications to represent the entity correctly. Metadata includes fields such as type, category, color etc. Metadata should be semi-static, i.e. it shouldn’t change much over time, but updates are not strictly forbidden.

Entities and their metadata are exchanged on the entity channel using the Entity message definition, and operations (like requesting updates, transfering ownership etc) are exchanged on the entities channel using the EntityOperation message.

Entity position

Initial position of an entity is optionally included in the create message. Subsequent position updates are exchanged on the position channel using the EntityPosition definition. The position message provides a lot of options regarding coordinate systems. No assumptions are made on update frequency, as that is very dependent on the dynamics of the simulation model, hence that is up to the application owning the entity to decide. The Unity and Unreal clients provide functionality for interpolating and smoothing between position updates.

Additional entity state

Depending on your application, you probably want to exchange more information about simulated entities than what is provided by the RTI common object model. In order to accomplish this, it is recommended to spend some time defining what states to exchange, based on what changes in the underlying models, and then defining a new channel and message format for each set of states.

As an example, in a driving simulation, one might want to define a VehicleState message definition, containing data such as wheel angles, lights and blinkers, and exchange that on the vehiclestate channel whenever a vehicle changes its state and/or periodically. In addition, if we want to exchange information on pedestrians, we could define a PedestrianState message and exchange that on a separate channel. The logic for which channels to subscribe to for which entities would be part of the data exchange contract between applications.

Another thing to consider is state update frequency. If you have multiple states for entities, some that change very frequently (such as wheel angles) and others that change less frequently (such as parking brake or occupants of a car), you probably want to exchange those states in two separate message definitions and channels rather than transmit all those states repeatedly at a high frequency.

See the documentation on data exchange model for more information on how to define your own messages.

If you’re developing in Unity or Unreal, the component-based architecture of game engines maps pretty well to a set of states per message/channel. In other words, consider implementing a component for each channel and message definition, e.g. for the vehiclestate channel and VehicleState.proto definition, you would have a VehicleStateComponent in your game engine, deriving from RTIEntityBehaviourclass in Unity and RTIEntityStateComponent in Unreal.