Game Development Community

Custom material / shader problem

by Guy Allard · in Torque 3D Professional · 09/13/2010 (4:43 pm) · 3 replies

I have a shader being used by a CustomMaterial that works fine in T3D 1.1 beta1 (and earlier).

The pixel shader includes lighting.hlsl and uses inLightPos to calculate a vector from the fragment to the main light source (a sun) in order to do some custom lighting calculations.

Previously, using 
float3(inLightPos[0].x, inLightPos[1].x, inLightPos[2].x)
gave me the position of the sun.

In 1.1 beta2, this no longer works. There are no shader compilation errors, but the shader always behaves as if the sun is located at (0,0,0). In fact, using any of the 4 positions encoded in inLightPos behaves as if they are (0,0,0). I am certain that the rest of the shader is working correctly, as if I hardcode a value for the light position within the shader, I get the results that I am expecting.

Can anyone shed some light on what has changed between 1.1B1 and 1.1B2 that is messing this up for me?
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Associate Tom Spilman
Sickhead Games
#1
09/13/2010 (10:52 pm)
I think what happened is we optimized for AL and skip sending any ligting info for materials that are not forward lit. So when it goes down to set the lighting for your material it hasn't gathered any lights for it.

The best solution here is for your shader to report to the system that it is forward lit and needs lights to operate.

You can try to hack something into MatInstance::processMaterial(). You can see there how it sets the mIsForwardLit there. If you force it on for all CustomMaterials that should get your light positions back. Let me know how that works for you and i can see how we can get this into trunk.

Torque Owner Guy Allard
Default Studio Name
#2
09/14/2010 (7:13 am)
OK, thanks Tom, I'll give that a shot.

I've noticed that as the engine evolves, custom materials and shaders are becoming more and more tricky to use. Is the intention to get rid of them altogether at some point, or are they just a little neglected?

Torque Owner Guy Allard
Default Studio Name
#3
09/14/2010 (7:53 am)
OK,

I quickly hacked something in like you suggested, by changing matInstance::processMaterial(), line 351
from:
mIsForwardLit =   !finalFeatures.hasFeature( MFT_IsEmissive ) &&
                  finalFeatures.hasFeature( MFT_ForwardShading );

to:
mIsForwardLit =   !finalFeatures.hasFeature( MFT_IsEmissive ) &&
                  ( finalFeatures.hasFeature( MFT_ForwardShading ) ||
                  dynamic_cast<CustomMaterial*>( mMaterial ) );

and the shader is now getting the correct light info and working as it should.