RE: spdl.... good or bad?

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

> I don't think SPDLs necessarily do what you think they do...
>
> There is the part at the bottom, that is the layout for property pages.
> What's happening here is that the data is read and put in the layout 
> manager.
> You can poke layout and attributes in scripting in the same way that it 
> does.
> We're using SPDL so that's human-editable file and there is no point in
> moving that to XML or anything else, as there is an API to create and
> modify property page layouts programmatically.
>
> The SDK team doesn't really want people to continue to use SPDL
> for custom properties or scripted operator, if I'm not mistaken
> only the shader developers should still need to use them, to define
> the parameters (which are tied to the order of the parameters in
> the shader's 'struct').  Although I understand that some people are still 
> on XSI 4.2

[Matt]
I don't think users want to use SPDL either ;-)

I'm well aware of the property layouts and such as I have written a lot of 
mental ray shaders since XSI v1.0.  Using SPDL to define shader parameters 
and layout and having a logic section that's not accessible or controllable 
from scripting within the XSI interface is a complete pain.  Every time I 
have to make a change to my shader, I have to unregister my shader, close 
XSI, edit the SPDL, run the SPDL through 'spdlcheck' (which does a poor job 
BTW), re-register the shader, re-launch XSI, then re-open my scene to test 
the change.  Complete pain in the ass as it's very slow and cumbersome.  If 
I had access to a standalone mental ray license, the process would be 
significantly quicker and easier:  recompile shader then re-render .mi2 file 
from command line - that's it.  No more than 3 seconds tops.  XSI's method 
takes several minutes per iteration.

I would like the ability to drive some of that stuff via scripting so I 
wouldn't have to dork around with shader registration all the time and 
generating presets.  XSI should be smart enough to recognize the SPDL info 
and dynamically push the appropriate bits to mental ray at rendertime rather 
than rely on a preset that constantly needs updating with each edit or 
corrupts XSI because it somehow becomes out of sync with the other shader 
components.  The biggest issues I run into with shader development is 
registry corruption from bad SPDLs - SPDLs which are deemed to be clean by 
the spdlcheck command but still fail to install properly or generate valid 
presets for whatever reason.  The system for validating a SPDL is pathetic. 
Every 10 weeks or so I have to reinstall windows (or at least, XSI) to get 
around all the flakiness from the corruptions or else I won't know if my 
shaders are working properly or not.


> The part at the top is the definition of the parameters, and that behaves
> slightly differently between shaders, and custom property set/ scripted 
> op,
> but in both cases it's used to build a data structure that is then saved
> in the preset.  Whether you're able to add or change connection types,
> it's not a really limitation or function of the SPDL, but the eventual
> architecture working in conjunction with mental ray.
>
> in both cases the SPDL is not a programming API but it's a script to
> poke things either in the layout manager, or the parameter definition
> dictionnary, a one-time thing.

[Matt]
Which is exactly why I don't like it.  It's very limiting. The system needs 
to be more dynamic to allow changes as the scene gets pushed to mental ray. 
If I want to change a shader parameter from type miScalar to miVector, then 
I should be able to drive that from within XSI, not go through the 
uninstall/re-install hoops I have to go through now.


> btw, even though there are GUIDs for each parameters in the SPDL,
> the only part that that was relying on the windows registry is the code
> to make the link between the preset file and the SPDL.  The parameter
> guids are things that XSI uses internally and were not going in the 
> registry.

[Matt]
You may want to check that again as I think that only applies to plugins and 
operators.  Prior to XSI v5.0, (I haven't checked v5.x yet) all shader 
parameters were registered individually in the windows registry.  If two 
different shaders contained the same parameter GUID, XSI would complain and 
not allow the 2nd shader to be installed/registered due to GUID collision. 
This could easily be confirmed using the registry editor and looking up the 
GUID.

What I would really like to see is a streamlined workflow for mental ray 
shader development in the area of eliminating the shader preset if possible 
and relying more on the data in the SPDL - but making the SPDL more dynamic 
and accessible to XSI Scripting instead of the hardcoded black box it is 
now.


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