효율적인 3D 익스포터 디자인


저작권 정보

현재 가마수트라가 번역허가를 내주고 있지 않은 관계로 원문의 링크만을 제공합니다. 하지만 영어에 도움이 필요하신 분들을 위해 아래에 해석을 달아놓았습니다. 원문을 읽으시다가 모르시는 부분이 있으시다면 비교하면서 읽어보시길 바랍니다.


원문 정보


소개

게임산업계에 존재하는 문제점 중 하나는 많은 프로그래머들와 아티스트들이 서로를 이해하지 못한다는 것입니다. 이 때문에 아티스트들이 프로그래머들을 컴퓨터 오타쿠 취급을 하고, 프로그래머들은 아티스트들을 생고생 시키는 툴을 만드는 거죠.

문제를 시각적으로 표시해주면 디자이너들이 문제를 더 빠르게 수정할 수 있을 것 입니다.


This article is about how you can make your 3D graphics exporter tools better, in terms of helping your artists get their job done. If you're lucky, this will get your project better art, which will mean bigger sales, and more money, fame and fortune. Plus, maybe your artists will actually like you for helping them do their best work!

이 글은 여러분의 3D 익스포터가 좀 더 디자이너들의 작업에 도움이 되도록 개선하는 방법에 대해 설명하려고 합니다. 운이 좋다면 여러분 프로젝트의 그래픽이 더 좋아질수 있을것이고, 덕분에 더 많이 팔리고, 더 많은 돈을 벌 수 있을 것이며, 명성과 부를 쌓을 수 있겠죠. 거기다 함께 작업했던 디자이너들이 당신을 좋아하게 될 것입니다!




철학


It may sound namby-pamby, but I think it's a good idea to come up with philosophical guidelines when you are designing your tools, to give you something to judge your choices by. Here are some of mine.

갑자기 왠 철학이냐라고 말할지 모르겠습니다만, 툴을 만드는 중 결정에 도움이 될만한 몇가지 철학적 가이드 라인을 가지는 것은 좋은 생각입니다. 여기 제가 생각하는 몇가지가 있습니다.


'''- Make your tools "bullet-proof"'''

'''- 여러분의 툴을 "방탄 조끼" 로 만드십시오'''

= 재벌중(포프)=


Obviously, the artists don't try to break your 3D exporter, but if you make them juggle eggs, then the yolk will be on you occasionally. If your tools are designed such that it's easy to make mistakes, people will make mistakes. If it's possible to design them so mistakes are harder or impossible, then you'll save a lot of time in the long run. How many times have you spent hours tracking down a crash bug, only to find was bad data, data you could have prevented from being bad in the first place if your tools checked for it?

당연한 이야기지만 디자이너들이 여러분의 3D 익스포터를 망가뜨리려고 하지는 않습니다만 대충 만들어 넘긴다면 이후에 발생하는 문제들에 여러분이 곤혹을 치루게 될 것입니다. 툴이 실수 하기 쉽도록 만들어져 있다면 당연히 사람들은 실수를 할 수 밖에 없습니다. 반대로 실수를 하는것이 어렵거나 불가능하게 되어있다면 많은 시간을 절약할 수 있을 것입니다. 맨처음 데이터를 읽어올때 체크하기만 했다면 발생하지 않았을 문제 때문에 얼마나 많은 시간을 소모하고 있습니까?

To give you a concrete example, I once received a skinning library and exporter from another team. I immediately made a simple test and tried to run it, and it crashed with no explanation. After asking one of the artists familiar with the exporter, he messed with it for about 2 hours and finally gave up, not able to get it to work. So, it then got passed on to one of the programmers more familiar with the code.

구체적인 예를 들어보도록 하죠. 한번은 다른 팀에서 스키닝 라이브러리와 익스포터를 받은 적이 있습니다. 즉시 간단한 테스트 데이타를 만들어 실행 시켜 보았습니다만 아무런 설명도 없이 프로그램이 죽어버렸스니다. 그 익스포터를 사용하던 디자이너 한명에게 질문해보았지만 그도 2시간동안 괴로워하더니 결국 이유를 알아내지 못하고 포기해버렸습니다. 어쩔수 없이 관련 코드를 알고 있는 프로그래머에게 물어보았습니다.

After an hour or so of passing the files over to him, he told me 'Oh! You need to have 4 or less influences per vertex.' That's fair enough, but why does the tool crash? First, the library could check for too many influences - at least the debug version. Second, the exporter could do a similar job. The exporter might be more useful if it's flexible enough to handle more than 4 influences - maybe it should be designed to take some kind of project-based configuration file, so that you can specify the limits for a particular system, and it can check for them and warn you. I'm sure that the same scenario that I went through happened several times during the project: artist adds new art, game suddenly crashes, hours are spent tracking it down to the problem of too many vertex influences.

한시간 뒤 그는 "각 버텍스에 영향을 미치는 본이 4개 이하여야 합니다" 라고 말해주었습니다. 그래, 그건 좋다. 헌데 왜 프로그램이 죽었을까? 첫째로 영향을 미치는 본의 개수를 체크 하지 않았습니다 - 최소한 디버그 버젼에서라도. 둘째로 익스포터도 그런 작업을 해주지 않았습니다. 물론 버텍스가 4개 이상의 영향을 받을 수 있다면 익스포터는 좀 더 유용해지겠지만, 아마도 이 익스포터는 프로젝트 기반의 설정 파일로 디자인 되었겠죠. 그렇다면 특정 시스템의 한계를 명시하고 체크 해서 경고를 해줘야 했습니다. 프로젝트 진행 도중 이후에도 똑같은 일이 발생할 것이라는 사실을 확신할 수 있습니다. 디자이너가 새로운 데이타를 추가하자 게임은 갑자기 죽어버리고, 그 문제를 찾기 위해 수많은 시간이 소모되겠죠.

In fact, some commercial engines that I've seen can export data that crashes the engine. What were they thinking? The exporter should never export data the engine can't handle. As well as this, the engine or tool, at least in debug mode, should check that the data is correct. Otherwise, you're just asking for hours of debugging.

사실 익스포터가 만든 데이타를 넣자 터져버리는 상용 엔진을 본적도 있습니다. 그들은 무슨 생각을 하고 있는 걸까요? 익스포터는 엔진이 다룰 수 없는 데이타를 뱉어내서는 안됩니다. 그리고 엔진이나 툴에서도 최소한 디버그 모드에서는 데이타가 정상적인지 체크해주는 것이 좋습니다. 그렇지 않다면 여러분은 매번 몇시간씩을 버그를 잡는데 소모하게 될 것입니다.

다시 한번 강조하자면, 여러분의 툴을 방탄 조끼로 만드십시오!


'''- Don't force your artists to speak to a programmer in order to work out why something doesn't work.'''

'''- 디자이너들이 프로그래머에게 "왜 작동하지 않죠?" 라고 묻도록 하지 마십시오.'''

If your artists have to come to you every time something doesn't work, then you're going to be chasing down issues for your artists all the time.

만약 함께 일하는 디자이너들이 무언가 작동하지 않는 툴 때문에 날마다 여러분에게 찾아온다면 함께 일하는 디자이너들을 위해서라도 명심해 두어야 할 부분입니다.

Anything you can do to design your tools so that artists can figure out the issues on their own means you can work on other things, and everyone can get their work done faster and with less frustration.

문제가 발생했을때 디자이너들이 무엇이 문제인지 즉시 알아 차릴 수 있도록 툴을 만드십시오. 그렇게 함으로써 여러분은 다른 작업에 매진할 수 있을것이고 모든 사람들이 자신의 작업을 아무런 혼란 없이 더 빠르게 끝 마칠수 있을 것입니다.


'''- Make the tool, not the artist, do the non-artistic work.'''

'''- 디자이너들이 그래픽적 업무 외의 일을 하도록 만들지 마십시오.'''

This is pretty simple. Basically, don't force the artists to do things a trained monkey could do. An extremely simple example would be - don't force them to break up their quads into triangles. If you are passed a quad and you need triangles, then silently make triangles. Of course, you should probably check if it's planar or not and mark it as an error or warning (see below). But the point is - wherever possible, do the obvious thing.

간단합니다. 잘 훈련된 원숭이조차 할 수 있는 일을 디자이너들이 하도록 강요하지 마십시오. 아주 간단한 예를 들어보자면 쿼드를 트라이앵글로 쪼개는 일과 같은 것입니다. 쿼드는 필요 없고 트라이앵글이 필요하다면 그냥 쿼드를 자동으로 트라이앵글로 쪼개십시오. 물론 그것이 계획된 것이던 그렇지 않던 에러나 경고를 표시해 주어야 한다는 것입니다. (후에 다시 설명하겠습니다) 어쨋든 핵심은 가능한 명확히 하라는 것입니다.


'''- Make it possible for your tools to work as part of a one-step build process.'''

'''- 툴에서 이루어지는 작업을 되도록 일괄 작업으로 만드십시오.'''

You've probably heard about a one-step build being a good idea. The one-step build avoids human error, by eliminating all manual steps in the conversion of human-made creative assets to game-ready data. In particular, this means that artists should not be required to manually re-export their 3D models. They just create the models, textures, level maps, and so on. The build tools will export them as necessary (when they are newer than the game-ready versions of the same data.) An added benefit of the one-step build is that your artists spend most of their time creating art, instead of repeating non-creative tasks that automated systems could do a lot faster and cheaper.

아마도 공정이 일괄적으로 이루어지는 형태가 좋다는건 들어보셨을 겁니다. 디자이너가 작업한 데이타를 게임 데이타로 변환하는데 있어 수동으로 이루어지는 모든 단계를 없애고 일괄 생성 공정으로 만든다면 사람이 저지를수 있는 실수를 피할 수 있을 것입니다. 이것은 디자이너들이 3D 모델을 수작업으로 일일이 다시 뽑지 않아도 된다는 의미 입니다. 디자이너들은 단지 모델과 텍스춰와 맵등을 만들기만 하면 됩니다. 만약에 필요하다면 (현재 게임에서 사용되는 버젼이 변경되었거나 할때) 툴이 알아서 뽑아 주면 됩니다. 덧붙여서 원스텝 공정은 자동화 시킬 경우 좀 더 빠르고 편하게 이루어질 수 있는 비창조적 작업들을 디자이너들이 작업할 시간을 뺏겨가며 하지 않아도 된다는 이득도 있습니다.


'''- Make your tools to support the way that artists work.'''

'''- 디자이너들의 작업을 도울 수 있는 툴을 만드십시오.'''

There's a point to this piece of philosophy. Never forget that the goal of your tools is to help the artists make great art. You do that by designing your tools to support all the features and techniques that artists typically use. We'll go on to discuss some examples of how this philosophy comes into play.

이 철학의 주요 요지는 툴이 가지고 있는 궁극적인 목표가 "그래퍼들이 좀 더 굉장한 결과물을 만드는 것을 돕는 것" 이란 사실을 절대 잊지 말라는 것입니다. 디자이너들이 일반적으로 사용하는 기능들을 모두 지원하도록 하십시오.

이제부터는 이 철학들이 어떻게 사용되는지 이야기 해보겠습니다.


==툴 디자인: 3D 익스포터==

It seems like most exporters I come across are designed to export everything in the currently loaded scene in 3D Studio Max, Maya, Lightwave, and so on, but within the limits of the system the programmer designed. If anything in the scene is hidden, they don't export it, and for animation, they export based on the current setting of the time line in the user interface. Alternatively, they export the currently selected items. Some people refer to this export style as WYSIWYG exporting. It sounds like a good idea at first, and it might be great for testing your new engine. But with a little thought, it soon becomes clear that a different design would make things go smoother for everybody involved.

대부분의 익스포터가 그런것 같긴 합니다만 과거에 3D Studio Max, Maya, Lightwave 등의 툴에서 현재 화면 상에 보이는 모든 것을 그대로 뽑아주는 익스포터를 만든적이 있습니다. 만약 어떤 물체가 숨겨져 있다면 뽑지 않고, 애니메이션도 현재 맞춰진 키프레임으로 뽑아내었습니다. 또는 현재 선택된 오브젝트를 익스포트 하기도 했습니다. 보통 이런 것을 WYSIWYG (You See Is What You Get) 라고 부르죠. 언뜻 보기엔 괜찮아 보이기도 하고, 새로운 엔진 테스트에는 훌륭할지도 모릅니다만, 조금만 생각해보시면 모두가 사용하기엔 그다지 좋은 형태가 아니라는 것을 알 수 있을 것입니다.

Let's see what some of the problems are, and the solutions that come up by applying the philosophies above.

무엇이 문제였는지, 그리고 그 문제들에 대한 해결법들에는 어떠한 것들이 있는지 앞서 언급한 철학들과 대조해가며 알아보도록 하지요.


'''- Make your tools show errors that can be noticed, understood and useful.'''

'''- 에러는 알아보기 쉽고, 이해하기 쉬우며, 유용한 형태로 보여주십시오.'''

Asking an artist to look through ten thousand lines of diagnostic output, in order to find the three warnings that flew by while the data is converted is not useful. Following the "Don't force your artists to speak to a programmer" philosophy, the best way to deal with problems is to show them visually. If certain polygons are obviously wrong, then somehow mark them and show the artist.

디자이너에게 데이타가 컨버팅 되는 동안 단 세줄의 경고를 찾기 위해 수천줄의 메세지를 지켜보고 있으라고 하는 것은 전혀 무의미한 일입니다. "디자이너가 프로그래머에게 질문 하도록 만들지 마십시오" 라는 구절에 따라, 이 문제를 처리하는 가장 효과적인 방법은 시각적으로 보여주는 것입니다. 폴리곤이 잘못 되었다면 디자이너에게 어떻게든 표시하고 보여주십시오.

In my tools, if certain polygons are bad, I'll still output the polygons or the rest of the model, but my file formats have an optional semi-generic error encoding system where I can put in error messages, error lines, error points, and so on. When the 3D objects are loaded up into the viewer or the game, any object that has error information can be displayed or marked in obvious colors such as flashing red.

제 경우 폴리곤이 정상적이지 않더라도 그래도 일단 저장을 하거나 그 부분을 제외한 나머지 부분만이라도 저장을 합니다. 그리고서 에러 메세지나 잘못된 라인 혹은 벡터 번호를 준비해둔 파일의 에러 입력 시스템의 자리에 저장을 해둡니다. 이후 뷰어나 게임에서 3D 오브젝트를 불렀을때 에러 관련 정보가 있다면 반짝거리는 빨간색 처럼 눈에 잘 띄이는 색으로 화면상에 표시합니다.

Those objects can then be selected, and the errors specific to that object can be brought up. If the errors are visually representable, then the polygons associated with that error will also be displayed if the object is selected and a particular error highlighted. For example, an error selected in the debug menu that says "polygon has too many weights" will highlight the polygon in question in the game or previewer.

오브젝트를 선택했을때 오브젝트와 관련된 에러들을 가져와 보여줍니다. 만약 에러가 시각적으로 보여줄 수 있는 형태라면 특정 에러나 그 에러와 연관된 폴리곤을 선택 했을때 출력해주는 것이 좋습니다. 예를들어, 디버그 메뉴에서 "폴리곤에 영향을 미치는 본이 너무 많습니다" 라는 사항을 선택했을때 해당 폴리곤을 표시해주면 됩니다.

Another good idea is to have the programmer that wrote the error message put their name in the message. For example, it could state: "WARNING: <gman> found vertices with more than 4 influences". That way, the artist will immediately know who to talk to if they have a question about the message.

좋은 팁이 한가지 더 있습니다. 에러 메세지를 작성한 사람의 이름을 에러 메세지와 함께 출력해주는 것입니다. 다음과 같은 형태가 되겠죠. "경고: <gman> 4개 이상의 본으로부터 영향을 받고 있는 버텍스가 있습니다." 이렇게 함으로써 아티스트는 관련 질문을 누구에게 해야 하는지 즉시 알아차릴 수 있습니다. 


'''- Never let your tools fail.'''

'''- 여러분의 툴이 실패하도록 만들지 마십시오.'''

I know some of you will disagree with this idea, but hear me out. This is a goal I tried to reach on my last game. No matter what the problem, try to output something into the game or previewer. This goes along with the philosophy of "Don't force your artists to speak to a programmer in order to work out why something doesn't work".

물론 이 생각에 동의하지 않는 분이 계실지도 모르겠습니다만 일단 들어보십시오. 이건 제가 마지막으로 작업했던 게임에서 목표로 삼았던 것입니다. 게임이나 프리뷰에서 무슨 문제가 발생하더라도 무엇이든 일단 출력하려고 했습니다. 이건 "아티스트들이 프로그래머에게 무엇인가 작동되지 않는다고 말하는 상황을 만들지 않도록 하라" 라는 원칙과도 일맥 상통 합니다. 

It's very frustrating when you can't build a level because something is broken, and even more so when the problem is unrelated to what you are currently working on. It's best to at least get the object or level working as soon as possible, even with errors or missing items. For example, if a texture path is incorrect and you can't find the source file for the texture, then use a special 'ERROR' texture and still write out the file. This will make it visually clear to the artist what is wrong, and they will most likely know how to fix it immediately, but they will also get to see their model now instead of later.

무엇인가 깨져 있다고 맵 데이타를 부를 수 없다면 매우 곤혹스러울 것입니다. 게다가 현재 작업중인 것과 관련이 없는 문제라면 더더욱 그렇겠죠. 가장 좋은 방법은 오브젝트나 맵을 가능한 곳까지는 불러서 배치 하고 에러나 출력하지 못한 아이템을 표시하는 것입니다. 예를 들어 텍스춰 경로가 잘못 되어 파일을 찾을 수 없다면 "error" 텍스춰를 사용하고 and still write out the file. 이렇게 하면 디자이너들에게 무엇이 잘못되었는지 명확하게 시각적으로 알려줄 수 있으며 대부분 어떻게 고쳐야 하는지 곧바로 알아차릴 수 있을 것입니다. 그리고 일단 작업 결과물을 확인 할 수 있겠죠.


'''A good idea for a default texture is the letter "F" - it's something you can instantly tell orientation from (whether it's upside down, backward, rotated, and so on.) Also, putting a single pixel-wide edge color around the edges of the texture will let you see where the texture repeats, and if your UV coordinates are referencing the texture all the way to the edges.'''

'''디폴트 텍스춰는 어느 형태로 놓여져도 방향을 알아낼 수 있는 글자 "F" 가 좋습니다. 여기다 외곽에 방향별로 다른 색상으로 한줄씩 그어놓으면 모든 방향으로 끝까지 텍스춰를 참조 했더라도 어떤식으로 반복되어 배치 되는지 알 수 있습니다.'''



Another example from my level building tools - if one object in the level has errors the level still gets built, but that object is just tagged as bad. There are often thousands of items in a level made by different people. If all it takes is for one of them to be bad to stop your level from loading, you are not going to be getting much work done.

제가 만들었던 툴에서의 또 다른 예를 들어보겠습니다. 데이터를 불러오는 중에 한 오브젝트에 에러가 있다면 그냥 "잘못 되어 있다" 고 체크만 해놓고 넘어갑니다. 데이터에는 여러사람이 만든 수천개의 아이템이 들어가 있습니다. 이중 단 한개의 아이템이 잘못되었다고 데이터를 불러오는 도중 멈춰 버린다면 아마도 여러분의 작업 시간에는 많은 제약이 따를 것입니다.
 

'''Some engines just crash if a texture is missing. Why?'''

'''어떤 엔진들은 텍스춰를 찾지 못할때 멈춰버립니다. 왜죠?'''


You can go into more detail still, using both warnings and errors in exported data. A warning means that the data needs to be fixed, but the object should still run. In other words, the game should feel safe to execute the A. I. code for that object without fear of crashing. An error means that the particular object is not in a state the game can use. After loading a level, all objects with warnings would be flashing and all objects with errors will just have a name displayed in their place. At that point, the artist or designer can select objects and find out the specific errors. This is much easier to fix than sifting through hundreds of lines of building diagnostics.

익스포트 데이타에서 '''경고'''와 '''에러''' 를 사용하십시오. 경고는 데이터가 수정되어야 하지만 일단 동작은 한다는 의미입니다. 다시 말해서 해당 오브젝트를 다루는데 게임이 멈춰 버릴 위험은 없다는 것입니다. 에러는 게임에서 사용 할 수 없음을 의미합니다. 맵을 부른 후에 경고는 깜빡거리며 표시되어야 하고 에러 수준의 오브젝트는 그 오브젝트가 있어야 할 자리에 이름만 표시해 줍니다. 그 시점에 디자이너나 기획자들은 오브젝트를 선택하고 에러를 발견 할 수 있을 것입니다. 맵 로딩중 남은 수천줄의 로그 속에서 문제를 찾아 수정하는 것 보다는 이쪽이 훨씬 쉬울 것 입니다.

However, in some cases it might be appropriate to fail immediately, especially if building a level or object takes a long time. If there are things you can check for quickly that you know will cause a problem, you might want to bring those to the attention of the artist immediately. But if possible, visual evidence is almost always better than just an error message.

하지만 어떤 경우에는 즉시 실패하는 것이 좋을 수도 있습니다. 예를 들어 미리 체크해보고 맵이나 오브젝트가 불러오는데 시간이 너무 오래 걸릴 것 같아 문제가 발생할거 같다면 불러오지 못하도록 함으로써 디자이너들에게 주의를 줄 수 있습니다. 하지만 가능하다면, 몇줄의 에러 메세지 보다는 시각적으로 보여주는 것이 언제나 더 나을 것입니다.


'''- Don't force your artists to remove helper objects.'''

'''- 디자이너들의 Helper 오브젝트를 지우도록 하지 마십시오.'''

Many exporters require your artists to have the data they need, and only that data, in their 3D editor. Artists are not allowed extra lights, extra models, extra cameras, and so on. But have you ever actually seen how your artists work? They need lights to light their models. They need extra models for constraints, for checking sizes, or for other references. Asking them to have to delete those every time they export is asking for trouble. 

많은 익스포터들이 디자이너들에게 3D 에디터에서 필요한 데이타만을 남겨두길 요구하고 있습니다. 디자이너들에겐 광원, 확장 모델, 카메라와 같은 것은 허용되어있지 않죠. 혹시 디자이너들이 어떻게 작업하는지 본적 있습니까? 그들은 모델에 빛을 비춰보기 위해 광원이 필요합니다. 그들은 구속 조건이나 크기를 체크하기 위해서나, 혹은 작업을 위한 더미 모델들이 필요합니다. 그들에게 데이터를 뽑을 때마다 이러한 것들을 지우길 강요한다면 문제가 될 것입니다.

Firstly, you are making artists do this work manually every time they export. They may even have to rebuild all their lights and constraints if they accidentally save after they've deleted them for exporting. Alternatively, they may forget to remove them, export and thereby clutter the game with un-needed items. Even worse, they may accidentally make the game crash and you've got another hour or two as you try to figure out why.

디자이너들에게 수작업으로 데이터를 뽑을 때마다 이러한 작업을 하도록 만들었을때, 그것들을 지우고 데이터를 뽑은 후에 실수로 데이터를 저장 해버렸다면 그들은 다시 여러가지를 재배치 해야만 할 것입니다. 결과적으로 디자이너들이 지우는 것을 잊어버리고 게임 속에는 불필요한 아이템들이 어지럽게 떠다닐 것입니다. 최악의 경우엔 게임이 멈춰버리고 이유를 찾아내기 위해 여러분은 한두시간을 소요하게 될 것입니다.

Following the "make your tools support the way artists work" philosophy, it would be better to find a way to let artists specify what needs to be exported, so that you can ignore all the rest. That way your artists are unlikely to make as many mistakes. They don't need to remember to delete objects. They don't have to worry about accidentally saving after having deleted objects. They can keep all the objects, lights and cameras that make their job easier.

"디자이너들의 작업을 도울 수 있는 툴을 만드십시오" 라는 철학을 기억하십시오. 디자이너들에게 무엇을 뽑을 것인지 명시한 후에 나머지는 무시하게 만들 수 있을 것입니다. 이렇게 한다면 디자이너들의 실수가 줄어들겠죠. 불필요한 오브젝트를 지우는 작업을 할 필요가 없습니다. 데이터를 뽑은후 무심코 저장해버리는 실수를 두려워할 필요가 없어집니다. 디자이너들은 그들의 작업을 더욱 간편하게 해주는 광원이나 카메라와 같은 모든 오브젝트들을 남겨둘 수 있을 것 입니다.

I'd also recommend that the artists should specify what to export, as opposed to specifying what not to export. If you choose the "not" route, then if they add something and forget to mark it to "not" be exported , you're going to end up with stuff you don't want in your data. This is worse than finding something is missing because it was not specified, since once it is specified it will never be missing again. It is usually easier to see what is missing in the game than to notice something extra that isn't supposed to be present.

덧붙여 디자이너들이 무엇을 뽑지 않을 것인지 명시하는 것 보다는 무엇을 뽑을 것인지 명시 해주는 쪽을 추천합니다. 디자이너들이 새로운 오브젝트를 추가하고 익스포트 하지 않겠다는 것을 명시하지 않았을 경우 데이터로 뽑지 않는 것이 좋습니다. 이 경우 뽑히지 않은 데이터를 찾아야 되니 좋지 않을 수도 있습니다만 여러번 실수 하지는 않을 것입니다. 또한 적어도 표시 되지 말아야 할 무언가를 알아차리는 것보다는 무엇인가 출력되고 있지 않다는 것을 확인하는 쪽이 훨씬 쉽겠죠.


'''- Don't force your artists to check export settings more than once.'''

'''- 디자이너들에게 한번 이상 익스포트 셋팅을 설정하도록 강요 하지 마십시오.'''

Many exports have a gigantic amount of settings. For example, they include elements choosing whether to export vertex colors or animations; whether to save textures as filenames or re-write them; whether to save as an object or a character; what internal name to use for a character, and so on.

여러 익스포터가 끔찍하도록 많은 설정을 가지고 있습니다. 예를 들자면 버텍스 칼라나 버텍스 애니메이션을 포함 시킬 것인지, 텍스춰를 파일 이름만 저장할지 아니면 포함 시킬지, 오브젝트인지 캐릭터인지, 캐릭터를 위해 내부 이름을 사용할 것인지 등이 있습니다.

While these settings might be important, it's asking for trouble to ask your artists to check them every time they export the same file. Following both the "Make the tool, not the artist, do the non-artistic work" and the "make it bulletproof" philosophy, these options should be set once and saved somewhere for exporting that particular file. So, if the camera is not supposed to be exported in this file, then the next time the file is loaded and exported it will automatically not export the camera. If another file is supposed to export animations with a base node called "orcbase", then if it is loaded and exported again, it should automatically export animations as "orcbase".

물론 이러한 설정들은 중요하기 때문에 디자이너들은 같은 파일을 매번 뽑을때 마다 여러분에게 문제점에 관해 문의할 것입니다. "디자이너들이 그래픽적인 일이 아닌 것을 하도록 만들지 마십시오.", "여러분의 툴을 '방탄 조끼' 로 만드십시오" 두가지 철학에 따라 이 옵션은 한번만 설정하도록 하고 설정 내용을 어딘가에 저장해 두십시오. 만약 카메라가 데이터로 뽑히지 않았다면 다음 번에도 자동으로 카메라를 뽑지 않도록 해야 합니다. 또 어떤 파일에서 "orcbase" 라는 이름의 노드를 기반으로 한 애니메이션을 뽑았다면 다음에도 자동으로 "orcbase" 의 애니메이션을 뽑아야 합니다.

Following the "make it bullet proof" rule, the artist should only have to look at settings if he or she needs to change them, and never once they are set. If they have to check them every time they export, odds are some percentage of those times they will miss checking or un-checking an option, and the coder and the artist will lose more time working things out.

"여러분의 툴을 '방탄 조끼' 로 만드십시오" 라는 룰에 따라 디자이너들은 단지 바꾸기 원하는 것만 보면 되며 다시는 그것을 건드릴 필요가 없어야 합니다. 만약 디자이너들이 매번 그것을 확인해야 한다면 그들이 체크해야 되거나 체크해야 되지 말아야할 옵션들을 놓치는 경우가 더욱 많아질 것이며 프로그래머나 디자이너 모두가 작업할 시간을 상당히 잃게 될 것입니다.


'''- Don't use the time line as an exporter setting.'''

'''- Time Line 을 익스포터의 설정으로 사용하지 마십시오.'''

Lots of exporters export animation by looking at the current time line in the user interface. If it's set from frame 10 to frame 150, then they export 141 frames from frame 10 to frame 150. As above, this is also error-prone. Every time an artist exports, they have to remember to put the editor's UI in a certain state. If they forget to do so, then certain in-game animations will no longer work properly.

많은 익스포터들이 애니메이션을 인터페이스에 지정된 현재 시간을 기준으로 데이터를 뽑곤 합니다. 만약 프레임이 10 부터 150 까지 설정되어있다면 그 사이 141 프레임을 뽑곤 하죠. 이와 같은 경우는 잘못될 확률이 높습니다. 그래픽 데이터를 뽑을때 마다 디자이너들은 올바른 자리에 UI 를 맞춰두어야만 합니다만 만약 그것을 잊어버렸을 경우 게임에서는 제대로 된 애니메이션이 나오지 않겠죠.

Following the "make your tools bullet proof" philosophy, it's better to have a way to specify once which frames to export. That way, artists don't have to remember to reset the time line. They know when they export, no matter what state the UI is in, they are going to get the frames they want. 

"여러분의 툴을 '방탄 조끼' 로 만드십시오" 라는 철학에 따르자면 어느 프레임을 뽑을 것인지 명시 할 수 있도록 해두고 한번 설정한 이후에는 다시 설정할 필요가 없도록 만드는 것이 좋습니다. 디자이너들은 데이터를 뽑을때 더이상 UI 를 손댈 필요 없이 자신이 원하는 프레임을 얻을 수 있을 것입니다.

An even better option would be to write a flexible specification system that allows your artists to put more than one animation in the same file. For example, your walk cycle might be frames 10 to 40, and your run cycle might be frames 100 to 130. Some artists find that method of animating much easier than forcing them to do every animation in a separate file. It also means global changes to a character, like adding a gun attachment point to the hand, will be reflected without changes needed to all the other animations.

같은 파일에 하나 이상의 애니메이션을 넣음으로써 좀 더 유용한 시스템을 만들 수 있습니다. 예를 들어 걷는 동작이 10 ~ 40 프레임 사이에 있고 뚜기 동작이 100 ~ 130 프레임 사이에 있다면 각각 파일로 구분해 놓았을때보다 훨씬 더 찾기 쉬울 것입니다. 또한 손에 총 어테치 지점을 붙이는 것처럼 전체에 적용되어야 할 수정을 가할때 여러개의 파일을 일일이 수정해야 될 필요도 없어집니다.


'''- Don't force your artists to collapse hierarchies.'''

'''- 디자이너들에게 상속 구조를 정리하도록 만들지 마십시오.'''

Another issue I see in lots of exporters is that they export the hierarchy in the 3D tool directly to the game hierarchy. In order to have the best speed in today's hardware, it's important to have as few separate models as possible.

많은 익스포트들 발견할 수 있는 또 하나의 쟁점은 3D 툴에서 사용되는 상속 구조를 그대로 게임에 적용한다는 점입니다. 요즘의 하드웨어에서 최대 속도를 내기 위해서는 가능한한 최소한으로 모델을 구분해두는 것이 좋습니다.

Unfortunately exporters that export the hierarchy directly require the artists to take separated models, and merge them into one model. A simple example might be a static 2-wheeled cart. The artist might build it using 2 tubes for wheels, a cylinder for an axel, 6 cylinders per wheel for the spokes, and then a box minus 2 faces for the cart area. In some exporters, if those objects are not all merged into 1 model, they will be exported as 16 separate models. Most programmers don't give that a second thought; they just assume the artists will merge everything.

불행히도 별다른 가공 없이 상속 구조를 그대로 뽑아내는 익스포터에서는 디자이너가 일일이 모델을 나누고 다시 합치는 작업을 해야만 합니다. 2륜 카트로 간단한 예를 들어보겠습니다. 디자이너는 바퀴를 2개의 튜브로 만들 것이고, 하나의 실린더로 엑셀을, 바퀴마다 6개의 실린더로 스포크를 만들 것이며, 박스로 카트의 몸체를 만들 것입니다. 어떤 익스포터에서는 이것을 하나의 모델로 합치지 않고 16개의 구별된 모델로 익스포트 할 것 입니다. 대부분의 프로그래머는 디자이너들이 모든 것을 합쳐서 작업할 것이라 생각합니다.

Once the artists merge the models, it becomes much more difficult to edit. For example, if an artist wanted to widen the cart, they would want to stretch the axel and the cart, but not the wheels or the spokes. If you forced them to collapse the model they can no longer do that easily.

디자이너들이 한번 모델을 합치면 이후로는 수정 작업이 매우 어려워 집니다. 예를 들어 디자이너가 바퀴와 스포크를 제외하고 카트 몸체와 엑셀만 크기를 늘리고 싶어하는 경우 말입니다. 만약 디자이너들에게 모델을 모두 정리 합치라고 강요한다면 이러한 작업을 더이상 쉽게 할 수 없을 것입니다.

"Making your tools support the way that artists work" means letting the artists leave their models in the state best suited for them to edit it to perfection, not the easiest state for a tools coder to export. If your exporter has a way to specify: "From this node down in the hierarchy, merge all children into one model", you'll allow your artists to leave their art in the best state for editing, and still get optimal models for the game.

"디자이너들의 작업을 도울 수 있는 툴을 만드십시오." 라는 말은 프로그래머들에게 익스포트 하기 쉽게 만들라는 것이 아니라 디자이너들이 작업하는 모델을 쉽게 수정할 수 있는 최고의 상태로 남겨두는 것을 의미 합니다. 여러분의 익스포터가 "이 노드 아래의 모든 노드를 하나의 모델로 합친다" 는 식의 기능을 지원한다면 디자이너들은 수정하기 쉬운 형태의 작업물을 남겨두면서 게임에 최적화된 모델을 얻어 낼 수 있을 것입니다.


'''- Don't use the hidden or frozen attribute to filter the export.'''

'''- 숨김이나 고정 속성을 필터로 사용하지 마십시오.'''

Going back to "Make your tools bullet proof", your exporter shouldn't care if something is marked as hidden or frozen. That's because your specification says what to export, regardless of whether a particular item is hidden or frozen. Like above, your artists may have hidden something to make the model easier to edit, and then saved the file. The next time the file is exported, the code should still be exporting everything required and not exporting extraneous items. Otherwise, you are going to run into time-consuming debug problems, next time you load up your level.

"여러분의 툴을 "방탄 조끼" 로 만드십시오" 에 따르자면 아이템이 숨겨졌던 고정되어있던 무조건 익스포트 한다고 명세를 통해 알리고 숨기거나 고정해둔 정보를 사용해서는 안됩니다. 디자이너들은 작업을 좀더 쉽게 하기 위해 모델을 감춰둘수도 있으며 그 상태로 파일을 저장할 수도 있습니다. 이후에 그 데이타가 익스포트를 시도할때 코드는 이전과 마찬가지로 필요한걸 익스포트 하고 외부 아이템은 익스포트 하지 않아야 합니다. 그렇지 않다면 문제를 찾기 위해 시간을 소모하게 될 것입니다.


'''- Don't export function curves!'''

'''- 펑션 커브를 익스포트 하지 마십시오!'''

I've seen many exporters that pull function curves directly out of the 3D package. The documentation for the exporter then goes on to tell the user that, because of this *feature* the artists are only allowed to use certain kinds of animations. Does anybody see a problem here? All the interesting animation functions require features not supported by function curves. Probably the most important one is constraints. Constraints are incompatible with exporting function curves, as are expressions.

3D 데이타에 펑션 커브를 그대로 담아내는 많은 익스포터들을 보았습니다. 때문에 문서를 통해 작업자들에게 특정 애니메이션 기능을 사용하기 위해서는 펑션 커브를 사용해야만 한다고 강요하곤 합니다. 여기서의 문제점이 무엇인지 아시겠습니까? 괜찮은 애니메이션 기능들은 펑션 커브의 지원이 필요 없습니다. 아마 가장 중요한 것은 구속 조건일 것입니다. 구속 조건은 펑션 커브와 같이 익스포트 시에는 표현이 제대로 이루어지지 않습니다.

Following the "Make your tools support the way artists work" philosophy, a much better solution is to sample the output of the package in question. You can then write some curve fitting functions, if you happen to want to use function curves to compress your data. This way, your artists are free to use every tool at their disposal to make great animation, and you'll still be able to compress their results to something reasonable.

"디자이너들의 작업을 도울 수 있는 툴을 만드십시오" 라는 철학에 따라 더 좋은 해결 방법은 결과물의 샘플을 보여주는 것입니다. 이렇게 함으로써 펑션 커브를 데이타를 압축하는데 필요하게 되었을때 활용할 수 있을 것입니다. 이 방법을 통해 작업자들은 애니메이션 작업을 하는데 있어 자유롭게 툴의 모든 기능들을 사용할 수 있을것이며 여러분은 그 결과물을 조금 더 나은 형태로 저장할 수 있게 될 것입니다.


'''- Don't ever consider editing a middle file format.'''

'''- 중간 단계 파일 포맷의 수정은 절대로 고려하지 마십시오.'''

Middle file formats are a great idea. They allow you to separate your processing tools from your exporters, and also make it possible to use different 3D packages on the same project.

중간 단계 파일 포맷은 훌륭한 아이디어 입니다. 중간 단계 파일 포맷을 통해 여러분은 익스포터에서 작업 단계를 구분하게 할 수 있으며 프로젝트 내에서 다른 형태의 포맷으로 바꿀 수도 있습니다.

'''두개의 오브젝트에 에러가 발생했으며, 소파는 경고 수준의 객체 입니다.'''


However, middle file formats should really be treated just like .obj or .o files in a compiled language. They are files that the build process makes that are temporary files, never to be touched by human hands. The reason? Obviously, if any changes need to be made to the 3D data, it's going to be made by the artists back in the original 3D package. Any changes applied to the middle format are going to be lost when the artist re-exports the new model.

하지만 중간 단계 파일 포맷은 반드시 컴파일 언어에서 .obj 나 .o 파일 처럼 다루어져야만 합니다. 이들 파일은 빌드 공정에서 생기는 임시 파일일뿐 결코 직접 수정되는 일은 없습니다. 이유는 명확합니다. 3D 데이타에 수정이 필요하다면 작업자들이 가지고 있는 원본 3D 데이타에서 이루어져야 합니다. 중간 단계 파일 포맷에서 이루어진 수정 사항은 이후 재차 익스포트시에 없어질 것이기 때문입니다.

This goes back to the goal of your tools being to help your artists make great art. If your processes involve editing the middle file formats, and that editing is lost every time your artists edit an original 3D source file, you are forcing someone to waste time manually re-tweaking the new middle file. You've just given them an incentive to not want to edit things to be better.

작업자들이 굉장한 결과물을 만들 수 있게 만들자는 여러분의 본래 취지로 돌아가도록 하죠. 만약 작업 공정에서 중간 단계 파일 포맷을 수정하는 것이 허용되고 작업자들이 원본 3D 파일을 수정할때마다 수정 사항이 손실 된다면 누군가는 매번 시간을 낭비하게 될 것입니다. 단지 작업자들에게 수정하지 않는게 좋을것 같다고 말하십시오.


'''- Don't needlessly limit the possible applications of your exporter.'''

'''- 여러분의 익스포터에서 가능한 기능을 제한하지 마십시오.'''

Design your exporter to handle as many cases as possible. To give you a concrete example, I once worked with an exporter that required the artists to manually export a "bind pose" for skinned characters. That one idea removed any possibility of using that exporter to export full real-time 3D cut-scenes, since a cut-scene would never have all the characters in a bind pose state. Instead, the exporter should lookup the bind pose automatically.

여러분의 익스포터가 되도록 많은 경우를 조작할 수 있도록 설계하십시오. 좀 더 구체적인 예를 들어보자면 저는 언젠가 스키닝 캐릭터에서 "bind pose" 만을 수동으로 익스포트 하는 익스포터를 요청을 통해 작업한 적이 있습니다. 이 한가지 아이디어로 인해 모든 캐릭터가 바인드 포즈 상태일리는 없으니 3D 리얼타임 컷씬을 통째로 익스포팅 할 수 있는 가능성이 사라졌습니다.

In Maya at least, there are 2 bind poses. There's one that Maya calls the "bind pose", and the one it actually uses. You want your exporter to use the one Maya actually uses, because the one it calls the "bind pose" is deletable and trust me, your artists will delete it. Why put them through the frustration of having to do their art over? Just make your exporter handle it in the first place. 

''!!!''마야에는 2개의 바인드 포즈가 있습니다. 하나는 "bind pose" 라 부르며 실제로 사용됩니다. "bind pose" 라 불리는 그것은 삭제가 가능하고 디자이너들이 그것을 지울 것이기 때문에 여러분은 마야를 사용하길 원할 수도 있습니다. 왜 디자이너들은 그래픽적인 아닌 일로 괴롭히는 거죠? 그냥 여러분의 익스포터에서 처음에 컨트롤 하도록 하십시오.

Another example of this would be limiting your exporter to only exporting one item at a time. That limit would provent you from exporting multiple characters or multiple animations. If you removed that limit, your artists would be able to make real time cut-scenes with a single click export process, as well as make it easy for artists to animate throws and other multiple-character animations.

또다른 예를 들어보자면 아마 여러분의 익스포터는 한번에 한가지만 익스포트 할 수 있게 되어 있을 것입니다. 이 제약은 동시에 여러 캐릭터나 여러 애니메이션을 익스포트 할 수 없게 됩니다. 만약 이 제약을 제거 한다면 디자이너들은 단순한 익스포터 작업으로 리얼타임 컷씬을 만들수 있게 될 뿐만 아니라 던지는 애니메이션이나 동시에 여러 캐릭터의 모션을 설정할 수 있게 될 것입니다.


'''- Don't create or load bad data.'''

'''- 잘못된 데이타를 생성하거나 부르지 마십시오.'''

Your exporters should never create bad data, and your engine, previewer and tools should never load bad data. Obviously, if you have bugs in either, you might get bad data, but often there are other issues at play.

익스포터에서는 절대로 잘못된 데이타를 만들지 말고, 엔진과 프리뷰어, 툴에서는 잘못된 데이타를 절대로 불러들이지 마십시오. 만약 어느 한쪽에라도 문제가 있다면 잘못된 데이타가 생성될테고 어디에서든 자주 문제가 발생하게 될 것입니다.

I put version numbers in all my data files to support the idea of making your tools bullet proof. This is done so that the art previewer and game code can check if they understand a certain type of file, and print an error on the screen if the version is out of date. The alternative is that your game loads the data, then crashes without showing a specific error, and you spend hours trying to figure out why.

저는 툴을 방탄 조끼로 만들라는 생각으로 제 모든 데이타 파일에 버젼을 넣어둡니다. 이렇게 함으로써 프리뷰어나 게임 코드상에서 파일의 정확한 형식을 알 수 있게 되며 만약 버젼이 유효하지 않다면 에러를 출력합니다. 무엇보다도 중요한것은 게임에서 데이타를 부를때 프로그램이 죽거나 하지 않고 에러를 보여줘야 한다는 것입니다. 그렇지 않다면 여러분은 이유를 찾기 위해 매번 시간을 낭비하게 될 것입니다.

There are other various ways to handle this issue. For example, at one company I worked at, the version numbers were used as part of the load path. So, for example, a version 2.1 character might come from "\gamedata\2.1\characters", where as code that needed 2.3 version characters would load them from "\gamedata\2.3\characters". Based on their version, all the tools knew where to put their results. 

이 문제를 다루기 위한 몇가지 방법들이 있습니다. 예전 제가 일하던 한 회사에서는 버젼을 로딩 경로의 일부로 사용했습니다. 예를들어 2.1 버젼의 캐릭터는 "\gamedata\2.1\characters" 에서 불러오며, 만약 2.3 버젼의 캐릭터가 필요해지면 "\gamedata\2.3\characters" 에서 불러오게 됩니다. 각 데이타의 버젼을 기반으로 해서 모든 툴은 결과물을 어디에 저장해야할지 결정하게 됩니다.

This method had the advantage that people using older versions of the code still had access to data that worked with their version. In turn, people using or working on newer tools and newer versions could safely build new assets, and not worry about breaking everyone. Personally I'd probably use both ideas just to be safe. But, however you do it, a similar approach will save everybody time not tracking down version issues.

이 방법은 사람들이 예전 버젼으로 데이타를 다룰 일이 있거나 할때 매우 유용합니다. 또한 새로운 툴과 새로운 버젼으로 안전하게 새로운 작업을 할 수 있으며 무엇인가 손상될 걱정을 하지 않을 수 있게 됩니다. 개인적으로도 이 두가지 아이디어는 매우 안전하다고 생각합니다. 하지만 만약 여러분이 이 아이디어를 채용한다면 

In my version numbers, I have option bits - for example, a bit that says if the file is the kind of file with error information or not. I mentioned above that putting error info in the file is a good idea for development. But in the shipping product, that code and that data is a waste, so I compile it out. But I still have the code check for a version number, and that includes whether the file is a development file or a release file. Otherwise, during final bug testing it's likely that a development file is going to get accidentally used during testing. Without the check and corresponding error, there are going to be hours spent tracking down the cause of the crash.

저는 버젼 정보에 옵션 정보도 포함해 둡니다. 예를들어 정보에 파일에 앞서 좋은 아이디어라고 언급했던 에러 정보가 있는지 그렇지 않은지와 같은 정보를 표시해둡니다. 하지만 발매 버젼에서는 이 코드와 데이타는 낭비가 되므로 제거해버립니다. 그래도 버젼 정보를 확인하는 코드만은 남겨두어 파일이 개발 버젼인지 릴리즈 버젼이던지 간에 확인합니다. 그렇지 않다면 최종 버그 테스트 도중 개발 버젼 파일이 사용되어 아무런 확인이나 에러 출력없이 많은 시간을 낭비하게 될 문제를 일으킬 수 있으니까 말이죠.


'''- Don't require manual exporting.'''

'''- 익스포트시에 수작업을 요구하지 마십시오.'''

Manual exporting breaks the advice of the one-step build. I can't believe how many teams put up with manually exporting things - it should be possible to type "make", and have all your 3D assets reprocessed from original Max/Maya/Lightwave files into the data for your game.

수작업으로 이루어지는 익스포트는 일괄 빌드 공정에 대한 어드바이스를 무시하는 것입니다. 굉장히 많은 팀들이 수작업으로 익스포팅을 하고 있습니다. - 이것은 반드시 "제작" 으로 간주되어야 하며 모든 3D 데이타들은 원본 Max/Maya/Lightwave 파일로 부터 게임에 사용될 데이타로 재가공되어야 합니다.

What happens when you don't do this? Every time you make a change to your 3D format, your artists have to manually re-export everything. When you start a new platform again, everything will have to be manually re-exported.

이렇게 하지 않으면 무슨일이 발생할까요? 여러분이 3D 포맷을 바꿀때마다 디자이너들은 모든 데이타를 수작업으로 다시 익스포트 해야만 합니다. 만약 여러분이 새로운 플랫폼에서 작업하게 된다면 수작업으로 다시 익스포트 해야만 합니다.

Yes, of course, for a previewer function you'll want a "preview" option that will export the data and pop it into your previewer. But when the data actually exports into the game, you want exporting to happen automatically every time you ask it to rebuild your data.

네 물론 익스포트될 데이타를 여러분의 프리뷰어에 띄워보기 원할수도 있습니다. 하지만 실제로 게임에 사용될 데이타라면 여러분은 데이타를 다시 만들때마다 자동으로 익스포트 되길 바랄 것입니다.


==3D 익스포터를 위한 자동 일괄 작업==

Following the "Make the tool, not the artist, do the non-artistic work", once you've solved the items above, it should be a relatively simple matter to make automatic exporting part of your build process. For Maya, you can use Mayabatch. You can pass Mayabatch a script that your build process creates to load and export a file. For 3D Studio Max, you can do the same with 
Maxscript by having your build process create a script to load a file, export it and exit Max.

"디자이너들이 그래픽적 업무 외의 일을 하도록 만들지 마십시오" 에 따라 여러분은 위의 문제를 해결 할 수 있습니다. 여러분의 작업 공정에 자동 익스포트를 과정을 넣는다면 상대적으로 쉬운 문제가 될 것입니다. 마야에서는 Mayabatch 를 사용할 수 있습니다. Mayabatch 스크립트를 사용 함으로써 여러분의 빌드 공정 중에 익스포트 파일을 만들고 불러들일 수 있을 것입니다. 3D Max 에서는 Maxscript 로 파일을 부르고 익스포트하고서 맥스를 종료시키는 똑같은 작업을 할 수 있습니다.

Another added benefit of not requiring manual exporting is that your artists will never wonder which Maya/Max/Lightwave file they need to load up, in order to edit an asset. The file they need to load will be the file that's in the build.

수동 작업이 필요 없어질 경우의 또 다른 장점은 디자이너들이 수정 작업을 위해 Maya/Max/Lightwave 파일을 로드할 필요가 없다는 것입니다. ''!!!''그들이 원하는 파일은 작업 공정에 의해 자동으로 처리 될 것입니다.

However, I'm not suggesting there should be no way to manually export. I'm merely suggesting that your tools should be able to build in one step. Your process should facilitate matters, so that if you need to rebuild something, there are no manual steps required. If you need the ogre model rebuilt, you should be able to say something like "rebuild ogre". The alternative is to hunt down the one artist in your company that worked on the ogre, knows which of 45 files named ogre_23.max, ogre26.max, ogre25b.max, ogre-test3.max, and so on need to be loaded, and then where and how to export it. This is not a very appealing process.

하지만 수동 익스포트가 없어야만 한다는 이야기는 아닙니다. 단지 여러분의 익스포터에서 일괄 빌드도 지원해야 한다고 말하고 있는 것입니다. 여러분의 공정을 간단히 만들어 두면 재작업이 필요할 때에 수작업이 필요치 않게 될 것입니다. 만약 여러분이 오우거 모델의 재작업이 필요할때 여러분은 단지 "오우거 재작업" 이라고 말하기만 하면 됩니다만 ogre_23.max, ogre26.max, ogre25b.max ogre-test3.max 와 같은 이름들의 약 45개의 파일중에서 어떤 것을 로드해야 하고 어떻게 익스포트 해야 하는지 알고 있는 회사의 오우거 담당 디자이너를 궁지로 몰아넣는 일입니다. 이것은 절대 매력적인 작업이 아닙니다.

For example, in a recent project, we used some 3rd party tools that didn't follow this advice. We had a character with eight animations. As I was programming, there were several times I had to ask my artist to add a few nodes to the character's hierarchy. Because the system didn't support a one-time build solution, each time he edited the character, he had to hand export the model, and hand export each of the eight animations. This included editing several exporter settings before each export. If the exporter had been designed better, he might need to only press one button to get all nine files exported, after having done it the first time.

예를 한가지 들자면 근래의 프로젝트에서 저희는 이 충고를 따르지 않는 써드 파티 툴을 사용했습니다. 8개의 모션을 사용하는 캐릭터가 있었고 저는 간혹 프로그래밍을 하면서 디자이너의 뼈대에 몇개의 노드를 추가해달라고 부탁하곤 했습니댜. 시스템 차원에서 일괄 빌드 공정을 지원하지 않았기 때문에 매번 그는 캐릭터를 수정하고서 모델을 익스포트 할때마다 8개의 모션을 일일이 익스포트 해야만 했습니다. 또한 익스포트 할때마다 여러가지 옵션도 수정해야만 했습니다. 만약 익스포터가 좀 더 나은 형태로 되어있었다면 그는 버튼 하나를 누름으로써 9개의 처음 설정했던대로 모든 파일을 한번에 익스포트 할 수 있었을 것입니다.

In this case, the multi-stage export is still not the end of the story. The artist had to then take each of the nine exported files and copy them to the correct places in the build. If the tool truly supported a one-step build, that entire ten minute manual labor error prone process would have been reduced to saving the file and saying "done!".

이런 여러가지를 동시에 익스포트 하는 경우에 대해서 아직 이야기가 남아 있습니다. 디자이너들은 9개의 익스포트된 파일들을 일일이 그 파일들이 있어야 할 장소로 옮겨야 합니다. 만약 툴이 일괄 빌드 공정을 지원한다면 전체 10분 가량의 에러 발생 가능성이 있는 작업을 파일을 저장하고서 "작업이 완료되었습니다!" 라고 말해주는 것으로 대체 할 수 있습니다.


'''하나의 파일에서 여러개의 캐릭터와 모션을 한꺼번에 설정합니다.'''

 
There are levels or stages of one-step building. Sometimes, you want an immediate export-like function to iteratively edit an object being used in the current level. Other times, you want to click one button or type one string, and have a particular object or level and all its updated assets re-exported and reprocessed. Other times, you want all of it re-exported and reprocessed from scratch. Or possibly, you might want to rebuild the entire game. Your tools should support all of the above. If your exporter just supports manual exporting, only the first option is available to you. If your exporter is based initially on automated exporting, all the other options are just simple interface issues.

일괄 빌드 공정으로 레벨이나 스테이지에서도 가능합니다. 간혹 여러분은 현재 레벨에서 사용되는 오브젝트들을 수정하고 다시 익스포트하기를 바랄수도 있습니다. 또 어떤 때에는 한번의 버튼 클릭이나 한 문장으로 특정 오브젝트나 레벨등을 모두 업데이트 하고 다시 익스포트 하길 바랄수도 있을 것입니다. 또는 데이타에 손상이 발생했을때 다시 익스포트 하길 원할수도 있을 것입니다. 혹은 게임 전체를 업데이트 하길 원할 수도 있을 것입니다. 부디 여러분의 툴은 이 모든 것들을 지원하십시오. 만약 여러분의 익스포터가 수작업 만을 지원하고 옵션은 여러분만 사용 가능한 것이 될것지만 만약 익스포터가 자동 작업에 기반하고 있다면 다른 모든 옵션들은 단순한 인터페이스적 차원의 문제가 될것입니다.


==명세 정보는 익스포트와 구분해서==

Some people will read the above ideas and believe what I'm suggesting is a system that uses a specification file, as opposed to a WYSIWYG system, but please don't make that mistake. In other words, some imagine some ugly non artist-friendly text file that specifies what and how to export stuff, versus the common method of exporting that you currently see in the 3D package. Although the ideas above require a specification, that doesn't mean making the spec couldn't be WYSIWYG. 

어떤 분들은 위의 아이디어를 읽고 제가 제안하는 명세 파일 시스템이 WYSIWYG 에 반대 되는 것이라고 생각할 수 있습니다만 그렇게 생각하지 말아주십시오. 무엇을 어떻게 익스포트 해야 하는지에 대한 내용을 디자이너들에게 익숙하지 못한 텍스트 파일로 만드는 것은 보기 안 좋을수도 있지만 일반적인 3D 익스포터들과 비교하여 생각해 보십시오. 비록 명세 정보가 필요하지만 이것은 WYSIWYG 로 만들지 말라는 이야기는 아닙니다.

For example you could make a plug-in for your favorite 3D software that looked at the current scene, what's visible and what's not, and generated a specification file for the exporter system. This would essentially give you the same functionality as a normal no-specification file system, but it would have all the advantages above plus more. 

예를들어 여러분이 사용하는 3D 소프트웨어에 무엇이 보이고 무엇이 보이지 않는지 현재의 장면을 볼 수 있는 플러그인을 만들고서 익스포트 시스템을 위한 명세 파일을 만들 수도 있습니다. 이것은 본질적으로 명세 파일을 사용하지 않는 시스템과 똑같습니다만 더 많은 장점들을 가지고 있습니다.

For example, with a specification-centered file system, you can have multiple characters per 3D file, and extract each character separately. That would be useful for genres like fighting games, where there are animations and moves that combine two or more players and complex movies such as throws. The artists would find it hugely beneficial to be able to keep both characters in one file, and animate them together.

이 명세 파일 시스템 에는 한번에 여러개의 캐릭터를 넣을수도 있으며 하나씩 구분해서 넣을 수도 있습니다. 이것은 둘 혹은 그 이상 캐릭터들의 동작이나 움직임을 포함시키거나 영화처럼 섞을 수 있으므로 격투 게임 같은 장르에 매우 유용합니다. 디자이너들은 하나의 파일에 캐릭터들을 유지할 수 있고 함께 애니메이션 시킬 수 됨으로써 굉장한 장점을 얻을 수 있을 것입니다.

Another advantage is that using a specification file reduces the chance for human error in the build. Sure, the artist might forget to add something to the spec file if they add a new object in the scene. But the chance for that mistake happens only once, when they add something new or delete something. With a good preview system that will be known almost instantly. 

또 다른 장점은 작업 공정 중 발생할 수 있는 에러를 줄여줍니다. 물론 디자이너들이 오브젝트를 추가했을때 명세 파일에 무엇인가 기입하는 것을 잊어버릴 수도 있습니다만 실수가 발생할 수 있는 경우는 단지 무엇인가를 추가하거나 제거할때 한번 뿐입니다. 좋은 프리뷰 시스템이 있다면 이마저도 금방 찾아낼 수 있을것입니다.

In contrast, relying on a manual exporter system creates an opportunity for error every time a file is saved - i.e. every time an animation is tweaked, a texture remapped, a property edited, etc. So, not only is the spec file system more powerful ( allowing multiple animations, characters and other actions per file), but it drastically reduces the chances for errors. All the while, this doesn't restrict the artist from having other scaffolding in the file to help them do their job.

대조적으로 수작업 익스포트 시스템에 의존하면 파일을 세이브 할때마다 에러가 발생할 기회를 만드는 것이 됩니다 - 예를들어 애니메이션은 매번 틀어질것이며, 텍스춰는 다시 씌워지고, 속성은 수정되어 있겠죠. 그렇기 때문에 명세 파일 시스템이 좋은 것입니다 - 파일마다 다중 캐릭터, 모션을 사용 하는 것이 가능해지죠. 이것을 통해 에러가 발생할 여지를 철저히 줄일 수 있게 될것입니다. 어떤 경우에라도 이것은 디자이너들이 그들에 작업에 사용하는 다른 사항들을 제약하지는 않을 것입니다.

Separating the exporter from the specification file generator also gives you unlimited options regarding how to generate the spec. You could:

명세 파일 생성기는 익스포터와 구별해둔다면 사양을 어떻게 만들 것인지에 대해서는 아무런 제약을 받지 않게 될 것입니다.

* Have a "make a spec from what you can currently see" specification plug-in for your favorite 3D package.
* "현재 보이는 것으로 명세 정보를 만든다" 라는 기능의 플러그인을 3D 툴에 추가합니다.
* Make a spec system that specifies by layer what gets exported. Layer 1 could be background graphics, layer 2 could be A.I nodes, layer 3 could be lights, and so on.
* 명세 시스템은 익스포트 되는 것끼리 레이어로 구분한다. Layer 1 은 배경이 될 수 있을것이며, Layer 2 는 A.I 노드, 레이어 3 은 광원과 같은 것이 될것이다.
* Make a spec system that allows you to specify values for each joint per animation, and say whether or not that joint's animation data should be exported or not. This would make it easy to compress and apply secondary animations. 
* 명세 시스템이 각 애니메이션의 연결 시점의 값을 설정할 수 있도록 하고 그것을 구분으로 하여 익스포트할지 안할지 결정할 수 있도록 한다. 이것은 2차 모션을 압축할때 매우 유용하다.

If you make your specifications text or XML-based, you'll have the option to hand-create them when needed, on top of generating them like mentioned above. 

만약 명세 정보를 텍스트나 XML 로 작성한다면 앞서 언급한 최초의 생성시 수작업 수정도 가능할 것입니다.

In fact, although it can be a cop out, if you make a good exporters that export based on a specification, you can start with hand written specifications. Then, as your team has time and finds new issues to solve, you can make more and better specification generation and editing tools. Those tools could be any of the spec-making plug-ins mentioned above, or they could be Microsoft Infopath-based XML or a web-based editor with a list of each animation, starting and ending frames, and joints to include or exclude. The sky's the limit.

사실 만약 명세에 기반해 익스포트 하는 좋은 익스포터를 만들고 싶다면 여러분은 일일이 손으로 명세를 작성하는 것에서부터 시작하는 것이 좋습니다. 이렇게 함으로써 팀에서는 해결해야 할 새로운 사항들을 발견하게 되며 여러분은 좀 더 명세 생성 시스템을 개선하고 툴을 개선할 수 있게 될 것입니다. 이 툴은 모션의 시작과 끝 프레임의 리스트를 표시하게 되며 앞서 언급했던 사양 제작 플러그인이 될 수도 있으며 MS 의 Infopath-based XML 또는 웹기반 에디터가 될 수도 있습니다.

There's another advantage in solving all of the above issues - the ability to allow the artist to create 3D cut-scenes completely in their favorite 3D package. There's no more having to edit the camera in-game, or assemble all the parts (characters, backgrounds, camera motion, character animations) separately, They can just make the perfect cut-scene using all the features of the 3D package. Then using a spec, either automatically or hand generated, all the required parts can be automatically exported and run through your tool-chain to get into the game.

디자이너들이 3D 컷씬을 만듦에 있어 또 하나의 장점이 있습니다. 더이상 게임에서 카메라를 수정하거나 각 부분들(캐릭터, 배경, 카메라 움직임, 캐릭터 애니메이션)을 조립할 필요가 없다는 것입니다. 디자이너들은 각 부분에 모든 기능들을 사용하여 완벽한 컷씬을 만들 수 있을것입니다. 그리고 자동으로 혹은 수동으로 작성한 명세 정보를 이용하여 자동으로 익스포트하고 게임에서 돌려볼 수 있게 될 것입니다.

You can even merge specs as well. You could pass the tools multiple specs, and they would load all the items referenced by the various specs, export them, and process them into a single bundle of data for loading. This is a great way to bundle together related data that is best edited separately.

또한 명세 정보를 합치는 것도 가능합니다. 툴에 다중 명세 정보를 넣고 관계된 모든 아이템들을 로드하고 익스포트하여 로딩을 위한 하나의 묶음으로 만들어 둘수도 있습니다. 이것은 연관된 데이타를 각자 수정하고 한꺼번에 묶어둘수 있는 굉장한 아이디어 입니다.


결론 : 행복한 아티스트들이 더 멋진 게임을 만듭니다!



I hope this article has pointed out why it's important to design your tools with a philosophy in mind. My impression is that most tools are designed by a programmer, for a programmer, to supply data for other programmers. Therefore, the work flow of the person who is going to use the tools is not carefully considered. Nor are possible ways to avoid errors. Game library code writers are often some of the worst offenders, not because they are not smart, but because their sole goal in writing an exporter is generally to make some test data for their library. No thought is given to using the tool outside of that one small case. I think most tools would benefit from taking these kinds of ideas and philosophies into consideration during their design.

이 글을 통해 저는 왜 철학을 가지고 툴을 디자인하는 것이 중요한지 전하고 싶었습니다. 저는 대부분의 툴이 프로그래머에 의해, 프로그래머를 위해, 다른 프로그래머를 지원하는 데이타를 만들기 위해 디자인된다고 느꼈습니다. 그로인해 실제로 툴을 이용하는 사람의 작업 과정이 고려되지 않습니다. 뿐만 아니라 에러를 피하는 방법도 고려되지 않습니다. 게임 라이브러리를 작성하는 사람들은 대부분 최악의 제공자들입니다. 그들이 뛰어나지 않아서가 아니라 그들의 목표가 라이브러리의 테스트 데이타를 만들기 위해 익스포터를 만들기 때문입니다. 자신 외의 사람들이 툴을 사용하는 경우에 대한 배려가 없습니다. 툴을 설계하는데 있어서 이와 같은 아이디어와 철학을 고려하면서 설계를 해 나간다면 분명히 많은 도움이 되리라 생각합니다.

While some of these ideas might be more work than the simpler solution you are living with now, it only takes one programmer to implement a better solution. The solution will effect, help and benefit 10 to 150 artists, which will more than pay for itself over the course of the project.

이 아이디어들은 여러분이 사용하고 있는 간단한 작업 방식들 보다는 훨씬 나을 것이며, 단지 한사람의 프로그래머에 의해 구현되는 것입니다만 이 작업 방식이 10명에서 150명의 디자이너들에게 영향을 미치고 편의를 제공한다면 프로젝트 전반에 걸쳐 더 많은 이익을 가져다 줄것입니다.

In the end, the more you help your artists, the better job they will be able to do. That's not only going to mean better art and more sales, but it will mean less stress for you and maybe even some compliments from your fellow artists. What, compliments to a programmer from an artist? I bet you thought it was impossible!

마지막으로, 조금 더 디자이너들을 돕는다면 그들은 더 나은 작업을 해낼수 있을 것입니다. 그것은 단지 조금 더 나은 결과물이나 조금 더 많이 팔리기 위해서만은 아닙니다. 하지만 여러분은 더 적은 스트레스를 받게 될 것이며 디자이너들은 여러분에게 감사해 할 것입니다. 디자이너가 프로그래머에게 감사한다? 저는 여러분이 그게 불가능하다고 생각하고 있으리라는데 걸겠습니다.




감사의 말씀


I wanted to thank all the people that helped me with this article. This includes personnel from Atari, Inxile, Humongous, Naughty Dog, Electronic Arts, Capcom, Sony, and Activision.

이 글과 관련하여 저를 도와준 모든 사람들에게 감사를 전하고 싶습니다. Atari, Inxile, Humongous, Naughty Dog, Eelectronic Arts, Capcom, Sony, 그리고 Activision 의 직원분들께도 감사드립니다.


번역문 정보

  • 초벌번역: 김민규
  • 재벌번역: 포프
  • 감수: ?

현재상태

  • 초벌번역완료 (2005년)



Comments