RE: spdl.... good or bad?

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

> The reason for this is mental ray's inability to re-define
> shader declarations and keep its head (think: existing
> shader connections and phenomena), otherwise I'd
> be all over it. It's a complete horse but you would
> have the same problem even if you were using
> those oh-so-dreamy-looking .mi files in Maya or Max.

[Matt]
the issue isn't whether I use a SPDL or .mi file to define parameters, it's 
the workflow for doing so.  Having to learn multiple API's to work within a 
single application is ridiculous.  I can understand the divide between XSI 
and mental ray, but having a distinct language that isn't native or friendly 
to either is the part that's poor.  That's why I say abolish the SPDL and 
move the parameter definitions to something more workable with the rest of 
XSI.  Just to write a shader requires some knowledge of C/C++, JScript or 
VBScript, SPDL, and possibly more languages/API's depending on your needs - 
that's too much for a single tool.  Instead of a SPDL, I'd rather see 
something like XML or HTML because it already supports embedded Javascript 
and is easy to manipulate to create the desired interface for the user.  It 
would also work with the rest of XSI as it already supports XML/HTML in 
Netview and other areas.  Consolidation is what I'd like to see.

I'd prefer a standalone mental ray license over SPDL or the dreamy .mi files 
with Maya/Max, but nobody provides standlone ray licenses with the 3D app. 
The downside to that, of course, is I cannot change parameter values easily 
during testing without rendering a gazillion frames.


> Also, if you have a spdl where spdlcheck does a
> poor job of validating, we'd love to have it so
> we can harden it. It's hard to cover all the cases
> without having input to test against.

[Matt]
I don't have those examples with me because those were from when I was 
writing shaders at Omation.  In a nutshell, I got the impression that 
spdlcheck didn't check the entire SPDL for errors, but rather only targetted 
lines dealing with GUIDs and certain registered components.  If there was a 
syntax error in a property layout, if data types mismatched for a parameter 
between the top and bottom sections of the SPDL, or if something was defined 
twice in a lesser critical area of the SPDL, spdlcheck would be fooled 
rather easily.  Upon installing the shader, XSI would do it, but silently 
generate in invalid preset or some other corrupted entity that wouldn't be 
discovered until renders failed and I had to conduct and exhaustive post 
mortem to figure out why.  The culprit would've been something as stupid as 
a misplaced comma or semi-colon, but it would take a few hours to find it 
because neither XSI nor mental ray would provide errors leading to the 
source, they'd complain about the symptoms instead which were often 
unrelated.


> As of 5.11 there is no registry storage for shaders.
> Have you tried it?
>
> It also solves the registration problem. Ie. shaders are
> automatically updated on startup and their
> preset is even regenreated. Most spiffy.

[Matt]
Unfortunately, I don't have access to XSI v5.11


> That is true, compound objects (colours, vectors,
> matrices and structs) were registered as COM objects,
> as were shaders. As of 5.11, as before, that is no longer
> the case. These COM hacks were deplorable and we've
> been doing our bestest to take them out. Given their
> pervasive nature throughout the code base (it was
> implemented during ye olde Twister) it has taken up
> until now to do the work required.
>
> You might want to check out later versions of XSI, we
> *do* make the occasional progress.

[Matt]
So what happens now if I try to install 2 different shaders that have the 
same GUID defined for a parameter?


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