Lessons Learned: Essays and Contest Winner

Here are all the entries from all who entered the contest. I enjoy running contests like this, that give something to the larger community- I am sure people will learn lots from reading these essays. Thanks to all who entered!

[fieldset]

Working in the Service Sector
[anchor]bronwen[/anchor]
This opinion piece is a response to the second contest on tech-artists.org. The brief: describe the most important thing you’ve learned as a technical artist. This job is so full of challenges and lessons it’s hard to choose just one lesson – problem solving, communication skills, patience, perseverance, multi-tasking, and the ability to keep an open mind are all important attributes. So, rather than focusing on how we do the job, I’d like to talk about who we do it for. After all, fundamentally, this is a service industry.

Technical artists are enablers. Although many of us are talented artists and/or programmers in our own right, very little of our work reaches the end consumer. We’re around to make sure that artists can produce their best work possible within the constraints of the target medium. I’ve learned a convenient bit of jargon at Valve that helped me look at my role in a new light. Anyone who uses a tool you’ve created is called your “customer.” The most important thing I’ve learned as a technical artist can essentially be summed up: the customer is always right.

For six years I worked at Pseudo Interactive, a game development studio in Toronto, Canada. I’d like to describe the lessons I learned from Pseudo’s rollout of a new tool called BRISE. BRISE was a node-based shader editor (similar to ShaderFX, though not DCC-software specific). In French, “brise” means break, signifying that this tool was a break from our old system.

Boy, was it ever.

Our old system was flag-based, inflexible, and thoroughly entrenched. The new tool was completely open-ended. My task was to introduce entirely new concepts to the art team and get them productive again within a short time frame. As the development of the tool progressed, I had been documenting it and writing tutorials. I used the tutorials as a lesson plan, and took the artists through eight 3-hour classes. This brings me to the first lesson I learned in this process.

Communicate with the art team, not at them.
Anyone who has done training in the course of their jobs can sympathize here – I had a stressed team, a short timeframe, a complex tool, and a series of lessons on a projector. The temptation was to read from the screen just to get through it. After all, my job is to write tools and shaders. I’m not a teacher, right?

Dead wrong. The tool is useless without users. I had to force myself to ask questions, high-school teacher style, and use more examples than I’d actually prepared and documented. Some people got it quickly, more quickly even than I’d anticipated. Some lagged. I told myself this was normal. Not everyone would be an expert user. I’d focus my time later, one-on-one, on those I picked out to be shader-writing prodigies.

Everyone needed a base level of competency, though. If they weren’t to write shaders, they at least had to be able to use ones created by their teammates. One of the artists I was working with repeatedly failed to grasp a crucial concept – even to the point of becoming argumentative. I tried phrasing the concept different ways but couldn’t get the point across. Finally, as a last resort, I drew a simple diagram, an inverted pyramid. He responded immediately, “Oh, I get it. I’m a visual learner, you know.”

He wasn’t the only one who had an epiphany. In retrospect it seems obvious that an artist would be a visual learner. I had been trying to communicate in the way that I learn best instead of trying to understand how he sees things.

Put yourself in the artist’s shoes
I’d had a difficult time, initially, convincing the production team and company owners that BRISE was a good investment. I’d be the only one able to use it, they argued. All my time would be taken up writing shaders, and I’d be under a lot of pressure to support the entire team. The current system was understood and useable by everyone, so why change?

I was determined that the artists could learn the system. Give them the power, I argued back, and they will do amazing things with it. Although I still maintain this as a basic tenet of my professional philosophy, I allowed my conviction to blind me. I structured not just the lessons themselves but the entire lesson plan in a way that made most sense to me – as a tool manual for creating shaders. How do you connect nodes? How do you make a basic diffuse shader? I wanted to turn out more shader writers.

I had failed to ask myself the most basic of questions. What does the artist want to accomplish with this tool? I’d answered with what I wanted to accomplish: writing shaders that support the art director’s vision. But is that what the typical artist wanted to do, day to day?

The first thing our art team wanted to do was apply a generic shader that lets them see their objects rendering in-game. This is how I should have started my tutorials. Instead, it was the last lesson. The artists ended the tutorial sessions weary and over-challenged. We didn’t get to the part that was most relevant to them until the very end. If I’d placed myself in their shoes, I could have better seen how this tool fit into the overall pipeline, and approached the tutorials from a top-down perspective, instead of from ground-up.

This was a really tough lesson for me to learn. Like many technical artists, I started out as an artist who could script. For several years in my career, this was how I worked: see a problem, fix it for myself, and clean it up for the team. Being your own “customer” makes tool writing really easy. Putting yourself in someone else’s shoes is a challenge.

Convince them the payoff is worth the pain
Artists want to solve visual problems. That, correctly, is where the majority of their brain-power goes. They don’t want to spend time thinking about how to make a tool do what they want. They want to think about mood, style, and composition.

They especially don’t want to try something that takes them completely out of their comfort zone. When an artist is really familiar with a tool, using it is like using a pencil. The mechanics are automatic. Only the output is interesting to them. So convincing an artist to try a new tool can be difficult – it makes it much harder, initially, for them to reach their goal.

Even if I think a tool will make an artist more productive, I have to remind myself that any energy they put towards learning a new tool is energy they aren’t using to produce artwork. I ought to have considered my tutorials in the context of the pipeline. New tools must be considered in that context as well. Does the new addition take an artist out of a comfortable environment? How many applications have to be open for an artist to complete an asset? When switching between applications, how many opportunities are there for the content to break?

I started out by saying that the customer is always right. Obviously my statement is a bit simplistic. An artist can’t make a good decision about whether a tool is going to be helpful without enough relevant information. As a technical artist, sometimes you have to market new tools to your target audience. Showing them features and time-saving shortcuts will help motivate them. If you can’t convince the art team that the new tool will make them more productive, you may have to go back to the drawing board. Since they’re the ones doing the work, they’re in a good position to judge the value of a new addition.

I ought to take a moment here and clarify that I consider “more productive” not just to mean “make more stuff” but also “make better stuff, faster.”

BRISE fell into the category of “better stuff, faster.” It was pretty far outside the comfort zone of most of the artists, and was initially disappointing as a result. During the first week of training it looked to them like “mediocre stuff, slower.” As I mentioned before, the time frame for training was really short. We were in the process of building a small level which would be the nucleus for a larger game-play area, and the level was due in a few days. We managed to get it looking like it had in the old shader system within two days, which in itself was a success. Without a grand leap forward, though, it was hard for the team to see the possibilities inherent in the new system.

One of the core features of BRISE was referenced groups. I’d instructed the team on them, and made sure they were used religiously throughout all the shaders in the level. After discussing the visuals with the art lead and art director, I gathered the team around my desk to show them how one quick change could dramatically impact the whole level.

I opened the specular group node in one shader and added a new output – an “out of range” output that took over-bright values and passed them to what, in our engine, was termed the “radiance buffer” (essentially a glow pass). Switching back to the level editor, I enabled the model’s ability to write values to the radiance buffer, causing the specular highlights to bloom.

The art team gave some gratifying “oohs,” and started to divvy up who would change which shaders to have the same functionality. I had to interrupt them to remind them that the node I’d changed was referenced into all their shaders. With 10 seconds of work, the entire level’s look had been updated. They watched while I copied the write-to-radiance-buffer values to the whole level, and the whole team erupted into grins.

Speed, power, and the will to use it. Finally, success.

If only I’d shown them that first.

Conclusion
The process of rolling out a new tool is always fraught with challenges. As technical artists, we’re in the unique position of sharing our offices with the customers for our tools and pipelines. We’ve got the chance to react quickly to feedback at all stages of development. Keeping your ego out of the equation and really listening to your customers makes for truly great improvements and innovations in your pipeline. Our job is to free the artists as much as possible from the constraints and slowdowns of digital content-creation technology, so that they can focus on making a truly great product.
[legend]Winner: Bronwen Grimes[/legend][/fieldset]

[fieldset]

I was Technical Artist/Pipeline developer/Motionbuilder group lead on a MoCap project, and I was given assignment to fill an arena with thousands of characters.

First step was to reference 100 characters in Maya, position them around in a ring shape, and assign 7 different animations to them, randomly,
and whole process should be driven through a MEL script.

Where I got stuck was, after referencing and positioning, I had to import .anim files on each of them.
Now as importing animation data was taking horrible amount of time, there was no way Maya could hold up the scene after 20 or 23rd import, it would crash, for sure.

After 2 days of mindjob in cleaning unnecessary data,
there came a revelation: why not use Maya’s connections?

So the solution derived was import 7 .anim files one time, and then connect the anim nodes to as many characters in scene.

During this whole week of assignment, there were some issues with superiors, in terms of level of confidence and timeline, but what I learned was, just dont give up that soon.

What if you are just 99.98% done?
[legend]vishangshah[/legend][/fieldset]

[fieldset]

There are two things I’d like to talk about, the first one that thought us a great lesson is SCALE and the second one would be World-Up Axis.

Scaling, no matter how simple this may seem, is actually one of the biggest issues we’ve faced in our production pipeline. We’ve suffered not only
from our own mistakes, but also from supervisor’s decisions as well as interoperability issues in this regard with other studios we’ve worked with on the project.

The problem with scaling is that not many artists and especially supervisors, understand it. It’s not just making something smaller on the screen, as they think, there’s much, much more to that the artists don’t have a clue about. One of such examples is when you have a 2D tracked background with beautiful matte painting and you try to integrate your 3D objects in it, especially flying objects, like a helicopter, in our case. The problem is, you don’t have any reference point in the scene, so you can’t estimate where the object is, how big it is (aside from visual clues) or where it travels. The supervisor comes in and says: “right, cool, make it bigger at the beginning, but keep the end of the action, I like that”, the first thing the poor artist does is takes the scale tool and scales the heli up, keys the pose and continues with it.

Usually, artists are very hotheaded and all they care about is the final visual feedback they get from their actions. However, when they then pass on the scene to you to finalize the shot, add secondary animations or simply retarget the animation to a higher-res rig, you feel like you’re about to die or better yet, kill somebody! I’ve wasted so much time on shots with messed up scale I can’t even begin to count. My rough estimate would be about 20-30% of the shots were more or less suffering from this issue. The other scenario was the cooperation with US post houses as they tend to use royal units as opposed to our, European, metric units. So passing character anims onto them so that they can match up their character animation or simulation stuff, was also a pain as I had to constantly re-calculate and re-target our rigs. Thankfully there wasn’t too many shots that we had to do this way.

The last instance of such problems was a complete miss-match of scale in environments we had to produce. Specifically, there was a palace building, very tall, which played a key role in many shots, that had two different scales. The lower part of the palace was scaled up to regular human scale, but as the palace was tapering up to the sky, the upper part, the tip, of the palace, where a huge heliport was based, was extremely small in comparison to the lower part. This wasn’t an issue in overview or large shots where you saw the building in relationship to the other buildings or the whole scenery as the scale seemed right. However, some shots ware situated around the heliport and since the heliport was scaled about 33% down to the base in relationship to human scale, we had big trouble with shots where the helicopter I was talking about before, was traveling directly down the building, so, we either had to figure out how to scale the building smoothly when the camera was following the falling helicopter, or we had to figure out a way to scale the helicopter up to its original scale when it was falling down along the tall building. To make the scenario even more complicated, there was also a scene being acted out inside the helicopter with 5 digital actors in it that were visible through the windshield and other windows. Literally a hell-of-a shot. When you realize that the client, the director or the visual effects supervisor constantly change their minds about details in such shots, you can imagine that I almost killed somebody when working on a fifth iteration of this shot. The tip of the cake was the fact that I was also responsible for transferring the animation data among various software packages: I rigged all the characters/vehicles/props in 3ds Max. The simple, FK, rig was then used in MotionBuilder for the main animation. Then I imported the animation (well, in the better case) back in Max and applied all the fancy high-res rig features, like all the correct flesh deformations, cloth simulation, secondary animations etc… which I then had to export to either Maya (for RenderMan) or XSI (when rendering in MentalRay) depending on the character/vehicle/prop.

So, in the end, we fought through all the shots with great success, thankfully, but there was really a lot of wasted time that drained our fatigue and patience, which could have been avoided. So, the lessons learned from this are two, actually: 1) AVOID scaling as much as possible in your shots, especially non-uniform scaling of characters or more complex rigs. Uniform scaling of FK systems seems to work fine, however, don’t count on transferring such systems smoothly among various software packages! 2) If you really can’t avoid scaling, try to identify such issues ahead and design your rigs with this feature in mind so that you don’t scale your controls/systems, but instead “move” proportionally to an arbitrary point all of your controls. This works in many cases, but is very hard to setup and takes much more time than doing your rigs with fixed scale. Also, there are cases that you simply can’t construct a procedural rig as the system won’t allow for it. To my disfavor, I wasn’t able to determine such scenarios as the production was very hectic and we made a lot of mistakes at the beginning where instead of planning, we jumped in and tried to do it all the hard way. Secondly, even if I was able to identify such scenarios ahead of time, I wasn’t given the luxury of spending hundreds of hours on one rig. So, in the middle of production I wrote numerous scripts and tools that only I used just to “fix” such problems.

The second lesson we’ve learned that I’d like to share with you is the World-Up axis. 3ds Max is probably the only package that uses Z for it’s world Up axis in contrast to XSI, Maya, MotionBuilder or Cinema (the primary tools we’ve used on the show). So, even though Max might be the leading app. of these all in terms of number of users, the problem is interoperability. With all the trouble and such that we’d to go through as I described above, add constant transform matrices recalculations when you want to transfer something from/to 3ds Max. Thankfully there are functions etc… that can help you with that, and even if there weren’t any, writing your own algorithm for such a thing isn’t a big problem, but this one little thing adds to all the problems we’ve had. Especially if you have artists on board completely unaware of what a Matrix is! I didn’t bother explaining them all as there really wasn’t a point, they didn’t want to listen to you anyways :wink: all they care about is their art, which is all cool and fine and my responsibility (among other things) was to ensure smooth transaction of data from them to other artists. So, one example would be having your character fully rigged and prepared for animation import/export, but the animator decided to place the character’s Reference node in MotionBuilder under a null to better organize his scene. Seemingly innocent act, however, when you think about it, the default Matrix Up-Vector in Max is the Z axis, but, in MotionBuilder, the Up-Vector is the Y axis. So, when the artist created the beautiful, innocent and helpful null, placed it somewhere in the scene and rotated it and THEN parented the character’s Reference or Hips node to it, they, fully unaware, effectively rotated the character’s world Matrix. So, importing the animation back in Max resulted in a very surprising effect of characters flying through ground or walking up the Z axis etc… Easy to fix, but a little bit of a pain. The other example might be cameras, which was another big problem in the production we faced, but that’s a different story. We tracked everything in Boujou or SynthEyes, which then got exported out as a MaxScript file as the matchmove artists knew primarily 3ds Max. They then created simple layout scenes for the shots and saved them as FBX and MAX files when finalized. Then comes in and update, however, the art team has already had cameras distributed in their scenes in their respective software packages (Maya and XSI mainly). So, syncing up the guys with newly created cameras or when they accidentally moved the camera, or deleted animation on them etc… was also a little bit of a challenge. I decided that instead of handing out FBX files and make them all delete their old cameras and import new ones or hope they didn’t rename anything and just re-import animation from the FBX on the nodes, wasn’t a very good idea. So I wrote some tools that wrote the animation data off of the new cameras, wrote them in a MySQL database and them synced them back in XSI and Maya on a button click, turned out to be a better, faster, but mainly safer solution, thankfully. But this also required recalculating the Matrix from frame to frame. I once witnessed a 3ds Max artist trying to sync a camera with a Maya artist sitting close to each other. The camera was static, so they thought they didn’t need a TD to do so :wink: How surprised were they when after going through all the Translation and Rotation axes the camera in Maya was completely off.

So, the lesson learned here is simple, either don’t use 3ds Max or XSI together in a production environment. It’s very drastic and quite radical, but you’ll avoid a lot of problems arising from the missaligned
matrices. And the reason to skip Max or XSI is that Maya has the option to use either Y up or Z up axis, but neither Max, nor XSI (afaik) do.

I hope you’ve found this article at least funny if not useful in your production and will try to think about these issues way ahead of the production before you lay down the first null or bone in your rig, I certainly will! :wink:
[legend]loocas[/legend][/fieldset]

[fieldset]

During my training as a 3D artist, I stumbled upon an unsung profession in the industry. I was trained to become a feature animation rigger because of my fascination. Throughout my career as a student, in a class full of 3D modelers, I was able to hone my skills as a rigger. On top of that I enjoyed going to each of my classmates and helping them with Maya’s not so well known tools. I’ve even gotten as far to learn MEL and automate the rigging process itself.

Less than a month after I graduated I applied to several places. The first one to contact me back was Harmonix. I was intimidated from the company’s sterling record, however I was confident in the fact that I could rise up to any challenge.

What I found amusing was the rift between the coders and artists. I also realized that there was just one other person that could be considered a technical artist. It was actually a coder that took care of most of the implementation of new art tech.

Jumping into the fray, just weeks before crunch, I instantly melded in as the mediator between the two camps.

From my first few weeks in the company the most important thing I learned is that, as a tech artist, I needed to remain confident. I am dealing with artists that know very little about the technical side of our 3D package. On the other side of the spectrum, I am dealing with coders that are unaware of artists’ needs for simplicity in tools. By being confident in my own talents, I had to do a lot of running between both sides and maintaining an open line of clear communication, on top of my skinning and other tech-art based tasks.

I’d like to think that I was able to just come in, collect information, and deliver it in a straightforward and prompt manner allowed me to seize the initiative and help fill in a slot that the company never truly had. Trusting my own abilities became more important at that stage of my career.
[legend]chairmanleo[/legend][/fieldset]

[fieldset]

[anchor]erilaz[/anchor]As a generalist I’ve had to cover a lot of different tasks over the years, but I’ve always found that the simplest design is still the best. Not just from a technical perspective, but also an artistic one.
Like many technical people I often fell into the trap of over-thinking a problem. I still do from time to time, and it’s usually when the problem itself is not clear. I can’t remember who said it, but it was a turn of the phrase “If you can’t find the answer you haven’t asked the right questions”.

It may sound odd to take you back this far, but it changed my way of thinking forever.

Fifteen years ago when I was in Year 10 high school we had to solve a practical mathematical problem for our major assignment. Our job was to place a bike trail alongside a river using a series of equations that linked up together to form a continual path. I tried many types of equations to fit that river based on the dimensions. I tried trigonometrical curves, parabola, logs and so on (This was year 10, so I knew nothing about Bezier and so forth). After a week into frustrating and increasingly more complex ideas, I decided to ask the one person who would know the best solution: My father.
Dad is an electrical engineer, and so I thought if anyone had the smartest most mind-boggling solution it would be him. He sat down with me for 10 minutes as I showed him my numbers and drawings. He looked at my work, then looked back at the original question along with the drawing of the river and said something I’ll never forget:

“You’re over-thinking it.”

He then walked off for a bit while I stared at the question in confusion. How could I be over thinking it? Maths was about over-thinking!
I went over the drawing again with little avail. When he saw I was still struggling, he picked up a pencil and drew three curves. I say curves: One was a straight line. A straight bloody line! In my effort to find a neat set of equations I had completely forgotten about one of the most common graphical relationships there was!

It sounds naive looking back on it, but it’s true of a lot of problems. The simplest answer can be staring you in the face, but you often don’t consider it because it’s too easy. Dad’s simple words and simple line seriously changed my way of approaching thinking to this day.

I can honestly say the only time I’ve felt that “Wow, it’s so simple!” moment recently is when I watched Francois Levesque’s presentation from GDC this year. The way he used simple ideas to solve a complex problems was pure genius. I’m sure the implementation was a bit more complex, but the actual ideas were perfectly simple and a marvel to behold.
[legend]Erilaz[/legend][/fieldset]

[fieldset]

It is when we realize we don’t know everything that we learn the most. As an animator who works closely with the tech artists, I realized that we maximize productivity and efficiency when the relationship between tech an art is like consumer and producer.

Many times in the past I have worked with tech artists who created tools that may have been groundbreaking when it came to the cutting edge technology but weren’t as useful or were too complex to use. Then I have been lucky to have worked with others who understand the needs and tailor the tools to those needs.

Bottom line, if you work on an new tool, please make sure-

  1. It is needed and will be used
  2. Make it simple and friendly enough to use, we artists like things simple :slight_smile:
    [legend]mookman18[/legend][/fieldset]

[fieldset]

Wow… What a college question to ask and perhaps my next interview as well! It’s more interesting because until recently I never even realized I had a title. Technical Artist. I’ve written the backbone for a 3D animation company with over twenty artists and was never referred to in that sense. Usually I just joked, that I code because I can’t model! Honestly, I make a box like this “box()” For years, my mediocre video post tasks took precedence over writing scripts and integrating processes which would have saved the company so much more. Not until recently had the “management” realized that most of the things the artists where doing, they where doing faster with my tools. Then I got a full time position coding and a nice pay bump. Recently and just by chance, I met someone who utilizes the CG talk forums. He said he remembered my “Little Blue Egg Guy”, named Foco in case you wanted to know, from the first time he logged into CG talk in 2003. We discussed in detail some specifics of 3dsMax issues, general modeling, and of course scripting. After a short while, he started to recount my postings. The way a football fan recounts plays from a game. It was almost awkward, but he was just so jazzed to pick my brain and excited to hear about implementations I had made at our animation company. It made me realize that I’m a little bit of a rock star out there. In reality all of us are little rock stars ( some big than others ) and if you’re lucky you’ll get a line in the credits. Yeah it’s after the music credits and most of the audience has left. But if you force your children to stay and watch, you too can have your fleeting moment of fame! And then it’s back to the pit to solve yet another issue that autodesk won’t realize IS an issue for at least another two years.
Oh, I missed that on huh? There was suppose to be something about “important things learned…” Um… I guess that we’re all undervalued until you truly realize for yourself the value of what you do. I believe most of us do what we do because the problem is there and we have the ability to fix it, not because we think of our selfs as the innovators that we truly are…

( self pat on the back )
[legend]KramSurfer[/legend][/fieldset]

I’ll be getting in touch with Brownen in a day or two and in a couple weeks we’ll announce our new contest. Thanks again to everyone!

wow! these are some great essays, very insightful. Required reading for TAs i think. Is there any thought about submitting these to gamasutra.com or gamescareerguide.com maybe? Good work all!:D:

This is great stuff, i just started as the first Tech Artist for a studio and it seems im being pulled in several directions, trying to get everyone up to date on the new tools, while researching shaders and helping out right at alpha to get some last minute tasks done. It nice to hear that the area i want to focus on more (improving production pipeline) is the interest that other Tech Artists share.

Keep up the great forum I am starting to rely on this and the wiki to squash any doubts as i truck along and start stepping on toes :slight_smile:

I’ll try and get in touch with the powers that be and see if some of these can be published… there are some really great essays here!

Totally agree with Bronwen Grimes’ perspective to the job. Show the artist how they benefit from learning a new tool and they’ll adopt it more readily. Hefty documents only aim to drive artists away - they’re simple folk :D:

Thanks for the contributions guys! Great read all-around.

Wow, nice articles, guys! Congrats and thanks for sharing!

北京企业网站推广方法北京企业网站推广方法是网络营销的主要内容,其重要性不言而喻,有效的网站推广既需要网络营销一般策略的指导,更需要有效的网站推广方法,网站推广方法正确与否在很大程度上决定了网络营销的效果。因此,研究和从事网络营销,不能不关注网站推广。 《网站推广的方法——120种网站推广实用方法》是我计划在2005年上半年完成的著作,考虑这本书的选题是在2004年5月初,也就是《网络营销基础与实践》第2版书稿完成后不久。经过几个月的考虑,现在已经完成了全书内容结构的计划,并开始了内容写作,预计要在6个月后才能脱稿。在制定本书写作计划过程中,和网络营销领域的一些朋友谈了自己的想法,大家都非常赞同这个选题,认为系统的网站推广策略对网络营销的实践应用会有很大帮助,同时又觉得写作和出版过程漫长,希望能尽早看到该书的内容。同行门的想法可能也代表了一些读者的愿望,因此打算与以往出版书籍的写作和内容发布方式不同,将边写作边连载,计划从2004年11月下旬开始,到2005年6月份,在7个月左右的时间内,每周在网上营销新观察(连载一篇最新的内容,直到该书出版上市(同时仍正常发表其他网络营销文章)。

Thats plenty of information being shared through these articles.Kudos to all those who participated in the contest.I agree with djTomServo about submitting this to gaming forums.Ofcourse these articles will be of gr8 help to those who wish to make a successful career in this sector.

Very cool article you got! I just added you to my bookmarks!___________________________________Buy Cheap Gaia Online Goldvgdomainmmopet