Return to XSI 2005-05-27 - By Raffaele Scaduto-Medola
Back
I think, its important to remember a few key points.
The first and most difficult being finding lack of talent in XSI.
Relatively speaking compare to Maya, the XSI TD community is not has big
as Maya. This is aggravated by the fact that getting work visas for
foreigners in the US has become extreemely difficult since 2003.
Which was a played a big decision in how I setup the original pipeline at
Omation. If you can't get people to help because of restriction beyond
your control, you will need to figure out some way to train the people you
can find to learn while on production. And in the US most available people
will come from a Maya background.
The good news with this type of work you actually increase the amount of
users who can get into XSI.
I am fully aware there are more efficient ways to work with XSI, but I am
interested in the most pratical way. In a perfect world I could have hired
top level programmer to write actual C++ code and compile directly into
the software,have the US government grant me carte blanche on visas, and
of course get all those people within a reasoneable amount of salary
expectations. Of course that's not what I was facing when I started this
process at Omation.
As for the command syntax. Again there are many different ways to code.
Everyone likes to bring in their own flavor. The basic framework I setup
works, because everyone from our high level programmer, to our most
junior, fresh out of Maya world could understand it cleary straight away.
Again I know its not the most effecient, but it enable me to setup a level
plane for everyone to work together as a team. Inside of those registered
functions, programers could do whatever they wanted, but the call to that
function would never change, this is a way to make sure people wouldn't
have to rewrite (redo work) their script everytime someone changed the way
their function worked. Its simple and modular (not computer science work
but a pratical engineering problem).
The interesting this to see was the natural progression scriptors (ok not
programmers) would take throughout production. As internally to the
functions, I could see the evolution from use of commands and variables
(just like people were used to in Mel) to a object passing which you can
do in XSI.
The basic nutshell...
myFunction ( $baseName, $argumentList, $debugState ) {
1- parse out the $argumentList token...
(eg "curveName=objA,color=red,xpos=0.34" )
2-do whatever you like using XSI commands, or passing objects,
or if so incline $$$ call a compiled plugin.
}
This makes is easy to get lots of people with different levels of
scripting/programming to work together. Which is what you need when making
a feature film (or any large project).
As for the autoloader, I used it because it makes it really easy for me to
manage over 100 user plus a renderfarm user to make sure they are getting
the right tools setup. If you have a better way of managing large sets of
users without having to go to each computer to see what is registered,
what is not, then great for you. We had adminstrative issues with having
plugins registered through workgroup, as it meant everyone need to have
administrative root access to their local system. Maybe now its been
worked out (or not ???), but then again my point is, it worked... a no
brainer, because in production you should be impedede by Operating
system limitations. Again in the best world scenarion I'm sure there's a
cooler more efficient way to use XSI built in registry system, but since I
didn't have the time to dig deep inside, I went with what I knew works.
My most basic point is about the practicality of a large scale production
using XSI. It is doable, but need to wary of how you plan on spending your
time solving problems...
RSM
On Fri, 27 May 2005, kim aldis wrote:
> 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
>
__ ____ ____ ____ ____ ____ ____ ____ ____ ____ _____
Raffaele Scaduto-Mendola - www.turbolinea.com
raffaele@(protected)
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
