[Feature Request] Define custom vLight interaction shader in Material (similar to newstage but for lights)

[nbohr1more]

I've been trying to do this in my own code branch but I've hit some snags with char casting that I am
not good with.

Basically the idea is to create a keyword like ambientLight but which allows you to specify which programs run for that light in the material def. In vanilla, I've found that you can't just provoke a newStage lookup for the GL bind in Draw_ARB2 the same way the bind works in Draw_Common but my
attempt at a workaround was to add a placeholder in the definition area at the bottom which then can grab data from NewStage. Still, using NewStage itself means that some of the exclusions in Draw_Common for lighting might cause some sorta paradox so I guess you'd want a conditional in Material.cpp to say if vLight is customLight then send the program to this char variable or else send it to NewStage.

[Pat Raynor]

Alright let me get this straight: basically you want a global material keyword that changes the interaction shader on specific materials?

so for example:

models/human/head001
{
   highQuality
   customLightInteraction subsurfacePBLInteraction

   blahblah texture stages, etc.....
}

looks easy enough to attempt to implement with the current backend, you could kinda piggy back off the way fog and ambient lights work.

I'll give trying to implementing it a whirl.

[nbohr1more]

(Thanks)

Well that's one thing I was aiming to have (custom surface interactions).

This idea started with trying to find a way to use Sikkpin's cubemap light projection with spherical falloff without breaking existing lights that use the 1D+2D projections. I can create a hardcoded path for that but then I realized that it would be handy to be able to specify this in the light's material def. That way, not only could you use cubemaps... you could also do things like have multiple falloff image \ projection image pairs or use a 3D texture as the input. Then I realized with the use of the spectrum keyword, you could also pair this with surfaces.

As for the custom surface interactions, it occurred to me that you'd need access to the stencil buffer and further you would need to ensure it ran every time a regular light hit the surface. I haven't looked at the render order enough to tell whether this would work out of box.

[nbohr1more]

Oh, one way-out I idea I had was to use code comments in the ARB or GLSL shader that act as
a placeholder where you could insert code snippets to add more interaction complexity also by defining them in the material def. The parser would just identify a special character sequence in the shader and concatenate the snippet into it. I think with GLSL you can call other shaders from within a shader so that's probably obsolete thinking now.

[nbohr1more]

Thanks for looking into this!
One thing I was looking into was granting vLight (viewLight_t) in tr_local.h info about customLight but I was concerned that using this would break future work to improve SMP support due to this comment:

// viewLights are allocated on the frame temporary stack memory
// a viewLight contains everything that the back end needs out of an idRenderLightLocal,
// which the front end may be modifying simultaniously if running in SMP mode.
// a viewLight may exist even without any surfaces, and may be relevent for fogging,
// but should never exist if its volume does not intersect the view frustum

[Pat Raynor]

Gonna drop this feature request as the renderer is about to change a lot shader wise....