By default, the simulation engine will get the same terrain database (file) as defined in Terrain::3D Editor::OpenSceneGraph window. But often, the terrain that should be displayed on vsTASKER GUI 3D view does not need all the details of the rendered scene. In such case, the GUI and SIM database are different in size and details but should keep the same scale, origin and projection definitions.
When this option is checked, the source code of vsTASKER will be processed by the wizard in order to include all the necessary OSG code to make entities displayed automatically on the OSG terrain view. The specific code will be added between special tags that shall not be removed. Once inserted, it will no more be changed and user can amend it.
If unchecked, the wizard will remove all wizard added code, including whatever user has inserted between the tags!
Using the wizard has now been deprecated since version 7.1. It can still work but we strongly suggest to use the Model Components, as explained in the Tutorial.
Note that both methods cannot be mixed! To convert a database to use Model Components, first, uncheck the Code Wizard, generate the code then proceed as indicated in the Tutorial.
Wizard only runs at code generation. To add or remove it, check or uncheck then generate the code.
When checked, display some textual data on 2D projection.
The object used is /src/osg/osg_hud.cpp
The function called at each frame is drawImplementation().
Either the 2D OpenGL code is entered here, either it is put into the HUD panel of the HMI property window (in such case, do not disable the HMI to allow code generation).
Header and Source code can be modified into this window or directly from Visual Studio from the solution (or any other text editor).
If code is modified, it will be automatically saved when OK button is depressed.
It is a good idea to save the modified code under another file to keep the original one unchanged. Usebutton for that.
Refer to "Understanding Runtime" in the Tutorial document of vsTASKER.
Do not forget that all provided source code in vsTASKER environment is subject to change from one revision to one another. So, it is a good practice to change the name of any cpp wrapper if any change must be applied on it.