4. Setting up the Main Viewer
In this chapter, we will walk through setting the main focus of our application: the viewer.
- Instantiating and Starting the WebViewer
- Setting Callbacks
- Configuring additional WebViewer options
Create the main entry and structure for the application
To get started, we will create a new JS file titled app.js and place it in the src/js folder. The app.js file will contain our main application logic, as well as manage the setup and handling of our WebViewer object.
To better organize our code, we will be breaking up our code and using the external module approach for this development. We will be using the ES6 class syntax to encapsulate functionality. Let us start by making the main class in our app.js file. This is where we will instantiate our viewer and build our application through composition from other objects we will create later. Right now, we will just leave the class and constructor blank and return to it.
Setup, Instantiate, and Start the WebViewer object
As discussed in the Getting Started guide, HOOPS Communicator requires that the DOM content and structure be loaded before trying to instantiate any WebViewer objects, since they will look for a <div> id to populate. Because of this, we will instantiate our main class within the onload browser event callback, once all the DOM content has been loaded.
Lastly, since we have provided the CSS file for you, you can import the CSS at the top of the app.js file. Your app.js file should now look something like this:
Because we have provided the HTML and styling, we should see the <div> element present that we can instantiate our WebViewer into. We will use this div ID when setting up our viewer.
We can see that the div ID we are interested in is called "viewer". We will do the same procedure documented in the Getting Started guide to instantiate an empty viewer. Go ahead and write the following code in the constructor of your main class, using the "viewer" div ID.
If you look back at your web application, you will see nothing has changed. This is because we have not yet started the viewer, just instantiated it.
Again, you may be wondering why nothing has changed – don't worry, we haven't loaded a model yet - you can specify a model when instantiating the viewer, but we elected not to.
Create the WebViewer callback skeletons
The next step is to setup the callbacks on the WebViewer. If you are unfamiliar with basic callback usage in HOOPS Communicator, or need a refresher, please review the callbacks section of the Getting Started guide. For our application, we are interested in two main callbacks – modelStructureReady and selectionArray.
Because we want to load a model to the scene after we have instantiated and started the viewers, we need to wait for the modelStructureReady callback to fire, or else we will get an error to trying to access the Communicator.Model class too quickly. The selectionArray callback will be used to gather user selection events, and query model/node information.
From the comments, you can see we will be performing several steps in each callback. Let's start with the modelStructureReady callback first, as it is rather straightforward.
When the modelStructureReady callback is fired, we should be able to add some additional elements to our scene, like a navigation cube and axis triad. By default, you can access the navigation cube and axis triad via the Communicator.View object in the WebViewer. We will retrieve these objects, enable them, and move the navigation cube from its default position to the lower right corner of the scene.
In addition, we will spice up our viewers by adding a colored background consistent with our UI theme. This is as simple as calling setBackgroundColor on the Communicator.View object. You can specify a single background color, or make a gradient from top to bottom by providing two colors. We will choose to make the gradient.
Lastly, but most importantly, we will enable the input button to load a model to the scene. We will write this functionality later, but by waiting for modelStructureReady to fire before enabling the button will ensure we get no loading errors by trying to load a model prematurely. Our final modelStructureReady callback will look like this:
The selectionArray callback is more involved, and will rely on some other aspects of our application, so for now we will keep it empty and revisit the callback as we develop the pieces we need for its functionality.