Return to XSI 2005-05-27 - By kim aldis
Back
I've a few comments, below:
> -- --Original Message-- --
> From: owner-xsi@(protected)
> [mailto:owner-xsi@(protected)] On Behalf Of Raffaele Scaduto-Medola
> Sent: 27 May 2005 10:20
> To: XSI@(protected)
> Subject: Re: Return to XSI
>
>
> - Programming. Avoid VBscript. JScript is perfect as it is
> close to C syntax.
>
Jscript is good and I very much agree with you on the vbscript thing.
Vbscript simply isn 't structured enough to allow you to deal with large
code libraries in any kind of sensible fashion. But if you're building
pipelines you need for xsi to talk to the outside world and Jscript, being
made with security in mind, isn't good at that. Perl and Python are - see
note on sql below. I'd advise Python, Perl is a tad rambling where Python is
very tight but still has a good module set. Mysql, XML, sockets and good
file handling are some of the things that Python will do for you where
jscript won't.
> The other benefit, which I would encourage
> is using Mel like syntax ($ signs in front of variables,
> commands like syntax passing unique single variables at the
> top of your scripts).
This puzzles me; I'm not sure why you advise this but I would personally shy
away from trying to make any tool behave like another one. I also think
that's one of the biggest mistakes you can make with Xsi. I've spent a good
deal of time scripting Unix shells and Perl and I'm quite thankful not to
have to prefix variables in this way. And there are more important things to
be careful of when developing variable naming conventions. If it's for the
purpose of highlighting variables then a good text editor or IDE will do
that for you much more constructively. I'm genuinely curious, though.
What does 'commands like syntax passing unique single variables at the top
of your scripts mean?
> XSI can uses many of MicroSoft engines,
> and JScript can be programmed with objects very efficiently.
> But the practical issue of finding high level Object oriented
> programmers is difficult, Keep it Simple. At Omation, I was
> able to hire people with Mel experience and let them workout
> and learn XSI guts through the SDK (first using commands,
> then more and more using the object model).
> interested in scripting.
Obviously this would be because there's a shortage of good xsi people, not
because hiring Mel people is preferable ;-) You *will* need to consider OO
if you're building pipelines. Getting the best people you can, though, is
critical, I can't emphasise this enough.
>
> -mySQL rules. Unfortunately I'm not sure how you can do this
> on Linux, but in Windows world you can create a "sql" object
> which is acessible within XSI. IE you can setup the
> automation tools to check-in/check-
Python will do this on both Linux and Windows (as will Perl if that's your
bag).
> out assets,renders
> automatically between XSI and mySQL (or I believe any SQL
> flavor). This makes larger project manageable, and automated.
> If your in management side, you need to understand that
> tracking assets trhough production is important (something
> SQL engines can do really well).
>
> -build an command autoloader. XSI as pre-built tools to
> auto-install addons, plugins, etc... I would recommend you
> figure out some scheme to auto register scripts directly,
> without having to package them, that way you can make the
> connection between your scripts and the users at your
> facility "live". I've build a couple over the years in both
> Maya and XSI.
> The main benefit, is that everyone can automatically get the
> latest greatest version of scripts available. And tied to a
> consistent syntax format that everyone adheres to, it will
> make your script development, sharing knowledge and encourage
> people working in teams to solve complex problem. With system
> I devellop, I could actually spread out the work of rigging a
> single character to several people at the same time
> (chaining, deformation, facial targets...).
This is what plugins and workgroups are for. There are performance issues
here ( Graham ;-) ) but there are ways of being selective about what loads
for what class of user.
>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
