SPDL and GUIDs!!!

[Atyss]

>> 1. Do I just copy the GUIDs from other SPDLs and put them in my New SPDL file or 2. do I have to generate new GUIDs for each new SPDL file I create.

The latter. The point of GUIDs is to have a truely unique code to idently the object. You have to generate a new GUID for every shader, and every parameter of that shader.



>> Any help would be greatly appreciated, I'm looking forward to hacking and generating my own shaders, though I realize I still have to build up my knowledge of C++.

Only if you want to write shaders. If you are porting mr shaders from other software, reading mi files and writing spdls will do.



>> Also, does anyone know where I could find a complete listing of GUIDs used in XSI, seems like that would be a lot eaiser than searching through SPDLs all day.

Ew. You may not know but there at least several thousands of GUIDs used in XSI, as every single parameter and property has a GUID. You can in fact find that number when you run Norton WinDoctor, wich reports several thousands of invalid registry errors (these are the XSI GUIDs registered in the Windows registry). You may want to look into the Windows registry if you really want to list the GUIDs.
Btw, check out the DataReposity entry in the scripting documentation. This allows you to retrieve the GUID of an object (understand programming object, like a parameter).


Cheers
Bernard

[sealtm7]

Hey Bernard,

Thanks for your help. Guess I need to do some more exploring. Would it be possible for you to roughly layout your process of making a new shader via SPDLs? Do you use the Shader Wizard for this process or do you just create the SPDL file in a text editor and then register it through spdlreg2 and then create a preset through spdl2preset? As far as generating new GUIDs for each parameter in the SPDL, does that mean you have to custom code (in your .dll) for example, an ambient color function or as I asked before can you just copy the ambient color GUID from say, a lambert SPDL? Also, how does the SPDL link to the .dll file that's generated, does every parameter need to be releated to a line of code in the .dll or can you freely add SPDL parameters? Thank you for you help. I''ve been running through this for about 3 days and I feel like I'm missing something. Oh yeah, your production DVD was a real help in getting up to speed in XSI, though I have to go through a few more modules (was a MAYA user for 3 years).

Thank you from a confused XSI noob...

[bravmm]

H,

just some quick answers:
You can use the wizard to set things up quickly, and finish in a text editor. The wizard is known for errors in the GUID's, so I alsways edit finally within a texteditor.

Registering could be done the way you described, you can also fire up xsi and install the spdl from within xsi itself. Be sure ot have the dll and spdl in the same install folder or xsi will not find all files.

For the rest I didn't come that far yet, but it sounds plasible to copy/paste excisting shadercode from one spdl to another, due to the fact that's basic xsi code. But I have mostly converted shaders for practice, my programming skills are very very baisc in this.

Hope this helps,

rob

[Atyss]

One step at a time....


>> Do you use the Shader Wizard for this process or do you just create the SPDL file in a text editor

You can proceed this way. When you become more familiar with the spdl structure, you can start directly in a text editor. However, the Shader Wizard just makes things easier.



>> and then register it through spdlreg2 and then create a preset through spdl2preset?

I don't know what spdlreg2/spdl2preset is, but all you need to do is put the dll and spdl in the same directory, then install the spdl. This is create a preset file, wich is the actual shader file you put in the Render Tree.



>> As far as generating new GUIDs for each parameter in the SPDL, does that mean you have to custom code (in your .dll) for example,

You don't mess with GUIDs in dll. dlls are the compiled C++ code of the shader. It doesn't care about spdls, GUIDs, and the likes. All you have in such files are parameters (name and definition), algorythms, links to other files etc.



>> an ambient color function or as I asked before can you just copy the ambient color GUID from say, a lambert SPDL?

I would not do that. Spdls are the interface elements of compiled components. If the compiled component contains parameter X and another contains also parameter X, you are better to have two different GUIDs so XSI will never make a mistake and confuse the two. You can theorically reuse GUIDs, but this subject to risks.


>> Also, how does the SPDL link to the .dll file that's generated, does every parameter need to be releated to a line of code in the .dll or can you freely add SPDL parameters?

You are free to omit parameters in the spdl. However, the paremeters that you use must match the names and order of those in the dll. The good thing is that if you are translating a shader from Maya or 3ds max, you can simply read the mi file and write the spdl parameters in the same order.


Cheers
Bernard

[sealtm7]

thank you Bernard and Rob,

Its making a lot more sense, Ill be going through the process all day today. I guess what was confusing me was was seeing all the GUID calls in the phong shader, which I assume is just an encapsulated render tree. When I checked the GUID numbers they mached other reference GUIDS (for example color to scalar reference GUID), which led me to the idea that it was just a copy paste thing. I'll work with the Shader Wizard and try what you have both suggested, but I may be back online tonight to ask more questions or hopefully share my success. Thank you both for your help, where the SDK has not been too clear for me.

[Atyss]

The SDK is indeed not very clear in this area. Personally I think SI should provide an easy way to package render tree network into phenomena, as you can do in Maya.

Speaking of phenomena... You mentioned the reference to existing GUIDs. That's because most shaders available in the Render Tree are phenomena, not shaders. A phenomenon is a network of shaders that appears like a single shader to the user. All its parameters are exposed in a centralized interface. The Phong, Blinn, and such as phenomenon comprising of at least half a dozen shaders. So by creating spdls you can also create phenomenons. In this situation you can reuse GUIDs to reference existing shader parameters you want to pull in your phenomenon.

But if you want to write a shader from scratch (that is, in C++) or port a shader from another software, you are better to regenerate GUIDs for each parameter, for the reasons I mentioned.


Cheers
Bernard

[sealtm7]

You know what Bernard, that makes total sense and the picture is becoming clearer by the minute. Thank you for further clarification. It seems like there are two apporoaches and I wish the SDK was more clear about that, but then again it may have been and I just didn't catch on. So, if I can just elaborate on your discription of a "phenomena". A SPDL is just a collection of shader properties, and in fact, is the way phenomena (or the preset nodes that we use in the render tree) are created? and if I want to create custom parameters (for example through C++), that's when I end up creating unique GUIDs for those custom parameters not already included in XSI? I think I got it now. Yippee!!! Thank you Bernard you have helped me on toward a deeper understanding of XSI. Geez, I feel like I owe you something.

[Atyss]

Man you're a source of questions hard to satisfy ;-)


>> A SPDL is just a collection of shader properties

Spdls have a larger scope than just shaders. Spdls are the elements in XSI that provides a persistant interfaces to parameters, no matter if these parameters are from shaders, from object properties, from custom parameters, and so on. When you think spdl, think interface, nothing more.



>> and in fact, is the way phenomena (or the preset nodes that we use in the render tree) are created?

That would be right for phenomena, but preset files for the Render Tree can originate from shaders directly, not just phenomena. Remember that preset files are nothing more than a list of values for certain parameters (parameters originating from a ppg, ppg itself created by a spdl).



>> and if I want to create custom parameters (for example through C++), that's when I end up creating unique GUIDs for those custom parameters not already included in XSI?

Exactly. But like I said, if you want to do the right thing, you should always generate new GUIDs.

If you are to write a shader in C++, then you can forget about phenomena. For optimal performance and simplicity, you will most likely build monolitic shaders (a single shader that offers all the desired functionality) rather than phenomenas. Monolitic shaders, however, do not offer the same flexibility as phenomas and therefore require more work from the programmer. There is nothing that prevents you from writing a shader in C++ that connects with other shaders though, then in the spdls you would use the appropriate GUIDs to point to the appropriate shader parameters.



Cheers
Bernard

[sealtm7]

Thank you for your prompt responses Bernard, Now its time to dig in! Unfortunatly I couldn't spend much time on it today, but I'll try tomorrow. Its good to know there are such knowledgable people in XSI community. If I have further questions I won't hesatate to ask, besides It'll keep you sharp =).

[Alive_&_Kicking]

Hello sealtm7,

Since I've done few conversions of standard mray shader interfaces to xsi.mray, here is my part on spdl's...

1.Use the shader wizard only to create the parameters (their type, etc). Do not use the wizard to create the layout of your shaders (that's the second part of the process) - it's quite buggy. Save the spdl file and start editing it in a text editor.

2. Be careful with the values you put - if you convert standard mray shader check the shader version number, parameter names carefully , etc.

3. GUIDS - unique or hardcoded
3.1. Be very careful with guids as they are part of windows registry...
3.2. To generate GUIDs the easy way (you need this only for some portions of spdl shader writing)- start xsi switch to vbscipt and type the command for guid generation (sorry - don't remember the name - it's in the docs) many times, then save the guids in a text file for later use.
3.3. Unique shader GUIDs - every parameter (incl the spdl itself) in a shader must have a unique guid number, except:
3.3.1. The spdl output params (decribed in docs)
3.3.2. Ambience (or scene ambience) - in shaders this is usually the "ambience" part in the mi file. For this parameter the spdl must look like this:

Parameter "ambience" input
{
title = "Scene Ambience";
guid = "{3515CC74-082C-11D0-91DE-00A024C78EE3}";
type = color;
flags = 1;
texturable = off;
inspectable = off;
value = 0.1 0.1 0.1 1.0;
}


3.3.3. Lights and Light Lists: To add lights links to your shaders (illum) in the shader wizard add only the "mode" integer param - this is inclusive/exclusive mode - It will have unique guid. "Mode" must be texturable=0 and inspectable=0. Do not (and you cannot) add lights array. Open the generated spdl and add the following code


Parameter "lights" input
{
title = "Light List";
guid = "{YYYYYYYYYYYYYYYYYYYYYYYYYYYYY}";
ui "mapping" = "{38D56C23-8C0D-11D0-857D-00A02417D029}";
texturable = off;
type = array
{
Parameter "lights" input
{
title = "Light";
guid = "{XXXXXXXXXXXXXXXXXXXXXXXXXX}";
ui "mapping" = "{38D56C23-8C0D-11D0-857D-00A02417D029}";
texturable = off;
type = light;
flags = 1;
}
};
}

The XXX... and YYY... parts are to be replaced with unique guids - that you've saved to a file :)
This part also must be added to the Defaults portion of the spdl

lights
{
Name = "Light";
Description = "Light";
UIType = "LightListParamItem.LightListParamItem.1";
}


4. SPDL structure - default values, ranges, hiding params for RT editor connections, arranging params in groups, tabs - all this you can check in existing shader spdl...

5. Don't install directly the spdl - use spdlcheck first. In case of errors it will spit out line numbers and such...If it's fine - use File>Addon>SPDL

6. Phenomena - Creating Phenomena is a bit tricky. There are three stages: Creating & Declaring Parameters and Assembling Graphs.

6.1. Start by drawing on piece of paper the shader graph that you want to package - it helps later :)

6.2. Parameters in phenomena: The parameters you create in the wizard must match by name existing params from installed shaders - they must have unique guids however.

6.3. The Phenomena part of the spdl is made of 2 parts: Shader declaration and Connections

6.3.1. Shader declaration - You define which shaders you are going to use in your graph. They are declared as follows: node "ALIAS" (any name you want) = guid "{XXX...}";
The guid part is the guid of the shader itself - the third line in the installed shader spdl file. So if you want to use the RayType shader in your graph you wil put Node "ALIAS" = guid "{8604221E-BCFA-11D1-90E9-0000F804EB21}"; The ALIAS will be used later for easy naming of connections.

6.3.2. Connections: Now the graph must be described in text form: Description format is:
Connection "ALIAS::Param1" = SOMETHING; You have to define the connections or values for all params in the used shaders, linearly...

There are three options:
Connection "ALIAS::Param1" = interface "Param"; >> e.g. You have defined a Param in the phenom param declaration stage (the wizard), e.g. a color parameter. The value from this parameter will be assigned as value to Param1 of ALIAS shader. Or to more than one param in shaders in the graph.

Connection "ALIAS::Param1" = "ALIAS_1"; >> This will read the output from a declared shader. In other words, you have defined what values you want for ALIAS_1 shader and feed it's output into input of Param1 of ALIAS. If the shader has a struct output use ALIAS_1::OUTPUT1

Connection "ALIAS::Param1" = value 1; >> This is in case you want not to connect a shader into another shader input, but rather assign directly a value to it.

The last line of the Phenomena portion must be Connection root = "ALIAS_LAST_SHADER" or the shader that everyting is piped into. It's output must match the output defied in the spdl.

So that's it....
Cheers

[francescaluce]

I have not read all.. but 6.2 is incorrect,
you are not forced to match the name,
just the order of the parameter list.

for the Connection keyword you forget
this occasion:

Connection "myshader::input" = value "mytaggedshader" ;

it correspond to a 'shader' keyword into the declaration
file. it is the only one not mentioned in the manual...

/f

[Alive_&_Kicking]

Francesca, are you sure about param names? I remember that I tried with my own names and it didn't work out:(((

Thanks for the note about shaders assigned to 'value'. I forgot this one...

Cheers

[sealtm7]

here is a little flow chart that I think visually illustrates the process of creating a SPDL file for shaders. Please feel free to correct it or add to it. This thread has been really helpful and will continue to be helpful in the future. thank you Alive for your detailed procedure and to francescaluce for your willingness to check the process for errors. By the way, this a really stripped down concept of the SPDL process for shaders...


http://stu.aii.edu/~rs301/Layout.jpg


Thank you contributers, I hope you will all continue to aid me in my quest.

[Alive_&_Kicking]

One more thing I forgot,

Struct outputs in shaders - that is more than one output form a shader. Unfortunately XSI cannot use in the RT such shaders...But they can be used in phenomena...So make the base shader spdl first, then a phenomena with this shader and a passthrough (or other) shader...

Here is how to define struct outputs (this is to be done manually)

Parameter "out" output
{
title = "shader output parameter";
guid = "{XXXXXXXXX}";
type = struct
{
Parameter "out_1" output
{
title = "out_1";
guid = "{YYYYYYY}";
type = color;
flags = 1;
}
Parameter "out_2" output
{
title = "out_2";
guid = "{ZZZZZZZ}";
type = scalar;
flags = 1;
}
};
}


Check the mr documentation on phenomena for further details...

Cheers

[Atyss]

http://stu.aii.edu/%7Ers301/Layout.jpg



You need not the mi file in the equation. The mi file is there only to tell you the parameters and their values, so they can be used as a reference to build the spdl.


Cheers
Bernard

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.