AU Class
AU Class
class - AU

Cultural Tapestry and Design of "Unsung Empires: The Cholas"

이 강의 공유하기

설명

Join us for an insightful session on how Ayelet Studio, with just three artists and an 18-member team, created the narrative-driven game Unsung Empires: The Cholas using Maya software as a pivotal tool. Discover how we harnessed Maya software's powerful features for prototyping, modeling, and animation to streamline workflows and bring the game to life. Learn how the immersive experience—enriched by captivating storytelling, unique artistic styles, memorable characters, engaging dialogues, and evocative music—resonated deeply within the gaming community, fostering a sense of pride among players. Explore the secrets behind the success of Unsung Empires: The Cholas and gain valuable insights into using Maya for game development.

주요 학습

  • Learn about using Maya software's robust features to create intricate 3D models and animate characters and environments.
  • Explore the principles of captivating storytelling, unique artistic styles, and engaging character development.
  • Learn about Maya software's role in game success.

발표자

  • Abraham Kirubakaran Jebaraj
    With a passion for Indian history and a vision for innovation, Abraham spearheads the artistic direction and strategic initiatives of the Ayelet Studio, pushing the boundaries of storytelling and creativity. Under Abraham's leadership, Unsung Empires continues to captivate audiences with its compelling narratives and rich visual landscapes.
Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected
      Transcript

      ABRAHAM K: Hello, everyone. So welcome to today's AU session on cultural tapestry and design of Unsung Empires-- The Cholas. This is actually a case study. And before we go dive deep in, so I want to start with a question or more around, like, what is the ideal criteria to build a IAAA game.

      And before that, what is a IAAA game? Pretty much, we know that triple-A games are more around budget driven. You get a high-quality games, or open world, or with a lot of gameplay stories and stuffs. And IAAA is nothing but it's actually a indie studio who wants to build a triple-A quality game with limited budgets.

      But there are a lot of titles that have come, and it performed really well as well. Pretty much, one thing which I would say is like, every single game has this pattern. So they always have a industry veteran there or x big studio with over 15 plus years of experience, and they always have a minimum team size of a hundred. And they scale-- it goes up to 1,500 or 2,000 as well. And with a funding size of $5 million plus, and the entire timeline to release a IAAA game is actually a minimum of three years of a complete production.

      This is actually the ideal scenario to build a IAAA game. But in our scenario, so what we had was pretty much like-- we did not have any of game building experience as well. And our team size was around three member team. And funding wise, we are bootstrapped. And we had a really tight deadline to release the game within like four months. We just want to get the technical demo out. And when I told all these scenarios, pretty much we know what was the expected output.

      I think the result-- what we would expect is something-- kind of something like this. So this is actually one of our previous shot from the game. So you have a character, you have the environment with, not like a proper game, right? It's more like a tutorial. But what we are able to deliver is the visuals something like this. When I told about the session is going to be about Unsung Empires-- The Cholas, this is actually an ancient dynasty from the 11th century. And pretty much, you have all these kind of visuals, the entire color palette, entire story set in the South India with all these big temples and the entirely different people. And you have entire different flora and fauna as well.

      And these are some of the in-game screenshots. And in the session, I'm going to walk you all through. So what are the things we did? And what are the challenges we faced? And how we are able to get these results? I think this is going to be our outcome for the class today. And I'll just walk you all through, like, our entire journey. And pretty much, we go deep into the entire-- the session.

      I just want to talk about me as well. So pretty much, I have over 10 plus years. I was working as a enterprise architect. We-- and I-- I'm a huge gamer as well. I pretty much love all the action adventure RPG and all the story-based games. And this is my third company. So I founded the ILS Studio around 2.5 years before. And I love reading history books, all the stories, and all the references, and all the historical things that happened.

      And one other thing which would definitely tell is, like, I'm a huge fan of our heritage. Like when we talk about India, we have a lot of culture that originates from, say, like 1,000 plus, 2,000 plus years. And we have a lot of those references. So pretty much, that's where all these things started with Unsung Empires-- The Cholas as well. So the Cholas are like the 11th century dynasty from the south India. And these kings are some of the-- some of them are-- we still call them as a pride of Tamil Nadu, or pride of India, because they did a lot of those things in the history.

      And what we are going to see today is pretty much a straightforward. So I want to start with, what are the things we are building? Like, I'll show you a quick snippet on or the show reel of what's cooking in our studio. And I want to talk about the three perspectives, pretty much like how our entire assets development or everything drives around that. And I want to walk you all through the framework, which worked for us, the development methodology.

      And I want to talk about the final challenge around the authenticity versus the game readiness. So this is going to be our workflow. And I think let's get started with, what are we building? So before we even go into the showreel, so I want to give a bit of overview about the location or the visual which you are going to see. So this entire setup is set in 11th century. And the song which you would be hearing is actually composed for the game. And we call it as called these things as experiences.

      And what you are seeing is actually the king, the Rajendra Chola. So he actually won the war, and he's coming back to his kingdom, and people are celebrating. That's the scenario. And so get ready to hear a pretty good, or pretty-- dance vibe kind of video. And here you go.

      [VIDEO PLAYBACK]

      [MUSIC PLAYING]

      [NON-ENGLISH SINGING]

      [END PLAYBACK]

      ABRAHAM K: So pretty much, we saw the video, right? So that was the one-- that was the output, which we are working on. And even with these-- the small experience in game, we actually had more than around a thousand plus assets that was developed just for that particular experience. So before I go into the process, so one thing which I want to talk about is so there may be a lot of the solo devs or a lot of indie game developers, or the studio heads would be attending the session.

      So I just want to talk about, what are the stakes, which we face whenever we are working on a title or more around a IAAA title as well? Obviously, the first stake is going to be the financial stability. Like, there are a lot of things that comes-- everything drives around how much fund you have, what is the scale you can just go and to sustain the operations and development of the game? I think that is going to be the crucial thing.

      And second part is building the credibility, right? So you started a studio and you're working on your IAAA title, but there are certain ways we can build our credibility. Like, one thing is like you release a game, and get the traction, or you have industry veteran who come from a pretty popular studios. And the third one would be, of course, the team because they are going to be the crucial one for driving the entire development. When we say, like, we call it as a team, I think we pretty much learned these things in a hard way of hiring a wrong people as well.

      So pretty much nowadays, what we do is we prioritize people's culture more than the skill. And when you have close bunch of these people who are aligned and are passionate, I think the magics happen with all these development assets, and pretty much all the visuals are done by two 3D artists who did all these creation. So I think the dynamics matters whenever you are having a small studio and you are developing a IAAA game.

      And definitely, the last one is going to be the visibility, or the relationships, which you have with all the platforms for the visibility part and the distribution part as well, because you don't have a triple-A brand, but you need a proper game build or a proper, I would say, a vertical slice to pitch to the publishers, or the distributors for the game. I think that'll be another thing. And one other-- one-- another way to do that is going to all the events. I think that is crucial. Pretty much, you go to all the worldwide popular events, or the consumer events, just for the gaming part.

      And I want to start with a pitfall, which we faced. And we call this as a process pitfall. This is a pretty interesting one. So there are three different things why the process comes in, and that blocks the development. I think the first one we call it as the process for process sake. Right? So when you're following the procedures, I think the following procedure becomes more important than creating a game. So whenever we want to implement certain things in our studio, OK, we'll start with how efficient we can set up the process.

      And we spend time on setting up the process. These are the team which will be doing this. These are the teams that we'll be sending the file here and doing all the changes there. And what that happened was the outcome was around, say, you build a game, but you are more around spending a lot of time on creating processes. And the second one was the irony of good intentions.

      So the whole point of creating a process is to be efficient, right? But what happened at the later part was when the team was scaling, it actually became a roadblock for us as well. There are a lot of bottlenecks, like there will be a-- say we want to go to the Tokyo Game Show, we need a game build for the TGS. But the challenge was we had a process that required a lot of different approvals to get the game build out. That kind of created a lot of bottlenecks in shipping the game and doing the demos.

      And the last one I would call is we wanted to call overformalization. Technically, so this won't happen, but say if your team size is more than like 20 plus, you always have a hierarchy, you have a multi-level approvals, and even a, say, for example, is one of the classic example, which would tell us a small team spending more time on documentation with all the different approvals than actually the game development. People don't even spend time to put these assets into the game and test it, or play it.

      Instead, they do the documentation and they do send for approvals. And say, the turnaround time takes weeks for getting a single asset approved with all the color changes, with all the 200 feedbacks. But at the end of the day, you are still on the same place without any progress in the game development side.

      So one thing which we decided is we should not-- we should not do this. And we need to make sure the process has to be efficient. So what we did was we actually prioritized quality and efficiency over the process. So what we do was-- so we spend more time on getting the quality right. And we actually target efficiency as the second one. And instead of creating a lot of processes for each and every pipeline, or creating the assets, or building, or shipping, or testing for those kind of things.

      So inside the quality, one thing which we want to make sure is when you are building a game, which is around the Indian era, pretty much like the older one, we wanted to give the player an unique experiences because that is going to be the key so that you have a unique gameplays. That sets the game apart. And definitely, we want to make sure we have a really good game mechanics because the graphics doesn't speak for itself. You need a interesting mechanics for the player to play the game.

      And the next one is the sound and the art part. I think one thing I always say to the team is, like, the-- a good music contributes to 50% of the immersiveness you provide to the players. You need a proper authentic sound, and which makes the gameplay engaging and interesting.

      On the efficiency side, it's pretty straightforward. So there are three things which we always try to factor out. One is the time management, so how optimized we can keep the schedule to get the most preferred outcome. And the second one is the budget, so how efficiently we can allocate budgets, say whether the budget is going to our team, or the program, or marketing, or we try to identify the best-case scenarios for getting the maximum impact.

      And finally, this is the interesting part. So we wanted to-- we always go with the industry standard. And we try to leverage the best in the industry and which works for us to streamline development. I think this is the part where we actually went with Maya as our primary-- we would call it as an aggregator. Pretty much, it is a core of our asset development that all the concepts and all the things that are created comes to Maya.

      And from there, it goes to Unreal Engine, or the game engine, or it's for marketing, or a high-fidelity cinematic. The Maya acts as a middleware between all these different teams. So and I definitely want to walk you all through the stack which we use. So our game engine is Unreal. So we do our entire development in Unreal Engine. And Autodesk, pretty much we use all the set of tools. And today, we are going to talk about Maya. So how are we using our asset pipeline?

      And for the audio and the motion capture wise is for the [INAUDIBLE] middleware. And we use-- we create trees using SpeedTree. And definitely, all the build happens in cloud for our quality team. And finally, we use repository as the Plastic SCM. So the three prospective-- so for every cultural aspect of development, there are three different things which we try to evaluate. So one is the asset authenticity, and the second is the asset creation framework, like how we are creating it. And the third one is going to be how we are going to use it, asset interoperability.

      So we'll start with asset authenticity. So why creating an authentic asset is important? I think we need to ask that question even before diving deep into creating the assets, because creating the asset, the process is pretty same. But creating it, making sure the asset is authentic, and it's accurate, is going to bring all the difference.

      So you can't create a 20th-century house for a 11th-century setting in the Chola dynasty. So we need to make sure we do these things right. So there are a few things which we do that really work for us. So we want to make sure we set the vision and the style right. And these authenticity doesn't matter only for creating the 3D models, pretty much everything. The art, the music side, the sound effects, the writing, all these things are factors the authenticity.

      Say, if I'm writing a chapter where both the players are talking to each other, you need like certain props or the set pieces that should be authentic or accurate to that era so that we create a cohesive game world. And that enhances the immersion as well. And definitely, one another thing that contributes to creating these authentic assets are definitely the passion and the vision as well.

      So you're developing a game, you have the end goal of what or how you want the players to conceive. So I think that is crucial whenever you are creating a game of these things, or a historic one, or a IAAA-category kind of games because there are a lot of different hats you need to wear to get the output right. And the process is pretty simple. We start with the research. You just set the game theme, or set the setting.

      And one thing that really worked for us is reading all the books, all the literature, all the pretty much like-- Tamil has 2,000 plus years of history with the literature that talks about how was that era? How was people who were-- what people were doing there? And what was the visual and those kind of things? And even certain movies we watched to get some references as well.

      So I think the research part is going to be the challenging part where you need to identify your source for creating all these assets. And then we went to all the places that are still present that are, like, 1,500 plus years old. And we actually took the pigs and we actually felt the presence there. Whenever you want to create a immersive game, I think you need to experience that particular place in person, or that equivalent of it.

      And even one thing which I would say is, like, the color palette, which actually is completely unique. Even between south India and north India, we have completely different color palette. Here, it's actually the lush green with all the paddy fields, with all the water stagnating there. And I think these kind of things are crucial whenever you're creating these things. So I think going to that particular place, getting these references are going to be the mos important one. And then, it's pretty straightforward. We go with concept and prototype, and we create concept for these--

      We try to do all the different variation. And finally, we create a style guide. Or we call it more like a-- even we have a color guide for our game. Like, if you are using a brown, it should be this color. If you're using a lavender color for your clothes, you need to use it for a certain set of people because in that era, these colors are called as the rich-people color. People with pretty much the high-tier houses, they buy those clothes.

      So these kind of setting are done even before the pre-production to make sure we are on a right track. And these are some of the examples. Like, the left one, or the real-world reference, this is called the Big Temple. This is from south Tamil Nadu. And the right side is from in-game screenshots where we recreated the exact same temple there.

      And this is just a quick modeling of how we did in Maya, because these have-- these texture has pretty much a lot of complicated pieces. And the challenge was to make sure these assets are game-ready as well. So that's where the challenges came in. But we were able to factor it. We created these modular one and we actually implemented in-- implemented these in our game. And these are some more screenshots. And all these are in-game captures. The character, the costumes, the dresses, which I was talking about, all these things are defined at the first step.

      And now, we come to the asset creation framework. So asset creation framework is more like, what is our methodology in creating these assets. So we know we can watch movies or we read books, we get all the references. But whenever you are creating a world, the challenge here is there are a lot of assets that comes in. Even the showreel which I showed has more than a thousand plus or 1,500 plus assets that are done just for that. With all these parts, the people cheering, and the costumes, and everything there are even more than 2,000 plus instances were created.

      So when you're doing these things at-- as a experience of this scale, there are a lot of challenges that comes in. Like, you are building a game that needs to run on, say, like PC, PS5, Xbox. So you need to make sure you don't cross the device ability to run these things at the best quality. So that's where we created our own framework called DICE, and we call it as Dynamic and Integrated Compositing Engine.

      So what it does is it's actually a material layer system. So pretty much, what I can say is we created a repository of assets, or the shaders, or say like, the game can have gold wood. The gold can be of multiple variations. It's a new gold, or a old one, or we have the box, even the small, small things like the soil, or those meshes. So what we do is we create a shader repository and we reuse those things at different places of the game so that even if you have a thousand instances, you're just going to use, like, three materials, or three shaders for those assets.

      So one of the classic example which I can give is, like, the houses. So when you are building a world of-- our current scale is 4 kilometer across 4 kilometer. So when you want to fill the world with all these houses, you need a proper optimization method. That's where DICE comes in. And pretty much all the low-tier or the mid-tier houses have around eight to 10 materials, or shaders, that doesn't cost any performance for us. So that's a huge thing.

      And we create all these things with Maya and the shader configuration, how the look and feel should be. Everything is created in Maya, and we brought it to Unreal Engine. And so using DICE, it leveraged us in a lot of different ways. So one thing is we're able to iterate it faster because you have the shader repository there. So you just need to model it.

      You put the shader, you try to add different layers, and you add more details to it. And this reduced texturing completely. So because you have the repository where you reuse things, so it's easily-- it optimized our entire development time of creating assets. And one another best part is, like, say if you have multiple metals, say, you want to try aluminum, or you want to try a steel, or you want to try a gold or something, so we were able to swap it real time and see how it looks.

      So let's say, one-- another example from the game is, like, the enemy and the player has the sword. For the enemy character, so we just give a steel one, a wear of 1. For the player, we use the aluminum one, which is altogether, a shiny one, and the new steel, or aluminum. So we just swap the shaders there. But the mesh is still the same. And we're able to do it in game in Unreal Engine, which was the assets were created from Maya.

      And one other thing is we're able to create the shaders. And the best part was we're able to navigate it through all the basic ones, and we can reuse it for the next title, or it is being shared across our studio for all the different works as well. This is not just for the game engine. We even use it for marketing materials if we need to shoot a cinematic or something. So we try to get the shader repository. We use that for creating the assets.

      And the key features are three different things. One is going to be the layering. I think layer contributes a huge thing that differentiates from a gold mesh A to gold mesh B. So we add different blending and mixing options for all those textures. And there are multiple properties, which we created those as well. And definitely, one other feature is the performance. That's where the entire DICE started. So we-- the entire texture memory got reduced from 6 GB to pretty much 1.2 GB for us. And that kind of increased our entire spectrum of devices.

      So initially, we were planning around, like, we need to-- the minimum support was around 20 series systems. But we were able to get the game running on 1650 as well at the same quality. I think that's a huge thing for us. There's a huge market space who still uses 1650, and we can target those.

      And the last one is the reusability. I think whenever we write these kind of things, one thing which we always say is, make it modular. Make sure all your assets are reusable and we're able to reuse-- we now not just create meshes that are reusable or modular. We even duplicate the textures or the shaders that are reused as well with all the different variations.

      And these are some of the numbers, which we are able to get from the impact of DICE on world building. So currently, we have more than 10,000 plus assets. And we are still expanding our library. And so with all the high-definition textures, we brought the entire texture count to less than 3,000. So typical usage here was if you have 10,000 assets, the texture count would be around 30,000. But we're able to bring it to 3K.

      And on the Unreal Engine, or the game engine side, there are two things which we saw difference was the draw calls. The entire draw calls became-- we got it reduced to less than 70% of what we had earlier. That was a huge performance boost for us. We were able to use the draw call budget on other things, like for the mechanics, for the combat, or for adding the effects. So for those things, we were able to use it as the DICE optimized our entire asset workflow.

      And we also saw the FPS increase of more than 30% So it's pretty much directly proportional. So you're optimizing your draw calls for the game, you're getting a better FPS. So we even found out pretty much earlier, like we getting around like 80 or something. Then we got more than 110 plus FPS for the game. That to the same location with all the same assets.

      And I just want to walk through you all our asset creation pipeline as well. So pretty much all these things starts from the brainstorming, right? So I was talking about the first step, how we go to places, or how we take references, how we are-- create our concepts. And we primarily try to moodboard everything. And pretty much, this is the time-consuming part for us because after the modeling and the integration is pretty straightforward, we figure it out at Maya and Unreal Engine. And it's pretty straightforward.

      So once the concepts are done with all the different variations, we try to do two different set of modeling. One-- we start with high-poly modeling, then we make it a low-poly one just for the game readiness. And it depends on the assets too. So one thing which we always try to follow is, like, how many pixels would that asset be inside the game? Say you have a 1080p display and the asset is a cup or a grass. It's going to be very minor. You don't want a 4K texture for that particular grass.

      So those kind of things are decided there, and where we optimize it. And definitely, we also have a high-poly version just for the cinematics or for the marketing assets we try to create there. And then the mesh goes for UE mapping and texturing. And the texturing part here, what the team decides is, say whether we want to use the DICE shaders or whether we want to just go with the traditional method. So I think there are two ways we try to approach here.

      So if you have-- if you are creating an asset where the total number of instances is going to be more than 10, we go with DICE. We try to take a existing shader from our repo and we try to use that. And finally, we just decide whether-- if that particular asset needs any rigging or animation. Say pretty much, if you are creating a windmill or something, it needs to be animated, it needs to have a bones.

      So we rig those meshes inside Maya, and we try to get the output from there. And once that's done, so all these things happen within our 3D repositories. The-- our 3D artists have their own Plastic SCM repository where they have all these things checked in, and they have multiple versions there. And they have all the shaders. And the final output is-- so we have two different set of integration.

      The normal one is going to be the FBX. We create the FBX, we move it to Unreal Engine, and we integrate it within our game. And we also have more like a live link kind of thing. So we use the Unreal plugin for Maya. So we pulled the assets from Maya to Unreal Engine as well. And finally, these assets are stored inside a altogether a different Plastic SCM repository where we store our source code and the entire game source code, and for the mechanics, for the environment, and everything.

      And all these steps are documented. And all the iteration happens in confluence. So we use Jira internally and we try to document all these things. And even we have our repository management integrated with Jira as well so that whenever a developer uses it, they try to tag that particular task so that we can backtrack it and identify for which task the commit was made and the branches was created for the features branch.

      And one-- another challenge, which we faced whenever-- when we were doing these are how to plan the resources. You don't have-- whenever you're running an indie studio and creating an IAAA game, we don't have a lot of people to throw in to develop things. So initial days, like we try to do, we gave the big picture to the team, and we were trying out three weeks or five weeks sprint. But the challenge was people are not able to get the exact expected outcome for the game because people are getting distracted thinking about the big picture of creating the world and everything with all the different things.

      So what worked for us was we switched it to the weekly outcome-based development. The best part was it's pretty much five days. So we have two days for testing, two days for development, and the scope is limited as well. We tried to make sure it's doable, and people take a task, wrap it, integrate it, and we do this every single week. And another thing that really worked out for us is the game day. So we do game day, say, like every three weeks or so. So pretty much everyone bring their new tech, or the things that they learned, and we do more like a Hackathon.

      And we try to test it out as well. And if it really works out, we try to use these assets within in game, or we try to identify those processes, and we try to implement those things. I think the DICE was created from the game day because we had-- we found out that there can be a shader repository that can be created. And we can use Maya and Unreal to integrate it. So pretty much trying out new things really helped out for us with all the new things that's coming out in Maya, or coming out in Unreal Engine.

      People try to stay updated to the latest technology. And there are two things that-- there are some drawbacks on DICE as well as the challenges which we faced was creating variations. So you're creating a game assets. It can't be like a similar pattern-based textures repeating throughout the world. Player needs variation. So there are two different ways we handled it. One, we used local decals for managing the variations.

      So the wall will have cracks like the imperfections. And the second one was adding multiple base shaders. So if you're creating a new shader, so what we do is we try to parent these-- the sub shaders with the existing ones so that we reuse all the assets without creating a new one. But it's completely altogether a different one. So here, you can see we created a modular asset on the left that was created using DICE.

      And the middle one is actually a unique UE one, but textured using DICE. And the last one is the concept art. This is one such housing, which we have it in our game. And we use the unique texture using DICE, the middle part. And we try to match the concepts as much as possible. But pretty much even if you have a thousand houses, you still are going to get three shaders just for this, just for the roof, or the walls, or the doors.

      So all the other things that are added here are the different layers that was created using DICE. And this is a pretty interesting topic as well. So whenever you say you want to create a authentic asset, and that's where you have bottlenecks around how we can make it game ready, because whether the asset has to be authentic or whether it has to be game ready, I think that's where we try to take around like-- one question, which we ask is whenever we come into these kind of-- these kind of comparison is, what is the impact for the players?

      I think that is going to be a question which we ask every single time. Say if you are authentic and if it is going to be giving a completely good or really a huge experience for the players, I think we go with that. And another thing is we want to make sure we preserve the significant elements around the culture as well. But it has to be game ready too, right? So you can't just put a one million triangle count temple into the game just because you want to make sure it's authentic as possible.

      Even the temple you saw earlier, the first thing was initially, we wanted to do a photogrammetry and bring the real temple into the game. Then we found out that's not going to be-- that is one of the way to do it. But that won't be an optimized way. We want to create a modular one so that we can reuse it for all the temple elements inside the game. And it's optimized one as well. So I think the drawback on that perspective is we lose details, but we can run these things on a spectrum of devices because when we say it's going to be a game, this is not just going to be the temple, right?

      So you have the sound, the audio, the mechanics, the animations. We have budgets for all these different things that comes into playing the game. And at the end of the day, it's always going to be the FPS. How many FPS you are getting in that particular set of system, or in that particular resolution? So there are a few things which we use Maya there. We leverage these features for optimization, or for creating a game-ready assets.

      So one thing is the decimation, which is a huge impact on us-- which had a huge impact on our game. And we used Quad Draw as well. And this creates a efficient topology for our models. And for the textures, we leveraged Maya's UE toolkit, UE layout, and texture baking for optimizing the textures. And when creating the shaders, we try to import those and reuse those efficiently too.

      And in addition to it, we create LODs, the normal map, and we also create proxy objects to make sure we render these things efficiently. And finally, whenever you are working with the limited resources, we leverage instancing and we also use Alembic cache for optimizing the duplicates.

      On the Unreal side, it's pretty straightforward. So the outcome is entirely driven on frames per second, FPS. So we made sure we track these at a regular interval. Say we have a set of reports where QA needs to provide capturing all the 15 different metrics. And if we find out any different huge variation when adding these things into the world, we actually come back to the code change and we identify what was the exact problem of doing those things.

      And similarly, we try to optimize the shader types, we try to recreate all the maps that are created for the landscape material. And for the complex geometry, like a temple or the palace, we try to leverage Nanite. Nanite has really good impact on the complex geometry. So for all the simple meshes, we use LODs.

      And for the long shot, or you want to do a distance mesh, or show the distance world, so we try to segregate all the HLOD elements so that the houses will be visible even when you are more than the loading range of the player so that it's optimized. But it does not need to have a lot of details as well.

      And the final part is how we move all the things which we create in Maya to Unreal Engine. That's going to be the key thing. So we use Unreal Engine Connector for asset transfers. So the shader reassigning is the only thing which we do in Unreal Engine is since we have all the shader repository created there, we actually import those things from Maya and we just reassign those. And the repository management really helped out for us. In addition to what we have is we have our own scripts created for cloud build and deployment using Jenkins.

      So we integrated those 3D asset repository with our game source code repository. So every time there is a the 3D pipeline is running our asset creation pipeline is running in the cloud, we try to generate all these meshes and put it in the game source code as well so that you have all the effects that comes from the Maya is being moved to the game source code too.

      And finally, we leverage Maya's Python and Unreal's API as well to talk between both the tools so that the people who are creating the 3D assets can integrate it within Unreal Engine as well so that it doesn't go all around with all the different set of people to do the texturing or creating the assets, importing to Unreal, and placing it in the level. Our artists create those and use those in game as well.

      And this summarizes pretty much the entire steps of how we create our asset, and how we create our-- create these things authentic as possible, and how we're able to build it. And these process, or I would call as setting these things in a pipeline, worked out really good for us with Maya being the central core handler with all the different departments. We're able to create more than like 2,000 plus assets with two people in four months.

      And we have-- we still have around, like, six to eight months of active development as well. But we're able to ship this and get the expected quality as well. So this is going to be the crucial for creating the asset authentic and game ready with the proper framework. You should be able to achieve it too. And thank you so much for attending the class. And yeah, thank you.

      ______
      icon-svg-close-thick

      쿠기 기본 설정

      오토데스크는 고객의 개인 정보와 최상의 경험을 중요시합니다. 오토데스크는 정보를 사용자화하고 응용프로그램을 만들기 위해 고객의 본 사이트 사용에 관한 데이터를 수집합니다.

      오토데스크에서 고객의 데이터를 수집하고 사용하도록 허용하시겠습니까?

      오토데스크에서 사용하는타사 서비스개인정보 처리방침 정책을 자세히 알아보십시오.

      반드시 필요 - 사이트가 제대로 작동하고 사용자에게 서비스를 원활하게 제공하기 위해 필수적임

      이 쿠키는 오토데스크에서 사용자 기본 설정 또는 로그인 정보를 저장하거나, 사용자 요청에 응답하거나, 장바구니의 품목을 처리하기 위해 필요합니다.

      사용자 경험 향상 – 사용자와 관련된 항목을 표시할 수 있게 해 줌

      이 쿠키는 오토데스크가 보다 향상된 기능을 제공하고 사용자에게 맞는 정보를 제공할 수 있게 해 줍니다. 사용자에게 맞는 정보 및 환경을 제공하기 위해 오토데스크 또는 서비스를 제공하는 협력업체에서 이 쿠키를 설정할 수 있습니다. 이 쿠키를 허용하지 않을 경우 이러한 서비스 중 일부 또는 전체를 이용하지 못하게 될 수 있습니다.

      광고 수신 설정 – 사용자에게 타겟팅된 광고를 제공할 수 있게 해 줌

      이 쿠키는 사용자와 관련성이 높은 광고를 표시하고 그 효과를 추적하기 위해 사용자 활동 및 관심 사항에 대한 데이터를 수집합니다. 이렇게 데이터를 수집함으로써 사용자의 관심 사항에 더 적합한 광고를 표시할 수 있습니다. 이 쿠키를 허용하지 않을 경우 관심 분야에 해당되지 않는 광고가 표시될 수 있습니다.

      icon-svg-close-thick

      타사 서비스

      각 범주에서 오토데스크가 사용하는 타사 서비스와 온라인에서 고객으로부터 수집하는 데이터를 사용하는 방식에 대해 자세히 알아보십시오.

      icon-svg-hide-thick

      icon-svg-show-thick

      반드시 필요 - 사이트가 제대로 작동하고 사용자에게 서비스를 원활하게 제공하기 위해 필수적임

      Qualtrics
      오토데스크는 고객에게 더욱 시의적절하며 관련 있는 이메일 컨텐츠를 제공하기 위해 Qualtrics를 이용합니다. 이를 위해, 고객의 온라인 행동 및 오토데스크에서 전송하는 이메일과의 상호 작용에 관한 데이터를 수집합니다. 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 이메일 확인율, 클릭한 링크 등이 포함될 수 있습니다. 오토데스크는 이 데이터를 다른 소스에서 수집된 데이터와 결합하여 고객의 판매 또는 고객 서비스 경험을 개선하며, 고급 분석 처리에 기초하여 보다 관련 있는 컨텐츠를 제공합니다. Qualtrics 개인정보취급방침
      Akamai mPulse
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Akamai mPulse를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Akamai mPulse 개인정보취급방침
      Digital River
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Digital River를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Digital River 개인정보취급방침
      Dynatrace
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Dynatrace를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Dynatrace 개인정보취급방침
      Khoros
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Khoros를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Khoros 개인정보취급방침
      Launch Darkly
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Launch Darkly를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Launch Darkly 개인정보취급방침
      New Relic
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 New Relic를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. New Relic 개인정보취급방침
      Salesforce Live Agent
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Salesforce Live Agent를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Salesforce Live Agent 개인정보취급방침
      Wistia
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Wistia를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Wistia 개인정보취급방침
      Tealium
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Tealium를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Upsellit
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Upsellit를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. CJ Affiliates
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 CJ Affiliates를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Commission Factory
      Typepad Stats
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Typepad Stats를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Typepad Stats 개인정보취급방침
      Geo Targetly
      Autodesk는 Geo Targetly를 사용하여 웹 사이트 방문자를 가장 적합한 웹 페이지로 안내하거나 위치를 기반으로 맞춤형 콘텐츠를 제공합니다. Geo Targetly는 웹 사이트 방문자의 IP 주소를 사용하여 방문자 장치의 대략적인 위치를 파악합니다. 이렇게 하면 방문자가 (대부분의 경우) 현지 언어로 된 콘텐츠를 볼 수 있습니다.Geo Targetly 개인정보취급방침
      SpeedCurve
      Autodesk에서는 SpeedCurve를 사용하여 웹 페이지 로드 시간과 이미지, 스크립트, 텍스트 등의 후속 요소 응답성을 측정하여 웹 사이트 환경의 성능을 모니터링하고 측정합니다. SpeedCurve 개인정보취급방침
      Qualified
      Qualified is the Autodesk Live Chat agent platform. This platform provides services to allow our customers to communicate in real-time with Autodesk support. We may collect unique ID for specific browser sessions during a chat. Qualified Privacy Policy

      icon-svg-hide-thick

      icon-svg-show-thick

      사용자 경험 향상 – 사용자와 관련된 항목을 표시할 수 있게 해 줌

      Google Optimize
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Google Optimize을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Google Optimize 개인정보취급방침
      ClickTale
      오토데스크는 고객이 사이트에서 겪을 수 있는 어려움을 더 잘 파악하기 위해 ClickTale을 이용합니다. 페이지의 모든 요소를 포함해 고객이 오토데스크 사이트와 상호 작용하는 방식을 이해하기 위해 세션 녹화를 사용합니다. 개인적으로 식별 가능한 정보는 가려지며 수집되지 않습니다. ClickTale 개인정보취급방침
      OneSignal
      오토데스크는 OneSignal가 지원하는 사이트에 디지털 광고를 배포하기 위해 OneSignal를 이용합니다. 광고는 OneSignal 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 OneSignal에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 OneSignal에 제공하는 데이터를 사용합니다. OneSignal 개인정보취급방침
      Optimizely
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Optimizely을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Optimizely 개인정보취급방침
      Amplitude
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Amplitude을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Amplitude 개인정보취급방침
      Snowplow
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Snowplow를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Snowplow 개인정보취급방침
      UserVoice
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 UserVoice를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. UserVoice 개인정보취급방침
      Clearbit
      Clearbit를 사용하면 실시간 데이터 보강 기능을 통해 고객에게 개인화되고 관련 있는 환경을 제공할 수 있습니다. Autodesk가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. Clearbit 개인정보취급방침
      YouTube
      YouTube는 사용자가 웹 사이트에 포함된 비디오를 보고 공유할 수 있도록 해주는 비디오 공유 플랫폼입니다. YouTube는 비디오 성능에 대한 시청 지표를 제공합니다. YouTube 개인정보보호 정책

      icon-svg-hide-thick

      icon-svg-show-thick

      광고 수신 설정 – 사용자에게 타겟팅된 광고를 제공할 수 있게 해 줌

      Adobe Analytics
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Adobe Analytics를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Adobe Analytics 개인정보취급방침
      Google Analytics (Web Analytics)
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Google Analytics (Web Analytics)를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. AdWords
      Marketo
      오토데스크는 고객에게 더욱 시의적절하며 관련 있는 이메일 컨텐츠를 제공하기 위해 Marketo를 이용합니다. 이를 위해, 고객의 온라인 행동 및 오토데스크에서 전송하는 이메일과의 상호 작용에 관한 데이터를 수집합니다. 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 이메일 확인율, 클릭한 링크 등이 포함될 수 있습니다. 오토데스크는 이 데이터를 다른 소스에서 수집된 데이터와 결합하여 고객의 판매 또는 고객 서비스 경험을 개선하며, 고급 분석 처리에 기초하여 보다 관련 있는 컨텐츠를 제공합니다. Marketo 개인정보취급방침
      Doubleclick
      오토데스크는 Doubleclick가 지원하는 사이트에 디지털 광고를 배포하기 위해 Doubleclick를 이용합니다. 광고는 Doubleclick 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Doubleclick에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Doubleclick에 제공하는 데이터를 사용합니다. Doubleclick 개인정보취급방침
      HubSpot
      오토데스크는 고객에게 더욱 시의적절하며 관련 있는 이메일 컨텐츠를 제공하기 위해 HubSpot을 이용합니다. 이를 위해, 고객의 온라인 행동 및 오토데스크에서 전송하는 이메일과의 상호 작용에 관한 데이터를 수집합니다. 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 이메일 확인율, 클릭한 링크 등이 포함될 수 있습니다. HubSpot 개인정보취급방침
      Twitter
      오토데스크는 Twitter가 지원하는 사이트에 디지털 광고를 배포하기 위해 Twitter를 이용합니다. 광고는 Twitter 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Twitter에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Twitter에 제공하는 데이터를 사용합니다. Twitter 개인정보취급방침
      Facebook
      오토데스크는 Facebook가 지원하는 사이트에 디지털 광고를 배포하기 위해 Facebook를 이용합니다. 광고는 Facebook 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Facebook에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Facebook에 제공하는 데이터를 사용합니다. Facebook 개인정보취급방침
      LinkedIn
      오토데스크는 LinkedIn가 지원하는 사이트에 디지털 광고를 배포하기 위해 LinkedIn를 이용합니다. 광고는 LinkedIn 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 LinkedIn에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 LinkedIn에 제공하는 데이터를 사용합니다. LinkedIn 개인정보취급방침
      Yahoo! Japan
      오토데스크는 Yahoo! Japan가 지원하는 사이트에 디지털 광고를 배포하기 위해 Yahoo! Japan를 이용합니다. 광고는 Yahoo! Japan 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Yahoo! Japan에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Yahoo! Japan에 제공하는 데이터를 사용합니다. Yahoo! Japan 개인정보취급방침
      Naver
      오토데스크는 Naver가 지원하는 사이트에 디지털 광고를 배포하기 위해 Naver를 이용합니다. 광고는 Naver 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Naver에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Naver에 제공하는 데이터를 사용합니다. Naver 개인정보취급방침
      Quantcast
      오토데스크는 Quantcast가 지원하는 사이트에 디지털 광고를 배포하기 위해 Quantcast를 이용합니다. 광고는 Quantcast 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Quantcast에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Quantcast에 제공하는 데이터를 사용합니다. Quantcast 개인정보취급방침
      Call Tracking
      오토데스크는 캠페인을 위해 사용자화된 전화번호를 제공하기 위하여 Call Tracking을 이용합니다. 그렇게 하면 고객이 오토데스크 담당자에게 더욱 빠르게 액세스할 수 있으며, 오토데스크의 성과를 더욱 정확하게 평가하는 데 도움이 됩니다. 제공된 전화번호를 기준으로 사이트에서 고객 행동에 관한 데이터를 수집할 수도 있습니다. Call Tracking 개인정보취급방침
      Wunderkind
      오토데스크는 Wunderkind가 지원하는 사이트에 디지털 광고를 배포하기 위해 Wunderkind를 이용합니다. 광고는 Wunderkind 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Wunderkind에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Wunderkind에 제공하는 데이터를 사용합니다. Wunderkind 개인정보취급방침
      ADC Media
      오토데스크는 ADC Media가 지원하는 사이트에 디지털 광고를 배포하기 위해 ADC Media를 이용합니다. 광고는 ADC Media 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 ADC Media에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 ADC Media에 제공하는 데이터를 사용합니다. ADC Media 개인정보취급방침
      AgrantSEM
      오토데스크는 AgrantSEM가 지원하는 사이트에 디지털 광고를 배포하기 위해 AgrantSEM를 이용합니다. 광고는 AgrantSEM 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 AgrantSEM에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 AgrantSEM에 제공하는 데이터를 사용합니다. AgrantSEM 개인정보취급방침
      Bidtellect
      오토데스크는 Bidtellect가 지원하는 사이트에 디지털 광고를 배포하기 위해 Bidtellect를 이용합니다. 광고는 Bidtellect 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Bidtellect에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Bidtellect에 제공하는 데이터를 사용합니다. Bidtellect 개인정보취급방침
      Bing
      오토데스크는 Bing가 지원하는 사이트에 디지털 광고를 배포하기 위해 Bing를 이용합니다. 광고는 Bing 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Bing에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Bing에 제공하는 데이터를 사용합니다. Bing 개인정보취급방침
      G2Crowd
      오토데스크는 G2Crowd가 지원하는 사이트에 디지털 광고를 배포하기 위해 G2Crowd를 이용합니다. 광고는 G2Crowd 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 G2Crowd에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 G2Crowd에 제공하는 데이터를 사용합니다. G2Crowd 개인정보취급방침
      NMPI Display
      오토데스크는 NMPI Display가 지원하는 사이트에 디지털 광고를 배포하기 위해 NMPI Display를 이용합니다. 광고는 NMPI Display 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 NMPI Display에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 NMPI Display에 제공하는 데이터를 사용합니다. NMPI Display 개인정보취급방침
      VK
      오토데스크는 VK가 지원하는 사이트에 디지털 광고를 배포하기 위해 VK를 이용합니다. 광고는 VK 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 VK에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 VK에 제공하는 데이터를 사용합니다. VK 개인정보취급방침
      Adobe Target
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Adobe Target을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Adobe Target 개인정보취급방침
      Google Analytics (Advertising)
      오토데스크는 Google Analytics (Advertising)가 지원하는 사이트에 디지털 광고를 배포하기 위해 Google Analytics (Advertising)를 이용합니다. 광고는 Google Analytics (Advertising) 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Google Analytics (Advertising)에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Google Analytics (Advertising)에 제공하는 데이터를 사용합니다. Google Analytics (Advertising) 개인정보취급방침
      Trendkite
      오토데스크는 Trendkite가 지원하는 사이트에 디지털 광고를 배포하기 위해 Trendkite를 이용합니다. 광고는 Trendkite 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Trendkite에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Trendkite에 제공하는 데이터를 사용합니다. Trendkite 개인정보취급방침
      Hotjar
      오토데스크는 Hotjar가 지원하는 사이트에 디지털 광고를 배포하기 위해 Hotjar를 이용합니다. 광고는 Hotjar 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Hotjar에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Hotjar에 제공하는 데이터를 사용합니다. Hotjar 개인정보취급방침
      6 Sense
      오토데스크는 6 Sense가 지원하는 사이트에 디지털 광고를 배포하기 위해 6 Sense를 이용합니다. 광고는 6 Sense 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 6 Sense에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 6 Sense에 제공하는 데이터를 사용합니다. 6 Sense 개인정보취급방침
      Terminus
      오토데스크는 Terminus가 지원하는 사이트에 디지털 광고를 배포하기 위해 Terminus를 이용합니다. 광고는 Terminus 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Terminus에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Terminus에 제공하는 데이터를 사용합니다. Terminus 개인정보취급방침
      StackAdapt
      오토데스크는 StackAdapt가 지원하는 사이트에 디지털 광고를 배포하기 위해 StackAdapt를 이용합니다. 광고는 StackAdapt 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 StackAdapt에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 StackAdapt에 제공하는 데이터를 사용합니다. StackAdapt 개인정보취급방침
      The Trade Desk
      오토데스크는 The Trade Desk가 지원하는 사이트에 디지털 광고를 배포하기 위해 The Trade Desk를 이용합니다. 광고는 The Trade Desk 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 The Trade Desk에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 The Trade Desk에 제공하는 데이터를 사용합니다. The Trade Desk 개인정보취급방침
      RollWorks
      We use RollWorks to deploy digital advertising on sites supported by RollWorks. Ads are based on both RollWorks data and behavioral data that we collect while you’re on our sites. The data we collect may include pages you’ve visited, trials you’ve initiated, videos you’ve played, purchases you’ve made, and your IP address or device ID. This information may be combined with data that RollWorks has collected from you. We use the data that we provide to RollWorks to better customize your digital advertising experience and present you with more relevant ads. RollWorks Privacy Policy

      정말 더 적은 온라인 경험을 원하십니까?

      오토데스크는 고객 여러분에게 좋은 경험을 드리고 싶습니다. 이전 화면의 범주에 대해 "예"를 선택하셨다면 오토데스크는 고객을 위해 고객 경험을 사용자화하고 향상된 응용프로그램을 제작하기 위해 귀하의 데이터를 수집하고 사용합니다. 언제든지 개인정보 처리방침을 방문해 설정을 변경할 수 있습니다.

      고객의 경험. 고객의 선택.

      오토데스크는 고객의 개인 정보 보호를 중요시합니다. 오토데스크에서 수집하는 정보는 오토데스크 제품 사용 방법, 고객이 관심을 가질 만한 정보, 오토데스크에서 더욱 뜻깊은 경험을 제공하기 위한 개선 사항을 이해하는 데 도움이 됩니다.

      오토데스크에서 고객님께 적합한 경험을 제공해 드리기 위해 고객님의 데이터를 수집하고 사용하도록 허용하시겠습니까?

      선택할 수 있는 옵션을 자세히 알아보려면 이 사이트의 개인 정보 설정을 관리해 사용자화된 경험으로 어떤 이점을 얻을 수 있는지 살펴보거나 오토데스크 개인정보 처리방침 정책을 확인해 보십시오.