This article is intended to XSI users who have no or little experience with scripting and programming at all and would like to learn. Hopefully it will help them take the best decisions.
Why do people start scripting in XSI?
There are several flavors of people who start scripting in XSI. Here there are presented more or less in order of technical expertise. Note that these are just guidelines and generalities, not absolute truths!
-There is the hardcore programmer. This person can code anything he likes, from scripts to shaders to full-fledges self-running applications, and in any area of your choice: mail servers, render management, shaders, database transaction systems, and the list goes on. While these person can create astonishing shaders, great compiled operators, even standalone renderers or entire particle plug-ins, many of them would not be able to create a complex 3D scene. This is because these folks are known as pure developers, that is, they excel with code. These folks, very rare that is, are brought into larger studios as developers to develop new technologies. It is rare they are brought in only to write scripts, when they do it is to complement their low-level C/C++ code. Since they profer to handle low-level code, they will generally learn scripting only because they have to, to interface their tools with XSI. They do not necessarily take the time to become good XSI scripters.
- Then there is the typical technical director (TD) and technical artist (TA). This guy has to learn scripting, period. The TDjob is to create tools for the artists and solve problems in XSI, the TAjob is deliver technically challenging material that most artists could not do. Scripting is a necessity. There are very few question at what langage he will learn first, ideally, he'd learn them all. Generally, TDs/TAs know about several technical aspect of XSI: scripting, scripted operators, expressions, shaders, spdls, custom operators, and so on. For these guys, scripting is just another tool allow them to deliver that complex material. These guys generally make the best scripters, as they are the ones who spend the most time in scripting documentation. More, most TDs and TAs are actually artists with very advanced technical expertise, so they understand the way artists think, and will develop tools with the artist in mind.
- The next one is already proficient in at least one scripting /progamming langage, not necessarily related to XSI, and is not a TD/TA. This person is just an artist with a technical edge, has done several tools and scripts. XSI uses industry standard langages, so there are chances that one may know any XSI scripting langage without ever seeing XSI before. For these people, starting scripting in XSI is just as natural as starting texturing is for a texture artist. They are already aware of the pros and cons of scripting, and generally will want to take advantage of it as soon as possible to create their own tools so they can be a better artists. Also, it is a lot easier for them to learn scripting in XSI since they are already familiar with programming concepts. When don't know the langage, they first choose a langage and then open the langage documentation and learn it. When they already know the langage, they simply open the XSI scripting docs and learn about the langage implementation in XSI.
- Finally, there is the clueless guy, the one has never done scripting or programming. For him, reading others scripts is like reading unordered scrabble words. This person may be simply interested in scripting, may have been convinced by another that it would be in his interest to learn scripting, or he might have reached the point where he feels that scripting is a necessity to go further technically. This guy, of course, will have the hardest of times.
Step one: choosing a langage
This is probably the most difficult one to answer, as this is a very subjective matter. There are pros and cons to every scripting langage. I will try to present these pros and cons to the best of my knowledge, but remember that what follows is mine only, and anyone may have a different view. Also note that I'm not the most advanced scripting guru there can be, so in one year I could have a different opinion.
- VBScript: Well-rounded for scripting in XSI, lots of features. The XSI documentation is almost 100% VBScript, and most of the available scripts on the internet are in VBScript. Another big advantage is that it has "Visual Basic" in its name, wich means that it can be used in other contexts than XSI. For example, Excel uses VBA, wich is almost the same thing, and you can use your VBScript knowledge to do actual Visual Basic projects, that is, self-running compiled applications.
However this is one important point that has to be taken into consideration: Microsoft. VBScript and the Visual Basic family is Microsoft technology. If you are like me, you may know that MS is synonymous of bugs, security holes and deficient support. As with every Microsoft technologies, it is unlikely that VBScript will be upgraded a lot.- JScript: Another well-rounded scripting langage for XSI, many features as well. I prefer JScript over VBScript, for two reasons: one, I find the syntax 10 times clearer in JScript, and two, I don't know very much VBScript :-P The big problem with JScript is the documentation. Although it's not as bad as it used to be, still most of the XSI scripting documentation doesn't have JScript examples. So you're left on your own in many situations. Again this is not as bad as before, since you can ask on mailing list and forums, that means delay in answers... if answer there is. Another disadvantage is that it is also a Microsoft langage, and thus you never know when the langage will stop being upgraded. Finally, be aware that most internet ressources about JScript are for web applications, since this is the main area where JScript is used outside XSI.
- Python: I have to say upfront this is the langage I recommend. You can do about anything with this langage: XSI, applications, database, email, servers, and so on. Despite having been created about 20 years ago, is still subject to new releases and improvement. Since it is open source, it means that when a new version is released, it has be extensively tested and debugged by brigades of people. The langage documentation is great. You have countless ressources available, for all kinds of interests. There are countless free modules (sort of extensions) that give more functionality to Python. Plus, one thing it has and not the two previous is that you have standalone interpreter. An interpreter is basically a shell where you can type code and execute it. It means that you type lines of code and debug them very quickly, without having to use it in another application. Another big advantage is that there is no consideration regarding Windows/Linux. Used as a standalone, Python will run seamlessly on both platforms. Plus, the implementation in XSI 4.0 is very reliable. Finally, the most important to me, is that the syntax is extremely clear, consistent, compact, and simple.
The disadvantage of Python are that examples are almost non-existant in the XSI scripting docs. Although this is not such of an issue when you already know another langage like VBScript or JScript, it can be an issue if you are not very proficient with Python and don't know any other langage. The other disadvantage is that on Linux, the implementation of Python in XSI requires XSI to lead active scripting binaries each time you run a script or a command, wich involves a delay of 1 to 3 seconds! Hopefully this will be solved in future versions of XSI.- Perl: I don't know anything about Perl, except few things told be others. Perl is said to be the best langage when it comes to rendering management tools and this sort of applications that handles lots of data at the same time. Perl is multi-threaded, and there very performant with large datasets. Perl is known to be the best langage when it comes to regular expressions. Perl examples are also non-existants in the XSI scripting docs.
Step two: learning the langage
There is important thing you have to do and will spare you lots of headaches: learn the langage outside of XSI. Many, including myself, do this error: they try to write scripts while learning both the langage and the XSI object model at the same time. So basically you are trying to learn three things at once when you do that: programming concepts, a langage, and the use of a langage in a particular application. These are three different things, and to receive specific attention. You can't move to the next without being confortable with the previous one.
Learning a programming langage has to be done methodically, otherwise you waste more time than you gain knowledge. As it has been mentioned a moment ago, the first thing is get familiar with the programming concepts. These are universal and apply to all langages. They are the fundamentals of programming, and include things like looping, converting data of a certain type into another type, referencing data with variables, and so on.
The best ressource I have seen so far to do this is this one:
http://www.freenetpages.co.uk/hp/alan.gauld/
This will introduce you to programming concepts using mostly Python. Don't take the langage into account, this website is so general and the examples so well explained that the langage is irrelevant. Once you have read this extensive tutorial, you are ready to actually learn a langage. Note that there is nothing that prevents you from trying the examples on your side (that means installing Python, see below).So know that you know what programming is all about, you are ready to actually learns the ins and outs of a langage. One of the reasons why I recomment Python is that when you install it you get an extensive tutorial that shows you how to use its main functionalities. Get it here:
http://www.python.org/download/
I also invite you to install PythonWin, a module specifically intended for Windows, and will allow Python to be available in XSI:
http://prdownloads.sourceforge.net/pywin32/pywin32-203.win32-py2.3.exeIn the case of VBScript and JScript you may wish to install these:
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp
And also here is the VBScript and JScript documentation:
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp
Here is a good ressource for VBScript beginners:
http://www.microsoft.com/downloads/details.aspx?familyid=411C2B99-C7BC-4972-9513-15E53C1F681A&displaylang=en
The only thing with VBScript and JScript is that since there is no standalone interpreter, you will need to used webpages and execute the code in a browser. That sucks, but it will be a good exercice to learn how to do web pages with lots of functionality :-PBasically what you need to do know is to read the langage documentation and learn the langage. Try the examples in the documentation. Note that the Microsoft docs do not come with tutorials, so you will want to look for additional tutorials. Once you are confortable with data types (string, boolean, integers...), variables, constants, conditionals, loops (for, while, and the likes), functions,methods and regular expressions, you are ready to start scripting in XSI. At that point, it should not be too hard, all you'll have to focus is the XSI object model and few thingies about the implementation of the langage.
Step three: the XSI object model
To any serious scripting in XSI, you need to know the object model. The object model is a term to describe an approach to scripting that involved dealing with data is if it was objects, and how this data is structured. Basically, the software and the scene is represented as a hierarchy of objects with properties and methods. Here I'm not talking about 3D object, but programming objects. For instance, even parameters are objects with properties (like "value" for examples). Once you know how to traverse this hierarchy to access objects you can write lots of scripts. I'm not saying that everything is easy (while accessing partitions properties can be tricky, it is downright a nightmare to do anything with geometry subcomponents like vertices and UVs).
Fortunately the XSI scripting documentation focuses a lot on the object model, and the examples abound. For this reason, you will soon find that as long as you use the object model, it doesn't really matter what scripting langage you use, because the object model is the same in each langage. Only the syntax and langage feature change. This makes the code generally easy to port from one langage to another, without regard to what langage feature you use.
Note that the object model is not necessarily the end of it all. Although you should always favor the object model approach to scripting, sometimes a script is more effective with a good old low-level command. You will find that there are things that will not work with the object model (that you though they should) but works very well commands. The opposite is also true.
Step four: doing something useful
Now that you know scripting, you need to write useful code. It is one thing to create scripts, it is another to maximize the use of this scripts.
Learn as soon as possible how to handle functions, and how to break your code into functions. This will allow you to reuse easily your code. You will find that very oftenly you will reuse the same code in different context, so having it in a function is simply a matter of copy-paste and modify few things here and there.
Comment your code as much as you can. Not only this will help others to read your code, but it will help you read your own code. By experience, I can tell you it doen't take long (like a week) before forgetting about a script. When you reopen the script to take things out of it or modify it, it will be a lot easier if you have lots of comments and a clear syntax than if you have a solid block of code. Also, if you start doing toolsets (toolbars, layouts and the likes), you will need to create help pages that launches in Net View).
After some times you will also notice that you use a lot certain functions. For example, if you are a rendering TDs, you may have to use in most of your scripts a function that traverses the Render Tree. In these cases, you should consider making these functions into self-installed commands that you can call from other scripts. Therefore you don't have to find scripts that use this function to copy-paste it into your current script, all you have to do is to call the installed function with the appropriate arguments. Also, this will make your scripts shorter and easier to troubleshoot.
Also try to make your scripts "dumb-proof". A dumb-proof script assumes that the user is dumb. That is, it will throw lots of warnings, message boxes informing of a user error, and offer secondary ways of achieving the result. For example, if the user didn't select the right thing, a message box should pop-up telling him. A pick session could start to give him a second chance. If the pick sessons failes, then another msg box pops. This way the script educates the user how to be used.
Your scripts should give feedback about its progress. It need not being every step logged, but things like a picked object or the completion of the script should be logged. In fact, the more logs, the better, as long as it doesn't slow down the script. When you log everything you can your scripts will slow down considerably.
Make your log message meaningful. The log should not report the named of the picked object, but tell the reader that the reported name is actually a picked object. See what I mean? Also include in logs the name of the script, so you know that this message comes from your code, not XSI. For example, if your script deletes an object, the delete command will be logged by XSI, like this:
DeleteObj(null);
But if you add your own log after the delete command that says what object has been deleted, it could look like that:
//INFO : <MyScript> : myObject deleted.
Finally, when you write a script, it has to be done with the artist in mind, not yourself. It means that its use has to be as smooth and intuitive as possible. Never assumes an artist will know intuitively what to do.