At this point the reader may also find it helpful to use the Hoops3dPartViewer to open the model of their choice and then open the segment browser, set the starting point to “root segment” via the drop down box and then explore this hierarchy interactively.

In HOOPS/MVO each View is represented by an HBaseView object, which corresponds to a separate driver instance segment under the corresponding driver type segment (“opengl” or “msw”, as examples). As indicated in the diagram, the information contained in these segments relates to how the Model should be displayed on the screen (or printer, file, etc depending on the particular driver).

Each Model is represented by an HBaseModel object, and this corresponds to a unique segment (or segment tree) in the “?Include Library”. It is important to note that these Model segments should only contain the specifics of the model data itself, and not the presentation of the data. Lighting and camera information belongs with Views, not Models. Only attributes that are fixed properties of the model should be set in the model segments.

2.0 Working with Models and Views

2.1 Model Setup

To start working with some existing data you typically must first load a file. The location in the application code where you handle file loading is the appropriate place to create your new HBaseModel object, since the Model refers to the graphics data being dealt with in the application.

Here is what this code might look like:

void MyMainAppObject::OpenFile()
{
    m_pHoopsModel = new HBaseModel(m_pHDB);
    // we’ve created a model and so we have
    // a location in the graphics database
    // to insert our visualization information
}

Now that you have the HBaseModel object, you can begin to populate the Model segment with geometry and subsegments. The handle to the Model segment is accessed using the HBaseModel::GetModelKey() method, which returns a key corresponding to the root of the segment hierarchy for that model. The following shows how the model segment would be accessed and populated with data from the file:

void MyHBaseModelObject::InitModel()
{
    HC_Open_Segment_By_Key(GetModelKey());
        // read in file and map any graphical
        // information to HOOPS segments/geometry
    HC_Close_Segment();
}

2.2 View Setup

This is where the interaction between Model and View becomes apparent. Because each View is an onscreen representation of the Model data, an HBaseView object must be created for each viewport in the application. Initializing the HBaseView object is the critical step that brings this whole article together. This is where Model objects become tied to View objects.

The constructor for HBaseView accepts a pointer to an HBaseModel object. This is how an HBaseView object becomes tied to an HBaseModel. Here is what the HBaseView initialization code might look like:

2.3 Working with the Model

Your application logic is now ready to interact with Views and create or edit the associated model information (segments and geometry) as necessary. The HBaseModel object can be accessed from the HBaseView object by calling HBaseView::GetModel() Additionally, the key of the top level segment associated with the HBaseModel object can be directly accessed by calling HBaseView::GetModelKey().

For each View in the application, you can use the HBaseView::GetSceneKey() method to access the Scene segment, and include whatever parts of the Model data that you would like to see in the View by using HC_Include_Segment() function.

Once you are comfortable with the way Includes work between your Models and Views, you can explore more advanced functions such as Conditional_Include and Conditional_Style. These functions allow you to have greater control over how and when segments are included in your View.

2.4 Exporting Model Information

When it comes time to exporting your application data, there are generally two ways of dealing with the graphics information stored in your Models and Views.

A. Exporting only Model information

This is a good approach if you are not concerned about retaining view information, and involves writing out information beginning with the Model object’s segment. This means that only the ‘raw’ graphical information that represents the model is exported, and any View information that exists at export time is lost. Reading applications would need to reset View attributes from scratch.

B. Exporting both View and Model information

This is a good approach if you wish to preserve View information, and involves exporting the View attributes beginning at the ‘Scene’ segment, along with the raw model information. This gives other applications the ability to see ‘saved’ views. (Perhaps it was desirable to capture several views which showed the model from different angles or represented zoom/detail views that depicted a sub-area of the model.)

However, the reading application would need to have special logic to properly handle this view information. If it did not, then the application’s View settings might have no affect and the model could appear ‘frozen’. (This is because the View settings in the file might include a HOOPS Camera, and a higher-level camera set in the application would take no affect due to the nature of HOOPS’ attribute inheritance. The lower level camera ‘wins’.) Therefore, if you are exporting to your own custom file format and also develop the reading applications, then you should ensure that the View information is correctly processed. This typically would involve querying it, removing it from the Model, and resetting it in the View.

If the data is being exported to a HOOPS Stream File (HSF), then you should can store the initial camera setting by using the HSF specification’s TKE_View opcode. This stores a camera as a separately identifiable entity in the HSF file, and thus enables HSF reading applications to separate the View from the Model. Note, if the name of the TKE_View is ‘default’ then the protocol in HSF reading applications is that they honor that camera as the initial camera when the model is first loaded.