Inspiration

Rising interactivity of the web platform and the pricing model of cloud services converge to a trend where 3D VFX rendering workloads can be offered as an on-demand service. This can offer smaller 3D modelling companies to flexibly adopt and scale their hardware needs without upfront hardware costs (CPU, GPU, Memory). Imagine a 3D effects modeler/artist with a cheaper personal PC wanting to offload compute intensive rendering tasks to high performance VMs. OpenVDB is an industry standard software library used to render high resolution sparse volumes (think water, snow, smoke, clouds). Renderers based on this toolchain find use in all popular 3D animation and VFX studios and scientific simulations. What if you take this a step further and offer it as a service or prototype visualization tool?

What it does

This project takes a volume data (.vdb file) and runs a ray tracer to generate a 2D rendering/image (.exr) on the cloud. The user can use a web app to upload his volume data and obtain a rendered image without them to having an expensive personal machine to perform this task.

How we built it

MVP is to have a web app to upload volume to an ‘input’ bucket. The bucket triggers a lambda function for POST-ing this object to a service running on a VM with a volume ray tracer configured. VM performs the ray trace and moves the result (.exr) to another ‘output’ bucket. The web app can let the user access the results from this ‘output’ bucket.

Challenges we ran into

As a newcomer to the massive aws ecosystem, the IAM policies and roles that need to be navigated for the individual services to have access to each other was an unforeseen time cost for us. In context of this and the time constraints the services are not integrated. The web portal could not be developed.
From the design diagram (2), (3(a)), (3(b)) were implemented. (1) and (4) missing.

Accomplishments that we're proud of

Configured an EC2 VM with the required prebuilt ray tracer utilities, developed a web service on the same to invoke the same. Configured the buckets on aws to have on trigger a POST to the service on VM upon input upload. The service invokes the renderer.

What we learned

Design should have been simpler in the given time constraints, could do better in estimating effort. Tech: EC2, IAM, CloudWatch, Lambda functions, AWS cli, Apache httpd.

What's next for RenderWeb

Integrate missing services, redo security, add authentication, containerize instead of VM perhaps.

Built With

Share this project:

Updates