3D Design Reviews On-demand with Autodesk VRED and AWS

Introduction

3D product visualization and virtual prototyping are integral to product design, especially in industries including Manufacturing and Automotive. Last year, teammates from the AWS Spatial Computing community wrote a blog post about Autodesk VRED, a software package that helps designers’ prototype and collaborate on high-quality streams or renders of engineering artifacts. That post, titled “Virtual prototyping with Autodesk VRED on AWS”, provided details on optimizing VRED for the Amazon Elastic Compute Cloud (Amazon EC2) G5 instance family and enabling different configurations, such as adding a shared file system for assets; it also included a link to an “Autodesk VRED and NVIDIA CloudXR on AWS” Quick Start deployment guide.

This blog post explores a novel approach to deploy Autodesk VRED on AWS in a way that can be integrated into Design and Engineering workflows and remove operational heavy lifting.

Last year, Autodesk Consulting presented a proof-of-concept (PoC) Django application that used VRED’s Python API to automate the setup of collaboration sessions. VRED customers on AWS have sought an option to scale their collaboration sessions using AWS services. The goal is to simplify data movement and reduce the operational burden of acquiring and managing hardware like GPUs and storage.

The Autodesk AWS Partner team engaged the AWS Open Source and Emerging Tech (OSET) team to help scale VRED deployments on AWS. This provided an opportunity for Solutions Engineers from the OSET team to adapt and take inspiration from Autodesk Consulting’s PoC and the AWS Partner Quick Start deployment released last year. The focus was on enhancing the end-user experience (UX) by making the process as simple as setting up a web meeting. The idea of building a VRED service emerged, and Autodesk colleagues were keen on exploring further.

Read on to discover how we designed and implemented the VRED Session Management Service (VRED SMS), which enables on-demand 3D design reviews.

Design considerations

When designing VRED SMS, we focused on two personas – end users, who launch and participate in design reviews, and IT/DevOps teams, who deploy and manage that solution.

For end users, we aimed for a user experience akin to setting up a web meeting. End users may already use an asset (or project) management system, which would be an ideal starting point to launch design reviews; that system essentially stores/links assets. Building an API-based web service would offer the flexibility to integrate those existing systems or allow for a more customized user experience.

Additionally, we considered the total time required to fully launch a VRED session using the Autodesk VRED and NVIDIA CloudXR on AWS Quick Start solution (released by the AWS Partner team). It leverages AWS CloudFormation to deploy AWS resources and Amazon EC2 user data scripts to install and configure VRED on Amazon EC2 instances. Although this initial approach was effective for launching a VRED environment, its total launch time (about 30 min) exceeded the experience we wanted to deliver. This led us to consider packing the VRED install and base configuration into a pre-built Amazon Machine Image (AMI) and leveraging the VRED API (see VRED Python documentation) for session-specific configuration. These major tasks – building AMIs and handling VRED sessions – involve coordinated steps, so we planned to automate it as workflows. The overall goal was to reduce the total launch time to produce an active VRED session to about 15 min. Additionally, with the Quick Start solution, end users (and teams including IT) needed to apply manual changes to their VRED configuration for subsequent design reviews involving other assets. Workflow automation and an API-based service would help implement a self-service user experience for end users and reduce operational burden on IT.

For IT/DevOps teams, our goal was to make the architecture composable, customizable, and simple to deploy and operate. For any project involving service-oriented architecture design, we typically express its dependent resources as an AWS Cloud Development Kit (AWS CDK) application. AWS CDK is a framework that allows developers to define infrastructure using code. Notably, the workflows driving AMI-based pipelines and session handling would be fully customizable to support additional requirements or configurations.

Architecture and implementation details

Based on the prior requirements and design considerations, the resulting solution comprises two key components:

• Golden AMI pipeline: to create base-level AMIs for different VRED versions and configurations.
• VRED Session Management Service: to launch and tear down VRED collaboration sessions.

Golden AMI pipeline

The Golden AMI pipeline is configured to build AMIs containing VRED and other dependencies that are installed using Amazon EC2 Image Builder. That pipeline provides an automated, end-to-end solution for creating customizable Golden AMIs based on a versioning scheme. Overall, this solution provides versatility through supporting variations in VRED versions, operating systems, and other dependencies.

The following figure shows a high-level architecture of the Golden AMI pipeline, which is defined by a set of pipeline and component configuration files. These configuration files specify inputs such as base AMI, configuration settings, and software packages for AMI customization. The output of the pipeline is an AMI that’s ready to be launched on Amazon EC2 along with the necessary software that was embedded in that AMI. This approach accelerates the deployment process when launching new Amazon EC2 instances on demand, especially when those embedded software packages are large and/or complex (including many dependencies).

Figure 1: High-level architecture

Implementation

The Golden AMI pipeline is derived from the AWS Sample, aws-cdk-golden-ami-pipeline. Written in TypeScript and deployed using the AWS CDK Toolkit and Node.js, this implementation offers a streamlined solution to build custom AMI pipelines for VRED. The Golden AMI pipeline takes a different approach compared to the VRED Quick Start solution. It uses Amazon EC2 Image Builder (or image pipeline) to integrate software and configuration into the AMI, whereas the VRED Quick Start solution uses Amazon EC2 user data scripts to perform entire software installations and configuration during launch. Overall, the Golden AMI approach accelerates VRED launch times, which improves the user experience for an on-demand design review service.

The image pipeline takes a base AMI and data stored in AWS SSM Parameter Store (SSM Parameter Store) and Amazon S3 as inputs. A base AMI contains a stock operating system (OS) (such as Windows Server 2022) plus the software drivers required to run VRED Core. SSM Parameter Store stores configuration parameters which are paths to VRED Core install media (i.e. /install-media-bucket/vred-16-0), a load script used by VRED SMS, and component configuration files (described in the next section); these artefacts are all stored in S3. The image pipeline is customizable, and multiple pipelines can be created to build custom AMIs to support different versions of VRED (e.g., VRED 2024.2, VRED 2023.1) and operating system combinations.

Configuration

The Golden AMI pipeline is defined and customized using pipeline (or main) configuration files and component configuration files. For a given Golden AMI pipeline, there is a JSON-based “main configuration file” and YAML-based “component configuration file”; both of these files are versioned. The primary purpose of the main configuration file is to define the orchestration process of the overall pipeline. The build component and test component configuration files define fine-grained commands that are executed when the pipeline runs. These commands are responsible for deploying, configuring, and testing the software packages that are stored within the outputted AMI.

Figure 2: Golden AMI pipeline recipe and components

Once the Golden AMI pipeline is deployed, the resulting image pipelines can be run from the Amazon EC2 Image Builder service console in the AWS Management Console to generate custom AMIs. Generated custom AMIs are identified using an AMI ID, which can be used to launch Amazon EC2 instances in the chosen region. Optionally, Amazon EC2 Image Builder can be configured to distribute these custom VRED AMIs to other regions and accounts. There’s flexibility to deploy a single image pipeline to a single AWS region that services multiple regions, or multiple pipeline deployments in different regions (if required).

VRED Session Management Service

The VRED Session Management Service (VRED SMS) provides a high-level REST API to create, tear down, and retrieve information about VRED collaboration sessions. The VRED SMS API enables customers to launch VRED sessions from practically any client application that can interface a REST API; for example, an extensible asset management system storing VRED scene files, or an entirely custom application to schedule and launch design reviews.

Table 1: VRED SMS REST-based API – resources and methods

Figure 3: High level architecture

The provisioning workflow that launches VRED instances and their collaboration session is the most complex part of this architecture. This workflow leverages a combination of the following AWS services: AWS Step Functions, AWS Systems Manager (SSM), and AWS Lambda. In the preceding diagram, a Step Functions state machine performs high-level coordination for this workflow – from receiving user requests to deploying an active VRED collaboration session. SSM Automation documents are the mechanism used for launching and preparing multiple VRED instances in parallel. Lambda functions handle incoming VRED SMS API requests for performing specific tasks, such as launching a new VRED collaboration session.

A state machine’s definition is flexible – it provides the ability to choose from a variety of states when constructing workflows. For example, some of these states include:

• Task state: a simple unit of work (i.e. writing data to a table in Amazon DynamoDB).
• Choice state: adds conditional logic based on the output value of a previous state.
• Map state: iterates in parallel through a data set that can be passed between states.

The state machine definition for the VRED SMS project was intentionally made compact and foundational in scope. It can be expanded to define custom error handling, notifications through other messaging systems, or provide support for other capabilities that leverage other AWS services. AWS Step Functions has a growing list of optimized AWS service integrations and direct AWS SDK service integrations to satisfy most use cases. A further benefit is that Amazon API Gateway integrates directly with AWS Step Functions. The following figure illustrates a detailed view of VRED SMS’ state machine and corresponding payload data relayed by the API upon receiving a request to create a design review (VRED collaboration session).

Figure 4: Orchestration automation

First, the provisioning workflow receives a POST request containing a JSON-based payload from the client application. That request is received by API Gateway, which responds by triggering state machine execution. This payload consists of the following structure with field names (in quotes), data types (in square brackets), and field value descriptions (after data types):

{
   "input": [JSON string] Input data supplied to Step Functions execution
   "name": [string] Unique name for Step Functions execution
   "stateMachineArn": [string] State Machine ARN to execute
 }

The preceding input field represents the information needed to start a VRED collaboration session. The input field value is passed directly as input data to the state machine’s execution; the name and stateMachineArn field values identify the state machine to execute. The following example is a formatted view of the expected format for the input field value:

{ 

  "bucket": [string] S3 bucket allocated to storing VRED scene files,
   "prefix": [string] prefix/folder containing a specific VRED scene file, 
   "key": [string] filename of a specific VRED scene file,
  "participants": [
    { "user": [string] userid, "host": [boolean] true },
    { "user": [string] userid, "host": [boolean] false },
    { "user": [string] userid, "host": [boolean] false },
    ...

  ],
  "session_pw": [boolean] set session pw?,
  "instance_type": [string] EC2 instance type,
  "vred_version": [string] VRED version
}

Note: the preceding ellipsis denotes other participants that may be included in the collaboration session.

When the state machine executes, it first checks the provided S3 key and prefix to confirm that the requested VRED scene file exists at its specified location. Next, a UUID is generated to represent a new collaboration session id, which is then written to DynamoDB (it maintains state information regarding the newly established VRED collaboration session and its associated VRED nodes). The following table is an illustration of the VRED collaboration session state information captured in DynamoDB.

Table 2: VRED SMS database design

Next, the VRED version (provided in the request payload) is used to find a corresponding AMI for launching VRED instances. SSM Parameter Store stores the mapping between VRED versions and AMI’s, along with configuration metadata (included in the following figure) that’s used by different components of the solution.

Figure 5: VRED SMS configuration metadata

Collaboration session requests are validated for accuracy prior to their launching. The workflow then progresses to preparing the required VRED nodes (one per Amazon EC2 instance). VRED SMS provides each participant their own individual VRED node (for optimizing performance). As VRED requires GPU hardware, our recommendation is to leverage G4dn or G5 instance families for optimal graphics performance.

prep-node is a Map state in the workflow that iterates through the list of session participants found in the input data and in parallel, provisions a VRED instance (terms “node” and “instance” are used interchangeably in this context) for each participant using SSM Automation. An SSM Automation document defines the steps (listed in the following figure under the “Step name” heading) to be run for each required VRED instance:

Figure 6: VRED node prep SSM Automation

SSM Automation represents a workflow similar to Step Functions, however the former is typically used for infrastructure configuration and deployment tasks. The SSM Automation document accommodates important items needed for a VRED node to be in a ready state to join a collaboration session. These items include: logging node information to DynamoDB, checking a node’s availability state, verifying that the VRED executable and VRED API are accessible and running. Host-based actions on a node (e.g. running scripts locally using SSM Run Command) are performed by the SSM agent software that is embedded in the AMI.

When a VRED instance is ready, a SSM Run Command document executes a load script on that node; this load script is embedded on the AMI and is added when the Golden AMI generates this custom AMI. The load script expects two arguments: S3 scene file location and VRED version. The VRED version is used to resolve paths (including the Python environment bundled with VRED) and VRED-specific registry keys required for licensing. The load script retrieves the VRED scene file and Python helper scripts from S3. These scripts are used to launch the VRED executable, load helper classes required for VRED API interaction, and check the availability of the VRED API. Next, the load script queries the license server from SSM Parameter Store (which was populated during the CDK infrastructure deployment) and assigns the VRED licensing configuration. Lastly, the load script runs helper scripts to launch the VRED executable, load the requested scene file, and instantiate a Collaboration class that contains methods and helper functions to support the VRED collaboration session lifecycle (including event handling).

Once VRED and its APIs are running on all nodes, the state machine summons all of those VRED nodes to join the collaboration session. To summon those VRED nodes, the state machine invokes a Lambda function (via VPC) to issue commands to the VRED Web API (hosted by the VRED Cluster Service) on each host; this Web API provides a mechanism to invoke code in an attached VRED session to support actions including: joining a collaboration session, loading a scene file, and general status checks. This command-and-control pattern of externally configuring and then remotely controlling a VRED instance can be applied broadly to perform a limitless number of actions in VRED. If a collaboration session password is requested, then the Lambda function creates one and stores it in AWS Secrets Manager; a reference to the secret ARN is associated with the session information stored in DynamoDB. This password serves as an added layer of security for the collaboration session.

Once all hosts have joined a collaboration session, that session is marked as “active” in DynamoDB, and an Amazon Simple Notification Service (Amazon SNS) notification email is sent to the end user, who requested the collaboration session. Amazon SNS supports a variety of notification types, including HTTP request to an API, and SMS. It is possible to use a callback mechanism by registering a webhook callback function in the client application to accept events/signals that indicate that the VRED collaboration session is ready.

Figure 7: Active VRED collaboration session

Conclusion

Overall, the VRED SMS project was successful proof of concept. We designed and built an architectural pattern to scale VRED on AWS and delivered a web service for end users to request design reviews on-demand through the VRED SMS API. The hosted RESTful web service is powered by AWS, and provides a highly automated end-to-end experience for managing VRED resources and collaboration sessions from setup to tear down. This innovative approach to deploying Autodesk VRED on AWS, allows for seamless integration into Design and Engineering workflows, and demonstrates how customers can remove operational heavy lifting.

If you would like to discuss the VRED SMS project in greater depth, please contact your Autodesk or AWS account team representative. They will be able to work backwards from your use case and brainstorm using this project as a reference architecture.

Further reading

To find out more about Autodesk VRED, visit their product page at https://www.autodesk.com/products/vred

Related AWS blog post: Virtual Prototyping with Autodesk VRED on AWS