Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / 3D Theory & Graphics / Fast Lightmaps Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Aymeric BARD

August 17, 1999, 05:13 PM

I read everywhere that lightmaps must be implemented as one lightmap by face, but is it realist for an harware accelerated engine ? That means that my nicely optimized engine that draw every polygon which share the same material (texture) in one call will have to be ripped off, and faces will be have to draw one by one, constantly changing the texture handle (which is costly for the 3D card) ??? How the hell does quake work in GL ?
I thought of one big lightmap texture with many little lightmap in it, but it's complex if all the lighmaps does not have the same size, and it should be bifeltering problem on the edge of the face (filtering on the neighbor lightmap...)

Any help will be greatly appreciated
Aymeric

 
Warren Marshall

August 19, 1999, 02:00 AM

To the best of my knowledge, Quake uses one lightmap per poly. But since the lightmaps are so small, compared to the poly (usually 16:1 ratio) they aren't that expensive to render...

Also, the general approach is to render the scene without lightmaps, and then do a second pass that just blends in the lightmaps. Unless you're using multitexturing ... in which case, I'm lost because I don't use that. :P Anyone have any experience in that area?

 
Parashar Krishnamachari

August 27, 1999, 03:51 PM

Warren Marshall wrote:
>>To the best of my knowledge, Quake uses one lightmap per poly. But since the lightmaps are so small, compared to the poly (usually 16:1 ratio) they aren't that expensive to render...

Also, the lightmap can just as well be rendered by any lighting scheme. One could just as well use a very fast lighting algorithm. It also isn't entirely necessary to have a lightmap->poly associative hierarchy. The lightmap is essentially the image as a whole with lighting only.

>>Unless you're using multitexturing ... in which case, I'm lost because I don't use that. :P Anyone have any experience in that area?

Well, he mentioned hardware, so I think he could leave it up to the hardware to do multitexturing. But if you're gonna do lightmapping anyway w/ or w/o hardware, it's not that difficult to introduce a second texture layer. Of course, you've slowed things down in terms of flipping to the screen, but you might be able to render those buffers nice and fast.

- C.P.I. / ASMiNC

 
Jim Broad

August 28, 1999, 07:48 AM

I currently render the lightmaps first, and then blend on the base texture in the second pass, using BLEND = SRC_COL. My main reason for doing this, is I understand that 3DFX can't do blending on DST_COL (can anyone confirm this ?).
It would definately be better to batch up the scene per-texture, render, and then blend the lightmaps on top as Mr.Marshall says - as that would maximize the throughput to the 3d-card.



Warren Marshall wrote:
>>To the best of my knowledge, Quake uses one lightmap per poly. But since the lightmaps are so small, compared to the poly (usually 16:1 ratio) they aren't that expensive to render...
>>
>>Also, the general approach is to render the scene without lightmaps, and then do a second pass that just blends in the lightmaps. Unless you're using multitexturing ... in which case, I'm lost because I don't use that. :P Anyone have any experience in that area?

 
Jaimi McEntire

August 29, 1999, 03:30 PM

You should create 256x256 lightmap polygons. Pack as many lightmaps
onto one texture as possible (be sure to group them by proximity to
each other, so you don't have to swap lightmap textures so much).
Be sure to leave 1 pixel of blank space between each lightmap.
Render all your polygons sorted by texture, keeping a linked
list of the lightmaps needed to be drawn by lightmap texture.
Then go through each lightmap texture, and blend in all the
lightmaps. That's what I do, and the engine is very fast -
you can check it out here: http://www.eldermage.com

Aymeric BARD wrote:
>>I read everywhere that lightmaps must be implemented as one lightmap by face, but is it realist for an harware accelerated engine ? That means that my nicely optimized engine that draw every polygon which share the same material (texture) in one call will have to be ripped off, and faces will be have to draw one by one, constantly changing the texture handle (which is costly for the 3D card) ??? How the hell does quake work in GL ?
>> I thought of one big lightmap texture with many little lightmap in it, but it's complex if all the lighmaps does not have the same size, and it should be bifeltering problem on the edge of the face (filtering on the neighbor lightmap...)
>>
>>Any help will be greatly appreciated
>>Aymeric

 
This thread contains 5 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.