Expanding in the Design Studio with ShotGrid

BRANDON TASKER: Welcome, everyone. My name is Brandon Tasker, and I'm a product manager here at Autodesk. Today, we're going to be talking about expanding in the design studio using ShotGrid. Before we get started, I'm not going to be talking about roadmap topics today, but we will touch on some things that aren't necessarily going to be part of the product. So whatever you see in the presentation today, please do not make any purchasing decisions on this presentation.

So expanding in the design studio. Today, we're going to go through the basics of getting you from ShotGrid, out of the box, into production. But it's going to be a little bit different than my previous presentations. We're not going to tell you how to do it, but we're going to show you how we've done it on an internal project and how we built out a new show car with collaboration with Genesis Design to help discover the future that all of you, our customers, are building towards.

At the same time, we're hoping to explore some of the biggest challenges that our customers are facing using and getting started with some of our tools. And so using this latest show car example, we'll show you how you can make sense of this ever-complex and ever-changing design project.

So we're going to help you make sense by showing off our thought process of setting up a real design project using ShotGrid, all the thoughts and decisions and challenges that have gone into the project setup. Then we're going to provide insights by actually showing you what a real design project looks like. And then we're going to share all the different things that we've done to give you guys opportunities and ideas of what is actually possible.

So let's get started by showing you the exciting internal project that we've been working on. So as I briefly mentioned, we partnered with Genesis Design to build a new vehicle for our automotive material. And this, or what I'm talking about today, isn't going to be about flashy marketing. But while some of the outputs have been that, the goal here today is to show you really closely what a design studio project would look like in comparison to yours.

We want to mimic your design process down to every iteration and in the simplest form. And as much as flashy marketing stills are super nice, they aren't always necessary, and they don't always show up throughout the whole design process. So we want to match what you guys do every single day.

So how did we do this project internally? Well, first of all, we took our Agile product development team, we added a couple of industry experts, and we focused on this concept vehicle project. We took a month, entirely dedicated and [? focus ?] of our time, and we helped bring in all of the automotive industry experience and innovation that we've had working with customers for the last four years.

And all of that said, our goal was to build out a ShotGrid site, build out a configuration and a workflow with meeting the needs of that specific project, and really fine-tuning and figuring out what would work in the ideal workflow. And so, why do we do all this? Well, we wanted to feel your challenges and your pain. We wanted to go through step by step and understand every little detail and need of the design project that you would be working on and make sure that we weren't missing anything.

And when we do, we wanted to make sure that we could make it better at every step, so by capturing feedback, concerns, and issues, and addressing them in real time. We wanted to go fast and make changes and try things out. So this project wasn't supposed to just show you what ShotGrid is capable of. It was an opportunity to try new things and experiment with what's possible. Then we can turn around and share it with you like I'm sharing today and gauge some interest.

So next, let's start to show you some of those crazy ideas, which are actually all very sensible, and help start the discussion there. And I want to do this because I think it'll be interesting to share what we've done internally, how we're thinking, how we're working, in hopes that we can connect better with you and share all of this information.

So overall, a bit of an agenda and the workflow that we're going to cover. We're going to talk about projects. We're going to talk about all the components inside a project, a lot of stuff around what we've previously called assets. Then we're going to assign some work.

And then, once work is assigned, we'll move onto creating and publishing automotive design work. Once that's done, we'll talk about reviewing and approving and feeding that data back into the review and creation process. All right, so let's get started.

Project creation. So when you first start with a Shotgun site, first thing you're going to need to do is create a project. And lots of customers ask us, what is a project? So during this internal design project that we did, our goal was really to take the industry learnings that we've had with all of our customers and reassess, and make sure that this works, and then try it. Make sure from the beginning of a design project to the end, the concept of a project still works.

And so to figure this out, we had to talk deeply about what are projects, what types of projects there are, who decides when a project exists, and who decides what it's going to be. How often do these projects happen, who is the market for these projects, and all of these different questions go into building our decisions on what a project actually is.

So for example, if this is a totally new vehicle design, then we know that it's going to need to go through all of the milestones and theme iterations. But it also could be a model change of some [? type, ?] minor or major. And with that, we would just need the latest vehicle production data, and we could start making tweaks moving forward.

So jumping, essentially, to the answer that we have found is that in an automotive design project inside of ShotGrid, the best explanation is really a single product iteration. So if you're building a vehicle for a single year or a single iteration, that is its own standalone project.

And we know not all OEMs are continuing this yearly cadence, but this works really well. And as long as you can follow this iteration cycle, that will work really well for you. And obviously, as I just mentioned, new vehicle projects are going to be part of this as well, or a model change. Either one of these as a single product iteration will work perfectly as a project for you out of the box.

And so in our case, for our internal design project, we did the Aviera 2021. So this means that this Aviera is for that model year. If this vehicle comes in different styles-- an example is a convertible, or a hatchback, or, probably in this case, an extended wheelbase-- we would have these as components of this project.

And so, how do we decide on what a project really was and be confident in that? Well, we know that with ShotGrid, there are something to do with projects and how they're siloed. And there are obviously some drawbacks to siloing them off, but there are also a ton of benefits.

With a siloed project, you have a lot of flexibility. You can make the project what you need to be. And we've also built tools to help you share between projects when you don't. But when a project is flexible like this, you can build it out for your unique needs, for each project's unique needs, and you have the ability to change it without affecting other projects.

And this is what our customers have been doing for a long time, which essentially means they start a project, they make some changes to how the project works in ShotGrid, they improve it, and then they start a new project. When they start the new project, they start based off the last one and where it ended.

And then when they go through, and they make changes to that project, and they start a new one, they start off from where the last project ended off. And so over time, this just builds up to a nice iteration cycle where you're constantly evolving how you work with your ShotGrid site.

So let's create a project. Click on Add Project, pick a name, pick the automotive design template. You can now pick a type and upload a simple thumbnail. And that's it. We're done, we've created a project.

So that was a lot of information around what is a project and why it's important. But I think it's important to share, too, all the thought that we had to do to go into this and to make sure that all of this actually works in the definition of an automotive design project.

But before we totally leave the project topic, once you've first created one, your studio can now start extending metadata for these projects. And it's simply called fields in ShotGrid. The simplest example we would have would be the type of project. I already mentioned you can do that. And here, you could add things like an advanced design, a show vehicle, a minor model change, a major model change. Whatever your terminology is in your studio, you can use as a type.

Five years down the line, maybe you want to look back at all of the show cars that you built. You have a really easy way to filter and find all the show cars you built over time. Another good example would be building for a specific market. As in, maybe in five years, too, you want to go and look at all the vehicle designs you've done for South America. You can very easily filter using the ShotGrid tools, filter by the market that you've defined.

But in our example, we also wanted to track generation. We thought generation is something that's very useful and common. Most of the most popular vehicles on the road come from a generation and have been widely around for a long time. So just by grouping by generation, we can make some sense of all the different design projects that have happened over time.

So that said, you're really free to add as much metadata or as little as you'd like to projects. And it can be super powerful to organize and keep track of all the work your teams are doing. But let's move on now to the project components, the things inside of the project itself.

So as I said, components are a really important part, too, and there's a lot of functionality that can be had here. In the past, if you've heard me speak before, I've talked a lot about assets. And that terminology, I think, is also not entirely clear.

So our goal when we do this internal design was to figure out, how can we better define assets? If you don't know what assets means and you have to ask us, that's not a good thing. So we wanted to find a new set of terminology and a new way of working to make this really easy to understand from day one.

And that's why we've come up with these four new titles that are underneath the asset subheading. So themes, models, zones, and parts. I think these should all be self-explanatory, but as a quick summary, a theme is obviously a design theme, work done by a team that helps different design teams compete against each other, going through the milestones to finally be chosen as the newest vehicle design.

As a design theme evolves through all of the milestones, eventually, one will be chosen. That will then evolve into the model. Models are also the place that we'll be able to describe those different model types, which would be the standard sedan versus the hatchback versus the convertible.

And we can reuse the next thing, which are zones, in any one of these different models. Zones are obviously breakdowns of the model itself. And parts are obviously part breakdowns of those zones. As designers work in more detail, they're going to break down parts in smaller areas to do higher-quality surfacing. And we think using all four of these captures this in a really nice way.

So let's dive a little bit deeper and show you what those will actually look like. So here's our page after the design project was done. So we had four exterior themes and four interior themes. And as I said, a theme represents the design theme that a team is going to work on to try to win the overall concept.

And it's going to move through all of the major milestones. And you can see here, there's a lot of different topics that are in red. That means that they were omitted at a certain milestone, it means they weren't continued on at a certain point.

But the value you get from this is that all the information is still there. All the design work still exists, all the notes that were made still exist. So in the future, if you ever want to come back, or even today, if you want to come and use a component or a part-- let's say the styling of a really nice grill that somebody did-- you can go back and know that that work is in there, find it, and reuse it on your latest project.

So as I mentioned, once a theme makes its way through the design process and becomes-- it will evolve to a model. And a model, in our case, we just called standard. This is going to be the standard vehicle; this is going to be the base model that we're going to build different body types around. And so for this type of vehicle, we chose the extended wheelbase as the best option, the most realistic option for the type of project we're doing.

And you can start working here, but pretty soon, design teams are going to start breaking out in different zones and working on front versus rear. So once you start doing that, you're going to break and work in the zones. And you're going to [? place ?] those zones as references in the model. That means these models will be the high-level view of each major model in this design project. So at any time, if you want to go and see the progress, you want to review or visualize work, the model is the place that you can do it.

Now going into zones, as we mentioned, as you go into more surfacing detail and you start breaking down your model into zones, you can start tracking those in ShotGrid. And you can see here that we have front faces, rear faces, headlights, taillights, side panels, all of the standard simplistic zones that you would want in a vehicle.

At this point, it's probably good to call out that we're not trying to replicate engineering workflows. We just want to categorize different parts of the vehicle in very simple ways. So by no means do you need to list out every single part you're going to build. You just need to break it up for your design team and how they're going to work.

And again, I want to add that when you break out into these zones and people start doing surfacing or visualization work on specific zones, all of this can be linked directly back to the model it came from and can be referenced in there. So you always have a single source of truth of all that information.

And then parts. So parts, again, are fairly explanatory, but zones get broken down into smaller pieces, those become parts. Again, you don't need to track every single part from an engineering standpoint. You just need to track the parts that your team and design studio is going to work on that are separate.

So if somebody is going to work on a bunch of interior parts that need to be split up and work done by individual people, this is a great time to create a part. Break it out of the zone, but link it back into the zone so you always have a grouping at a high level of the zone itself. Maybe that's an interior or a front fascia. You can always see and keep track of the progress at any given time.

OK, so, a lot of work has gone into just figuring out some basic naming conventions that really work. And as I said, we had to take a lot of learnings from our past customer conversations and rollouts with them, and also our own internal work that we did here to find a best-case scenario, and also test it and make sure this works through every step of the pipeline. So this should now give you a really good starting point to set up your design projects and hopefully will be much easier to understand out of the box than our old asset naming that we had.

OK, so once components are created, we're going to move on to actually assigning the work. And so assigning work in ShotGrid was always done and has always been done in tasks, and that's not going to change here. And the basic recommendation, [? that ?] [? was ?] always just start with the departments in your studio as a single task.

So the standard departments we see everywhere, design, modeling, visualization, color materials, clay, Class-A-- Class-A can be in design, sometimes in engineering, whatever works for you-- can be a single task. And those tasks help describe the work that's going to be done on a specific theme, model, zone, or part.

So we more or less left this part the same. But what we did do during this project that I think was really interesting was we added special task templates. And as a quick example of a task template is here we have a theme that we've created, and we just apply a test template, which is essentially just a group of predefined tasks.

And this is what's really cool in what we did during this internal project, which was we figured out that the best way to do this was in additive test templates, which means we built a specific template for every major milestone. As the designs progressed through milestone by milestone, we just progressively added a new template to it. By doing that, we added new tasks that then needed to be done, and we pushed the project along with these new jobs to be done.

The best and simplest example for this is when a project starts, very early on, it's usually mostly 2D work. As that project nears the end, it's going to be into the high-quality surfacing and visualization for quality assurance. So you can see how these tasks would get added over time to change on how the project is reflecting and how it's progressing through all of the milestones.

And so just a quick example. When you apply that template, you can see we get automatic tasks added to that component that now can be assigned. So simply assigning a person in your team to do that work, and you're good to go. You now can or your design team now can start publishing work and design work directly to these tasks.

And here's a bit of a bigger view of that. So in our design projects, internally, we did all of these. We had to go through every single milestone and all the tasks that came with it. So this is just a single theme, and you can see how it transitions from all the gateways into the theme freeze, and into model freeze, and handoff to engineering, eventually, and how, as time goes on, some of these tasks get much larger. There's more work to do, and there's more detailed work that must be completed.

All right, so once the tasks are added and people are assigned to the work, now you can start creating work. And one of the biggest questions that we had once we got started is, how can we make a modeler or a designer's job a little bit easier?

And the question really was, how can we help them set up their scene? How do we get the inputs that they're going to need to them really easily? And then, when they're done doing the work, let's say out of Alias in this example, how can we help them publish it in the simplest way possible?

And I don't have enough time here today to go into every detail that we investigated, but I'll show you some quick and interesting ones. So before that, though, let's remind ourselves that ShotGrid has some basic functionality for opening, saving, and publishing. So we're not going to touch on that today. We're going to go a step beyond.

So beyond the file I/O, beyond the publishing of a basic work file to the ShotGrid site, we're going to talk about how you set your scene up and how we can think about doing this automatically. And to use Alias again as an example, how can we set the scene up? So what are some of the things an Alias user might need when they first start on a project?

Well, they're going to need package data. Where is that package data? What is it? How can they find it? Can we bring that in automatically? Then, also, we're looking at how can we create layers in Alias and do that dynamically based on what part of the process you're working in.

If you are in creative design, do you want to have some basic layers for some shaders or surface types that will allow you to quickly and easily assign some materials to all the surfaces? Or are you in Class-A and like to have layer breakdown by parts or zones in more specific detail to make your life easier?

Then we also had materials. So talking about assigning materials, wouldn't it be nice if your Alias scene loaded with the appropriate materials? You could just quickly drag and drop on the surfaces and start getting to interesting visualizations quicker and faster than before.

So in this case, around package data and setting up layers, we took over this New File hook that we call it within ShotGrid. And what you can do with this is it allows you to add a little bit of custom code to go find things, search for things, and load them into the scene when you click on New File.

So I don't have an example of this actually getting set up. But what the possibilities we can do is, we could click on New File, and this could automatically go and find the linked package data for the project or the project type we're working on. This could dynamically generate all the layers that you would need in your scene for you, and maybe even load in a group of pre-approved materials-- the basic car paints of black, white, blue, red-- and then allow you to start applying them really early on in the process.

One of the more exciting things we've done, too, on the publishing side of when you now want to share this out, publish this, and share it with visualization or other modeling-- people on your modeling team, we've introduced, or tried to introduce, something called publish validations, which essentially just means that before you publish it, we're going to look at your Alias scene.

We're going to confirm and check some things that should be there-- and these things can be defined by your studio-- to make sure that when you hand it off to somebody else, it's cleaned up, it's orderly, it follows some sort of basic conventions.

You can see here at the top, a really great example is just deleting null nodes, cleaning things up so they're not making their way down to other departments. We're also looking at zero transform [? moves ?] on all of your surfaces, a nice, easy check that can be done by the system automatically, enforces zero transforms on all the surfaces. You don't have to worry about it. Every time you hand off data, this gets done.

So by doing this, we're looking at ways to simplify the life of the Alias user. They can get a validated publish every time. They don't need to think about all these little details as much as they maybe used to. Other departments as well, like visualization or engineering, now have a standardized file type that they can expect.

They know what's going to be in it, it's going to follow some basic conventions, it's not going to have a bunch of messy things. Design managers can also be happy, too. The data is flowing in an organized way. So there aren't any hiccups, there's not a lot of emails going back and forth, and there's some consistency, which will leave time for creativity.

So now that we published work, we're going to have a site full of different design work within ShotGrid. And now we can go in and review it. So reviewing stuff in ShotGrid, there are so many options. There's so many ways to do this and feed back that work to [? the ?] creatives. One of the biggest questions we asked ourselves was, what is the best way? What is the clearest way we can define for all of our customers to use out of the box?

And the ShotGrid way has always been to use playlists. And we're going to recommend that as well, too. Playlists allow you to group all the different versions together that you want to review. They can be curated, they can be managed, they can even be locked so that once you lock them, no one else can add versions to them. They can't be changed, and they maintain consistency forever into the future.

Playlists can be taken into any review and can be a list of different components or different ideas. Whatever you want it to be, whatever the review is for, you can capture it within a playlist. It's also the ideal place to capture all these review notes. So if you do a playlist and you review that, all the notes that are made are always linked to the playlist, meaning that you can go back in history, see which decisions were made at which milestone, and make sure that there's some visibility and transparency on what's happened.

And something I don't have time to go into real detail today, but milestones and playlists. When you work through those major milestones, it's really important to capture what was reviewed at that time. This is something we've heard from all of our customers.

And so a really easy way is just creating a link between those milestones and the playlist. So at any time, you want to go back in and check what was reviewed at the gateway 1 milestone, the theme freeze, you can go and do that. You can see what designs were reviewed, you can see all the comments and notes made, and you know why that decision was taken.

And we've also been able to extend playlists out to other workflows, like our review with VRED functionality that has been released now for a little bit. This allows you to take any version that's within ShotGrid, right-click on it, and say, Review With VRED. That now shows up inside of a VRED presenter view. This allows you to use the powerful visualization technology in VRED to review things on demand whenever you want.

So people that are not experienced using VRED can access this quickly. They can add notes, and these notes are shared between the desktop or the browser. So wherever you make the notes, they're always captured within the ShotGrid system.

And beyond that, too, we also extended this to work for playlists. So if you have a list of different design ideas, and you want to review all those together, you can select all these different versions within ShotGrid, you can add them to a playlist, and you can open them or review them with VRED.

So by doing this, you now have access right from your VRED desktop application to go through all the different versions that are stored in ShotGrid. You can review them, you can see what's in them, you can add notes to them, and again, you have the history that this playlist has been created, what was reviewed, and what notes were made.

All right, so moving on. Now that we have all of this reviewed, you have all this great content and versions inside of ShotGrid. You've done a full cycle and process through that workflow that I shared. So to summarize, [? review ?] [? and ?] [? playlists-- ?] they are the best practice, or the best and easiest way to stay organized. And you can use these in multiple forms to automatically capture notes from review sessions and make sure you have a history of everything that's been reviewed.

So that about summarizes my share out of setting up and getting your studio into production using ShotGrid and using our latest internal design project as an example for this. So let's just quickly go over all the different things that we talked about. So projects, we explained why projects are so important and how a project is really a single vehicle iteration.

We talked about how assets have now been broken down into themes, models, zones, and parts to make more logical sense out of the box. We then talked about the standard task workflow and all the basic tasks that you would use as departments, but also, how you can use task templates based on the milestones you're going to go through to additively build out the complexity as your design project goes through each milestone.

We then talked about how you can create and publish work and some of the investigations that we've done around importing and exporting data out of our desktop applications. And once you do that, and you have all this version [? reviewable ?] material inside of ShotGrid, you can review and approve that using a bunch of standardized playlist tools and review functionality that we offer out of the box.

So to summarize all of that up, and to see a little bit of our Genesis design project go through that lifecycle, I hope this was interesting. I hope this was interesting to learn a little bit how we think inside of Autodesk, how we've built our own projects. And I want to share that this is really just scratching the surface of all the work that we did in that one-month internal project.

So if this was interesting, please reach out. I want to hear from you. I want to hear if you'd like to learn more about what we've done, some other things that we've tried, and how this could potentially make its way into the product or into your studio one day in the future. So with that said, I'd like to thank you all so much for joining me today. Have a wonderful day, and take care.