Dynamic lighting and CustomMaterials

#1 That part of the code is old and possibly broken with all the changes that have occured for Advanced Lighting.

I believe those fields were part of the functionality of the SG lighting system in TGEA. I never used them myself, so correct me if i'm wrong, but it would render the object multiple times... once per-light... using those materials to do lighting.

Correct?

#2 Here is an explanation by John Kabus:

Interior Light Information to Custom Shader / #3

I have a shader that basically handles separate diffuse, normal and specular layers. Right now, I still have to debug it, but projectiles don't light the surface using this shader for some reason, and I have no idea why. Normal lights I put in the scene work flawlessly.

So I'm not even sure I have to do anything at all to be lit by projectile light in Torque3D.

#3 This is gonna be a bit long... but first some background info.

Advanced Lighting is a specifically a "light prepass renderer" which is a form of deferred rendering. So it renders the objects in the scene once to gather depth and normals, then it renders all the lights as 3d volumes into a lightinfo texture, and finally does the normal forward render sampling from the lightinfo texture the lighting at each screen space pixel.

Type the following at the console to see the different buffers:

toggleDepthInfoViz();
toggleNormalInfoViz();
toggleLightInfoViz();

So now back to the subject.... I see a few different ways to work with CustomShaders with Advanced Lighting.

1. Possibly the easiest way is to not use CustomMaterials and instead extend ShaderGen. I've started to make ShaderGen more flexible where you can plugin new Features. In beta 2 this should be much more flexible than it is now as i'll be using it for terrain rendering.

2. Next is manually participating in the lightinfo texture. If you were able to submit a render instance to the RenderPrePassMgr which renders the object's depth and normals then it will get lit when the lightinfo texture is generated. You can then sample from the #lightinfo texture during the forward render and generate your final lit pixel. The only thing that does this at the moment is terrain. GroundCover reads from the #lightinfo, but doesn't write into it at the moment... thats why you see lighting behind the grass. These are both worth examining to better understand the system.

3. Finally and possibly the hardest option is to do your own lighting. You would need to have shader constants to recieve the first and second most influencing lights and do calculations in your shader. It won't shadow correctly and will be computationally more intensive... but it will work. This is similar to what alpha blended translucent objects need to do (deferred renderers have trouble with translucent objects).

NOTE: You also need to support Basic Lighting... only 1 or 3 apply in that mode.

I realize that none of this are easy to get working at the moment... most of it is old, broken, and/or has missing functionality. But i do want to keep this thread alive as i do want to make it as easy as possible to integrate new shader features into Torque 3D.

#4 A note on projectile lights....

I believe in TGEA they just rendered a decal over other geometry with lighting projected on to it... thats not the case anymore.

They are real lights in AL, so if your object is not participating in the light prepass... it will not get lighting from projectiles. The benifit is that projectile lights can do everything a placed light can including casting shadows and per-pixel specular highlights.

#5 Thanks for the great information. Since I plan to do more with CustomMaterials, I don't want to extend ShaderGen for specific features that appear only in a single shader.

I think I'll take option 2, to me that sounds like the most proper way to do it. I'll start by checking the terrain shaders on their use of #lightinfo, I'm hoping I'll get pretty good hints there.

The object has to participate in the light prepass, since other lights affect it - I can light it and shadows are cast on it. So there must be some difference between projectile lights and a light I can place in the mission editor. I'll write again when I find out more.

Thanks again, Tom.

#6

Quote:I can light it and shadows are cast on it.

Ah... ok... i was forgetting something.

If you step into RenderPrePassMgr::addElement() when your object is first submitted for rendering you'll see how it adds a PrePassMatInstanceHook().

The reason your getting some lighting is because its generating a generic prepass material that does depth and vertex normals. It cannot do normal maps on a CustomMaterial because it doesn't know how to get to them.

The reason your object casts shadows is because it generates a simple shadow shader that assumes your verts are simple and static. If your CustomMaterial warped the verts of the object... it wouldn't appear that way in the shadow.

Quote:So there must be some difference between projectile lights and a light I can place in the mission editor

Not any that i know of... but i do know that i haven't seen a projectile light anything in the scene for a while. Maybe something got broken for all objects... not just yours.

Quote:I'll start by checking the terrain shaders on their use of #lightinfo, I'm hoping I'll get pretty good hints there.

Good place to start.

Notice that we use the TORQUE_ADVANCED_LIGHTING define in the shaders. Both TORQUE_ADVANCED_LIGHTING and TORQUE_BASIC_LIGHTING automatically get passed to all shaders when either lighting system is enabled. So you can use those to switch functionality.

Also TORQUE_SM is defined automatically... 30 for 3.0, 20 for 2.0 etc.

The autogenConditioners.h include is importaint to get the uncondition method for reading from the lightinfo buffer. You have to include that in the file for AL.

Hopefully that gets you started... feel free to ask any questions and nag me if something needs fixing.