If you want to modify or extend a VR-Vantage application, there are two main approaches you can take:

Build a plug-in that can be loaded by these applications (Creating a Plug-in )
Create a new application based on one of the supplied examples (./appsrc/userStealth, ./appsrc/userIG, ./appsrc/userXR) (Building a New VR-Vantage Application ).

In most cases, if your goal is just to extend our applications, we recommend the plug-in approach. If your goal is to create a new visualization application that shares the same basic framework as a VR-Vantage application, then it will probably make more sense to start with one of the example projects in ./appsrc and make changes within the application.

A good way to decide which approach to take is to ask yourself if you would describe the goal of your work as "VR-Vantage, with the XYZ feature disabled, and the ABC feature added". If the answer is yes, you should probably use a plug-in. If no, then create a new application.

For typical application extensions, plug-ins have the following advantages:

A plug-in developed with the VR-Vantage toolkit will work in VR-Vantage, IG, and XR, and most other VR-Vantage-based applications. So if your organization is using the VR-Vantage applications in different configurations or doing customized application development, a given plug-in can reused in multiple settings with no additional work.
Plug-ins facilitate easy integration with the work of other developers. If multiple developers add different capabilities through plug-ins, it is likely that you can use some, or all of them, together in VR-Vantage applications without additional development. On the other hand, if each of the developers added features by building separate custom applications, you would have to do additional work to merge the various extensions into one application.
Plug-ins allow you to easily include or exclude a feature to meet the needs of a particular project. If you do not want to use a feature, do not load the plug-in that implements it.
It will usually be easier to port a plug-in to a new version of VR-Vantage than it would be to port a custom application. It is less likely that you will have to merge project settings, or merge any source code, if the userapplication example source code changes.
Using plug-ins may help you avoid the need to purchase licenses for third-party libraries. Some of the third-party libraries that we have licensed (notably SpeedTree), require that developers buy a third-party developers license if they are building new applications using the VR-Vantage Toolkit, but do not require a developers license if a customer is merely modifying our existing applications using plug-ins.

Ideally, a plug-in module should be limited to a specific, single piece of functionality. For example, if you want to add a new menu to the GUI, and an unrelated new kind of scene object, use separate plug-ins. However, if the new features work together, such as a new kind of scene object and a menu option to configure or control it, then these two pieces of code should probably be built into the same plug-in.

Regardless of whether you choose the plug-in approach or the new application approach, the code you write to implement your new functionality will be largely the same. The principal difference in code between the two approaches is how you access the DtDe to register your new classes:

In a plug-in, the DtDe is passed to the plug-in's initDeModule() function.
In a custom application, you ask the main application framework class (DtVrvApplication, in DtVrvApplication.h) for a pointer to its DtDe. Switching between the two approaches is usually quite straightforward, if your new code is really an application extension.