Automate Your Visualization Data Preparation with VRED and ShotGrid

LIONEL GRAF: Hi, my name is Lionel Graf. I am an implementation consultant at Autodesk. My role, other than consulting, is to support our customers in the adoption and the customization of our technologies. What I will be talking about today is a good example of the type of use case, we are addressing with the customers we are working with.

From customization and automation, we can improve existing workflows and multiply the value of Autodesk solutions when making them work together. Let's see what ShotGrid and VRED can do together to automate data aggregation and preparation for visualization.

Please be aware that what you will see today is an example of how Autodesk consulting can help you push the boundaries of Autodesk products and extend functionalities beyond what is available out of the box. It is something you will not see in the product, and it does not reflect any plan for future feature development.

With that said, I would like to show you how you can achieve this. So let's review first what we will be talking about today. First, the words. We will start by talking about the solution components involved in this solution and how they can help you in taking advantage of a control pipeline to save time making repetitive and tedious tasks like preparing your model for visualization.

I will be using references from the automotive design workflow, but it also applies to a much larger range of use cases and industries. In fact, if you are producing content to illustrate and support design reviews on a regular basis, it should resonate to you.

Then, the "why." In a typical Design Studio, design reviews are happening on a weekly basis, meaning all the changes that happen between two project milestones need to be aggregated together in order to be presented to decision makers, and it has to be attractive. So depending where you are in the design process and how much people are involved in the content production, this can require a lot of effort to chase the latest models and prepare them for review.

In some cases, it can even be a full-time job to track the latest updates, gather data, put it together in a presentation environment with materials, lighting, variations, options, et cetera. Automating some of those repetitive tasks can help you, saving a huge amount of time and reduce the risk of errors. And it also reduces the risk of working in a design review and figuring out that the data is present, that what you are presenting is not the latest one.

Next, the "how." First, we will look at managing data in a consistent way with ShotGrid. ShotGrid is broadly used in the media and entertainment industry to help studios managing their work tasks and streamline collaboration between teams. Using ShotGrid to track release data helps to manage file versioning and make sure that the latest data is considered. We will also leverage ShotGrid Event Daemon to catch events that will trigger the automated process.

Regarding the automation, we will use VRED. Thanks to VRED API, we will package and automate all the tasks that are usually performed manually and publish the result back to ShotGrid. And finally, we will go through the benefits you can expect from using such an automated process and highlight the potential value.

Designing a product is a team effort. During design development, the project team is growing as the project matures. Detailing the design requires people from different expertise, sometimes from various locations, and understanding how the project moves forward requires you to capture the status of a number of different work streams running in parallel.

So on the regular basis, someone needs to gather all these models and put them together to visualize the project as a whole and report back on project progress. This may happen every week and can be a very time-consuming task, as the information is scattered across the team. This can be improved with ShotGrid and some automation. ShotGrid is well known to help with production tracking, making it easier to track progress on project assets.

The status of parts development is easy to visualize and update and communicating on project performance is much more efficient while being connected to the work being done. Retrograde also allows complex automation, with which we can extend its capabilities and design customized workflows.

What if we can let ShotGrid take care of packaging up the models and prepare a ready-to-use visualization scene? Using ShotGrid toolkit integration, accessing the data related to the task to perform is straightforward as well as releasing a model through ShotGrid's publishing process. From here, an automated process can capture the newly published file and trigger data aggregation and preparation.

Here, VRED is used to pull the existing parts together in a scene template and import the new published file. It also prepares the data, places the model, applies material computes lightmaps, and renders standard images. The output images and the VRED scene can then be published back to ShotGrid and be made available for review Visualization artists can then pick up the VRED scene to further develop the look and thus focus on making 3D shots instead of spending their time on data preparation.

So how did we get there? Let's dive deeper into the solution components first. We are using two well-known Autodesk technologies in the automotive industry, Autodesk ShotGrid and VRED. If you don't know yet what ShotGrid is, it is a pipeline management tool. This means that using ShotGrid, studios can improve the management of their creative work, track project progress and deadlines through tasks and boost team collaboration.

It helps, keeping creative projects on track and on time using dashboards and project reports. ShotGrid also helps speeding up iteration and improving review and approval workflows with dedicated tools. Giving feedback and collaborating with peers is made easy through notes and notifications. Plus, ShotGrid comes with desktop integration.

Tools like Alias, VRED, Maya, Photoshop, to mention only what is commonly used in the automotive industry, are all connected with ShotGrid, meaning that users can access ShotGrid project environment directly from their daily tools, and artists can focus more on their work and what they need to achieve instead of chasing the file they need to work in a complex network drive file structure.

And finally, thanks to a highly customizable environment, it can be tailored to your specific context. In the particular context of this solution, using ShotGrid ensures to manage data in a consistent way, and this is critical when we talk about automating data preparation and rendering workflows, which requires a reliable file organization and a naming convention to take advantage of version tracking.

VRED is typically used for real-time visualization, building configurators, and making photorealistic imagery. It has powerful functionalities to help combine many different file formats and can handle a very large amount of data for accurate visualization. VRED's rendering engine is giving amazing results, both in real-time visualization and ray tracing, so it suits almost any situation. And the same data set can be used for VR experiences as well as virtual photography.

Its engine is also able to handle simulation use cases like, for example, lighting or accurate visualization of measured materials. We can also use VRED for collaboration, connecting multiple VRED thread sessions together and gather distant users in the same virtual space and in VR or not.

With VRED's streaming capability, one can collaborate, review, and connect to a VRED scene from anywhere using host devices and web browsers. And finally, what we have been leveraging for our specific topic, VRED Python API gives us the ability to customize and automate almost anything.

The third component is involved here, ShotGrid Event Daemon. The event daemon helps us in accessing the ShotGrid events stream and trigger action on the back of certain type of events when they are detected. It typically runs on a server and monitors the ShotGrid event database.

When events are found, it uses custom plugins to perform actions. In our case, we are triggering a subprocess that will gather information about the published file and start a new VRED session to perform automated tasks on the data stored in the ShotGrid project.

So how do they work together? ShotGrid is at the center of that automated process. It manages the data and guarantees to have a structured and organized database. Also, we rely on ShotGrid to have the file versions which helps us down the road to know what needs to be updated or added to the assembled scene.

ShotGrid Event Daemon is monitoring ShotGrid's event activity. As every single action in ShotGrid is generating an event, we need to filter them so we can identify particular events. In our case, we will look for new published file events, which will trigger ShotGrid Event Daemon plugin to perform actions.

When a new published file event is detected, the daemon application starts a new thread session and triggers the automation. VRED then pulls all the existing files and the newly published files to aggregate them in a single scene. During the aggregation process, VRED automatically performs preparation tasks and saves the results. The output of this automated process is published back to ShotGrid and made available for review.

Let's get a bit more technical and have a deeper dive into the solution architecture. In addition to what I just described, it is worth mentioning that we are taking advantage of ShotGrid desktop integration in this process. This ensures that the shotcrete project context is known when working in Alias, and when the context the content creator publishes his work, we are sure that the data will be stored using the rules that we have been defined in the ShotGrid Toolkit configuration.

On publish, ShotGrid toolkit will create a new entry in the ShotGrid database and copy the file in the appropriate location on this, eventually using a particular naming convention if it has been defined. The new published file event will be called batch algorithm daemon and an aggregation task will start.

The daemon application will first gather information about the new published file context using ShotGrid API to read information about the parent entity in ShotGrid. This is where we can add information using ShotGrid custom fields and use them for more complex automation. Those information are used to generate a VRED starter script.

Once everything is ready, VRED is launched together with this script, which contains the automation tasks, and the automated aggregation starts. First, it gathers all the files to merge with the newly published file and then loads everything in the template. Once all the data has been imported, the script will perform the data preparation tasks.

We can imagine to automate anything. Here, as an example, we are focused on making the model ready for review, so materials are applied from the asset library, lightmaps are computed after having unfolded the UVs, and standard images are rendered for quick visualization. But we can think about more automation if there is some data to leverage. Let's imagine we are using CAD data, for example, which can contain meta information.

We could use this for scene organization, or if the source information contains pivot axis, we could use it to automatically apply animation and even generate what is necessary in VRED to interact with the parts and play the animation. Maybe we would like to apply a scene overlay and with kind of a simplified interface for manager to Review. The possibilities are endless.

Finally, once the visualization scene is ready, VRED will save it in the right place and publish it to ShotGrid. For the purpose of this class, let's simplify ShotGrid project architecture. The main idea is to have an input area where the source data gets published and an assembly entity which will host the result data.

We can also consider having a template environment to make sure that the scene context is consistent and that we compare to review files-- to review output files presented in the same digital environment. We will have here just one task per site where everything will be published, which will make it easier to retrieve the data to aggregate as it will end up in the same folder on disk.

So everyone working on the car exterior will just need to publish their work to the exterior asset on the wire models task. If we want to access the output preview data, we will need to just to open the latest data published on the VRED scene task of the review asset.

Obviously, in a real world scenario, the project structure may be a lot more complex. And we will need to aggregate data coming from various assets and maybe of different types. This is just a matter of how we configure the event daemon plugin, which will gather the information about the assets to be passed to VRED.

ShotGrid Event Daemon uses, by default, two main components. First, the daemon service, which role is to monitor and process the ShotGrid event table. It filters the event in the event database and executes the ShotGrid plugin when a defined event is called. The ShotGrid plugin on the other side is a Python script that will perform the tasks If the event is-- if the right event type is found you can see here an example of a ShotGrid event.

What we will be tracking is the event type. This type of event happens when a new file is published to ShotGrid. The event contains also information about the file that has been published. We will filter the event database on this particular file type, which means that every time we catch a shotgun publish file change event, we will check if it concerns our project, and if it is an Alias file. Then, we can trigger the automation.

Here is the automation in detail. The event daemon application when started is monitoring the ShotGrid event table. It also starts a separate process, which is waiting to see files to be processed. We will call this the processing application. When a new event is found, the shotgun event plugin will pull the new file information we saw earlier and append a queue of files to be processed.

The so-called processing application will take, sequentially, the files to be processed from the queue and build a VRED script populated with the file information. It will also take a bunch of other parameters we can define in the event daemon application, like the geometry tessellation parameters or the size of renders to be computed. It then starts to spread together with the script, which will handle the preparation tasks.

About the preparation, here are the steps the automation is going through. First, the new file is converted into a VRED file, it will help later in the loading process. In fact, we are using VRED's smart reference feature, which allows us to quickly load and replace component of the scene. For example, each part that has been published to ShotGrid from Alias is converted to a VRED file, and when we need to rebuild the assembly, we only need to pull the latest version of each part, which is much quicker with VRED components.

It also gives us the opportunity to manipulate the reference version. Let's say we wanted to see the last week status of a part. Well, we could build a small UI, which will let us replace the part with another version for example.

Once the new file is converted the scene template is loaded. This template can contain the default environment but also have some standard behavior, like visualization mode, for example, different lighting conditions, or even pre-programmed interactions, like a turntable for example. VRED will then gather all the existing parts and take the last version of each component to merge and load them into the scene.

At this stage, we have assembled all the different components parts or zone of the digital mockup. We can now make it look good. The script is then performing data preparation tasks. It cleans up the scene, getting rid, for example, of remaining curves, or maybe we want to filter some data or small parts, screws, et cetera.

Then, we want to compute lightmaps. To do so we need first to prepare lightmap UVs. So we integrated UV unfolding as part of the script. The last step is to render standard views. When the whole process is done, we have a ready-to-consume, real-time scene, plus some images always rendered from the same viewpoint, which can be used for quick review for example.

The VRED scene help designers and decision makers to make a complete view-- to have a complete view of the status of the project, and it also is a good starting point for visualization artists to start their work and Polish the scene for presentation.

So what can you expect from such an automated process? Well, the first obvious benefits is that you can rely on a consistent and controlled outcome. Having all the models managed in ShotGrid ensures to have a reliable and organized database which can be used with a standardized and automated data preparation process.

Also, being able to rely on a predictable output is allowing you to track the evolution of the work. The output and the associated images will always look the same. It is easy then to compare two outputs at different points in time in the design process or even see the evolution of the model being built.

From a value standpoint, you can save a huge amount of time. It is not necessary anymore to spend time chasing the latest update of the different components that need to be merged for the presentation. And building the assembly is not the most interesting task to do. It is time consuming to import all the files, to check if there has been a change, if this is an update, to reapply the material recompute lightmaps, et cetera.

Think about the time spent only on gathering and aggregating data. It can take a day or more, and it needs to be done on a regular basis for each review. Considering this is done every week, it can represent one third of someone's time over the year that can be saved or spent on more valuable tasks.

So with such a solution, you can save a lot of time reducing effort in data preparation and repetitive tasks. You can also rely on a predictable output, which will always show the latest data, and ultimately, shorten the design cycles, saving time in finding the right data or even detect earlier wrong design directions.

This concludes this presentation. Thank you very much for having watched this video.