PDA

View Full Version : Which first? Tcl or C++ ???


slooper
12-24-2003, 09:15 AM
I am wanting to learn a programming language and can't decide what would be most beneficial to a career in high end CGI. On one hand, if I learn C++ it will help me with Renderman, Mental Ray, 3dsmax SDK, etc. On the other hand, Tcl will allow me to use MToR SOOOO much better, and maybe other programs such as PiranhaHD... I also am primarily focusing on linux apps such as Shake, Maya, Houdini, Piranha, and Renderman. I know this is very vague, but I could use some advice from other TDs out there or those of you who have gone this route already. My ultimate goal is to be either a Technical Director, shader writer, procedural fx animator, or pipeline engineer. And yes, I do hate sleep.

Thanks!

Sean Looper

Hugh
12-24-2003, 11:11 AM
Well, as a pipeline engineer myself, I mostly work in C++ - at the moment, most of the work I'm doing is plugins for Shake and Maya... I've done a couple of tiny Tcl scripts, but that's about it (don't really know Tcl, though)

Personally, I think C++ is a very solid language to know - it will help you all over the place, and it certainly won't hurt to know it.

Another language that I'm learning at the moment is Python - I've not used it before, but I suspect that it will become my scripting language of choice in not too long - it seems great because it can be used for both short scripts and quite complex programs....


Anyway, going back to what you wanted to do:

Technical Director: Well, it really depends on what kind - if you're working in Maya, though, there'll be a lot of MEL to do.

Shader Writer: I really don't know enough of what this involves to be able to make suggestions here...

Procedural FX Animator: This depends on whether you'd just be the Animator, or if you'd be the FX TD too... If you'd be setting it all up, then you'd certainly want to know MEL - and knowing C++ would be useful too, so that you could (if needs be) write new fields, for example...

Pipeline Engineer: What you need to know for this purely depends on what kind of thing the company wants for the pipeline - it might be a matter of shell scripts to set everything up properly, or it might involve writing plugins for the various pieces of software involved so that the user doesn't have to think about where things go.... I'd definately say learn C++ for this - and shell scripting/python/ - also the various scripting languages in the packages you'd be using - MEL and Shake Macros in my case...



Hope that's been of some use...

mnm|cg
12-24-2003, 11:31 AM
C++ is the way to go. Personaly i don't like TCL/TK. I would prefer Python.

I mean you can start with Python and than you can move to C++.
Cause Python is the most beautiful and easy language.

slooper
12-24-2003, 05:40 PM
I was expecting that C++ was the way to go, at least initially. I hadn't considered Python. I will most likely learn that second, then. Maybe someone could tell me if Tcl is really worth learning then considering I've only seen it in PiranhaHD and MToR? This is a great help though.

Last thing, are there any specific concepts in C++ that I should avoid or focus on? I have several books on the subject, and want to do more of a crash course in C++ rather than become a complete guru. I don't plan on being able to write extremely complex programs, just to be able to script SDK plugins and other simple external tools for Maya or 3dsmax.. Also, I know a lot of MEL already, so it's good to know that it is relied on heavily in a production environment.

Oh! And is it possible to compile C++ scripts for windows on a linux machine? If not, are there free compilers for windows that I could use?

Thanks again for all the advice!

Sean

mnm|cg
12-24-2003, 06:00 PM
Python won't work with Maya like Mel or C++ ...
But at least(i assume you are a beginner to programming) Python is the best language around for beginners and for undestanding the basic concepts of OO programming. And it's very very easy. Once you learn Python, you'll see that you can learn other languages easier.
As i said, forget about Tcl/tk. C++ and MEL will do your Maya jobs....
And it's a great language. And Maya is written in C++. Also Windows and Linux are written in C/C++.
Start with Python(for understanding object oriented programming) ,then switch to C++. That's my opinion.

gga
12-27-2003, 11:07 AM
TCL is currently considered a somewhat outdated scripting language and has never been known for its speed. Its syntax is also rather cumbersome and the lack of true variable types and built-in OO is also an issue.
However, in the early 90s, it was the best alternative as it was the only easy to use graphic toolkit (Tk). Not surprising, within the gfx community some programs still do use it. Besides MTOR, Houdini and Nuke also rely on it for part of its GUIs.

Today, the graphic toolkit that made tcl so attractive(Tk) is available pretty much for all scripting languages with a similar syntax, so people tend to prefer more powerful or modern languages.

Python has recently evolved to be a very mature and one of the most advanced scripting languages around. Yet, I admit not liking its syntax and conventions (also, some of the new constructs in 2.2 like iterators and similar seem quite obfuscated to me). Also its speed still leaves some to be desired, imho, when compared to perl.
However, a language that I'd highly recommend these days (probably even over python) would be Ruby as a potential investment for the future. Ruby combines the simplicity of python's syntax (with no stupid tabulation issues or having to type so much) with some of perl's strengths (builtin regex, closures, etc). Its OO is probably one of the simplest around and it has a very elegant way of binding C++ code, too. More so, it recently introduced a way of getting rid of bindings all together and allowing DLL functions to be called directly doing a direct mapping of Ruby<->C structs (this could potentially make adding C libraries to the language a no brainer perhaps). My quick impressions is that its speed is closer to Perl's and that it is more strongly typed than python (ie. numbers are builtin classes).
Unlike python, ruby can function as sed, perl or similar replacements in the command line with identical syntax, too.
Also, besides supporting Tk, it supports FOX which is a much more advanced GUI toolkit (on linux and Windows, no mac yet) and the GL bindings are also the best I've seen in any scripting language.
Ruby's biggest disadvantage is that it is similar to python's state some years ago: it is rather new and it is not yet as popular and as such documentation and books are still scarce.
But I am already starting to see A LOT of future in it.

dmaas
12-28-2003, 02:01 AM
If I were hiring a TD-type person I would want them to know at least C, C++, Perl, Python, and at least some of the more common package scripting languages (MEL, etc). And with C I mean not just the language but also most common APIs (POSIX and/or Win32, definitely OpenGL, BSD sockets, at least one GUI toolkit, etc). With C++ I'd add at least one of the major "programming support" APIs - STL, Boost, .NET/managed code, etc (just so that you're not writing your own String or List classes all the time). Knowlege of make, sed, awk, etc would be implied.

Ifx3d
12-28-2003, 04:44 AM
woah there is a 3ds max SDK?! where can i get it?

Hugh
12-28-2003, 11:50 AM
I would have thought that your 3DSMax reseller would be able to give you directions - I don't know whether it comes with Max or whether you have to download it seperately....

Certainly with Shake, you have to contact Apple and ask for it...

MGernot
12-29-2003, 05:38 PM
Originally posted by Ifx3d
woah there is a 3ds max SDK?! where can i get it?

It`s on your 3dsmax CD.

rendermaniac
12-30-2003, 02:58 AM
I think Python is a really great scripting language and an excellent one to start with. It has a decent set of libraries and has good objects. Plus it doesn't have pointers which can be confusing (although useful in certain situations).

Perl is great too, although there is definitely a dividing line where you should use Perl for small things and Python for anything that needs complex data structures (not that Perl can't do them but they get crazy quickly....).

Ruby does have it's place, but I couldn't recommend it at the moment as it hasn't really got into production use widely yet. This may change, but not yet. (Japan may be different).

Most places use the unix C shell. Knowing foreach and while loops is useful, but for anything more complicated do yourself a favour and use Perl or Python.

You will have to learn C at some point (and C++). If you want to make it more interesting a really good tip I got was to learn it with something else - eg OpenGL. Then at least you have something graphical to work with. http://nehe.gamedev.net/ is a great place to start. Personally I'd start with the GLUT version or a windowing system you'd like to learn rather than win32.

Also for shaders you will need to know RenderMan Shading Language (RSL) - there is almost no way of getting away from it! Essential RenderMan Fast by Ian Stephenson (http://www.amazon.com/exec/obidos/ASIN/1852336080/rendermania-20) is a really good introduction, but you'll want to get Advanced RenderMan by Antony Apodaca and Larry Gritz (http://www.amazon.com/exec/obidos/ASIN/1558606181/rendermania-20) as well as it goes into far beter detail. If you only get one get Advanced RenderMan. Good renderers to practise with if you don't have Pixar's Prman are 3delight (http://www.3delight.com/) or Aqsis (http://www.aqsis.com/) . Unfortunately exporting to RenderMan without MTOR can get tricky.

Also Steve May's Renderman Notes (http://www.accad.ohio-state.edu/%7Esmay/RManNotes/RManNotes.html) and the new RenderMan Accademy (http://www.rendermanacademy.com/) are very good online resources.

Houdini's VEX language is based off of RenderMan Shading Language and Mental Ray uses C. RSL is based off of C anyway so knowing some C first is encouraged.

Personally I wouldn't bother learning Tcl specifically. The Tcl MTOR uses you can pick up very quickly. The main area Tcl is used is SLIM templates and the number of keywords is fairly limited. Download some from http://zj.deathfall.com/. The important thing to note is that the names of your parameters is not important, only the order as they are used to call your RSL function. This is the opposite of calling shaders from RIB where the name is important and not the order.

Also MEL is extremely useful - even though it is the most frustrating language you'll ever use! Alias has the Personal Learning Edition (http://www.alias.com/eng/products-services/maya/maya_ple/index.shtml) if you don't have access to the full version. Unfortunately you won't be able to export to RIB without the full version. The best way of learning this is to think up some projects which need complex setup and try them out. Something like laying out a street scene and then blowing it up (particle expressions help too) or flocking rather than character animation.MEL scripting for Maya Animators by Mark Wilkins (http://www.amazon.com/exec/obidos/ASIN/1558608419/rendermania-20) is a really good book for learning MEL and expressions. Complete Maya Programming by David Gould (http://www.amazon.com/exec/obidos/ASIN/1558608354/rendermania-20/) is more of a reference, but goes into more detail and also covers writing Maya plugins. (very useful).

Hope that helps a bit.

Simon

Hugh
12-30-2003, 07:34 AM
I started really getting into Python yesterday (just dabbled with it last week) and I'm going to have to, again, add my voice of support to it....

It feels as powerful as C++ but as easy as shell scripting....

Give me a few more days to get into it, and I might be able to give more of an in-depth review of the language

rendermaniac
12-30-2003, 01:42 PM
Now if we could only get Alias to rewrite Maya in Python ;)

Simon

playmesumch00ns
12-30-2003, 02:08 PM
And get Pixar to ditch that sonofabitch that is Slim and write a replacement in Python. mmmm yummy python.

Speaking of which, anyone see that thing about a 49' python in the paper today?

JLV
12-30-2003, 11:48 PM
So to try and summarize the mass of knowledge above for a beginner like myself.
It sounded like;
Learn Python first, for ease of use, and then learn C/C++?
Hold off on Ruby for lack of reference?
I know it's also preference, and individual needs, but this is the path I gathered.
Thanks to everyone who has posted so far in this thread.

playmesumch00ns
12-31-2003, 02:00 PM
It's also worth noting that Python and C++ are used for very different tasks. The choice about whether to use python or c++ is determined by the task you want to do, you can't simply switch one for another and expect great results.

JLV
12-31-2003, 08:16 PM
playmesumch00ns

Thanks, that much I do understand.
I keep reading that Python is a great first language to learn, and that it is a good way to ease into C/C++. I've been learning C on my own. I'm wondering if, with what I keep hearing about Python, maybe that's the way I should be going about this. Again thanks for your reply.

rendermaniac
01-06-2004, 02:38 AM
Sorry to be offtopic, but anybody wanting some Ruby references can find a good introduction here http://www.linux-mag.com/2002-04/ruby_01.html.

It looks like it could translate pretty easily to Slimtemplates as a lot of the syntax is similar. eg. Tcl's puts and {} block statements - useful to put RSL code in like Slim does.

But it also has Python style classes, iterators and functions and Perl style regex (the one thing I don't like about Python).

I think it's definitely worth having a look at by people out there (but not really as a first language - hence offtopic). I'm warming to it.

Simon

playmesumch00ns
01-06-2004, 09:36 AM
Looks like the bastard offspring of python and tcl *shudder*. Thanks for the heads up, will be keeping an eye on this one...

rendermaniac
01-06-2004, 03:05 PM
Bit more of a menagerie a trois. There's a bit of Perl love child in there too!

Simon

artistx
01-06-2004, 06:21 PM
Yeah, it looks like you have the right idea JLV in your summary of suggestions. I would say that if you are pressed for time and you really need to prioritize, learn C first. I really believe that even though C has pointers, if you have good introductory texts in C you can start in C no problem. C has been around for awhile now and many of the new authors are aware how to properly teach the concept of pointers and their appropriate usage.

I would get atleast three texts on C. Get one reference text which just lists all the functions of C, one layman's text which attempts to ease the pain of learning basic C concepts, and one other advanced C learning text which gives exhaustive in depth explanations for C concepts. This way, you read the beginner text on C. If there is something you still don't understand, you go to the more in depth text. Once you are programming in C, you use the reference text to get to functions that even an advanced teaching text would not include(perhaps the functions come too close to redundancy). I think C++ is a bit over-hyped these days. Yes, Object Oriented (OO) programming has some advantages, but procedural programming for the most part can accomplish many of tasks done in OO languages with less confusion. I believe we lose many potentially great programmers because they took an OO class like C++ as their first class instead of C and became hopelessly confused or discouraged. For your own sake, learn things one step at a time. Learn C before you learn C++.

As mentioned earlier, C is the language which many other graphics-specific languages resemble. RSL looks like C, the original renderman scene description is C, and I believe Mental Ray is C. If you were to read the "Renderman Companion" without knowing C, you would most likely be lost. By learning C, you would be killing the most birds with one stone - so to speak.

Next I would learn either RSL or C++. C++ will allow you to work more with 3d software API's. I believe both Maya's and 3ds Max's SDKs are C++ oriented. You may not get tangible results as fast as scripting, but again, you shouldn't have trouble moving from one software API to another because they both will be using C++. With scripting, you are almost going to have to start from scratch again, because you can't make any assumptions about the nature of the scripting language. MEL is not Maxscript. Eventually, you will want to learn scripting because it's often faster to throw some scripted code together. By the time you have learned C and C++, learning scripting will be a piece of cake.

As Rendermaniac has said," - there is almost no way of getting away from it!(RSL)". Since you just learned C you would easily flow into RSL and the C API for renderman scenes. There are so many influential computer scientists(who are suprisingly accesible) that use renderman and many renderman compliant renderers strive to include the newest rendering technology. On top of that, the renderman support base is strong. Renderman also seems to be the best of the few open doors leading to visual effects production house techniques. Many effects houses use renderman compliant renderers for their shots and speak in renderman-ese when they give behind-the-scenes technical presentations and explanations. Renderman is probably the closest thing to a postscript/universal language for rendering.

If you are not pressed for time then I would start at the beginning (or close to it). Get a text on the basic workings of a primitive computer and how assembly language/machine code works with the microproccesor. You don't have to study this in detail, just an elementary understanding will do. Once you have this knowledge, C pointers and addresses will make more sense. What's the point in all this? If you want to understand the core of programming, eventually, you have to study hardware.

Before you study C++, read a book on the Object Oriented philosophy. By studying the philosophy separate from the rules of grammar and syntax in a particular programming language, the student can more easily pick up any OO language. Why? because the underlying OO concept is the same for all OO languages. Unified Modeling Language (UML) is a way (sort of) to study the philosophy of programming, but it can get into cumbersome rules as well. It is a good way to approach programming design though.

So I recommend:

A.Bare minimum

1. C
2. C++
3. Renderman


B.With all the time in the world

1. Hardware/Software general knowledge
2. C
3. Object Oriented Philosophy
4. C++
5. Renderman
6. Scripting

JLV
01-07-2004, 02:43 AM
rendermaniac -
Thanks for that link.

artistx -
Thanks for that very informative post. Your suggestions pretty much parallel the plan I've started with. I get a little confused when I hear such amazing rants about Python, Ruby, etc., and how that is the best/easiest way to get your feet wet in this stuff.

Katachi
01-07-2004, 03:07 AM
A.Bare minimum

1. C
2. C++
3. Renderman


Sorry, but I totally disagree here. From programming point of view it is completely nonsense to learn C if you want to learn C++! C is a subset of C++ anyway, means it is still possible to write C in C++ (though not recommended at all ;), but this is has several reasons (also marketing, so the old C-gurus can turn to C++ more easily). Well, C++ is actually not based on C! but was developed as an own language. The programming paradigms are either object oriented and procedural/structured. C++ isnīt meant to be a pure OO-language because it MUST be possible to write systemprogramming with it!

Stopping this programming stuff, what I want to say is, if you want to learn C++, then do it right away and do NOT!! learn C before. This does not help you understanding OO and C++, it even prevents you from better getting into it. (Actually Stroustroup once even said that itīs kind of a mistake letting C-Coders programm in C++, because they cannot get away from their old C-Stuff). Stroustroup clearly says: DO NOT CODE C IN C++ if you want to code real C++. And I can only support this!

Why you should not learn C if you want to learn C++ is shown well here (a clear remark that C++ is meant to be independant, but containing a C-subset because of strategic reasons):
http://www.research.att.com/~bs/bs_faq.html#prerequisite
http://www.research.att.com/~bs/bs_faq.html#how-to-start

And maybe an interview with Stroustroup (pretty up-to-date):
http://www.artima.com/intv/goldilocks.html

Well, didnīt mean to hijack anything here (cause usually I do not look into this forum at CGTalk but that one was interesting :) )

Just my 2 Cents...

Good luck!
Best
Sam

Btw.: I think python is a good deal too. Very good OO language IMO!

gga
01-07-2004, 04:44 AM
Originally posted by rendermaniac
Sorry to be offtopic, but anybody wanting some Ruby references can find a good introduction here http://www.linux-mag.com/2002-04/ruby_01.html.


That link is dead.

For the introduction to the language, check:
http://www.rubycentral.com/book/


For general questions:
Newsgroup comp.lang.ruby
It is an active community with knowledgeable people (including matz, the language creator and two other Japanese implementers all of whom speaks good English)


For good comparison/transitions from other languages, check:

Python:
http://raa.ruby-lang.org/list.rhtml?name=pythontoruby
http://www.ruby-doc.org/RubyEyeForThePythonGuy.html
http://www.rubygarden.org/ruby?RubyFromPython

C/C++/Perl/Python
http://www.informit.com/isapi/product_id~{A76D1D1E-AD7D-483E-AB8D-38FB188396C5}/element_id~{F35419F2-DABB-4CDE-9347-98A5092F0778}/st~{58BD298A-1CB6-4590-B92D-95DFC1EA9331}/session_id~{29B134D0-2DC8-4469-AD1A-23BD4E2364E3}/content/articlex.asp
http://www.rubygarden.org/ruby?RubyFromOtherLanguages


Perl
http://www.theperlreview.com/Issues/The_Perl_Review_0_6.pdf



I think it's definitely worth having a look at by people out there (but not really as a first language - hence offtopic). I'm warming to it.
[/B]

I'd not consider it off-topic. I'd rank ruby as one of the best introductory languages, even if its docs currently suck. O'Reilly and others now have books on it (albeit about the much more inferior 1.6 version). Some universities in the States are now starting to teach it either together or as an alternative to python.
I've been using the language for about a week now and have absolutely fallen in love with it. I don't know. It just clicked with me. It is everything I wished python and perl were.
It's the second language I've learned in one day (TCL was the other, albeit of course TCL's syntax is silly) and the first one I became proficient within a week.
I've now removed python from my hard drive (a language I always hated) and will only keep perl around for its great docs on regex.
Ruby's phylosophy going around the net is that is a language with a Principle of Least Surprise (ie. what seems to logically work, usually does).

Here's a good description that echoes my own.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/79533

slooper
01-07-2004, 05:56 AM
This is all fantastic stuff - I'm not sure I want to delve so far towards Technical Direction if I have to learn .NET etc... This may be career-counter-productive, but I think I want to learn enough to be able to supervise productions, but still be able to work on the creative side of production. I don't want to be an IT guy, even if it is a gfx IT guy. That aside, I believe I will continue to pursue C++ and add Python to that list. I completely understand the importance of RenderMan and will return to my reference books on the subject once I feel I have a better control of C++. Quick questions though. If I want to write my own shaders from scratch, do I need to learn C, or is C++ sufficient?

Thanks for all the replies!!!

Sean Looper

artistx
01-07-2004, 07:41 AM
Hello Designer. I agree with you wholeheartedly. Perhaps my wording was off a little, but my message was already getting long. In my defense I just want to clarify the matter. Unfortunately, this will lead to another long post.

One should learn C first, but not so much because of its similarity or ~encasement in C++, even though both these things are contributing factors. Yes, C programmers often try to hack through C++ by using C methods. This goes to show that you can't halfway learn or use any language. By the same token, you can't learn C++ and go backwards and expect C to perform the way C++ does. Many of the functions do the same thing, but the keyword is different. I would guess, hacking through C with C++ wouldn't be a fun experience either. So our poster should thoroughly learn C and then completely learn C++ and its etiquette. This provides a conceptual and historical progression of learning. This will prevent the horrible C/C++ hybrid code.

I chose C as the first one to learn because it is fairly straight forward (withholding the pointer) and will give our poster the broadest application area. That is, he/she can apply C to RSL, the renderman C api, etc. C++ will also give you a broad application area, but there is more to swallow in terms of language and concept. It caters more to a modeler's api (i.e. Maya SDK or Max SDK). C resembles other rendering languages more so than other full languages like Java, Visual Basic, etc. In addition, C has a wide-spread general usage in the programming community. So with ease of use and broad application, C is giving you the best bang-for-your-buck so to speak.

Slooper, I think C is sufficient the majority of the time if you want to write shaders. On occasion C++ may be needed. It's good to learn both. I would choose C first.

It is a tough decision. I hesitated myself even as I was typing the first post on whether to recommend C or C++ first. If you want to ease into programming and you want to work with shader programming, I would go with C. If you want to work more with scene manipulation and plug-in work, go with C++. One eventually will call on the other and so, in the end, you will have to know both to a certain extent. For example, let's say you only know C and renderman. Then one day you want to bring one of your models that you built in a modeler package, say 3ds Max, into your renderman compliant renderer because your renderman compliant renderer has some extra cutting-edge features in it. You would need to use C++ and the 3ds Max SDK to build a good RIB exporter. On the other side of the coin, lets say you've been building exporters using C++ for the longest time, transfering files from XSI to Maya to Lightwave and so on. Then comes a day when you need to bring your scene into a renderman compliant renderer. You need that renderer because you have a special shader you want to build and no other modeler software offers the ease and extensibility you're looking for in their built in renderer. So you end up having to learn C to properly program and to better understand the shading languages and renderman scene description.

I believe that we lose beginner programmers because they are trying to swallow the OO concept and an accompanying language as opposed to learning a procedural language first. C++ is a powerful language, but it could be too much at once. That's why I recommended that our poster buy a book on the OO oriented philosophy first. Even though C++ can't be neatly categorized as an OO language it does use OO concepts. Going from C to C++(or any other OO language) is not a smooth progression. I never meant to imply this. Learning the general OO philosophy first will help the transition. However, I do believe that going from C to RSL or the renderman scene description is a fairly smooth conversion.


Statistics show that first time programmers pick up scripting faster than they pick up a full language. I suppose it's ok to learn python,perl or ruby if you have the time and don't mind waiting to learn another language before you can apply it to shader programming. I would be more an advocate for learning scripting first if it allowed you to apply the scripting as a rendering language. For example, it would be nice if you could apply your python code as RSL or scene description. There may be API bindings out there like that, but they are not in widespread use. Not as many renderman users would be able to help you if you had a question and you were using that scripting binding. You will still have to learn C and C++. With wiser C language teachers and better texts out there, I truly believe one can start out using C as their first language.

Hugh
01-07-2004, 09:21 AM
Originally posted by gga
That link is dead.

That's because it had an erroneous '.' on the end...

It should be:

http://www.linux-mag.com/2002-04/ruby_01.html

rendermaniac
01-07-2004, 12:38 PM
Out of interest there is a very nice RenderMan API in python called Cgkit http://cgkit.sourceforge.net/

I think the Aqsis developers have used it quite a bit.

Simon

artistx
01-07-2004, 04:21 PM
Interesting, Rendermaniac. I just downloaded that cgkit. I wasn't aware that the python api binding was big in the aqsis community. Thanks for the link.

prettyh8machine
01-20-2004, 08:39 AM
Im a dev guy with a CS background and Im currently working in the technical dept. of a (post) production house/animation studio. Our country is very new to all this and my company is pretty much the only company right now doing all this.

After reading all your posts, I was just wondering how can I use my CS knowledge (I know substantial C/C++ and MEL etc.). Right now I, alongwith some other guys, are doing all the procedural animations, scripting and plugin development etc. but all is for MAYA right now.

I've had around a year's knowledge of game/graphic programming with OpenGL and I used quite a lot of 3rd party APIs like SDL, OpenAL etc. for different purposes and I also developed a plugin for a map editor for our game using Python so I know Python is an easy language and I can pick it up very quickly.

Question is: where do I use this knowledge to help my company ? Like we don't have any formal FX/Rendering TDs and stuff...so I wanted to know how TDs actually work using all these languages so that I try to go in a positive direction.

Thanks

P.S. Currently we guys are working on procedural animation setup for a pool of sperms swimming in a direction (sort of flocking) etc. for some movie.

CGTalk Moderation
01-17-2006, 01:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.