Starting point for understand shaders and their fundamentals.
polycounter lvl 14
Hey all,
Hopefully search didnt let me down and hide threads from me but been trying to figure out where is a good starting point to learn the fundamentals behind shaders. I know there's HLSL for 3dsmax and maya. Im planning on picking up the HLSL series from cg-academy as the previews were actually pretty good. Was wondering if anyone could give some thoughts about some things I want some further clarification/input on.
1. I'm planning on grabbing tutorials to learn python/C# but would it be better to learn C++. Also do I need to know indepth knowledge of programming?
2. If I know the basics of how shaders work, is it easy to port the knowledge to say UDK. Cause I always saw the materials in UDK and if I followed a tutorial I would understand what that node was doing but if someone said hey you make this...I would not know where to start.
3. I've been researching a lot of what it takes to become a TA. Tech-artists.org has been an amazing resource for figuring out how convulted the description of TA has become
But almost each position asked for scripting knowledge and instead of asking which is better, which will help me understand the core concepts. Also any good spots to learn the languages would be awesome.
Hope to get some good feedback as always from polycount
Edit: Found this book, time to visit the library: [ame]http://www.amazon.com/Shaders-Programmers-Artists-Premier-Development/dp/1592000924/ref=sr_1_1?ie=UTF8&s=books&qid=1274112815&sr=8-1[/ame]
Hopefully search didnt let me down and hide threads from me but been trying to figure out where is a good starting point to learn the fundamentals behind shaders. I know there's HLSL for 3dsmax and maya. Im planning on picking up the HLSL series from cg-academy as the previews were actually pretty good. Was wondering if anyone could give some thoughts about some things I want some further clarification/input on.
1. I'm planning on grabbing tutorials to learn python/C# but would it be better to learn C++. Also do I need to know indepth knowledge of programming?
2. If I know the basics of how shaders work, is it easy to port the knowledge to say UDK. Cause I always saw the materials in UDK and if I followed a tutorial I would understand what that node was doing but if someone said hey you make this...I would not know where to start.
3. I've been researching a lot of what it takes to become a TA. Tech-artists.org has been an amazing resource for figuring out how convulted the description of TA has become
But almost each position asked for scripting knowledge and instead of asking which is better, which will help me understand the core concepts. Also any good spots to learn the languages would be awesome.Hope to get some good feedback as always from polycount
Edit: Found this book, time to visit the library: [ame]http://www.amazon.com/Shaders-Programmers-Artists-Premier-Development/dp/1592000924/ref=sr_1_1?ie=UTF8&s=books&qid=1274112815&sr=8-1[/ame]
Replies
http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter01.html
1.
I think it's easier to go the c#/script route to get fundamentals, especially as all the "hard bits" about C/C++ the low level memory management and so on are removed from those languages. And for most shader programming you would't need that kind of stuff anyway. That said, for "actual programmers" I would recommend starting with the low-level languages as it teaches more about the machine itself. But imo one can differentiate well here between "users" and "makers" of tech, therefore you should be able to enjoy the "simpler" languages and get faster to stuff that is directly related to what you need.
2.
experience, playing around... start with simple stuff, the rest will come with time
3.
same as with the shader stuff, start with basics, learning something new requires a lot of self motivation, keep the hurdles low at beginning so you can achieve things. That might sound boring first, but in fact sets the ground. I have seen some people rush thru the basics, and later they showed great lack. Don't just read, do stuff, simple stuff that might be useful. One of my first maxscripts was creating an animation that illustrated bubble sort of boxes with random widths.
imo if you want to get into programming, you gotta bite through the fundamental data container algorithms (trees, lists, sorting...) because it teaches the basics of algorithmic thinking and at the end you always need to manage your data somehow.
pure shader programmer artists also tend to just copy paste bits without understanding the math or whats really going on. you don't need to understand a lot linear algebra for shader stuff, but you should be able to understand homogenous coordinates and matrix operations and what they are for.
It's not as in-depth as hand coding your shaders but it's a lot easier for testing stuff out. And then afterwards you can open up the .fx file and see what the code does.
To be completely honest I still don't know what it takes to be considered a Technical Artist, and I guess the best idea, even if a bit idealised as he said, is the one pictured by Eric Chadwick in his "Technical Artist Guidelines". In my opinion (I may be wrong though) it varies quite a lot by studios, because the TA should be a sort of "problem solver", "fixer" and bridge between different areas like Artists and Programmers. Being so tied to the specific studio environment, TA requirements could be very different based to the pipeline, areas, ongoing projects and so on.
Anyway, I give my answers:
1. Before choosing a language, choose a task. It's almost impossible/useless to pick up a book on whatever argument and study it from cover to cover without anything to drive your efforts. The issue is even bigger if subject matter as programming is quite difficult. First step, in my opinion shouldn't be about asking yourself what's better to learn, neither in terms of programming language, nor in terms of complexity, deepen or shallower machine related stuff knowledge. After starting to code in one language, whichever it is, you can always add knowledge about more "hard core" issues, but the ease to start with something simpler is to digest the knowledge common to every programming task. So, I guess you should ask yourself what you'd like to accomplish. Is it a new tool for your favourite 3D software? Good, then start there: define the instruments, pick the language the software supports, then start learning and writing. Or you can start poking at game programming picking up a 3D engine like UDK or Unity and start learning their scripting languages (and "scripting" is not bad, nor a lower form of programming). In the end, start from a task, the programming language will follow. Once you got one, you can quite easily become proficient in others, knowledge is fairly portable.
2. Same answer as CrazyButcher. Start by tackling the basics, then with time everything will progressively become clearer.
3. If you are interested in a specific studio or software you may find clues about what's their pipeline like and start looking at those software scripting capabilities. Best resources are found in software documentations. If you are looking for information about a specific "generic" programming language, like Python or C++, internet can provide all sort of tutorials, and even free books. One of my favourite stops, when looking for a book on a specific argument is Amazon, reading through every comment to find the volume best suited to me, never been disappointed so far.
Sorry for the wall of text
@Talon: woah thats reminding me a lot of what UDK material editor is like and I always love node based
@SyncViewS: I love wall of text
Hopefully there's more stuff that people can add....gotta love Polycount and other sites for always pushing people in the right direction and motivation!
Like SyncViews said, my article is meant as a general guide. Even within the same studio you're going to have TAs with different skill sets and areas of focus. And that's the way it should be IMO.
I think one major thing that's in contention among Tech Artists themselves is how much art they should be doing, vs. just coding. In my opinion once someone is only creating code, and not actually touching art, then they've become a programmer, not a TA.
TAs shouldn't be creating in-game art, that's not their job. But they must be a part of making test assets (alongside art leads) to refine art guidelines for the team, and that means knowing the DCC tools the artists use, and how artists work.
IIRC there's a heated discussion about this on TA.org somewhere.
Yeah it's a fun field, keep at it! The industry needs more good TAs.
Now that I look at it my workflow could be faster by just adding scripts XD O man the thrill of the hunt.