In the meantime I’ll be cleaning up the commenting CSS (cause it’s ugly, “Bob” damn it) and figuring out how to make the wordpress machine phone friendly, cause who uses desktops anymore?

Be excited.  Someone should do it, and I’m going to be really busy.

Download Script here.

Directions for use:

•  Copy this script to your <Max Directory>\stdplugs\stdscripts folder
• Restart Max
• Open up the ‘Customize User Interface’ Dialog ( Customize > Customize User Interface )
• Select ‘GoodUtils’ from the ‘Category’ drop down
• Select ‘Show or hide collision’ from the actions
• Assign a hotkey using the assign hotkey area to the right
• ‘Save’ your UI settings

with the area in brown having to be repeated for every mesh, and the entire process needing to be repeated for every bake.  My solution involves a new node in Maya along with a UI and set of tools for interacting with it (collectively referred to as Bake Layer Tool).  You can see it in action below:

Watch this video on YouTube.

As can been seen, the process is very quick and easy.  The revised workflow looks something more like this:

with some steps only having to be taken once for a given mesh, even for multiple imports.

Current Version: 0.2.1
feel free to download the tool here.

• Please be aware that future versions of the plug-in may cause problems when updating, due to Maya plugin node IDs, so please do not use this plugin for critical work until I have it at version 1.0.
• Also be aware that I developed this tool on Maya 2012 with a fully updated install of PyMel.  This will not currently run on a vanilla install of Maya 2011, although I am currently considering working on making it backwards-compatible to 2011.

Below is a video demo/tutorial.  Download the tool here.

Jason Parks – Sony Interactive – Power Python for Maya – slides here

• Eclipse
  • Superb python development environment
• Pymel
  • Eclipse as a primary IDE
  • Wing (or eclipse) for debugging
• Why pymel?
  • not compiled
  • Autodesk blesses it
  • open source
  • free
  • a Pythonic maya language
    • actually OOP
    • the most important difference between pymel and maya.cmds
• Pythonic language in Maya
  • creation of a joint
    • myJoint = joint( )
  • list relatives
    • myJoint.listRelatives( )
  • All pertinent commands/functions are attached to the object
  • auto completion in an IDE will get you all methods of the object
  • dir( ) on an object will get you the same
  • Convenience Functions
    • myJoint.getParent( ) instead of myJoint.getRelatives( parent = True )
  • Readability is KEY
  • getting access to attributes is super quick and easy
  • Objects are known by their API DAG path, not the node name
    • solves a lot of problems by itself
  • Improved logging
• Eclipse
  • Open source
  • popular
  • tons of add-ons
  • Mark Occurrences
    • Super useful
  • Pydev Outliner
  • Pydev + Eclipse maya editor, tutorial on creativecrash
  • Eclipse is aware of the code base (autocompletion)
• Wing
  • Real-time Debugging
    • Break from Maya to debug
    • breakpoints, stack tracing, injection

As a bit of follow up to this talk, I just started using eclipse + pymel, and I’ve been converted, it’s definitely worth taking the jump, it makes writing the code much less tedious, and lets me focus on the actual problems at hand.

thanks for reading, hopefully you’ve found something useful.  If you feel like anything could be clarified or anything of that nature, feel free to leave a comment.

I’m going to actually sit down and finish typing out the rest of my notes from Tuesday. The rest of the days are much lighter on the notes.

Anyway, on with the show!

Tuesday (Tech Artist Bootcamp) (continued):

Seth Gibson – 343 Studios (Microsoft) – How to Train your Technical Animator – leveraging personality types – slides here

• Team Fit
  • the myth – it’s about who you’d want to have a beer with
  • It’s not about generic ‘strengths’ and ‘weaknesses’
  • it is about leveraging personality
• Personality assessment overview (I’m an Integrator, with a strong hint of Focuser)
  • The Focuser
    • “Management Material”
    • Question they ask: What?
      • “what is the job right now?” — not big picture
    • Generally self-reliant
    • Authoritative
    • Practical
    • Clear
    • Predictable outcomes
    • Areas to improve:
      • People skills
      • Breadth of knowledge
      • Time management skills
  • The Relater
    • “Who?”
      • “Who is involved?”; “Who is affected?”
    • People person
    • enthusiast
    • Better at scheduling than the focuser
    • Big picture/teamwork focused
    • Interpersonal
    • Effective communicator/presenter
    • Also a great tools/tech/etc. evangelist
    • Areas to improve:
      • Focus
      • Breadth of Knowledge
      • Depth of Knowledge
      • Time management skills
  • The Integrator
    • “Why?”
      • or, “What is the significance?”
    • Self directed, self-reliant
    • Finisher
    • strong team member, considers all the input
    • Asks (and often answers) the hard questions
      • Is there a better way to do this?
      • Is this the most productive use of time?
      • etc.
    • Areas to improve:
      • Leadership skills
      • People skills
      • Depth of Knowledge
  • The Operator
    • “How?”
    • Detailer, systemic
    • No stone unturned
    • Attentive to “little things”
    • Iterates and improves
    • Analyzes, monitors, documents
    • Knows systems, procedures, boundaries
    • Areas to improve:
      • Leadership skills
      • people skills
      • Breadth of knowledge
      • Time management
• Personality training now means personal success later
  • Assess early, leverage often
• Redefine “team fit”
• Re-think development paradigms

Steve Theodore – Undead Labs, Epic Fail – slides here

• Dealing with problems is a huge part of the job
• Defensive Design - take inspiration from real defense
  • Compartmentalize
    • like battleships!
    • Encapsulation
      • Small functions with clear jobs
      • well defined inputs and outputs
      • each piece is a black box
      • bigger jobs = a collection of small jobs
      • “Single responsibility pattern”
        • Each small chunk of code has a single responsibility
      • Why encapsulate?
        • localize problems
        • Simpler maintenance
        • Easier debugging
      • Extra benefits:
        • Reusability
          • Bug fixes happen in one place
        • Teamwork
          • It’s easier to divide tasks when you have a bunch  of small pieces with clearly-defined functions
        • Testability
          • It’s easier to figure out whats wrong when the function that is throwing the error has limited length
          • testing for individual black boxes is relatively easy
      • Different flavors of black boxes
        • Library code
          • intended to be used anywhere
          • should be the bulk of the code  we write
        • Tool code
          • complex jobs
          • very specific
          • should make use of library code
        • UI code
          • buttons, menus, etc.
        • Model View Controller
        • Black Box Code
          • What is inside a black box can change
          • inputs and outputs can not
          • wrap existing functions to add data or functionality
      • Document!
        • Memory is fallable
        • teammates need help
        • write your code for strangers to read
        • automatic documentation generation software:
          • Doxygen (many languages)
          • Epydoc (Python)
  • Debugging
    • Code stacks up
      • returns go down
      • debugging = inspecting the stack, and backtracking to the bug
      • 90% of the time, errors are from carelessness in how code talks to code
    • Debugging is the art of finding responsibility
    • Print Debugging
      • simple
      • cheap
      • limited
      • messy
      • fundamentally the wrong tool for the problem
        • you must know where the problem is to find the error
    • Logging
      • Print debugging plus
        • global on/off
        • write to text file
        • email
      • Python
        • use the standard logging module
    • PDB (Debugger)
      • step through code
      • inpsect variables
      • execute statements
      • move up/down the stack
    • IDE
      • Eclipse + pydev
      • wing
  • Exception Handling
    • Exceptions retrace the stack
    • catch only expected errors
    • Catch Fails
      • blatant catches
        • Hiding errors you should be fixing
      • Empty catches
        • (don’t lie to yourself, the error is still there)
      • Catching too high
        • your catch needs the right context
    • Catch Win:
      • tight scopes
        • expected errors
          • empty returns, etc.
        • External Errors, etc.
          • network, disk issues
    • Exceptions are friends
      • Valuable for debugging
      • flexible, because you can write your own
      • save all exceptions
        • text file
        • email
        • database
    • Good error reports
      • save whole stack
      • file, location, local vars
      • Python Stack Capture
        • sys.exc_info()
          
      • throw exceptions high on the stack to be handled lower

Adam Pletcher – Volition, Databases and Technical Art - slides here

• Embrace the database
• Relational Databases
  • Strengths:
    • Speed
    • Volume
    • Multi-user
    • data relationships
  • Hurdles
    • SQL query complexity
    • centralized service
  • How they work
    • Server -> databases -> tables -> Columns and Rows
      • Each Column has a type
  • Visualization
    • Allows you to quickly and easily show data in a visual format
      • Heatmaps, graphs/charts
    • Tools:
      • Pylab
      • Tableau
      • Excel
      • Custom views, reports
    • When graphing, show the trend line
      • Useful for proving viability to management/producers
    • Heatmap for tool usage/errors
  • Databases and Python
    • SQLite
    • pymssql
    • postgres
    • **SQL Alchemy
      • Pythonic
      • Independent of DB flavor
      • Abstraction layer between the python and the SQL/DB
      • Object relational mapping
        • direct relationship between code object and database data
          • add, update, delete
  • Start small and simple
    • install a server on your workstation to begin
    • start with a dumb datastore
      • good place to learn
    • Set goals for data capture

Bryan Moss – THQ Digital Studios Phoenix -Using Simulation data in real time – slides here

• Graphics talk, not so much tools
• Video simulation textures
• Pipeline
  • Sim cloth with DCC
  • Video node used in shader to add video to the shader
    • Render to texture
    • don’t be subtle
    • Can use compositing on videos
      • “fix in post” mentality
      • allows for a lot of flexibility
  • Bink for video compression
  • Cloth shader
    • Tech artists are invaluable here
    • art knowledge plus technical know how
    • Running the numbers is a must( PIX, Gpad, etc)
      • Tech artists should know exactly how much something costs
    • Downsides:
      • Art setup is cumbersome
      • Artists need to know multiple packages
      • can be tech heavy when designing, coding, maintaining shaders
    • Features
      • Extremely dynamic shader
        • 5 dynamic systems including cloth
        • multiple specular types
        • two sets of UVs
        • 5 textures plus one video texture
      • Bulk of cloth is in normal and parallax
        • swizzle out blue for using on the parallax
      • process helped by efficient, established shader pipeline tools

Bronwen Grimes, Valve Making and using nonstandard textures – slides here

I didn’t take many notes for this one, I was mostly trying to digest the material.  Definitely take a look at the slides for this one

• Standard textures
  • Diffuse, specular, normal, etc.
  • useful, but by no means the limit to what can be done with a 2-dimensional array of data (map)
• Non-standard textures
  • Manipulate the UVs through color data
  • Flow Map – representation of a 2-d vector field, plotting the flow of pixels on the surface
    • Water needed to follow the complex contours of the levels in a believable way
      • Flow around things
    • Flow map generated by Houdini & scripts (definitely reference the slides for this one)
      • artists were given a mock-up of the level, with the plane of the water.
      • They could then paint the flow on the surface, which was basically painting the surface normals
      • this information was then baked out to a two channel map
        • This data was not normalized, to allow for different magnitudes of flow
    • Use a noise texture (cloud) as a time input in order to offset the motion in timing
      • cycle the values so that this can also be used to mask off movement
    • Flow maps done by 2 artists, for 30 levels, in 1.5 days
  • Material Emancipation grid
    • had to be non-threatening, convey that it was non-blocking, and also communicate state (show player that it would “emancipate” level meshes
  • Surface-facing normals
    • The “science-y” gels for portal 2
    • Wanted texture to look like it had embedded sprites
    • ended up using a uv texture that reacts to the camera’s angle to the texture.
    • along with a bump offset, made a texture that made the bubbles always look round

My thoughts, where I decide to include them, will be in italics.

The slides and Rob’s (very dense) notes are available here.

Tuesday (Tech Artist Bootcamp) (continued):

Rob Galanakis – Bioware Austin, Ending the Culture War

• “You have crappy tools because you have a crappy tools culture”

• I had never thought of “tools culture” before, but that’s definitely what we had at Volition, what made it so possible for me to be effective even as a beginning intern.
• Can you share resources and tools between teams?

• You cannot have good tools and bad culture
• Changing culture is hard
• The Defining feature of a great TA is their impact on studio culture.
  • Streamlined workflow
  • strong communication
  • good code
  • This is one of the areas where I see the biggest need for/advantage of having a forked tech art discipline built in to a strong art program.
• Good pipelines take a decade to build
• Three Strategies
  • Figure out what Tech Artists and Engineering teams are good at
    • play to the strengths of engineering and technical art teams
      • Engineering teams are set up to build and maintain large systems
        • Engineering teams have more build, testing, and deployment infrastructure
        • More management means deliberate and manageable rate of change
      • TAs are good at working directly with content developers
        • TAs often start as content developers
      • TA teams are smaller and less managed than engineers
      • TA reports to, is taksed by, and is paid by content
        • Not engineering
      • Boyd’s Law – Speed of iteration beats quality of iteration
    • Engineers provide a solid foundation
      • TAs can/will not create a solid large system
      • TAs should iterate using the large systems as a base
  • 2. Replace adversarial relationships with positive structures

• Programming, art, and design hate each other because they compete for the same resources (programming time)
  • Create mechanisms to share resources and share people
• If you can’t trust the people who wrote the tech, you can’t trust the tech
• content creation’s tools budget is self-sufficient and sacrosanct.  Don’t steal resources from other areas
• Often, the poorest schedules are rewarded with the most resources, resources and people are shifted from functioning areas to the most mismanaged areas
• Don’t use tools budget to patch holes in bad scheduling
  • Probably painful at first, if the studio is used to depending on this, but seems like it would lead to great advances
• Content should control content’s budget.
  • they choose whether to spend budget on content or tools
• Let Engineering control the tech
• TAs can keep content developers away from bugs and issues in teh code
• Tools Vision is powered by TA

That’s it for the evening.  I may at a later date go through and write more of my personal thoughts, but for now, labs are closing soon, and I have other work to do.  Hope  you took something away from this.

As I’m currently working on thesis work, I’ll be typing these up during breaks from content creation and rolling them out as I finish typing each section.  I hope they’re instructive in some way, shape, or form.

Monday:

Riot Games/League of Legends Postmortem

• Difficulties:
  • Always in development, always adding new fundamental features
  • emergent work — game is live, users are finding bugs
• Solutions:
  • Triage daily (daily mandatory playtests)
  • Separate teams for live issues and feature additions
    • This allows for devs focused on immediate problems to focus there, and those focused on adding content to be focused where they need to be
    • Focus on the teams’ different cultures and levels risk aversion.  Put people where their personalities fit best ( this seems to tie in with Seth’s talk on Tuesday)
  • Scale testing
• Other Observations
  • Don’t change UI for small changes
    • UI changes have a high cost;
    • Even if the change is going to have a positive impact across the board, you’ll have people who are used to looking/clicking in one place and will have trouble shifting to the new location

Tuesday (Tech Artist Bootcamp):

Keith Self-Ballard – Volition, In Advocacy of Tech Art – slides here

My note: This was a fantastic talk, and, in my opinion, one of the most important talks of the bootcamp.  The notes are a little sparse, partially because I was just warming up my note taking for the morning, but largely because the talk was very to-the-point.  Once the slides are released, I’ll be sure to post a link.

• What Makes  a Tech Artist?
  • Flexibility and Adaptability
    • Bronwen Grimes later said the #1 quality she looks for in a Tech Artist is the ability to learn
  • Smart, Gets things done [and not a Jackass]
• Why do we need tech artists?
  • Communication between artists & programmers
  • Good tools give an employer the chance to address problems with low performing employees
    • Low performing content creators can hide behind the fact that the tools are bad [ when they are].
  • Focus
    • Content creators can focus on content creation, worry less about the tools themselves
    • Engineers can focus on engineering
• Challenges
  • Artists may grow overdependent on TAs
    • Arists need to be mandated to learn how to solve certain problems and remember when the same error shows up 2, 5, 15 times
    • Artists may stop looking for creative solutions
    • This was discussed at the Tech Art Roundtable on Thursday

Scott Kauffman, Making Tools your team will actually use – slides here

• 1- Know your clients
  • Artists can’t often describe what they want or need
  • Be a Generalist:  Know what every department does, and how they do it
    • Be able to understand the workflow that the artist is trying to improve without them having to explain it or show it to you
    • “Know just enough to be dangerous”
  • Find beta testers:
    • Attributes of a beta tester:
      • Technical – able to understand in some way what is happening with the tool and what went wrong when it breaks
      • Patient – willing and able to deal with a tool that is still in beta, and has some bugs
      • Eager – Active, not reactive, in seeking help when it is needed, and solving problems when it is not
      • Pathfinder – Willing to accept the challenges of being the first one working with a tool, and also willing and able to evangelize the tool to the rest of the team
      • In short, people with a little bit of TA in them
    • Meet with them regularly to collect feedback
      • Be proactive
  • Keep tack of who is using what
    • Make a database of telemetry on tools usage (who, how often, how long, how many clicks, etc.)
      • Find out who uses new tools the most
        • These will be good candidates for beta testers
• 2- Define the goal
  • Three questions
    • What problem is this tool supposed to solve?
      • This should go in the source code  at the top
      • Any time the tool does not meet this definition, it is broken
    • Who will be using it?
      • Design UI/feature set for target audience
    • Can this solution be added to an existing tool?
      • Helps prevent tool clutter
• 3- Deploy in stages
  • Version 1.0 should be as barebones as possible
    • get this to your beta testers as soon as possible
  • Once basic functionality is there, polish UI, add additional functionality
• 4- Simplify the UI
  • Intentionally or not, we design tools for ourselves
  • Example (bad): Zbrush
  • Integrate into the target environment (Max, Maya, Houdini, World Editor, etc.)
    • Artist should not be able to distinguish custom tools from built-in tools
    • Put new tools in logical integrated location and in custom tools menu
  • Avoid tool clutter
    • Occasionally do a tool list review
    • Too many tools = confusing
  • Make the UI expandable
    • Only show the currently required UI, expand the rest
    • A user will not use a tool that scares them
    • Hide complex UI until user needs/requests it
    • Start tools in a read only mode if applicable
  • Avoid customizable UIs and Hotkeys
    • Figuring out the beset layout and hotkey is your job
    • Any two users doing the same thing with the same tool should have the same UI
  • Button clutter is worse than menu clutter
    • Try to reduce button count.  If it doesn’t meet one of these criteria, move it to a menu:
      • Does it need to be clicked frequently or repeatedly?
        • Frequently: move, rotate, etc.
      • Repeatedly: Grow selection
  • Re-use your UI elements
    • Programming and Use efficiency
• 5- Provide Help
  • Don’t roll out a tool until it’s documented
  • Every tool should have a help button
  • All help docs should be in the same format
    • Use a standard template
    • Provide specific usage examples
• 6- Advertise
  • New tools
  • New Features
  • Breaking changes
  • Functionality changes
  • Pop up release notes on new changes
  • Create a one-sheet for new hires
    • Name of tool, one sentence description of what it does
    • If you can’t fit all of your tools on one sheet, maybe you have tool clutter?

Well that’s it for my current posting.  Hope that something here is helpful.  I’ll try to continue posting sometime today or tomorrow.

Thanks to all of the people who put things together, gave talks, or shared information, I learned a lot and I’m looking forward to keeping in contact with all of the people I met.

Ben Cloward wrote a great summary of the Tech Art Bootcamp, which you can find here.

While I was working on my first somewhat involved rigging project (for my Thesis), I realized I would need to constrain a large number of joints to a large number of other joints that could be very nearly identically named, save for a prefix.  I decided to spend a few minutes writing a little Python script to automate this constraining process in order to save myself time (and so that the time that I did spend would be more enjoyable).  The result was this little 75 line script that has worked quite well.  If I get into more rigging, I’ll obviously script more portions of it, but for now this was quite helpful.

Use:

• Must have a Control skeleton, joints prefixed with “ctl_”
• Must have a Bind skeleton, joints prefixed with “bind_”

1. Download the script here, and unzip it to your scripts directory
2. Import “constrain_joints_ctl_to_bind”
3. Select a node at or above the highest joint in the control skeleton hierarchy
4. run constrain_joints_ctl_to_bind.constrain_joints( ) at the Python command line in Maya