Game Development Community

Lighting not affecting the dts player

by Paul Usul Fluegel · in Torque Game Engine · 01/22/2007 (5:36 pm) · 5 replies

Hi,

I have come upon a very big problem, I cant get my interior's to cast shadows on my player, is this just the way it is, or am I doing something completely wrong.. this is the scenario:

img181.imageshack.us/img181/7684/deassshadows5vx.th.jpg
here he is standing under a lamppost, and should be partially in the shadows

img263.imageshack.us/img263/3879/deassshadows23wd.th.jpg
here he is standing behind the corner of a building, but in fact still lit by the light on the other side of the wall...

img265.imageshack.us/img265/6812/deassshadows38oc.th.jpg
here i have placed him under my entire city, and still he's lit

As you can clearly see that's all wrong..

Now the lamp post is a interior, does it need to be a dts?
Or do i need to change some attributes in the mission light/datablock?
Or is my fresh meat dts sick :P ?

Really hope some can help, as this is really killing me..
Look forward to hearing from you, Paul

About the author

Recent Threads


#1
01/23/2007 (9:10 am)
There's one known issue which can cause this.
it's a little involved to explain tho.

TGE lights the character based on on the lightmaps in the DIF files.

the idea is that a ray is cast straight down from the player,
it hits the DIF, samples the lighting at that location, and applies it to the player.

the problem comes in in the "sampling" portion.
altho there is valid lightmap texture values over the whole DIF,
for some reason TGE actually goes out and samples the lightmap only at the vertices of the polygon which the Player is above, and then interpolates those to determine the lighting at the player.

for example,
say you had a DIF with one huge triangle,
and it's dark everywhere except for a light in the middle.
when your player is in the middle,
TGE doesn't actually look at the lightmap in the middle,
it looks at the lightmap only at the corners of the triangle,
and then guesses what the lighting is in the middle.

it's kind of a bummer.

the way we've fixed it is by subdividing the DIF geometry wherever the lighting is changing a lot.
for example, in your streelight pic above, if you made sure the street had a vertex right there, it might work.

hmm, actually, maybe this isn't the problem you're encountering.
- does the Orc still look wrong when he's standing on the sidewalk versus the street ?
'cause there's got to be vertices at the corner of the sidewalk.

note - to see the lightmap you can use setInteriorRenderMode(5),
and to see the poly's, i think setInteriorRenderMode(2).
(or just try 0 thru 11 ;)
#2
01/23/2007 (9:17 am)
Thanks alot, for the reply! I will look at your possible solution :D

kind of a silly way of doing that thou.. hmm :(
#3
01/23/2007 (11:58 am)
Actually, the problem is with the mission light. Standard mission lighting does not compute collisions with lighting objects other than terrain and interiors, ie. anything dynamic. Because of this, the player will still be lit from behind walls. For the light, you will probably want to disable dts lighting and have all lighting from the player be calculated from the interior's lightmap.

However, this will solve the problem of your character being lit behind walls, but will lead to a problem that Orion explains. You will more than likely have to split up the brushes around complex lighting or changes in light to ensure the player is properly lit for what he is standing on.

I hope this isn't to vague.
#4
01/28/2007 (9:36 am)
I really get what you are saying, but I am not quite satisfied with the different solutions available just now, I have been trying the different approaches, and they don't really appeal to my game, witch is quite light shadow dependent..

Does TGEA offer any thing better? does any body know? it just says "Introducing multiple shadowing algorithms , self-shadowing objects" under the lighting, specifically the shadows...

This kinda has me stumped, as i would buy it first pay check around, if I was secured that interiors actually cast shadows on dts, IE the player..

And that really bothers me, and the hole calc the general light from what I am standing on, seems like a bit of a hack, but I don't know that much, so could easily be mistaken..

Could i maybe disable static light casting from the light source and enable dynamic light for the interior.. no, still does not solve the problem of the player not being lit, just causes a bunch of real time lighting..

but what have people done about this? are people living with this solution or have your teams programmer "fixed/improved" it..?
#5
01/31/2007 (10:14 am)
Interior light maps are not available to system memory during runtime, meaning vertex lighting info is the only way to extract static lighting information from the interior. There is code going into the next TGE release that does rough occlusion testing when using "Affects DTS Objects" on static lights, but dynamic lights still do not cast shadows (other than the projected shadows from players, vehicles, ...).

TGEA/TSE works in a very similar way, though with *much* nicer graphics.

People are working with that feature all the time (Torque has always done DTS lighting this way). You just need to keep how the level and player interact in mind while building interiors.