I'm certainly no Luc-Éric around here, but having had some issues with
spdls and having had developed few of them I wish to offer my opinion.
On 7/3/06, Stefan Andersson <sanders3d(at)gmail.com> wrote:
I have always been wondering about the spdl system that we are using
in XSI.
First of all, I don't think it is correct to think about spdls as a
"system", which imho would mean that a system could be replaced by
another, given sufficient time. I think it's more appropriate to think
of them has being one of the top-most layers of the XSI architecture.
That is, the GUI layer of XSI.
It seems a lot of the times when a plugin fails it's due to a
either
a.) Corrupt SPDL
b.) SPDL contains wrong search paths
c.) It doesn't contain everything that is needed.
I have never met these problems. My biggest gripes with spdls are the
fact that their implementation makes heavy use the Windows registry.
(note that the next two paragraph apply to XSI 4.2)
One big problem with spdls is not caused by spdls directly, but it is
through spdls that this problem manifests. Sometimes, through certain
manipulations, custom shaders installed into user and workgroup
locations will mess up with the Windows registry. References to the
shader spdls will be maintained while it should not. As a result, a
custom shader whose spdl path changes may become unusable, resulting
in error messages when trying to load the shader.
Another problem we have been having recently is that again, through
certain manipulations, someone connecting to a workgroup will not have
shader spdl register. I have no idea why, but re-installing the
shaders in the workgroup fixes the issue. I'm not sure this is
directly related to spdls, but again this is through spdls that the
problem is exposed.
XSI 5.11 changed the context a bit by no longer requiring shader spdls
to be pre-registered. They are registered (in the Windows registry or
not I have no idea) by XSI when XSI loads, pretty much like
self-installed plugins. However I have not played with 5.11 enough to
see if the problems I described are still there.
Anyhoooo... I'm no spdl genious, but the recent article on XSI-blog
made me think what the actuall purpose of a spdl is?
I think spdls are the GUI building blocks. Many GUI toolkits work this
way: you stuff in the elements, organize them into a layout, and
attach events/callbacks/logic to these elements. Then these elements
are inspected by the underlying code, the parameter values are pushed
in that code, and the operations called by the user can be performed.
The spdl is the XSI mechanism that implements these concepts. It is
the way parameters are exposed to the user through a graphical
interface. Also, and I believe this is GUIDs are for, they allow the
"under the hood" code to work with the said parameters by looking up
the Windows registry.
It is a pain in
the butt... but is there an actuall advantage to have it like this?
I see these advantages with the spdl:
- it's hackable, which means you can read it and modify it if you want
- it's flexible. Okay, before shooting at me, let me clarify: I don't
think it is the most flexible design at all, but I think it gives a
reasonable amount of flexibility. There is a fair deal of
customization you can do with spdl.
- logic: this is another flexibility item, logic allows you to put
custom code into existing GUIs, which is neat.
- when refreshing spdls, connections with other parameters do not break
Speed? Stability? or have other software makers a better solution?
I think a developer should answer this one. I've heard that Maya
implements mr shaders through the mi interface, which basically means
no layout and no logic. You get the full set of parameters, even those
you don't want the users to play with. But that's just what I
heard.....
Thinking of the rendertree as a bunch of macros is a really good idea
I think. and I can see myself in the near future building a lot of
these custom nodes.. to remove wast render tree hierarcys. The problem
then is to also install all those SPDL's on the farm, which can cause
a hole other set of problems.
What sort of problems?
Cheers
Bernard
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
