Interiors...need some help
by Chris \"Hobbiticus\" Weiland · in Torque Game Engine · 04/05/2003 (10:50 am) · 11 replies
This may be something only the GG peeps would know, but here goes...
For what I'm doing with the interiors, I need to be able to modify only the light that is added to the interior through the sun's directional light. So, I need to leave the ambient and interior lights alone. I also need to do this continually, so relighting the scene each frame would really put a damper on the fps.
I've been poking around the interior code for a couple days now and I still have some questions I just cannot figure out.
What's the difference between the normal light map and the alarm light map? Speaking of which, what is this alarm thing that's scattered everywhere? Are those the lights that pulsate?
What I think I need to do is extract the directional sun light from the light maps and store it in it's own place, then modulate that with the color I want and add it back in at render time.
If there's a simpler solution that anyone could come up with, that'd be great. Especially since this solution would take more memory for more lightmap textures and it would need 3 TMUs to avoid a 2-pass render.
Anyway, if anyone can shed some light on the situation, I'm all ears.
For what I'm doing with the interiors, I need to be able to modify only the light that is added to the interior through the sun's directional light. So, I need to leave the ambient and interior lights alone. I also need to do this continually, so relighting the scene each frame would really put a damper on the fps.
I've been poking around the interior code for a couple days now and I still have some questions I just cannot figure out.
What's the difference between the normal light map and the alarm light map? Speaking of which, what is this alarm thing that's scattered everywhere? Are those the lights that pulsate?
What I think I need to do is extract the directional sun light from the light maps and store it in it's own place, then modulate that with the color I want and add it back in at render time.
If there's a simpler solution that anyone could come up with, that'd be great. Especially since this solution would take more memory for more lightmap textures and it would need 3 TMUs to avoid a 2-pass render.
Anyway, if anyone can shed some light on the situation, I'm all ears.
#2
There's not much to do to get around the basic problem of arbitrary lighting :). Lightmaps are only good for static lighting or abstruse variations on the theme. You could have multiple lightmaps for different stages of the day, and fade them in and out (using a threaded software blender to avoid having to use many TMUs or an intense performance hit), but that would get ugly...
This is a problem which is only going to get solved by throwing cycles at it, I'm afraid, and systems just aren't there yet.
04/05/2003 (12:27 pm)
The alarm stuff came from Tribes2, where buildings would switch to an alternate lightmap if their power was cut. This was known as the "alarm" lightmap.There's not much to do to get around the basic problem of arbitrary lighting :). Lightmaps are only good for static lighting or abstruse variations on the theme. You could have multiple lightmaps for different stages of the day, and fade them in and out (using a threaded software blender to avoid having to use many TMUs or an intense performance hit), but that would get ugly...
This is a problem which is only going to get solved by throwing cycles at it, I'm afraid, and systems just aren't there yet.
#3
04/05/2003 (12:56 pm)
I don't really have to make the shadows move though - just make the color change which would require a LOT less computation time. Just can't figure out how to get a new lightmap to work.
#4
Adding a lightmap would mean 2 passes on a geforce 2, which probably isn't so great if you want to support that card.
If you're dead set on two lightmaps, though, during the lighting calculations you should split out the vector lights (just the sun at present, I believe), rather than trying to post process the lightmaps.
04/05/2003 (1:26 pm)
Chris, instead of using a new lightmap, maybe you should think about varying the vertex color (changes the whole lightmap) and/or using vertex lighting for some of the sunlight.Adding a lightmap would mean 2 passes on a geforce 2, which probably isn't so great if you want to support that card.
If you're dead set on two lightmaps, though, during the lighting calculations you should split out the vector lights (just the sun at present, I believe), rather than trying to post process the lightmaps.
#5
04/05/2003 (5:15 pm)
the problem is changing the vertex colors is that you have no control over the interior and exterior. So, if you change all the colors, then areas that have no interaction with sunlight will change, and that'll suck.
#6
04/05/2003 (7:32 pm)
Obviously, you'd have to change the colors appropriately based on wether they are getting sunlight or not - you could set a bitflag for this during the mission lighting. Just pointing out an alternative to busting the GF2 here - obviously, it's going to have drawbacks vs. using an extra TMU.
#7
04/05/2003 (10:07 pm)
Concidering the interiors are portaled and the engine already has the concept of inside/outside lighting it shouldn't be to hard to get a vertex lighting scheme to not touch the interior lighting.
#8
04/06/2003 (8:06 pm)
Is there? because I think I tried that, and the whole thing was outside when I tried using the mask for it. Is that a mapper problem or does that not work anymore?
#9
Is this something that was ripped out of torque? Because when I try to use it, I get sparatic effects.
It seems almost that SurfaceOutsideVisible means whether or not the outside is visible to the VIEWER insead of the SURFACE, which is a very bad thing. So, IDK what is up, but something is definately wrong here.
EDIT:
The mask works in the interior debug functions, but not for the renderARB_FC function for some reason. I really don't know what exactly is going on in there, but it also looks like there are redundent renders and a lot of other things that could be made much simpler. I just keep looking at the function and every lead I find leads to an even harder path to trace. All I want to do is modulate the exterior polygons with an arbitrary color. This shouldn't be this hard!!!
I tried copy pasting the debug render into renderARB_FC, and it worked fine, and with the SAME EXACT copy-pasted code that did the work in the debug render does NOT work in the origional renderARB_FC function. Don't ask me why, because I have no clue. Can anyone shed some light on the situation?
04/07/2003 (11:45 am)
Ok, that looks like it should be the way to go, but I think the support for inside/outside distinction is broken. The SurfaceOutsideVisible mask is defined, but never assigned to anything - it's just tested against. The mask is also grouped together with SurfaceFlagMask, but SurfaceFlagMask isn't assigned to anything either. The only time they could possibly be defined is in interiorIO.cc which reads/writes them from/to packet data.Is this something that was ripped out of torque? Because when I try to use it, I get sparatic effects.
It seems almost that SurfaceOutsideVisible means whether or not the outside is visible to the VIEWER insead of the SURFACE, which is a very bad thing. So, IDK what is up, but something is definately wrong here.
EDIT:
The mask works in the interior debug functions, but not for the renderARB_FC function for some reason. I really don't know what exactly is going on in there, but it also looks like there are redundent renders and a lot of other things that could be made much simpler. I just keep looking at the function and every lead I find leads to an even harder path to trace. All I want to do is modulate the exterior polygons with an arbitrary color. This shouldn't be this hard!!!
I tried copy pasting the debug render into renderARB_FC, and it worked fine, and with the SAME EXACT copy-pasted code that did the work in the debug render does NOT work in the origional renderARB_FC function. Don't ask me why, because I have no clue. Can anyone shed some light on the situation?
#10
I'm running a GF2, too, and running _MANY_ passes on interiors is still fast. The only catch is that your portals have to be properly placed to avoid over draw. I would feel comfortable running per-pixel per-light lighting on interiors (maybe no more than 3 or 4 lights in a room) on a GF2. I wouldn't worry about adding one more pass.
Hope this helps...
John.
04/07/2003 (11:46 am)
Hi Chris,I'm running a GF2, too, and running _MANY_ passes on interiors is still fast. The only catch is that your portals have to be properly placed to avoid over draw. I would feel comfortable running per-pixel per-light lighting on interiors (maybe no more than 3 or 4 lights in a room) on a GF2. I wouldn't worry about adding one more pass.
Hope this helps...
John.
#11
04/09/2003 (8:06 am)
*bump*
Torque Owner Desmond Fletcher
fletcher
do as you say: