hw lighting

[ozzyyzzo]

Hello,

certainly a silly question but..

Any chance to get rid of 'the really' only 8 lights settings?
it would be really nice if we could reset lightObjects parameters and encapsulate more than 8 settings.
(well, more or less the way it works with opengl)

[shagkur]

Hi,

well those 8 lights are HW lights so kinda hard to get rid of the limitation.
Ofcourse it's possible to set the lights new for each mesh you render in a scene.

regards
shagkur

[ozzyyzzo]

Hello

Ofcourse it's possible to set the lights new for each mesh you render in a scene

Ok then, just to avoid the confusion from my first post.
i understand the hw limit of the 8 lights and yes, i'd like to reuse/redefine multiple settings (as GXLightObj settings) over these 8 hw lights (that's what i was calling the way it works with opengl fixed pipeline)

Then while implementing lighting using on one hand devkitpro and on the other hand official devkit i'm facing the same problem:

<my frame pseudo code>

while displaying primitives do
- setting up to 8 lights (reusing same GXLightObj table, then filling with != values)
- display prims using same lights configuration

<end of frame>

for some reasons it seems that only the last configuration parameters overide the previous ones.
So i don't know how display commands/states are buffered along the pipeline but maybe there is something special to be done while using GXLightObj and passing them or maybe while using GX_SetChanCtrl(...)

Now speaking about N's own API and documentation it says about HW lighting that there is the limitation of 8 lights but also really only 8 settings!! They finally are recommending to use software lighting using additional texture passes/TEV stages (usual stuff: spherical env map, bump maps & so on) to avoid it.

Well, in my opinion THIS! is confusing ^^
So far i was unable to get more than 8 lights settings within a frame, this make me think about a damn bad limitation within the hw pipeline?

Finally, i get more & more confused as you are saying that it shouldn't be a problem to set up new lights settings for each mesh you render in a scene! <- that's what i'm expecting! ^^

Saying that, my light setup is looking like this: (unit as a channel (0-7) , status as boolean)

vrLightActive[unit] = (VR_BOOL) status;

if (status){

GX_InitLightColor(&vrLightObj[unit],color);
GX_InitLightPos(&vrLightObj[unit], vrLightPos[unit].x, vrLightPos[unit].y, vrLightPos[unit].z);

GX_InitLightAttn( &vrLightObj[unit],
1.0F,
0.0F,
0.0F,
vrLightConstantAtt[unit],vrLightLinearAtt[unit], vrLightQuadraticAtt[unit]);


GX_LoadLightObj(&vrLightObj[unit], (1<<unit));

lightMask = 0;
for (i=0; i <= unit;i++){
if (vrLightActive)
lightMask |= 1<<i;

}
GX_SetChanCtrl(
GX_COLOR0A0,
GX_ENABLE, // enable channel
GX_SRC_REG, // amb source
GX_SRC_REG, // mat source
lightMask,
GX_DF_CLAMP, // diffuse function
GX_AF_SPOT);

}
else{
memset(&vrLightObj[unit],0,sizeof(GXLightObj));
GX_LoadLightObj(&vrLightObj[unit], (1<<unit));

}

[ozzyyzzo]

Ok,

Finally i found the problem which was somewhere else into my code (as usual ? ^^)
So it works as expected and i'm really glad now
8 hw lights are far enough when you can make many combinations of them.

[Samson]

Just be aware that each active light adds to the transform cost for each vertex! That's the same in DirectX and OpenGL or when you do your lighting in a vertex shader.
In a professional game, even on next gen platforms like Xbox 360 or PS3, you try to have as few active lights as possible. If the light source is static, for example the street lights in a street scene, you'd calculate the lighting offline and store it in the vertex colour or as a light map. That gives you the chance to do more complicated lighting, like shadowing or indirect lighting, at virtually no extra runtime cost. Hardware lights are only applied to moving objects, and even then only the most important 1 or 2 lights. And on the background you only use dynamic lights if they're changing, for example spell effects or light sources that the player carries.