Re: spdl.... good or bad?

["Matt Lind" <speye_21(at)hotmail.com>]

I always found SPDL to be rather limiting - more trouble than it's worth.

There are times when I want a shader to take different types of inputs or 
act in completely different ways depending on the context which the shader 
is being used.  This requires a dynamic interface to remain optimal, but I 
feel SPDL forces me to hardcode certain elements or make finalized decisions 
I don't like.  SPDL is also in it's own sealed off world - one of the few 
areas of XSI that you cannot access from scripting.  You can put scripts 
inside of a SPDL file, but that's not the same as dynamically 
adding/removing/modifying SPDL data from another script or scripted 
operator.  SPDL is not user friendly or ergonomic.

I'm not too fond of SPDL documentation either as it's not entirely clear 
other than for simple shaders.  When you move to other shader types or need 
to implement controls to access things like vertex color properties, GUI 
widgets, or userdata such as Particles the docs are useless and lead to 
major hair pulling sessions.  Tasks that should take minutes end up taking 
days or weeks because you have to search the net or pick somebody's brain 
3,000 miles away for that elusive undocumented nugget of information to make 
it work.

One area where I was hoping SPDL would evolve would be with the phenomenon 
architecture allowing ability to create connections on the fly or from 
within shaders.  I would like to see a system where I can connect multiple 
shaders and not have to use multiple SPDLs to get the job done.  The worst 
part is the reliance on the windows registry.  I can see why GUID's were 
chosen for parameter definitions, but there has to be a better way.  Having 
to define dummy parameters to pass data between 2 shader SPDL's seems very 
wasteful.  It would also be nice if there were a way to reference a 
parameter by name instead of by GUID so certain types of things are 
possible - such as allowing a shader to reference a specific shader 
parameter so it can be overridden on a cluster material without causing GUID 
collisions upon shader registration - and I mean reference the parameter, 
not it's value.

In short, SPDL seemed to have a purpose at it's outset, but the development 
went on the backburner to the point that it's now archaic.  It would be 
better to replace SPDL with something a little more common such as XML or 
HTML where JScript and other languages can manipulate it as user's are 
desiring.


Matt

---------------------------------
Matt Lind
Animator / Technical Director
Softimage certified instructor:
   Softimage|3D
   Softimage|XSI
Matt(at)Mantom.net
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi