Light_brush and ambient color bugs
by Tom Spilman · in Torque Game Engine Advanced · 12/23/2004 (12:26 pm) · 13 replies
I'm messing with lights preparing to release this CartShop exporter... in particular the light_brush emitter. I setup the following scene which has a few unexpected results:
The most surprising result is that my ambient color was set to red... i got blue insted. I'm tracking this issue down now as it's probably just a typo somewhere.
Second is how the light brush is behaving. The floor and ceiling seem to be correct getting the green light brush light, but i'm surprised that the walls are not getting any green light at all. Also what is that little blue ring on the floor under the brush light. It doesn't seem that *any* ambient should be visible that close to the light.
FYI. The room is 512x512x192, the light brush is 128x128x24 with a falloff of 160.
The most surprising result is that my ambient color was set to red... i got blue insted. I'm tracking this issue down now as it's probably just a typo somewhere.
Second is how the light brush is behaving. The floor and ceiling seem to be correct getting the green light brush light, but i'm surprised that the walls are not getting any green light at all. Also what is that little blue ring on the floor under the brush light. It doesn't seem that *any* ambient should be visible that close to the light.
FYI. The room is 512x512x192, the light brush is 128x128x24 with a falloff of 160.
About the author
Tom is a programmer and co-owner of Sickhead Games, LLC.
#2
I wasn't aware that it was baking in the ambient lighting. But it does clearly show that it's the TSE runtime which is fouling things up. I'm thinking it's the code that builds the shaders or your using a BGR format.
12/23/2004 (4:15 pm)
Here are the two lightmaps generated:I wasn't aware that it was baking in the ambient lighting. But it does clearly show that it's the TSE runtime which is fouling things up. I'm thinking it's the code that builds the shaders or your using a BGR format.
#3
I've changed my mind... the lightmaps for the ceiling and walls are screwed up too as the edges should be smoothly blending together.
12/24/2004 (10:54 am)
Learning alot about the new renderer internals, but i've still not tracked down where the rgb values get flipped. Here is another screenshot with a plain white base texture and no bump map:I've changed my mind... the lightmaps for the ceiling and walls are screwed up too as the edges should be smoothly blending together.
#4
For now i'll focus on the light_brush lightmap calculation errors in map2dif.
12/24/2004 (11:30 am)
Ok.... ok... something weird is going on. If i do a 'Relight Scene' in the mission editor the interior will switch from BGR to RGB (meaning my red lightmaps turn from blue to the correct red). If i then do *another* 'Relight Scene' it swaps back from red lightmap ambient to blue lightmap ambient colors. I might poke at this some more, but i bet Brian can find it faster than i can.For now i'll focus on the light_brush lightmap calculation errors in map2dif.
#5
I kinda understand what's going on with the odd box effect under the light_brush. I'm not a radiosity expert by any means, so forgive me if i'm completely off base here. It seems to me the light_brush intensity value is non-intuitve how it is now. Here is the lightmap generated via two different light brushes with the same intensity but with different sizes:
I would have expected both to be the same basic coloring, but different sizes. Still investigating it all, but maybe the RadEmitter->mIntensity should take the size of the surface into account.
12/24/2004 (2:20 pm)
Sorry Brian... i know this thread is getting long, but i'm kinda in a groove here.I kinda understand what's going on with the odd box effect under the light_brush. I'm not a radiosity expert by any means, so forgive me if i'm completely off base here. It seems to me the light_brush intensity value is non-intuitve how it is now. Here is the lightmap generated via two different light brushes with the same intensity but with different sizes:
I would have expected both to be the same basic coloring, but different sizes. Still investigating it all, but maybe the RadEmitter->mIntensity should take the size of the surface into account.
#6
12/24/2004 (7:05 pm)
Ah, the joys of different definitions of light emission. ;)
#7
Why is the ceiling (image 4 posts up) getting *so* much light while the ground gets so little?
Why do the bottoms of the walls not get the same amount of light as the floor in front of them?
Why is the surface below which is closer to the light brush get less light that the sides or ceiling?
And of course... what's up with my red ambient coming out blue or red depending on how many times i 'relight scene'? =)
12/24/2004 (7:55 pm)
You probably know more about it than i do really, so if you get some time please explain these to me:Why is the ceiling (image 4 posts up) getting *so* much light while the ground gets so little?
Why do the bottoms of the walls not get the same amount of light as the floor in front of them?
Why is the surface below which is closer to the light brush get less light that the sides or ceiling?
And of course... what's up with my red ambient coming out blue or red depending on how many times i 'relight scene'? =)
#8
I'll let Brian address this stuff. My briefy, inaccurate two cents: I'd imagine that it largely has to do with map2dif using a pretty naive lighting model. We have better tech, just nothing we've deployed (see milestones for TSE.)
As for the relight scene thing, maybe the scenelighting code is mucking with stuff it ought not. :)
12/24/2004 (9:12 pm)
Don't look at me. I just work here. ;)I'll let Brian address this stuff. My briefy, inaccurate two cents: I'd imagine that it largely has to do with map2dif using a pretty naive lighting model. We have better tech, just nothing we've deployed (see milestones for TSE.)
As for the relight scene thing, maybe the scenelighting code is mucking with stuff it ought not. :)
#9
I'm not sure why the RGB is getting flipped exactly, but it has something to do with them getting flipped when they are loaded in GBitmap. For some %&^%$ reason DirectX uses a BGR order when submitting color data instead of the much more common RGB. So there is code in some places to reverse it.
Be aware that the light brush is not a radiosity light and therefore it does not bounce light around the room. It merely creates a bunch of smaller lights along the brush surface plane(s) to create a sort of "area light".
The bottom of the walls get less light because the angle from the lexels at the bottom of the walls to the light source is higher than of those on the floor. If you don't take the angle of the surface to the light into account and just use attenuation, your lighting looks really flat, almost ambient. That's, in fact, what the stock TGE lights do and is part of the reason the Lighting Pack lighting looks a lot better.
Moving a brush light source really close to the ground will cause it to get darker, especially if your lexel size is pretty large. The reason is that the angle from the lexel center to the light source(s) can get really high if the light is not centered right over the lexel. Don't do that ;) Or write a new light source type if that's an effect you are looking for - in this case removing the angle calculation from the lighting equation would make it look better and do what you'd expect - get brighter real close to a surface.
There are some lighting issues that need to get fixed before we do the first big release of TSE. I'm hoping I can give this another pass in the next milestone, otherwise it'll have to wait till I get to dynamic lighting in milestone 4.
12/29/2004 (11:07 am)
OK, what you are seeing Tom is a combination of several problems. First, there is currently no ambient light factor for the INSIDE of the interiors, but there is for the outside. Not sure why that didn't get in on the first run, but it will be fixed.I'm not sure why the RGB is getting flipped exactly, but it has something to do with them getting flipped when they are loaded in GBitmap. For some %&^%$ reason DirectX uses a BGR order when submitting color data instead of the much more common RGB. So there is code in some places to reverse it.
Be aware that the light brush is not a radiosity light and therefore it does not bounce light around the room. It merely creates a bunch of smaller lights along the brush surface plane(s) to create a sort of "area light".
The bottom of the walls get less light because the angle from the lexels at the bottom of the walls to the light source is higher than of those on the floor. If you don't take the angle of the surface to the light into account and just use attenuation, your lighting looks really flat, almost ambient. That's, in fact, what the stock TGE lights do and is part of the reason the Lighting Pack lighting looks a lot better.
Moving a brush light source really close to the ground will cause it to get darker, especially if your lexel size is pretty large. The reason is that the angle from the lexel center to the light source(s) can get really high if the light is not centered right over the lexel. Don't do that ;) Or write a new light source type if that's an effect you are looking for - in this case removing the angle calculation from the lighting equation would make it look better and do what you'd expect - get brighter real close to a surface.
There are some lighting issues that need to get fixed before we do the first big release of TSE. I'm hoping I can give this another pass in the next milestone, otherwise it'll have to wait till I get to dynamic lighting in milestone 4.
#10
I've seen the GBitmap::convertToBGRx()... i guess it's not as smart as i assumed it was and ends up toggling back and forth between RGB and BGR. Most likely the problem stems from GFXD3DTextureManager::_refreshTexture() which may pass GFXD3DTextureObject->mBitmap thru _loadTexture() multiple times which in turn calls convertToBGRx(). Two options here:
1. GBitmap needs to know it has already been flipped... which is bad as it causes all the rest of the engine to need to worry about BGR bitmaps.
2. Never use convertToBGRx() on the bitmap passed to _loadTexture()... instead allocate a new texture, copy it, then flip it.
I think 2 is a better option if you optimize bitmap copying in GBitmap.
As far as brush lights i'm kinda learning to live with the odd things in it. Still some massaging to the code so that it takes into account that the emitter patch and the target lexel are not points would help. I'll be looking at this myself and i'll submit any useful patches i come up with.
12/29/2004 (1:00 pm)
Thanks for the reply Brian.I've seen the GBitmap::convertToBGRx()... i guess it's not as smart as i assumed it was and ends up toggling back and forth between RGB and BGR. Most likely the problem stems from GFXD3DTextureManager::_refreshTexture() which may pass GFXD3DTextureObject->mBitmap thru _loadTexture() multiple times which in turn calls convertToBGRx(). Two options here:
1. GBitmap needs to know it has already been flipped... which is bad as it causes all the rest of the engine to need to worry about BGR bitmaps.
2. Never use convertToBGRx() on the bitmap passed to _loadTexture()... instead allocate a new texture, copy it, then flip it.
I think 2 is a better option if you optimize bitmap copying in GBitmap.
As far as brush lights i'm kinda learning to live with the odd things in it. Still some massaging to the code so that it takes into account that the emitter patch and the target lexel are not points would help. I'll be looking at this myself and i'll submit any useful patches i come up with.
#11
12/29/2004 (1:04 pm)
Heh... my simple hack to fix this for now.... call convertToBGRx() a second time before leaving GFXD3DTextureManager::_loadTexture(). The CPU burn of a second flip is probably better than a memory allocation, copy, then flip.
#12
Is there a plan for light_brush entities to eventually make it into the runtime engine? It doesn't seem like they would.
01/03/2005 (9:17 am)
Well i've just realised the biggest issue with using a light_brush: they do not exist in the final DIF. I should have realised it before, but they will not effect the player model at runtime or DTS shapes during a mission relight. This seems to limit their use to special effects with real lights (omni and spots) doing the runtime effects. Which makes me think that at some point an artist will ask for a way to disable an omni or spot light during lightmapping and have it only work for mission relight.Is there a plan for light_brush entities to eventually make it into the runtime engine? It doesn't seem like they would.
#13
This will require some experimentation, the lighting/shadow phase is milestone 4. I'd like to fix some of these map2dif problems in milestone 3 though.
01/05/2005 (3:49 pm)
It depends on how the lighting shakes out for dynamic objects (like the players). If we end up exporting lights from interiors and then light dynamic objects from the nearest lights, then we'll have to export the brush lights. It would probably look OK if it just lit from the center of the brush light. Or if it acted as a directional light within a certain radius. This will require some experimentation, the lighting/shadow phase is milestone 4. I'd like to fix some of these map2dif problems in milestone 3 though.
Associate Tom Spilman
Sickhead Games
So the ambient light issue is a problem in the TSE runtime and not map2dif code.