To get the .fx file for a realtime shader (RTShader), you go through the ShaderDef:
// Given a render tree node (shader), get the .fx file var o = Dictionary.GetObject( "Sources.Materials.DefaultLib.Scene_Material.MrWiggle1" ); LogMessage( o.ShaderDef.DefinitionPath ); // Given a progID, get the .fx file var sd = Application.GetShaderDef( "HLSLParser.MrWiggle.1.0" ); LogMessage( sd.DefinitionPath ); // INFO : C:\Program Files\Autodesk\Softimage 2012 SP1\Application\phenolib\HLSL\MrWiggle.fx // INFO : C:\Program Files\Autodesk\Softimage 2012 SP1\Application\phenolib\HLSL\MrWiggle.fx
Thank you for this useful tip. I’m working on an exporter that evaluates RTShaders right now and this is helpful. While evaluating the render tree, I can extract the XSI::ShaderDef from an XSI::Shader, so I think this is exactly what I need. Thanks for posting this!
FWIW my exporter is evaluating these RTShaders to determine what kind of data to export to the game engine. I hope to discover a way to access global variable annotations found in the STANDARDSGLOBAL so the exporter can export precisely the right data.
For instance, a shader that uses a low precision weight might have this kind of code:
float Script : STANDARDSGLOBAL = 0.8;
struct VS_Input
{
float4 position : POSITION;
float4 normal : NORMAL;
float2 uv : TEXCOORD;
byte4 weights : BLENDWEIGHT;
byte4 indices : BLENDINDICES;
};
The above is the standard declaration found in RTShaders, with one extra annotation item “BlendType” that tells the exporter to export the top four envelope weights/indices and metadata for the content pipeline so it will correctly use a byte4 for the vertex buffer it creates for the runtime. Different shaders might have different needs, such as HalfVector2 or a full Float4.
I’m hoping the XSI API has a way to discover RTShader global parameters and annotations (perhaps this would let me discover the BLENDWEIGHT binding and read the type directly? who knows), but if not, I will now be able to at least parse the file and get the data in a less elegant way thanks to knowing where the full path the the .fx file.