(libogc) hardware lights

techhnik
Posts: 15
Joined: Sun Jun 20, 2010 9:21 pm

Re: (libogc) hardware lights

Post by techhnik » Fri Sep 03, 2010 2:02 pm

I've downloaded it but it failed to compile, the errors are at gxdriver.cpp GX_InitTexObjUserData funtion and some others are not declared.
Any ideas?

shagkur
Posts: 53
Joined: Thu Sep 08, 2005 8:40 pm

Re: (libogc) hardware lights

Post by shagkur » Fri Sep 03, 2010 2:14 pm

Hi,

ohh, sorry, forgot about that. You've to grab the latest libogc from SVN. Due to the fact that i reconfigure TMEM in wiirrlicht i had to add some way to pass user data to the texture object.

regards
shagkur

techhnik
Posts: 15
Joined: Sun Jun 20, 2010 9:21 pm

Re: (libogc) hardware lights

Post by techhnik » Fri Sep 03, 2010 10:37 pm

I'm testing your demos right now:
-demo 1 didn't compile
-demo 2 shows exactly the same error I'm describing with lights (it can be clearly seen in the ceiling)
-demo 3, everything looks fine here, but the light emitter is very far from the ground, so my eye doesn't notice any lighting effect
-demo 4, the ship looks fine (didn't expect music :) )
-demo 5, I think this lights perfect, not sure because it's hard to say with textures etc, but looks perfect
-demo 6, this one really impressed me, it looks great. The tiny yellow refelction is amazing. Lights in this demo are hardware or software? I must do a slowed down test with this demo to be sure, but this one seems to work fine.
-demo 7, not much to say, nice particle system
-demo 8, same as demo 6

I still have to do some more tests tomorrow, but what I see in demo 2 is exaclty what I was describing, tomorrow I will link a demo showing the effect I mean (comparing software and hardware lighting);

dancinninja
Posts: 6
Joined: Thu Jun 10, 2010 3:08 am

Re: (libogc) hardware lights

Post by dancinninja » Sat Sep 04, 2010 6:53 am

I got the lesson 8 nehe to work by changing one thing:

Code: Select all

GX_SetChanCtrl(GX_COLOR0A0,GX_ENABLE,GX_SRC_REG,GX_SRC_REG,GX_LIGHT0,GX_DF_CLAMP,GX_AF_NONE);
to this:

Code: Select all

GX_SetChanCtrl(GX_COLOR0A0,GX_ENABLE,GX_SRC_REG,GX_SRC_REG,GX_LIGHT0,GX_DF_CLAMP,GX_AF_SPEC);
Works like butter. Mmmm.

...Also by moving the setlight function out of the main loop.

shagkur
Posts: 53
Joined: Thu Sep 08, 2005 8:40 pm

Re: (libogc) hardware lights

Post by shagkur » Sat Sep 04, 2010 8:12 am

Hi,

well a few "demos" are just tests i made and thus maybe a bit strange or won't even work. Although if you have a cube controller you can move the camera around in the scene.

demo2: This behavior is in the original Irrlicht demo exactly the same (with OpenGL and D9D drivers) when using a simple local point light. Also the room is a very low tesselated object.
demo4: This demo should show the spot light effect. Again if you have cube controller you can move the spot with the cross button.
demo5: Here i use Parallel Diffuse Lighting. That's how i use directional lights in wiirrlicht. From the documentation: "Although the hardware doesn't support parallel diffuse lighting, it is possible to obtain nearly parallel lighting by putting a light very far away from every object to be lit. If the light's position is sufficiently distant from the object, all rays can be considered parallel."
demo6: This uses for the stony donut "real" bumpmapping, means i use the indirect texture unit to bump the texture per pixel. Furthermore for the left donut the light is rendered into a texture to be use later by the TEV for bumpmapping. Again, here i use parallel diffuse lighting. For both donuts.
The right one is just colored and lit by this parallel diffuse light. For the reflection effect i use again a texture and project it onto the object by using the normals as the tex gen source. And a post translation matrix which uses the light direction vector to project it the right way. In fact this should, kind of, imitate specular highlighting but per pixel.

All lighting in wiirrlicht is done on hardware.

About local lights, i.e point lights: The GPU does here gouraud shading when AF_NONE or AF_SPOT is set. This can, sort of, circumvented by making a light be a parallel diffuse light. That's what i do when i declare a light to be directional in wiirrlicht.
For AF_SPEC it uses phong shading i belive.

Also the local lights in wiirrlicht all use distance attenuation too, which also has some influence on how the light color is calculated on the GPU.

And from all the discussion here i see your goal is to gain phong shading effects. And apart from a bug i figured yesterday in InitSpecularDir (used when AF_SPEC is set), there's not much i do with light data in gx.c. As you might have seen on yagcd there's a single register which sets up the XF unit for lighting.

Nevertheless i'm keen to see your demo(s) which shows the effect more detailed.

best regards
shagkur
Last edited by shagkur on Sat Sep 04, 2010 8:37 am, edited 1 time in total.

techhnik
Posts: 15
Joined: Sun Jun 20, 2010 9:21 pm

Re: (libogc) hardware lights

Post by techhnik » Sat Sep 04, 2010 8:35 am

Interesting...the thing is that most of the time I've been using GX_InitSpecularDir to set the light direction and half angle. Is it fixed in the svn?
Anyway, I've uploaded 6 compiled demos showing what I get. Comparing between software and hardware versions, the difference is clear: hardware verteices only show two states (full light/no light) while software vertices look much smoother.

Here's the link http://www.megaupload.com/?d=C2CPC2XA

shagkur
Posts: 53
Joined: Thu Sep 08, 2005 8:40 pm

Re: (libogc) hardware lights

Post by shagkur » Sat Sep 04, 2010 8:40 am

Hi,

indeed there was a bug in InitSpecularDir when calculating the lights position. For AF_SPEC the light position is reused by the HW as the light direction and thus has to be a negative value. And that was the bug. The multiplier was set to positive.

This issue has been fixed and is in the SVN now.

For demo5 you may comment "light1" (the directional light) to see how the point light alone works.

PD: Do i have to copy the "RevExamples" folder onto root of my SD?

PD2: The difference can clearly be seen in your examples. I'll port over your mesh loading code to wiirrlicht to be able to compare further more.

techhnik
Posts: 15
Joined: Sun Jun 20, 2010 9:21 pm

Re: (libogc) hardware lights

Post by techhnik » Sat Sep 04, 2010 3:48 pm

Well, I'll be expecting some news.
If you have any doubts regarding the model format, just say it and I'll try to help

shagkur
Posts: 53
Joined: Thu Sep 08, 2005 8:40 pm

Re: (libogc) hardware lights

Post by shagkur » Sun Sep 05, 2010 11:09 am

Hi,

i'm finished implementing the RMS loader code into wiirrlicht.
And here's the result i get: http://www.megaupload.com/?d=L4HRPE9V
Copy buggy.rms into "SD:/revmodels" and give the .dol a go ;-)
It's the buggy with a rotating local point light. I use here again AF_SPOT but also set the distance attenuation coefficients.

I'm looking forward to hear your opinion.

best regards
shagkur

PD: And once again, if you've a cube controller, you can move the camera around.

PD2: not very sure if i uploaded the right one: http://www.FastShare.org/download/9.dol

techhnik
Posts: 15
Joined: Sun Jun 20, 2010 9:21 pm

Re: (libogc) hardware lights

Post by techhnik » Sun Sep 05, 2010 2:29 pm

Hey that's incredible
it looks really really good.
But I can't reproduce it in my own code, this is the relevant code I use. Could you tell me how you do it?

Code: Select all

	guVector lpos = {0,-50,50};
	guVector ldir = {0,1,-1};

	guVecMultiply(view,&lpos, &lpos);
	guMtxInverse(view, inv);
	guMtxTranspose(inv, aux);
	guVecMultiply(aux,&ldir, &ldir);
	guVecNormalize(&ldir);

	GX_InitLightPos(&lobj,lpos.x,lpos.y,lpos.z);
	GX_InitLightDir(&lobj,ldir.x,ldir.y,ldir.z);
	GX_InitLightDistAttn(&lobj, 30, 0.9f, GX_DA_STEEP);
	GX_InitLightSpot(&lobj,90.0f,GX_SP_COS);
	GX_InitLightColor(&lobj,SC_WHITE);
	GX_LoadLightObj(&lobj,GX_LIGHT0);
View is the camera matrix
The model is adjusted to be about 50 units radius, so the light is set outside of it.
Still I am confused, faces seem to light more or less depending on the normal direction, but documentation says that spot angle attenuation uses L·Ldir to calculate angle and distance attenuation uses sqrt(L·L). None of those equations use the vertex nomal. How is this possible?

Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 4 guests