HI guys. I am curious on what people expect to see in a Pipeline portfolio. Or if a portfolio specifically for pipeline is needed?
I was originally a rigging tech artist so I have a lot of rigging pieces and some maya python tools like a simple pose library and an old production management tool. I think I know how to improve on the rigging side but have no idea on where to go for pipeline itself.
Any info about pipeline jobs or what the industry is looking for in pipeline TAs would be really helpful!
Hey there, welcome to TAO!
I’ll start by saying that my website isn’t in the best shape right now, nor do I think is it any more a good example of a TA portfolio. I’d made the images explaining my tool workflows at a time when we had to show our portfolios to people in person, on paper or on an iPad, and used those as static images on my website. We’ve come a long way since then! I was also coming out of my environment artist phase and was still in the mindset of “pretty pictures!”.
For pipeline and tools, I really like when folks clearly state the problem (since every production is different, and the person looking at your portfolio won’t have the context for the challenges you faced), then go on to describe the solution in as much detail as necessary to make it clear that you effectively solved the problem. Finally, it’s great to talk about outcomes. I don’t think it’s totally necessary to include all of implementation details, just the stuff you want to flex on.
So, using an example from my past I’d have a section of text like:
The Layer Rebuilder
Problem - Darksiders 2 was built with a modular kit of environment assets in a custom engine which lacked per-instance vertex paint support [ed. note this was 2011]. Being able to uniquely paint vertices to blend materials was critical for both art direction (to break up monotonous spaces) and level design (to guide the player through traversal puzzles).
The Solution - The custom engine we used for Darksiders 2 supported exporting level files as XML, which held data for the transforms of each modular piece. I had also created a database which mapped individual asset references to the 3ds max file. Using these two pieces of information (where an asset was in the world, and where it came from) I used a python script in a listening server (based off Adam Pletcher’s work in communicating between 3ds Max and Python) to parse the XML file and then create a layer definition file which was then automatically parsed in 3ds Max to merge in the specific assets necessary to reconstruct the level.
Artists would then select the World, Level, and Layer they wanted to recreate and click “Go!”. Once complete, artists filtered down to the wall sections that needed to be painted, and used 3ds Max’s built in vertex paint along with our materials in 3ds Max to paint moss, dirt, and traversal hints. The artist then exported these sections and dropped them into the world at 0,0,0, deleting the original modular pieces.
I additionally developed a technique to help artists define traversal hints, using the 3ds Max cut to to help shape the areas we needed for traversal hints (since traversal elements were included in the layer rebuilding, it was easy to figure out where they needed to go).
Outcomes - Without the Layer Rebuilder, we would never have been able to achieve the art direction and level design intent. It simply was not feasible to recreate whole levels by hand in 3DS Max from the modular kits. This tool received many updates over its lifetime, improving compile times and accuracy with each iteration. Most of the environment artists on Darksiders 2 used this tool throughout production.
I think it’s also really important to include images and/or gifs of stuff working. If you’re optimizing an old process or pipeline, you may consider flowcharts showing The Old Way and The New Way to really drive home how effective you were.
TL;DR Talk about the problem, talk about how you solved it, talk about how effective the solution was. Don’t forget the gifs.
2 Likes
Gotcha! Thank you for the detailed info, this helps a lot!
Oh, also do you suggest showing code snippets? What about video reels? I have a reel with couple of tools in it and feel like it takes a lot of time to explain everything in it.
Depending on what you are trying to show off this can be useful, or it can just be line noise. @ozzmeister00 's approach of “Problem, Solution, Aftermath” is really fantastic, if the solution was 20 lines of code that encapsulates the problem, yeah go ahead and include them. But also pictures, gifs, or quick videos are the real standout “LOOK AT ME” content for a lot of people who will be honestly just speed-reading/skimming your portfolio.
Short, snappy and eye-catching. You want your reel to make people go “Oh that looks interesting, this individual is clearly clever”.
The sad fact is that most people initially looking at your reel/portfolio/resume have been looking at dozens-to-hundreds and they don’t spend a lot of time doing it. You want to make sure you’re hitting them early with your wow-factor examples. Or if you know what the company is looking for, tailor your presentation to match.
2 Likes
I’ve been doing this full-time for a few years, and now make tools at a couple different studios.
The most important takeaways, in my opinion, are:
- The studio already knows what they need, they’re just trying to determine if you can solve their problems before spending time interviewing you. They want to see examples of problems you’ve solved in the past and what the outcome was so that they can compare it with their current needs.
- The problem you solved (the “what”) and the outcome is often more important than how you solved it
- The people reviewing your work don’t always have a technical background in tools, so getting too much into the weeds won’t benefit you. (This stuff questions will come up during the interview if it’s important to them)
With that understanding, you’re just trying to communicate in the most efficient way possible that you will be able to solve their problems effectively. Do this with concrete examples and simple explanations. The format you use largely depends on the type of tool you built and its complexity. I have gone with a hybrid approach in the past, where some tools were shown in video and others were written up on my website.
My site is here if you’d like to take a look.
What JoDaRober said basically. We’re looking for clever solutions for making things faster or better usually. So if you have a bunch of little tools that turn regular multi-step processes into single step processes, great. Big problem solving stuff, great. But things that show faster ways to create and setup rigs, Export processes, complex setups, any sort of automation. And I like the essay format: Introduction, Body Paragraphs, Conclusion. Present your thesis, meaning show the viewer what this thing does in a very quick fashion and why you needed this (What problem was being solved). Then explain a little about what it is and how you use it so they understand it in context, showing the process a little more in-depth. Then recap with another example of doing it quickly and explain how it saved time and was a benefit to the studio in the end (Like this turned 2 days of setup into a minute or two). And keep all of that quick. Think of it like and Ad, not a GDC Talk.
Your overall reel shouldn’t be more than 2-3 minutes. And if you have more content than that worth showing, break it up into categories so viewers can view based on what problems they need solved. Rigging in one video, tools in another, engine setup stuff, shader stuff, etc. Or if you don’t have enough for a video for each, at least break them up and group them in smaller groups. If it takes a while to show a particular process then do like they do with movie trailers. Hey, here’s the quick look short version. Interested and want to know more? I have a long form video for you.
Code samples, not in the reel, but if it’s your own code post it up to GitHub or something. Obviously don’t post anything that a studio owns without their permission. Some code samples aren’t bad, but they aren’t a deal breaker and that’s what the interview is for if people have questions there.
And back on the rigging vs pipeline stuff, the rigging is part of the pipeline. But a basic human is like base level expectation now and doesn’t do much good to show (Yeah, show one if that’s all you have, but don’t dwell on it. We’ve all seen an FK/IK setup now. Everybody gets it right away.) But if you have more complex machinery, or character with clothing or facial setups, great. Talking about how you managed split body animation, or swapping back and forth between rigs with facial rigs and without. Tools that allow for space switching quickly. Those are are great and part of an animation pipeline and speed it up. And seeing how you manage that stuff in engine too. Did you have to animate all the cloth, or did you have procedural setups that look good and don’t take time to animate? Do you have RBF or Control Rig setups in engine to deal with deformations in a way that doesn’t take animator time? All rigging, but all great pipeline stuff too.