 |
VR-Forces 4.10 Class Documentation
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Properties Friends Macros Groups Pages
|
VR-Forces 4.10 Class Documentation
|
The vrfSim application is a VR-Forces application that responds to control messages sent by a tool such as the VR-Forces GUI (vrfGui), by making appropriate calls to the VR-Forces Simulation API (that is, DtCgf.) vrfSim is fairly simple in the sense that it does not add a lot of code to what is provided by the VR-Forces API, but it is very powerful because it incorporates the full functionality of the VR-Forces toolkit.
It represents a self-contained CGF simulation engine, ready to be controlled by a remote control application, such as vrfGui. It accepts command-line options for setting modes and parameters, and it is configurable, because its capabilities and behavior are driven by the object parameter database and other files.
Many VR-Forces developers need an application that works just like vrfSim (keeps its command-line options, and ability to be driven by a remote VR-Forces GUI), but that replaces some default dynamics model with custom code, adds the capability to perform additional tasks, supports some new kind of sensor, and so on. Therefore, we provide source code and project files or makefiles for vrfSim in ./appsrc/vrfSimUser. You can edit vrfSimUser's main.cxx file, use the VR-Forces Simulation API to modify its behavior, and rebuild vrfSim.
In main.cxx, all of the functionality of the vrfSim application is encapsulated in the DtVrfApp class, defined in vrfApp.h. The main() function just instantiates DtVrfApp, calls init() on it, and then executes mainLoop(). The application's functionality was put into a class, as opposed to directly in main(), so that other applications (like the VR-Forces examples) could inherit vrfSim's functionality without duplicating code. DtVrfApp is not really a part of the VR-Forces simulation engine. It is a class that uses the VR-Forces simulation engine through the VR-Forces Simulation API.
When you modify or extend the vrfSim application, we recommend that you avoid making modifications to vrfApp.cxx or vrfApp.h, so that you do not have to merge your changes into future versions of these files when you upgrade. In most cases, you should be able to just obtain a pointer to the DtVrfApp's DtCgf object (using its cgf() member function from within main()), and configure it appropriately using DtCgf's member functions, managers, or factories.
Most of the VR-Forces API examples take this approach. For example, addActuator, which shows how to add a custom dynamics model for ground vehicles, adds just the following line to main.cxx to register its new subclass of DtActuatorComponent with the VR-Forces simulation engine:
When your application needs to configure DtVrfCreator, as described in 2.4.2 The VR-Forces Creator, (for example, when you need to register a custom subclass of a class like DtVrfObjectManager), you can pass your DtVrfCreator pointer to DtVrfApp::init(), which will pass it on to DtCgf::init(), as follows:
When you need to change the behavior of DtVrfApp in a custom application (for example to add or remove command-line options), we recommend subclassing DtVrfApp and overriding the relevant functions.
If you are embedding VR-Forces functionality in a larger application, you usually will not want to use DtVrfApp, since it represents an application that does nothing but execute a VR-Forces simulation engine, and therefore implements a simple main loop for you. Instead, instantiate the classes that you need explicitly within your application, for example, DtCgf, DtCgfDispatcher, DtBatchManager, and so on.
[<< Customizing or Extending the Simulation Engine] [Home] [Top of Page] [Checking for VR-Forces Licenses at Runtime >>]