This is my first post to this site, so I’ll start with a formal introduction :p: scratches head
I’m Arvind, a graduate student at the Entertainment Technology Center of Carnegie Mellon University, Pittsburgh PA. I had the chance to go the GDC this year as a student scholar of the IGDA. I’m an aspiring technical artist. I am working as a 3D artist here right now and my undergraduate was in programming. Here’s my website : www.arvindsart.com
I want to learn as much as I can about the field, and for me personally, the GDC has gone a long way in educating me. I attended the technical artist boot-camp on Tuesday (which was AMAZING!) and several other technical artist seminars(which were AMAZING too!). I sadly couldn’t attend the round-table sessions, but I did find about this website and registered.
So, getting to the subject of my post, I’m going to build a simple tool in Maya and write an easy tutorial aimed at aspiring tech artists called the Best Practices for Efficient Technical Artists. (I’m also looking at it as an exercise to teach myself the skills required to become an efficient tech artist). The focus of the the tutorial will go beyond just the technical aspects of the tool. I also want to focus on the best practices involved in creating a tool like communication with artists, documentation, UI accessibility, data analysis, maintenance and several other things that I heard the awesome tech artists talk about in the conference. I hope to learn a lot more in this forum.
I will implement the tool in the entertainment technology center where several teams are working on projects with small teams including artists, and I believe the environment of my school will give me some room for experimenting. Also, just a heads up, I am not an expert, and I will also be learning as I work through the tutorial.
This post is basically a shout out to the forum about my project. I would like to know what you think about this endeavor. I will of course be documenting the entire process here as I go along so that you can read it and review it for me.
Welcome to the forums! There are a lot of good people here. I’ve never seen someone impliment a ta pipeline in a school environment, I’d be interested to read a follow up post on how it went.
“I am not an expert, and I will also be learning as I work through the tutorial”
<----welcome to the rest of your life, and all of ours. I’m sure you’ll grow quickly, teaching is the quickest way to learn something.
[QUOTE=arvindk.86;9369]So, getting to the subject of my post, I’m going to build a simple tool in Maya and write an easy tutorial aimed at aspiring tech artists called the Best Practices for Efficient Technical Artists. (I’m also looking at it as an exercise to teach myself the skills required to become an efficient tech artist). The focus of the the tutorial will go beyond just the technical aspects of the tool. I also want to focus on the best practices involved in creating a tool like communication with artists, documentation, UI accessibility, data analysis, maintenance and several other things that I heard the awesome tech artists talk about in the conference. I hope to learn a lot more in this forum.[/QUOTE]
You cannot be both a beginner and skilled/experienced enough to write a best practices.
Focus first on learning, then on teaching others. That said, sharing your learning experience can be a valuable goal for both.
There’s no such thing as ‘best practices for tech art’. There’s ‘best practices for programming OOP systems’, and ‘best practices for making 3D art’, and ‘best practices for writing shaders’, but you cannot have a tutorial describing ‘best practices for a technical artist’ any more than you can ‘best practices for people who write’ because it will be so uselessly broad- best practices for are doing something, not for the people who do something. Since Technical Art is no one single thing, or even a related set of different things, making a ‘manual’ of sorts would be pointless.
There’s no manual to follow for being an effective TA, as I’m sure you learned Tuesday if you didn’t know already. There’s a reason- we haven’t figured it out yet. Some day I hope we will, but you need experience, failures, and successes to know what ‘best practices’ actually means.
Rob, give him a little slack huh, seeh you are a bummer some times:) even when I agree with you.
Arvind, I would focus on the tool, and document the experience going through creating it. Don’t worry about a “best practices” as much as doing a small postmortem wrap up once your done and really see what you as the “tech artist” could have done better.
I think that will give you a better learning experience and it will create a better best practice document for you and others to learn from.
Critical review and reflection of past work is one of the best way to learn what worked and what didn’t and set a reference point to move forward from. It is easy to forget or not realize how much iteration and trial/error (as well as shi^ ton of digital duct tape) the current set of TA/TDs have gone through to get where they are. This is what makes Rob write a post like he did.
Add to all of that, each studio and even team in the studio can have a totally diffrent set of software, workflow and target platforms that the true best practice is deep breathing, adaptability and a zen level of detachment to hard work,code,process and decisions that should be tossed out when they are not working as expected.
I used to write a “best practices” document for the junior TAs at my company. Although I think it’s mostly a “common sense” document - at least for those who have some work experience as TAs.
Like… document your code, document scripts / create manuals, read error messages when troubleshooting something, use version numbers when writing scripts, look at log files when tracking down errors, use elimination methods to narrow down the source of an error, document solutions to errors on the Wiki, don’t hardcode things, try to make code modular and re-usable, how to make a research plan for yourself and be able to learn things on your own (and track your progress) etc, etc.
Especially people who come from the art side sometimes have a quite chaotic and unstructured approach to solving problems or writing code. Giving them some pointers how to tackle problems in a structured and analytical way is quite useful for them at the beginning.
p.s. most people who join my team are fresh out of college or have little work/TA experience. Such a document is quite useful to get people started.
[QUOTE=RobertKist;9392]I used to write a “best practices” document for the junior TAs at my company. Although I think it’s mostly a “common sense” document - at least for those who have some work experience as TAs.
[/QUOTE]
Do you think you could post up a sanitized/non-NDA violating summary? Might give people a good push in the right direction.
[QUOTE=Rob Galanakis;9383]1) You cannot be both a beginner and skilled/experienced enough to write a best practices.
[/QUOTE]
Well, all I wanted to do in the first place is make a tool and document the entire process, to help myself learn. I am a beginner TA myself and I thought that making that document into a tutorial would be of help to others like me. I know that I am not experienced enough to write something like that on my own and that is the reason why I am in this forum, for help, from you :laugh:!.. further, after reading these posts, I agree that making a ‘best practices’ document would be beyond my scope. So lets just call what I’m doing ‘Technical Art for Beginners’ from now.
Ideally, as a tech artist, I want to create a tool which will replace redundant tasks in the artist’s pipeline. So, I plan to create a ‘commit’ tool (similar to the one which I saw in a session(maybe Scott Goffman’s?) at the GDC bootcamp) which will ‘save as’ the maya file and all texture files associated to the specified locations with one click.
Would you have any other simple tool suggestions that could be applied universally to general game pipelines which use MAYA?
Also, before I start building, I plan on talking to all the MAYA artists in my school to find whether the tool will actually be of any help.
[QUOTE=UncCheezy;9419]I don’t quite understand what this tool will do, how does this tool help out an artist?[/QUOTE]
I agree with Shawn, so take this as a great place to start your document, as you now have two volunteers who are willing to read and critique (constructively, of course) your documentation efforts, right Shawn ?
So first, I’m going to agree with Rob and recommend avoiding the idea of “Technical Artist for Beginners”, “Best Practices for Technical Artists”, etc, anything very broad like that for your first effort. In the long run, it’s probably not a bad idea to have a set of documents that are best practices for individual aspects of technical art at your studio (scripting, rigging, etc) which you could call your “Technical Art Bible”, but for now, I think a focused approach might be a better idea.
My proposal would be to start small and focus your effort just around the tool you’ve outlined here and practice writing documents that might be associated with the development process as it applies to this tool. Your first document could be from the standpoint of approaching a producer for resources. Shawn’s observation is a very common one you’ll be getting from lots of producers, so as i said, it makes a great place to start. Break this document into three distinct parts: Problem, Solution, Benefits. Your goal is to pursuade your readers why you need this tool, what the tool actually is, and how it will help the artists, eg:
“Artists spend an inordinate amount of time managing the texture files associated with a given Maya scene’s materials.B[/B] I propose a tool that will reduce the time spent managing texture files by tracking these dependencies and providing ‘one-click’ access to file operations.B[/B] This will shorten asset iteration time by lessening the amount of time artists spend in a file dialog versus the asset creation. B[/B]”
So that’s obviously a quick and dirty example, but you get the idea. This is a good exercise, as it requires you to really drill down into the problem you’re trying to solve. It may even end up presenting you with alternate solutions you may not have previously considered.
[QUOTE=djTomServo;9402]Do you think you could post up a sanitized/non-NDA violating summary? Might give people a good push in the right direction.[/QUOTE]
[QUOTE=arvindk.86;9409]which will ‘save as’ the maya file and all texture files associated to the specified locations with one click. .[/QUOTE]
Max already has a tool for this in the utilities section, it’s called “resource collector”, though I haven’t run across a maya counterpart. Anyone know?
I have a simple best practices guide that I teach the TA’s up at work.
You, as the Tech Artist/Animator, are the 100% filter. You have to catch EVERYTHING, because you are the fail safe. That said, you will fail. So, you need to know how to fix your own failures so you can maintain that 100%.
That was the best I could do to sum it up because what we actually are looking at and fixing or debugging, is going to change everyday.
[QUOTE=RobertKist;9392]I used to write a “best practices” document for the junior TAs at my company. [/QUOTE]
Nice, I too would love to go through this.
[QUOTE=bclark;9446]Annie there are tools in Bonus tools to do this, much like resource collector.[/QUOTE]
I’d still want to implement this just as an exercise for myself.
Also, with grad school, this might take a while …
[QUOTE=djTomServo;9422] “Artists spend an inordinate amount of time managing the texture files associated with a given Maya scene’s materials.B[/B] I propose a tool that will reduce the time spent managing texture files by tracking these dependencies and providing ‘one-click’ access to file operations.B[/B] This will shorten asset iteration time by lessening the amount of time artists spend in a file dialog versus the asset creation. B[/B]” [/QUOTE]
This looks pretty solid, thanks! Is structured pitching a common practice in studios?? Or is it more like anything that can convince the person in charge goes?
[QUOTE=arvindk.86;9478]Is structured pitching a common practice in studios?? Or is it more like anything that can convince the person in charge goes?[/QUOTE]
It varies, but for most of the places I’ve worked it is, especially for major systems. It’s a great way to get everyone to the table and it starts the paper trail. Getting a handle on your presentation skills early on is going to serve you well later in your career as you start to own larger systems and find yourself talking to more people about your work. And who knows, you may end up speaking at GDC one day too! :D:
Cool project, sounds gianormous. Divide and Conquer, anytime you get to a project that seems too big, cut it down, compartmentalize the issues and bugs, and note what is what.
[QUOTE=arvindk.86;9478]This looks pretty solid, thanks! Is structured pitching a common practice in studios?? Or is it more like anything that can convince the person in charge goes?[/QUOTE]
Tech artists are paid like everyone else, which means they must be justified on the same spreadsheets and diagrams like everyone else is. Understanding how management works is going to be the most effective way to get the budget and resources you need to do a task. Many TAs (and developers in general) don’t understand this, and end up frustrated (though appreciated!) because they can do great things technically but have never figured out how to register it with management. This sort of dichotomy- TA’s being some of the most appreciated people, but some of the most frustrated when it comes to justifying more resources or team members or scheduling considerations- is an all too common problem that we need to continue to work on.
Here’s the link to the tutorial
Here are the files (mel code, ui file and readme) :
As you will see, this is nowhere close to a ‘technical artists best practices’ that I intended to make. No sir, it’s not as simple as I originally thought. What I have here is a simple tutorial, made approachable for beginners. Let me know what you think!
I’d like to point out 3 topics that I briefly touched in my tutorial which could fall into the general workflow a technical artist: Project goal definition, data analysis and documenting. When I intended to make the best practices manual, it was topics like these that I thought would go into it. I now know I would need immense experience to write a manual like that, but I also think that it would be great help for the tech-artist community and game/FX industry in general if there would exist such a manual that we could follow.
?
