Yes, I tried it, but it's not as easy as that. In the case of shaders, not only do you need the GUID of the shader, but also the GUID of each and every parameter of that shader as it's the parameter GUIDs that Softimage stores to remember a shader's connections within the rendertree. You also need a functioning .dll so when Softimage parses the .spdl on startup it'll try to execute/load the .dll that it points to. The .dll can be a dummy that simply returns true or false, but it has to function within the API framework and return the data types declared by the shader.
Now that Softimage (as of 2011) has moved to shader defs using parameter names instead of GUIDs, I'm not sure how relevant this is anymore. Or at least, for new scenes created from scratch. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Amaan Akram Sent: Saturday, September 15, 2012 12:31 AM To: [email protected] Subject: Re: CLSID error and XSI base I wonder what would happen if you were to create a dummy SPDL in a workgroup and give it the GUID of the missing one that is making XSI fail to load a scene. Never tried, but often wondered... did anyone ever try this? On 15 September 2012 02:39, Matt Lind <[email protected]<mailto:[email protected]>> wrote: Pure guess: Not sure if still the case, but early versions of XSI used GUIDs to identify objects, plugins, etc... Kind of like using an ID to look up a record in a database table. Problem is when the item being looked up is not installed, there's no available information to determine what it was or how it fit into the larger scope of the data. I'm also guessing much of the data was stored in data structures like graphs to represent the scene data which would imply you need to have a valid object before you can get the next object. Example: you would need a valid shader to know which other shaders were connected to it's inputs as each shader parameter has it's own GUID. If the shader is not installed, then the GUID would point to a missing record which in turn means other locally connected items couldn't be retrieved either. If relationships are complicated enough, it might not be possible to clean up the scene. I think that is some of the reason why the self installing plugin architecture was written as well as converting from GUIDs to parameter names for ICE attributes and shaders in recent releases. Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Andreas Bystrom Sent: Friday, September 14, 2012 6:20 PM To: [email protected]<mailto:[email protected]> Subject: Re: CLSID error and XSI base while on the subject, what's the reason that xsi has always handled this case so poorly? a missing plugin would always render the scene non-functional but having xsi clean up and basically destroy the scene just because a plugin is missing or even a different version was installed isn't terrific. On Sat, Sep 15, 2012 at 3:49 AM, Ben Rogall <[email protected]<mailto:[email protected]>> wrote: The original is here: http://shaders.moederogall.com/ Haven't touched that page in a long time. Ben On 9/14/2012 10:27 AM, Luc-Eric Rousseau wrote: it sounds like it; the clsid probably changed in the process. I could find zbumb for xsi with google search.. it shouldn't be too hard On Fri, Sep 14, 2012 at 10:44 AM, Eric Thivierge <[email protected]<mailto:[email protected]>> wrote: If I remember correctly zbump was integrated as the default bump shader a while back. Am I correct Luc-Eric? -------------------------------------------- Eric Thivierge http://www.ethivierge.com -- Andreas Byström Lighting TD - Weta Digital -- 3D Artist/TD @ The Mill, London http://www.amaanakram.com
