This manual covers the installation and use of the Voxel Farm Cloud solution.


The Voxel Farm Cloud solution can be deployed using Microsoft’s Azure, Amazon Web Services or over a Local Area Network. Unless it is explicitly noted, you can assume statements in this manual apply to these three different deployment modes.


A typical Voxel Farm Cloud deployment involves setting up three different server services:


  1. Front Web Server. This is a ASP.NET application. It provides a WebUI for project management and data rendering; it also implements a REST interface to access and modify Voxel Farm cloud projects.
  2. Content Service. A stateless service designed for streaming content to clients. The Content Service produces multi-resolution views into spatial content on-the-fly, including dynamic queries.
  3. Processor Service. A service that performs time-consuming dataset processing operations, for instance converting a point cloud into a solid volume or surface.


For storage, the Voxel Farm Cloud platform requires:


  1. Access to a blob storage system (like Amazon’s S3)
  2. Access to one table in a key/value storage system (like Amazon’s Dynamo)


The Voxel Farm Cloud platform includes three client systems:


  1. Web client. A set of JavaScript classes that allow to interact with Voxel Farm Cloud servers and render spatial data in modern web browsers.
  2. C# client. A set of C# classes to interact with Voxel Farm Cloud Servers.
  3. Unity3D client. Based on the C# client, this adds rendering of Voxel Farm Cloud datasets inside Unity3D projects.


Architecture Overview


Once deployed, the different components in the solution will be operating as shown in the following architecture diagram:



This deployment involves:


  1. Setting up two public ports facing the clients (orange lines in the diagram). One is for HTTP/REST access, the other one is for TCP/IP streaming (supporting both native sockets and WebSockets)
  2. An instance of IIS that runs the Front Cloud web application
  3. Configuration of an Event Bus that will allow the different servers to communicate internally. The event bus is only necessary when a ProcessorServer is present in the solution. For a read-only deployment (that is, users will not be able to create or process new entities in the project), no Event Bus is necessary.
  4. Consider setting up at least two different machines, one running the WebFront and ContentServer services and the second one running the ProcessorServer service. Tasks performed by the ProcessorServer may take all CPU available, which may cause the other servers to starve and stagnate.


This deployment architecture scales out by:


  1. Adding more Front Web and Content Server nodes proportionally to how many users are connecting to read data from the system.
  2. Adding ProcessorServer nodes proportionally to the number of dataset import jobs requested by users.


When scaling up:


  1. Consider ContentServer benefits from increasing the number of CPUs and their frequency. The bandwidth between the ContentServer and the blob storage should be maximized. There is not much benefit in increasing RAM beyond 8GB. Also, since disk usage is minimal, there is little advantage in improving the speed and size of hard drives.
  2. Consider the ProcessorServer makes heavy use of all available resources. Increasing the available RAM (minimum 16GB) and the number and frequency of processor cores will have the most effect.