Archived

This topic is now archived and is closed to further replies.

Light Question

This topic is 5506 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a map editor, and want to add lighting to it. Thus far it displays lots of polygons with textures, but lighting isn''t implemented at all. I read that with OpenGL there can only be 8 lights, which leads me to my question. What do I do if I dont want a limit to the number of lights? I need to be able to add as many as needed.

Share this post


Link to post
Share on other sites
Use Lightmaps (mulit-texture (or overlay) each poly with your required light)

Or if you wanted to use hardware accelerated lights, for each poly (or room/zone/whatever) have the eight closest lights and then change the lights whenever you draw a diffrent poly. There is nothing stopping you changeing lights between polys.

Just remember that lights only affect the vertecies of each poly.



Do not meddle in the affairs of moderators, for they are subtle and quick to anger.


ANDREW RUSSELL STUDIOS
Cool Links :: [ GD | TG | MS | NeHe | PA | SA | M&S | TA | LiT | H*R ]
Got Clue? :: [ Start Here! | Google | MSDN | GameDev.net Reference | OGL v D3D | File Formats | Go FAQ yourself ]

Share this post


Link to post
Share on other sites
Or you can create your owne light object.

Pass all your polygone in a loop and for each polygone calcul de result a each vertex. You can create a dynamic list of your list and have infinit lights.

ex:
struct dk_Light
{
float r,g,b; //0 to 1
float x,y,z; //Position of the light
float Range; //The range. For attenuation
}

And then for each vertex you calculate the distance between light and your vertex. Make a poucentage % of the distance and the range and add r,g,b color of the light on your vertex.
Vertex.r = light.r * %
Vertex.g = light.g * %
Vertex.b = light.b * %

( this is just a little help, the concept is more complicated, and for realistic lightning, use Normals )

Share this post


Link to post
Share on other sites
Thanks for the suggestions, epecially the last one (gave me a bunch of ideas).

However, should I use lightmaps, I have a few questions.

1) Lets say I have a light in the middle of a room made up of lots of polygons. How can I generate lightmaps for all the polygons based on the light? Similar to how UnrealED and WorldCraft work.

2) How much memory would a large scene (high poly count) require with lightmaps? Much more?

3) Has anyone done this that can tell me what diffuculties they came across. Or know of a decent tuorial that explains how to dynamically generate lightmaps?

Share this post


Link to post
Share on other sites
1) http://polygone.flipcode.com/tut_lightmap.htm
That contains all you need to do simple Lambertian point-lighting.

2) It depends on how high-resolution you make your lightmaps. An RGB scene will be 3 times more memory intensive than a greyscale one. Remember that you''ll have a lightmap for every face, so if you have a very high-poly level and you have high-resolution lightmaps, you''ll use a lot of memory.

3) By dynamically generating lightmaps, I assume you mean in real-time. Generating lightmaps in real-time every frame is very, very slow, and gets slower for every extra light you have. So, you''d want to check to see whether the surface needs its lightmap updating (by checking if a light has moved since the last update, and checking that the light being checked is within a suitable distance of the surface) and if so, update it, otherwise leave it be. This may give you leeway to do bump-mapping too, perhaps via a fragment shader.

Share this post


Link to post
Share on other sites
>>2) How much memory would a large scene (high poly count) require with lightmaps? Much more?<<

usually lm''s are stored with less quality than normal textures
eg quake3a uses IIRC 5-6 (or less) 128x128 RGB textures for the WHOLE levels lightmaps

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html

Share this post


Link to post
Share on other sites
Yeah, I guess that a 16x16 lightmap can safely be mapped on a 128x128 poly. While having prerendered lightmaps works nice in a game with a small playable area (such as Quake 1&2&3), I don''t think it will work on BIG, outdoor areas...

Share this post


Link to post
Share on other sites
Lightmap in real time is IMPOSSIBLE.
Take my engine, to calculate the lightmap (shadow and everything) with a resolution like in QuakeIII, it take 20min for 3000 polygones. So, .01 frame per minute. Humm.. not bad, but I prefer 60 to 90 frame per seconde. lol

DUK engine

Troa Technologies.
(3d game development)

Share this post


Link to post
Share on other sites
No, no, no, I didn''t mean in real time. Sorry for not being more specific. Basicaly, when in the editor mode, I would click a button and it would calculate all the lightmaps and apply them. Thats waht I''m talking about.

Share this post


Link to post
Share on other sites
Ya, I understood. It was just a joke. hehe haha hoho. ok..

Yo, I want to see your map editor. Get my ICQ number : 92921263

I''ll show you my engine. I calculate perfect lightmap.

DUK engine

Troa Technologies.
(3d game development)

Share this post


Link to post
Share on other sites
quote:
Original post by Daivuk
Or you can create your owne light object.

Pass all your polygone in a loop and for each polygone calcul de result a each vertex. You can create a dynamic list of your list and have infinit lights.

ex:
struct dk_Light
{
float r,g,b; //0 to 1
float x,y,z; //Position of the light
float Range; //The range. For attenuation
}

And then for each vertex you calculate the distance between light and your vertex. Make a poucentage % of the distance and the range and add r,g,b color of the light on your vertex.
Vertex.r = light.r * %
Vertex.g = light.g * %
Vertex.b = light.b * %

( this is just a little help, the concept is more complicated, and for realistic lightning, use Normals )


This is exactly what the hardware does (in T&L cards: GeForce), only you are moving it into software. This is A Bad Idea. OpenGL will already do this for you in software if you don''t have capable hardware. Don''t use this method.

The fastest way to do it is to prioritse lights for each poly - or for even more speed - each area.

Just another note - this is what Unreal does for its objects - while the scene is done using light maps, objects (you can see it on your gun as you move around) use hardware lights - this is because they have many more polys. Unreal also does a similar thing for movers (platforms and doors).

For light mapping, you can put more than one face''s lightmap onto a texture - this is what CrystalSpace does.

Do not meddle in the affairs of moderators, for they are subtle and quick to anger.


ANDREW RUSSELL STUDIOS
Cool Links :: [ GD | TG | MS | NeHe | PA | SA | M&S | TA | LiT | H*R ]
Got Clue? :: [ Start Here! | Google | MSDN | GameDev.net Reference | OGL v D3D | File Formats | Go FAQ yourself ]

Share this post


Link to post
Share on other sites
ok. so openGL only suport 8 lights. And for model (qIII and Unreal), for each object they get the 8 nearest lights and put it in openGL lightning system to run faster. Good idea.

But it''s good for real time lightning. But if you only want to recalculate lightning in a map editor every time you place an object, you can do the hard thing.

And what your are talking about, 3D studio5 also use it like this.

DUK engine

Troa Technologies.
(3d game development)

Share this post


Link to post
Share on other sites