Return to XSI 2005-05-27 - By Anthony Rossano
Back
Hi Folks!
Having worked with RSM here at Omation and seen how the pipeline has
progressed, here are my two cents!
1) The most important thing in a large production is for there to be one
person who has a PLAN and carries out the plan. Raffaele was that man.
The plan doesn't have to be permanent, obdurate, immoveable, it can
evolve as the production does, but you have to start somewhere.
That somewhere involves naming conventions, filesystem conventions,
asset management, scene tracking, human resources, user education,
job-policies and a tech support structure.
2) Raffaele is right about people evolving from VB baby script to JS to
C..... Just as people evolve from the command scripting style to the
Object model. A studio plan should include helping the tech staff
start simple and move up.
3) Raffaele is right about MySql. I think a solid database is the most
important piece of software in the production. More important that which
App you use for modeling, or lighting or rendering.
4) the TD shortage.... true, true. It's Softimage's fault for fu*king
up the education/training channel so badly for the last five years.
That's where many of todays TDs came from.... It constantly shocks me
how Soft missed the boat there. Until there is somewhere new geeks can
go to learn technical aspects of XSI this shortage will persist. (don't
take this personally, G.....)
5) I agree that a consistent calling convention, variable conventions,
and a method for auto-distribution of scripts and tools is a great
thing. I would only quibble with Raffaele's plan of concatenating lots
of input variables into a string and then parsing it in the script to
extract the variables again.... it works but its ugly!
peace out;
ATR
Raffaele Scaduto-Medola wrote:
> 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
>
--
/* Anthony Rossano
Technical Director
arossano@(protected)
anthor@(protected)
jobs at omation!
www.byrecruit.com
*/
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
