Overview

HOOPS Communicator utilizes two distinct server applications that, when combined, can be used to support multiple simultaneous HOOPS Web Viewer (HWV) instances each viewing a distinct model.

Stream Cache Server

The Stream Cache Server (SC Server) provides support for efficiently streaming data contained in one or more SC models to the HOOPS Web Viewer (HWV), via a websocket connection. A single instance of a SC Server only supports one client connection, but many instances of the Stream Cache Server will typically be running in parallel on a single web-server.

The SC Server supports two modes - client-side rendering (CSR) and server-side rendering (SSR). In CSR mode, the SC Server will send CAD model geometry to the connected HWV and let the HWV perform 3D rendering using WebGL directly in the user’s browser. In SSR, the SC Server will perform 3D rendering itself on the server machine, then send the rendered results as image data to the HWV for display.

The SC Server uses WebSocket technology for its communication with the HWV, which requires that each SC Server has access to an unused networking port. The HWV can either connect directly to this port if all intermediate firewalls have been configured appropriately, or the HWV can use a single shared port via proxy technology. But note that even when a proxy approach is utilized, each SC Server instance still requires a dedicated networking port within the server machine because the proxying happens later in the networking sequence. If a proxy is being used, the server machine likely only needs to configure its firewall for the single proxy port to allow network traffic.

The next section describes the HOOPS Communicator HOOPS Server, which manages multiple SC-Server instances. But it’s important to note that the SC Server can be run directly if you should require a server configuration that doesn’t use the HOOPS Server.

HOOPS Server

The primary responsibility of the HOOPS Server is to manage multiple SC Server instances and associated resources on a single machine. The responsibilities include:

  • SC Server Lifetime Management: A new SC Server instance will typically be started in response to a request to view a model. An existing SC Server instance will be shut down if the associated HWV disconnects or if an inactivity timeout occurs. The maximum number of simultaneous SC Server instances per-server machine is capped by a user-managed configuration file, thus it is important to properly control the startup and shutdown of these instances.

  • Network Port Management: The HOOPS Server configuration must include a range of ports that are dedicated to WebSocket communication between the SC Server and its HWV. The HOOPS Server must ensure proper use of these ports and must reclaim any ports if a SC Server instance shuts down or exists unexpectedly.

  • View Requests: When a user wishes to start a new HWV, a request must be issued to create a new viewing session and thus start a new SC Server instance for that HWV. The HOOPS Server supports two types of viewing requests.

    • REST Handshake: In this mode, a viewing request is sent to the HOOPS Server via a REST-style HTTP URL. The HOOPS Server will start a new SC Server instance and respond with a URI that can be used for viewing by the HWV.

    • WebSocket Proxy: In this mode, a viewing request is sent to the HOOPS Server via a WebSocket URL, typically of the form “ws://<server-hostname>:<port>”. The server will start a new SC Server instance and internally proxy the request directly to that new instance.

HTTP-Server

In all cases, a standard HTTP web-server must also be used in conjunction with the Communicator servers to deliver HTML, JS, CSS, images, and any other files to the requesting browser. The HOOPS Server includes a built-in HTTP web-server that can be used for development and evaluation purposes, but it is not recommended for use within a production environment. In that case, an industrial strength web-server optimized for serving files should be used. Some alternatives here would be Apache or NGINX.

Rendering types

Client-Side Rendering (CSR)

With CSR, the SC Server streams model data to the HWV allowing the client hardware to render the 3D graphics using WebGL technology. WebGL is a JavaScript API for rendering interactive 3D graphics in a web-browser without the use of 3rd-party plug-ins. It is available in most modern browsers.

For small models, the SC Server can often simply just send over the entire model, but for larger models, that approach is not practical in terms of memory or network bandwidth. Thus, in the case of a larger model, the SC Server uses heuristics combined with its knowledge of the current 3D camera orientation to determine the best sections of the model to send to the connected HWV. This approach allows very large models to start rendering with partial data almost immediately when using the CSR approach.

Because WebGL relies on the client hardware to perform all rendering, any device running the HWV must be sufficient for rendering interactive 3D graphics.

Choose CSR when:

  • You have sufficiently high network bandwidth to serve 3D model data in an acceptable amount of time

  • The client device has enough computational power and GPU capability to properly render 3D models

  • The client browser supports WebGL

  • You intend to have a large number of SC Server running simultaneously on each server machine.

Server-Side Rendering (SSR)

When HOOPS Web Viewer is set up for server-side rendering, all rendering of the 3D model is performed by the GPU on the web server. As a result, your server back end must include an instance which includes a GPU. As the user interacts with the model, the server renders each frame and sends an image back to the client’s web browser for display, minimizing hardware requirements for the client. The images are sent in real time, so it will appear to the user as if the rendering is being done in real time on the local machine.

Please note that SSR is only used for the 3D model rendering - all other capabilities like buttons and the model browser are created on the client side via HTML. This includes all user-created measurement and markup data.

The main benefit of SSR is the fact that only an image is sent to the client and so the user can start interacting with the model almost immediately. SSR also allows you to access high-powered GPU technology which can offer significant benefits with very large models. The major downside is that using SSR shifts the hardware requirements to the server.

Choose SSR when:

  • You want to target the widest range of client hardware.

  • You are planning to serve very large models to disparate clients.

  • You have a sophisticated server back-end which renders at an acceptable speed for your models. It should also have the ability to scale with the size of your models and number of concurrent users.

SCS - Single File Based Rendering

A final option exists that allows a model to be rendered without needing to use the HOOPS Server or start an associated SC Server. When converting a source CAD model, the HOOPS Communicator Converter can be directed to generate a single file named “<model-name>.scs”. This is a standalone version of the CAD model that can be loaded into the HWV for rendering on the client using WebGL.

The SCS file will typically be delivered to the client browser using an HTTP web-server, so there is still a server involved, but this approach does eliminate the need for either a SC Server or the HOOPS Server.

While the SCS file approach offers some clear value due to its simplicity, there are drawbacks:

  • The entire SCS file must be received by the browser before any rendering of the CAD model will occur. For very small models this is fine, but for medium to large models this will create a noticeable start-up lag when compared to using CSR.

  • For larger models, the size of the SCS file can simply become too large to be practical.

Choose SCS when only small models will be viewed

Using SSL

It is possible to use Communicator with SSL. Please see our forum post about this topic.