(libogc) hardware lights

[techhnik]

Hardware lights don't work in libogc, the effect can be clearly seen in neheGX lesson8 (even more clear if you dissable blending and set GX_PASSCLR for the tev operation). You can also see it in this video http://www.youtube.com/watch?v=8Imygi6UpJk

This bug is very old, and I've repported it in some other places, but never got an answer.
Has anyone even taken a look at it? I think it's quite an important bug because any serious attempt to develop good graphics will be frustrated because of this. Software lighting is just SO slow.

Thanks in advance

[shagkur]

Hi,

Is this issue also on cube reproducible?

For the WII this is correct and can be changed by using AF_SPOT for the attenuation function.
By using

Code: Select all

GX_InitLightSpot(&litObj,0.0f,GX_SP_OFF);

you'll get your nice lightning. Because this will set the angel attenuation factor to it's default values of a0 = 1.0f, a1 = 0.0f, a2 = 0.0f. Also, by doing so, the lightning hardware doesn't use the lights direction vector but will still do an attenuation and hence give you the shading you'd expect when an object is lit.
Furthermore, by using AF_SPOT, you can also control the distance attenuation. And distance attenuation will only work if AF_SPOT is used. And such a distance attenuation is true for a bulb light as well.

regards
shagkur


PS: you may take a look into CGXDriver::assignHardwareLight in gxdriver.cpp: http://code.google.com/p/wiirrlichtcust

[techhnik]

Hi shagkur,

The problem is that angle attenuation is exactly what I want to do, and exactly the part that I think doesn't work.
I understand a0 a1 a2, k0 k1 k2 coefficients should do nothing when I set GX_AF_NONE, because the attenuation factor should alwais be one.

For example, I do this:

Code: Select all

GX_SetChanCtrl(GX_COLOR0A0,GX_ENABLE,GX_SRC_REG,GX_SRC_REG,GX_LIGHT0,GX_DF_CLAMP,[b]GX_AF_NONE[/b]);
GX_InitLightPos(&lobj,lpos.x,lpos.y,lpos.z);
GX_InitLightDir(&lobj,ldir.x,ldir.y,ldir.z);
GX_InitLightAttn(&lobj, 1.0f,0.0f,0.0f,1.0f,0.0f,0.0f);
GX_InitLightColor(&lobj,litcol);

In those conditions, the lighting equation should be something like this:
illum = Clamp(amb + clamp0(L·N))
where amb is the ambient color, L is the light position (or direction, I'm not sure) and N is the vertex normal.
That should result in a nice and smooth angle attenuation. But it doesn't, instead of that, illum is always either:
illum = amb
or
illum = 1
So I deduce that the problem is in L · N always returning 1 or 0, never an intermediate value, so the smoothness is just impossible. At the begining I thought the problem was mine, bad loading the normal matrix or something, and that's why I'm doing all my tests over the libogc example directly.

PD: I can not try this on a gameCube because I don't have one.

Best regards,
Technik

[shagkur]

Hi,

angle attenuation only works if you use AF_SPOT or AF_SPEC otherwise it's turned off or to be more precisely the HW will passthru 1.0f.
From GX API's point of view there's no calculation done to do the attenuation. Indeed it's a single XF register where i've set the bits to enable the light computation and how it functions.
The equation to calculate the resulting light color on the vertex is all done on the GPU.
For a detailed bit description what i set in 0x100e (the control register for color and light computation) look at http://hitmen.c02.at/files/yagcd/yagcd/ ... #sec5.11.4.
Again, all i can recommend you to get angle attenuation is to use AF_SPOT and for a normal diffuse point light set a0 = 1.0f, a1 = 0.0f and a2 = 0.0f.
Distance attenuation will still work by setting k0,k1,k2 to some meaningful values.

regards
shagkur

[techhnik]

Ok thanks, that will allow me to port part of my lighting system to hardware.
However, will diffuse attenuation be fixed in the future? because theoretically Wii hardware has diffuse attenuation support, and as you describe it, now it works as if this was always used:

Code: Select all

GX_SetChanCtrl(GX_COLOR0A0,GX_ENABLE,GX_SRC_REG,GX_SRC_REG,GX_LIGHT0,[b]GX_DF_NONE[/b],GX_AF_NONE);

There must be a way to tell the hardware that we want GX_DF_CLAMP instead, so hardware stops passing always 1.0f and it starts passing N·L

Thanks

[shagkur]

Hi

i'm still trying to figure out what's going wrong if there's something really going wrong
How does it look like if your mesh is highly tesselated? Because lightning is here done on a per vertex base.
Also could you or have you ever tried to use SIGNED? And for another test, could you pass "3" to SetChanCtrl for the diff_fn?

thanks in advance
shagkur

[techhnik]

Ok, I've just done some more testing, these are the results

GX_DF_NONE, always 1.0f, this one works perfect
GX_DF_SIGNED, ranging from -1.0f (it substracts lighing from the ambien light) to 1.0f
GX_DF_CLAMP, ranging from 0.0f to 1.0f
3 looks exactly like SIGNED

I have slowed down the demo to ridiculously low speed and I can appreciate that signed and clamp indeed are smooth, it looks more like (N·L)^10 than (N·L) because it happens SO fast, i'd say it's just about one degree.

I have a software implementation of the lighting equations that theoretically solves the hardware, and they're very very smoother. For example, if I light a highly tesselated sphere through software, the sphere looks perfectly smooth and round. But if I light the same sphere by hardware, you can see a light that divides it in two clearly differentiated zones: dark and bright.

Any ideas?

[shagkur]

To be honest i can't really tell why it behaves like this. But i'd say it's more or less a HW limitation when it comes to HW lighting.
For wiirrlicht i circumvent this by using the AF_SPOT and having the distance attenuation turned on. This gives me pretty smooth edges.
Due to the fact that lighting is done on per vertex you'll always see the difference between lit and unlit triangles, no matter how high tesselated
the mesh is. At least that's true for AF_NONE and DF_CLAMP/SIGNED. From what i've experienced.

And for the vertex colors the rasterizer interpolates them between the vertices of a triangle, that's probably the reason why it's is much more smoother.

regards
shagkur

[techhnik]

It's very very extrange.
I followed your suggestion and now I'm using the AF_SPOT also, it looks good but it has some limitations (So still have to use some software also). basically, the equation behind this part of the hardware works like this.

x = (Surface normal * halfvector)
d = distance
lightClr = (a0+a1*x+a2*x^2)/(k0+k1*d+k2*d^2);

This corresponds to the specular component of phong lighting equations, if we use a0,a1,a2,k0,k1,k2 for the coefficients of a maclaurin expansion. That's perfect.
But phong equations have another part: diffuse component, that must be calculated as the dot product of surface normal and light direction. And that's exactly what the part that doesn't work should do.

PD:Hardware lighting is calculated per-vertex and then interpolated to get pixel values, so it should be as smooth as software computed lighting (because I'm doing that per-vertex also).

PD2:I think there's actually a tricky way to do diffuse lighting with the specular hardware, but it needs two physical light objects per light and makes it not posible to use distance attenuation through hardware. I'll try and tell you more about this.

[shagkur]

Hmm....are you talking about normal point lights or specular, i.e directional lights?
If you want to use both in one light (to save HW lights) you may use the alpha channel of the light for the specular component to gain phong shading effects. This has ofcourse the limitation that only black - white values will be generated.
For the phong or specular effect on HW lights you'll have to use AF_SPEC then. Then you may use InitSpecularLight.
But again, from what i've experienced and what i know, the HW has some limitations in that.

You may grab this: http://www.megaupload.com/?d=TLKUYSK8
It's the wiirrlicht sources and some "data" folders which you've to copy onto the root of your SD.
Library build: "make wii-install"
examples build (in the examples folder): "make PLATFORM=wii"

I'd like to know your opinion about the results you see there.

regards
shagkur

PS: the data folders are: "media", "md5" and "awing" which you've to copy onto root of your SD