I’ve been thinking about learning C++ for about a year now - maybe longer.
So I was looking through books and websites regarding recommendations and I found this book called: “Accelerated C++ - Practical Programming by Example” by Andrew Koening and Barbara E. Moo.
Seems like a good book, judging from the intro. But I’m stuck at the whole “compile and run” -part.
I got Visual Studio 2012, but the manual is either a mess or in too much greek for me. Nowhere can I find any info about how to actually run and compile C++ code.
Maybe this book isn’t as good as I though, considering that it says you should visit their webpage about how to compile C++ code - well, there is no such info on their website… seems pretty lackluster to me.
Anyway, I’m looking for resources: online crash-courses, videos, e-books, any kind.
I want things that are compact: that doesn’t go into pointless complex details about things you are going to overlook later anyway. I want something that goes straight to the point, highlighting the fundamentals and cornerstones of whatever code needs to be learned in order to advance. I also want resources that provides example code AND work assignments.
How much I want to learn:
-Coding interfaces in a windows environment.
-Coding I/O to a custom program connected to Maya and/or Photoshop
-Maya API
-Writing shaders (HLSL, CGFX, D3D
-Basics of 3D engine programming (or at least the lingo)
pretty far the easiest thing to do would be to start with a text editor (notepad) and gcc from the command line and just ansi C. Work your way up from simple .c files to more complex ones with headers. Learn basic data types, arrays, pointers, file IO, memory allocation, etc. Then move to C++. (that’s how my school taught C/C++. We had gcc and good old borland C for DOS ) Then move to Windows or a framework like Qt. Get comfortable with it. Get comfortable with compiling and linking and building for x86 and x64. Then move on to Window’s APIs, learn how to create DLL libraries because that’s the basics you’ll need for Maya plugins and Photoshop (for extending ExtendScript). Get comfortable with 3rd party APIs. Read up even more on Photoshop to create true Plugins. That’s the rough order. You may have to reverse it a bit in the later stages I think.
Visual Studio itself can be quite a beast to tame if you’re not familiar. That’s why I recommend a simple text editor to start for your first steps. Then you only have to wrestle with the C language and not the big IDE. Once you know more about compiling and linking (and debugging), some stuff in Visual Studio should make more sense. But at the beginning, just pick one fight
At the beginning you really want to keep things simple. I think there should be some free wiki books for basic C/C++. I remember stackexchange.com had a few questions about book recommendations.
I haven’t done any D3D programming, so I can’t really help with that. I got myself to the level to write Maya, Photoshop and ZBrush dlls which I can access from there.
would love to learn C++ as well. but just do not see the need since Python is generally OK for my needs. however, i do understand that i need to get into it one of these days.
This guy has tons of tutorials that are useful for the tech guys like you and me. i highly recommend watching some of his tutorials and following them as an alternative learning solution. he has some videos on C++ and Python as well.
If you’re willing to pay for it I would recommend the C++ Maya Plugin Development course run through CGSociety. I used that as an initial entry point into developing plugins using C++ and found it really useful. There is also one dedicated purely to shaders, though i have not done that myself.
If you work within a studio, don’t be afraid to ask some of the programmers to give you a crash course of VS and general compiling queries. After all, they deal with that on a day to day basis!
Koenig and Moo is pretty much the ‘standard’ intro – which says a lot about how unfriendly C++ can be, but that’s another story. From my limited understanding, though, it’s an approach that tries to make it less dependent on down-to-the-metal C-style memory management techniques and more ‘object oriented’ so it’s probably a good step in for somebody coming from Maya and Python.
Your menu of options is pretty broad, i’d strongly recommend doing it step by step. In theory, at least, engine design, graphics programming, Maya interfacing and C++ are all independent of each other. However they overlap because the rythmns and conventions of both engine programming and Maya are deeply informed by C++'s way of thinking – If you’ve looked at the maya API documentation, for example, through the eyes of a python programmer you’d probably think the whole thing was pretty goofy.
So, if you’re serious about doing Maya plugins or game engines you probably want to start with vanilla C++ and do enough of it that (a) you can look at C++ code and figure out what’s going on (as in, ‘what’s with all those stupid colons’ or ‘why does this function have no body at all?’) It’s not that hard, although the language is certainly harder to pick up and run with than Python. Becoming good at it is a bigger matter - C++ is much closer to the hardware than Python, so the difference between ‘this runs’ and ‘this is done right’ can be huge. If you can avoid trying to do it all at once you’ll probably have an overall easier time.
Thank you all for your replies and a special thanks to you RobertKist for the in-depth learning path you described. I would like more of this - even more in-detail (more links etc) - if possible
It might sound like I want to rush this, skip important steps and so on but that’s not entirely the case: I want to avoid pitfalls and avoid learning unnecessary steps because frankly I do not have enough time. I can spend maybe an hour a day on this - maybe more during the weekend. So how can I keep my learning small but intensive in scale, focusing only on what is practically important?
Comming from the other direction (art instead of code) into TA seems a lot harder to me than the other way around. In fact, I don’t know a single TA (either IRL or on my LinkedIn network) who got into this with a background in art instead of code. That makes this look like an even bigger problem than it probably is.
GCC/The command prompt isn’t too unfamiliar to me so I guess that’s a good way to start. I took a Linux course in uni and I’ve used DOS in the past.
But would you mind explaining what you meant by “work with simple c. files”? Are you talking about file management? Creation, deletion, modification, renaming, moving, combining - all that? Or did you think about anything in particular?
I really appreciate all your links guys. Bucky’s C++ tutorials seem great! And the Maya API stuff will definetly come in handy.
Python is a very different language from C++ and involves a very different mindset. Although there are some commonalities (object-oriented programming, for example, and the basics of program logic), being good at one often involves deliberately blocking out the rules that apply when doing the other.
If your career focus is tech art, Python is more valuable - it’s more in line with traditional TA tasks and it’s better suited to the way most studios make and manage art tools. If you want to be a ‘real’ programmer (scare quotes intentional) C++ is a better choice: there’s not much of a market for high end games programming in Python. Look around here and you’ll see a lot of python discussion with a smidge of C++ - OTOH go to GameDev.net’s tech forums and you’ll see a lot more C++ than Python. Of course, good coders can swap languages, just like good artists can make good work in Max or Maya – but there is a reason why lots of pipeline gurus like Python while lots of game coders swear by C++: different tools for different jobs.
Speaking purely from a personal bias, I’d add that the notion that TA’s ought to come from a code background is a dangerous one. We already have tools programmers, they’re great folks who do useful stuff but they aren’t tech artists. However, I rarely hire anybody who can’t do at least passable production art as well as solid code. This makes hiring harder, no doubt, but it means that the people doing the work understand the problems of the artists they are supposed to be serving, and can see the problem from the perspective of their users.
[QUOTE=Theodox;21457]
Speaking purely from a personal bias, I’d add that the notion that TA’s ought to come from a code background is a dangerous one. We already have tools programmers, they’re great folks who do useful stuff but they aren’t tech artists. However, I rarely hire anybody who can’t do at least passable production art as well as solid code. This makes hiring harder, no doubt, but it means that the people doing the work understand the problems of the artists they are supposed to be serving, and can see the problem from the perspective of their users.[/QUOTE]
Plus just makes it incredibly easier to talk to artists or your art director and tell them whats up
oh tell me about the hiring But having C++ knowledge in the team really makes some things easier. Also good to have some coders who could teach an otherwise ignorant TA about things like automatic doc generation, unit tests, coding standards and so on and then work with the team to make sure adaption of these practices work. Not all TAs who can code decide to look into these things themselves. Many of them tend to be quite comfortable with just hacking away - which can be okay for small scripts, but is really bad for those huge pipeline tools (or worse, for the people who maintain them).
But yes, you need to know your production art workflow and ideally have experienced it yourself. Just as designing cars without having ever driven or ever even seen one won’t work that well
as a rigger TD, python is more than enough for me. if you are going to write something more mathematically demanding then C++ is the best thing to learn.
python is very good for it’s utility and productive way fo doing things. the book is OK…i will not say that it is a the best solution but i would advise that you have a primer in MEL first. my only complain about the book is it tries to condense a topic into a single chapter. other than this, this is a must buy for every Maya TD wishing to learn python or somebody who wants to take their python to the next level.
digital tutors has a great series done on python as well and i would recommend it,too…
[QUOTE=ricoMambo;21466]as a rigger TD, python is more than enough for me. if you are going to write something more mathematically demanding then C++ is the best thing to learn.
python is very good for it’s utility and productive way fo doing things. the book is OK…i will not say that it is a the best solution but i would advise that you have a primer in MEL first. my only complain about the book is it tries to condense a topic into a single chapter. other than this, this is a must buy for every Maya TD wishing to learn python or somebody who wants to take their python to the next level.
digital tutors has a great series done on python as well and i would recommend it,too…[/QUOTE]
I’m fully comfortable working with MEL so in that case Python does feel like the natural next step due to how often it’s used in this business. And knowing python would mean I can take the first step into photoshop -scripting without too much of a hassle (or so I want to believe). So yea, maybe Python is a better choice (postponing learning C++ …for now). After all, one year ago I knew nothing about MEL and today I can look at pretty much any code and figure out how it runs, what it does, and so on. If I can do the same with Python in a year, and then C++ in another year, I would be happy.
I would only learn C++ if you are sure you will be using it. Same with any other kind of language.
On my previous job I learned Python because that was necessary to solve their pipeline problems.
On my job at Codemasters I learned C++ for writing a plugin in max because we needed speed.
It makes learning a language a lot more rewarding.
In the end it is just a tool. Knowing a lot of tools does not make you a good developer. What you end up doing with the tools is more interesting.
good point about C++. When I got into it again it was mostly curiosity about using Qt natively. But I ended up writing lots of smaller tools with it - the stuff where I don’t know if the user has a Python interpreter installed, or when a 30 mb PyQt+Python py2exe program would just be too unwieldy when the same code in Qt/C++ is just a few MBs.
Hi there a bit of advice as per my experience…there is no point of doing a crash course unless you have a good knowledge of then programming language…just get it done thoroughly…yes it will take time but with sincere dedication it is easily achievable.
mel to python might be a better jump for what your are trying to accomplish, python is fully object oriented and less restrictive than mel, can give you direct access to QT, and since you mentioned photoshop integration, with just the comtypes module, you can easily control photoshop from the maya python interpreter or from a external interpreter.
really if your only experience is with mel, just learning the object oriented end of python and learning to bend your mind to think that way will be hard enough. your first few python scripts will prolly look and run similar to mel, but as you learn more and more features of the language it really changes the way you work.
Also you mentioned maya api, that can be access via python too and i have done everything from custom ray trace solutions, to exporters, to photoshop integration all with the maya API on python, and it is more than fast enough.
you don’t even need COM if you execute photoshop scripts as commandline parameter to photoshop.exe and create them dynamically from your python code (dDo uses this method. works very well!)
and what advantage would that give that you don’t get just using a com setup? Sounds more complicated having to use a python to write JS or VB for PS to run, when you can just use python + comtypes
Well, if you work with COM you might know the limitations. But here’s my list why you can consider this approach: you can use this approach in languages which have no support for COM (natively there’s none in Python unless you want to go via ctypes). You don’t need to distribute a 3rd party module - all you need is built in in Maya’s Python already. You can target older maya/python versions (e.g. 2.5 with x64, or even 2.4). You can use this approach with Max Script too if you like, or from ZScript. You can target a specific PS version. The user can have as many PS versions installed as he likes for this to work, x86 and x64. And if you read the Python COM code for PS you will see that it’s actually fairly similar to the ExtendScript code. You use the same commands, same parameters, etc.
Of course I’m not out to convert you (or anyone who has a working COM solution). It’s merely a different approach which could be useful for some. Add it to your repertoire and remember it as another tool in your belt
) Then move to Windows or a framework like Qt. Get comfortable with it. Get comfortable with compiling and linking and building for x86 and x64. Then move on to Window’s APIs, learn how to create DLL libraries because that’s the basics you’ll need for Maya plugins and Photoshop (for extending ExtendScript). Get comfortable with 3rd party APIs. Read up even more on Photoshop to create true Plugins. That’s the rough order. You may have to reverse it a bit in the later stages I think.
But having C++ knowledge in the team really makes some things easier. Also good to have some coders who could teach an otherwise ignorant TA about things like automatic doc generation, unit tests, coding standards and so on and then work with the team to make sure adaption of these practices work. Not all TAs who can code decide to look into these things themselves. Many of them tend to be quite comfortable with just hacking away - which can be okay for small scripts, but is really bad for those huge pipeline tools (or worse, for the people who maintain them).