I have no s at the end of light[1]

On Tue, Nov 11, 2014 at 10:36 PM, Daniel Brassard <[email protected]>
wrote:

> In my book:
>
> typedef struct
>     {
>        // Light list
>        int   i_light;     // memory address of first light in light array
>        int   n_light;     // number of lights in the light array;
>        miTag light[1];   // pointer to light array
>     } ml_shader_params
>
> On Tue, Nov 11, 2014 at 6:20 PM, Matt Lind <[email protected]> wrote:
>
>>   Update:
>>
>> Renderer Options set in the shaderdef don’t seem to be getting pushed to
>> mental ray at all.  Not only is the light list not getting properly wired
>> up, but the ‘trace’ and ‘derivatives’ flags I set in the renderer options
>> of my material shader don’t get wired up either.  When I query for those
>> specific flags using mi_query() in the shader _init() or _main() functions,
>> the flags are not set.  I have attempted this in Softimage 2013 SP1 and
>> Softimage 2014 SP2 with identical results.  I have also attempted to port
>> my shaderdef to JScript to see if it is a language problem.  same
>> results...although PPG logic works better in JScript.
>>
>> Am I doing something fundamentally wrong, or is this a bug?
>>
>>
>> Matt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I am updating some mental ray shaders I wrote many years ago.
>>
>> When using a .spdl for the UI and making the most minimal of tweaks to my
>> C++ code to be compliant with the current version of mental ray, the
>> shaders render as expected.  However, when using a ShaderDefinition to
>> define the UI and registration, the scene light list is always empty
>> resulting in dark rendered images.
>>
>> Code snippet illustrating how I’m declaring the scene light list in the
>> shader definition (C++):
>>
>>     Context oContext( oContextRef );
>>     Factory XSIFactory = Application().GetFactory();
>>
>>     // Shader definition
>>     ShaderDef oShaderDefinition = oContext.GetAttribute( "Definition"
>> );
>>     oShaderDefinition.AddShaderFamily( siShaderFamilySurfaceMat );
>>     oShaderDefinition.AddShaderFamily( siShaderFamilyShadowMat );
>>     oShaderDefinition.AddShaderFamily( siShaderFamilyPhotonMat );
>>
>>     // Parameter definitions
>>     ShaderParamDef oParameterDef;
>>     ShaderParamDefOptions paramOptions;
>>     ShaderParamDefContainer oParametersInput  = oShaderDefinition.
>> GetInputParamDefs();
>>     ShaderParamDefContainer oParametersOutput = oShaderDefinition.
>> GetOutputParamDefs();
>>
>>         // Add light list parameter
>>     paramOptions = XSIFactory.CreateShaderParamDefOptions();
>>     paramOptions.SetLongName( L"lights" );
>>     paramOptions.SetAnimatable( true );
>>     paramOptions.SetTexturable( true );
>>     paramOptions.SetReadOnly( false );
>>     paramOptions.SetInspectable( true );
>>     paramOptions.SetAttribute( siReferenceFilterAttribute,
>> siLightReferenceFilter );
>>
>>     oParametersInput.AddParamDef( L"lights", siShaderDataTypeReference,
>> paramOptions );
>>
>>
>> The light list as defined in my mental ray shader code.  Works correctly
>> with .spdl files, but fails without warning or error when using shader
>> definition files:
>>
>>     typedef struct
>>     {
>>        // Light list
>>        int   i_light;     // memory address of first light in light array
>>        int   n_light;     // number of lights in the light array;
>>        miTag lights[1];   // pointer to light array
>>     } ml_shader_params;
>>
>>
>> when I dump the number of lights in the scene via mi_info(), it returns
>> the expected number of lights in the scene when the shader is registered
>> using .spdl, but always returns zero when registered using a shader
>> definition:
>>
>>     miInteger NbLights = *mi_eval_integer( & paras->n_light );   //
>> number of lights in light list
>>
>>     mi_info( “Nblights: %d\n”, NbLights );
>>
>>
>>
>> Anybody know what the secret handshake is to get light lists to be
>> recognize by a mental ray shader when using shader definition files (C++)?
>> I would really like to ditch the .spdl format if possible.
>>
>> thanks,
>>
>> Matt
>>
>
>

Reply via email to