Lighting!!!

Quake actually uses radiosity lightmaps... Go look on www.flipcode.com, they have a few tuts about it.
And OpenGL''s built-in lights are dynamic...
You can also use dynamic lightmaps, but I''m not sure how.. I know I saw it around here somewhere.. Oh well, just google for it.

I''ve written a dynamic lights demo which uses a sort of fake 3D texturing algorithm and I''m hoping to write a tut on it soon. You can find the demo here :

http://www.exsanity.freeola.com/opengl.html

What about bump and RPG maps? They''re usful, I just don''t know how use them. Not that I need to, it''d just be a useful thing for the GD ppls to know.

Artificial entertainment- Define reality...
Contact: kyser3152@yahoo.com.au

I know what a bump-map is, but what''s an RGB map?

quote:

---

Original post by James Trotter
Quake actually uses radiosity lightmaps...

---

Quake uses regular lightmaps.

raiosity lightmaps are actuarly regular lightmaps.
Quake lightmaps doesn''t however have any relation to radiosity what so ever. quake 2 and 3 does.

Dynamic lightning when it comes to using lightmaps is not a different method, the quake engine modifies the lightmaps and the lightgrids in realtime just before it is renderd.
That''s why you sometimes can see the dynamic lights on the other side of the wall.

quote:

---

Original post by Luke Philpot
[quote]Original post by James Trotter
Quake actually uses radiosity lightmaps...

---

Quake uses regular lightmaps.




Sorry I meant Quake 2 and 3...
They actually precompute the lightmaps, with radiosity, before rendering...

quote:

---

Original post by exsanity
I''ve written a dynamic lights demo which uses a sort of fake 3D texturing algorithm and I''m hoping to write a tut on it soon. You can find the demo here :

http://www.exsanity.freeola.com/opengl.html

---

Nice demo!!

Looks like I made another great post so far

Anyway, Ive read the quake2 source code many times over and have studied how mr Carmack wnt about the dynamic lighting, to me its looks like he just made a circular triangle fan and then maped it to the "surface".

Anyway, Ive been told that quake3 takes something like 10 hours to compile its lightmaps...? kinda odd.

How does GL lighting work, I know that its per vertex, but how do they calculate it?

Thanx a lot...

~yodaman

quote:

---

Original post by yodaman
How does GL lighting work, I know that its per vertex, but how do they calculate it?

---

All of this is explained in the Red Book''s 6th chapter.

Ok here is some simple code of per vertex lighting
it''s an old one and i will never try to use lightmaps cos
per pixel lighting is the future.
But if someone can make it better or for spot lights post it!!!

btw: it''s not for real time rendering still precalculat and
store it for static meshes!




// For Omnidirection Point Lights
// This function does the vertex lighting calculations of a given object
// pVertices = global pointer to all Vertices from all objects
// pVerticesColors = global pointer to all Vertices Colors from all objects
void CGLObject3ds::CalcVertexLighting( Light3DS *LightObj )
{
static Vector3D lightDir;
static int i;
static float dist, radius, ratio, dot;
static float cr,cg,cb;

// for 3ds Omni Light - intensity is the 3ds multiplier
// 1800.0f make it bigger
radius = 1800.0f * LightObj->intensity;

// This loop goes through all Vertices in the scene
for( i=0; i < numOfVertices; i++ )
{
// Check for visibility (Front Face)
lightDir.x = LightObj->pos.x - pVertices.x;
lightDir.y = LightObj->pos.y - pVertices[i].y;
lightDir.z = LightObj->pos.z - pVertices[i].z;
// myVectorMath.Sub( &LightObj->pos, &pVertices[i], &lightDir);
myVectorMath.Normalize( &lightDir );
dot = myVectorMath.DotProduct( &lightDir, &pVerticesNormals[i] );

// Check if front faces visible
if ( dot > 0.0f )
{
// Accurate distance check
dist = myVectorMath.Distance( &LightObj->pos, &pVertices[i] );

// If within radius than calculate the vertices color based on its
// distance from the light, the light color and the lights intenstity
if ( dist < radius )
{
ratio = (1.0f - dist/radius) * LightObj->intensity;
cr = ratio * LightObj->color.fRGB[0];
cg = ratio * LightObj->color.fRGB[1];
cb = ratio * LightObj->color.fRGB[2];

// Befor this - pVerticesColors[x].x was filled with a base light color ( 0.3f, 0.3f, 0.3f )
if ((pVerticesColors[i].r += cr) > 1.0f) pVerticesColors[i].r = 1.0f;
else pVerticesColors[i].r += cr;
if ((pVerticesColors[i].g += cg) > 1.0f) pVerticesColors[i].g = 1.0f;
else pVerticesColors[i].g += cg;
if ((pVerticesColors[i].b += cb) > 1.0f) pVerticesColors[i].b = 1.0f;
else pVerticesColors[i].b += cb;
}
}
}
}

quote:

---

Original post by Luminous Blue
per pixel lighting is the future.

---

Agreed! Alot of engines use per-pixel lighting nowadays, and it gives amazing results! Sorry, I don''t have any examples right now... But with programmable pipelines it is much simpler to perform, because it''s all hardware.

About the post on lighting calculation times for Q3:
With the updated compiler you can perform advanced lighting calculations ( Radiosity, light filters, ect ) in under 30-60 minutes for a medium sized map.

The only problem about PPL is that it makes people have a decent video card or else the game will run slow. It ends up making you program a ''fallback'' method ( vertex lighting or something like that ).

exsanity, I agree that is a nice demo!

yes yes! Very nice work exsanity