(libogc) hardware lights
Re: (libogc) hardware lights
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?
Any ideas?
Re: (libogc) hardware lights
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
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
Re: (libogc) hardware lights
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);
-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);
-
- Posts: 6
- Joined: Thu Jun 10, 2010 3:08 am
Re: (libogc) hardware lights
I got the lesson 8 nehe to work by changing one thing:
to this:
Works like butter. Mmmm.
...Also by moving the setlight function out of the main loop.
Code: Select all
GX_SetChanCtrl(GX_COLOR0A0,GX_ENABLE,GX_SRC_REG,GX_SRC_REG,GX_LIGHT0,GX_DF_CLAMP,GX_AF_NONE);
Code: Select all
GX_SetChanCtrl(GX_COLOR0A0,GX_ENABLE,GX_SRC_REG,GX_SRC_REG,GX_LIGHT0,GX_DF_CLAMP,GX_AF_SPEC);
...Also by moving the setlight function out of the main loop.
Re: (libogc) hardware lights
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
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.
Re: (libogc) hardware lights
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
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
Re: (libogc) hardware lights
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.
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.
Re: (libogc) hardware lights
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
If you have any doubts regarding the model format, just say it and I'll try to help
Re: (libogc) hardware lights
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
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
Re: (libogc) hardware lights
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?
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?
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);
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?
Who is online
Users browsing this forum: Semrush [Bot] and 4 guests