Is lighting broken in libogc?

[sakitume]

Hello all. I've spent a couple of days trying to discover why my 3D scene's lighting is all messed up. I've exhausted all of the possibilities that I could think of that might be due to my code and am now left to believe that it may be something in libogc.

I've done some searches and found that someone else is reporting the same problem over on the wiibrew.org forum, see: http://forum.wiibrew.org/read.php?11,35629

Has anyone else run into this problem?

My next thought is to see if I can rebuild an older snapshot of libogc to see if it exists there as well.

[WinterMute]

Shagkur is currently looking into this one, more news as we have it.

[sakitume]

Great news. Thanks for the update.

If it helps, my test case is super simple and uses a single, plain, non-attenuated diffuse directional light. I setup the lighting with COLOR0A0 as follows:

GXSetChanCtrl(GX_COLOR0A0, GX_ENABLE, GX_SRC_REG, GX_SRC_REG, GX_LIGHT0, GX_DF_CLAMP, GX_AF_NONE);

I set the light position to be very very far away (to mimic an infinitely far directional light):
// lightPos is set and is in view space
lightPos.norm();
lightPos *= 1.e18f;
GXInitLightPos(&lightObj, lightPos.x, lightPos.y, lightPos.z);

The light attenuation terms are set to be 1,0,0,1,0,0, This shouldn't be necessary with the GX but I do it anyways. I do that using these functions:
GXInitLightSpot(&lightObj, 45.0F, GX_SP_OFF );
GXInitLightDistAttn(&lightObj, 0.0F, 0.5F, GX_DA_OFF );

I setup the normal matrix correctly, I've tried using both versions, on different occasions, (providing the proper version of the matrix: 3x4 versus 4x4) just in case one was buggy:
GX_LoadNrmMtxImm() and GX_LoadNrmMtxImm3x3()

I could give more specific descriptions to shagkur if desired, please don't hesitate to ask.

Cheers,
sakitume

[DRS]

I think I download devkit in april or perhaps may this year but for me lighting is working correctly.

Note that GXSetChanCtrl(GX_COLOR0A0, GX_ENABLE, GX_SRC_REG, GX_SRC_REG, GX_LIGHT0, GX_DF_CLAMP, GX_AF_NONE); creates an on/off behaviour on actual hardware. To get actual cosine attenuation you have to setup a lightdirection (any direction, doesn't matter for what I have seen) and set GX_AF_SPOT. In your code snippets I miss the setup for material, light and ambient colors. Just set material and light color to {255, 255, 255, 255} and ambient to {0, 0, 0, 0}. Furthermore, I never tried the InitLightSpot or InitLightDistAttn but if you set the A0 and K0 terms to 1.0f it should always render to full intensity.

The following code is working for me:

Code: Select all

		guVecMultiply(view, &lpos, &lpos);
		GX_InitLightPos(&cl_hwlight_obj[0], lpos.x, lpos.y, lpos.z);
		GX_InitLightColor(&cl_hwlight_obj[0], col);
		GX_InitLightDir(&cl_hwlight_obj[0], 0.0f, 0.0f, 1.0f); // doesn't really matter what direction		
		GX_LoadLightObj(&cl_hwlight_obj[0], GX_LIGHT0);
		GX_SetNumChans(1);
		GX_SetChanCtrl(GX_COLOR0, GX_ENABLE, GX_SRC_REG, GX_SRC_REG, GX_LIGHT0, GX_DF_CLAMP, GX_AF_NONE);
		GX_SetChanCtrl(GX_ALPHA0, GX_ENABLE, GX_SRC_REG, GX_SRC_REG, GX_LIGHT0, GX_DF_CLAMP, GX_AF_NONE);
		GX_SetChanAmbColor(GX_COLOR0A0, cl_hw_lightcolors[1]);
		GX_SetChanMatColor(GX_COLOR0A0, cl_hw_lightcolors[2]);
  

Edit: oh and I setup the normal matix the same as modelview. If I setup the transpose of the inverse everything stays unlit.

[techhnik]

Is there any news about this? if this doesn't work right, any serious lighting attemp will fail.
This shows exactly what the problem is:

http://www.youtube.com/watch?v=8Imygi6UpJk

that demo is just one of libogc examples compiled without transparency so the bug can be clearly seen. Since it's a libogc example, there is no way I did something wrong in the code, so its not my mistake, its a bug.

[nonameno]

what kind of light are you using ?? diffuse ? spot ?

from what i remember i had same shitty stuff with spot and surface of cube only composed of two triangles, like your code i bet. try to use tessellated faces for your cube i think there will be enought triangles to process nice shade.

NoNameNo.

[techhnik]

It's been long since I gave up on this issue, but I remember I tracked the bug upto the resolution of a lighting ecuation. The root of the problem is that where the hardware must return the result of clamp0(N*L), which must be a float between 0 and 1. instead of that, it only returns either 0 or 1, but no value between them. That's why the transition from shaded to lighten is so sudden. The problem is there, in the diffuseAttenuation, but I just can't fixe it because I don't know enough about GX insides.

[puppeh]

For the sake of people chancing across this post: I think the trick here is not to use GX_AF_NONE in GX_SetChanCtrl, but instead use GX_AF_SPOT and then turn the spot functionality off (by passing GX_SP_OFF to GX_InitLightSpot). E.g. for utterly basic diffuse lighting (no angle or distance-dependence, no specularity), set up a light as follows:

Code: Select all

  GX_SetChanCtrl (GX_COLOR0, GX_ENABLE, GX_SRC_REG, GX_SRC_REG, GX_LIGHT0,
		  GX_DF_CLAMP, GX_AF_SPOT);

  GX_InitLightPos (&lo, 20, 20, 30);
  GX_InitLightColor (&lo, (GXColor) { 192, 192, 192, 0 });
  // Initialise "a" parameters.
  GX_InitLightSpot (&lo, 0.0, GX_SP_OFF);
  // Initialise "k" parameters.
  GX_InitLightDistAttn (&lo, 1.0, 1.0, GX_DA_OFF);
  GX_InitLightDir (&lo, 0.0, 0.0, 0.0);
  GX_LoadLightObj (&lo, GX_LIGHT0);

The value for InitLightDir doesn't appear to matter.

I had no luck at all with GX_AF_NONE, though AFAICT that should have produced the same effect.