Workings Of See-ability?

[Ishtvan]

@Pyrian: We're thinking of trying something similar to what you described for the silhouette calculation. However, we're hoping we don't have to project the entire shadow/silhouette of the player onto the "back" wall with respect to the AI. Instead, we select a few points to do this with, like the top of the player's head, left shoulder, right shoulder, feet, for example.

 

We trace a vector from the AI's eyes to these 3 points, and see what texture is hit beyond them. (Incidentally, in doing this trace we'll be able to tell if the points on the player's body are blocked from the AI's eyes by geometry, which gives us some "partial visibility" detection for free). Then we check the brightness of the texture that is hit on the "far wall."

 

To rephrase, for each averaged point on the player's body, and for each AI that has the player in their FOV, consider a ray from the AI's eyes to the point on the player. Extend the ray past that point until it hits geometry behind the player. Read the texture brightness where it hits. Assume that the player is always pitch black, so the brightness of the background point gives you your silhouette visibility number. Average the points, then somehow factor this into the visibility number that is already obtained from the lightgem (direct brightness of the player) and distance to player.

 

You could compare the lightgem value of the player with the brightness of the background, but since the player is wearing black clothes I think it won't help matters if both he is lit up and the background is lit up. That's why I suggested assuming that the player is always pitch black.

 

@FishFace: Yeah I think there needs to be a distance cap. It's not fun to be spotted from 500m away. Also @both of you, be careful not to confuse silhouetting with eclipsing, where you actually step between someone and a point light source, so that someone far away who is looking at the far-field corona from that lightsource sees the light corona disappear entirely. That's a different effect and I don't think we'll be modeling that.

Edited May 18, 2005 by Ishtvan

[grinningman]

Sorry for the thread revival, I'm procrastinating. I'm assuming you haven't implemented silhouette detection yet

 

I don't think you should implement it. If someone can see your silhouette, all it means is that you're being lit from behind (i.e. the side of you the observer can see is dark, and the side of you that the observer can't see is lit). There's already a light gem to tell you how much light is falling on you, regardless of the direction. Voila: automatic silhouette detection.

[sparhawk]

Wrong reasoning. The lightgem just tells you how much you are lit in general, not wether you are standing in front of a lightsource.

 

Simple example: You are standing in a tunnel where a bright light is lit in front of it. Since you are in the tunnel, there is no light that can directly hit you. Nevertheless, when somebody enters the tunnel behind you, so that you are between the light and the observer, he would notice you because he can clearly see you against the light, even though the lightgem would show dark.

[grinningman]

I don't think it's the wrong reasoning - in your example, it is the reflected light from the wall (or whatever) you are silhouetted against that is illuminating you. By definition, you can't be silhouetted unless something is illuminating you from behind. The problem is that the game engine doesn't treat illuminated objects themselves as sources of light.

 

But I guess this is just restating the problem in a different way - instead of finding a way for the guards to detect your silhouette, you have to make every lit object another source of light. This is probably too difficult - there might be too many calculations, and you'd have to work out how reflective each surface/object is.

[sparhawk]

I see what you mean. But still this is wrong. First of all, if you are far enough into the tunnel, you would definitely not be lighted up, but visible from the other side.

And secondly, this is a game engine and not real light, so they had to do some limits somewhere.

 

In fact, the engine properly lights up your character, even if you are not directly in line with a lightsource.

[grinningman]

First of all, if you are far enough into the tunnel, you would definitely not be lighted up, but visible from the other side.

 

I guess I disagree. If you are so far inside the tunnel that you're not lit at all, there won't be enough light for someone else to see your silhouette against. I will check next time I'm in a dark tunnel with a friend

 

In fact, the engine properly lights up your character, even if you are not directly in line with a lightsource.

 

That's interesting - how does it do this? Is it ambient light, or does the light spill around corners?

[sparhawk]

I have to check this to make sure.

[ZylonBane]

I don't think it's the wrong reasoning

But, alas, it is.

 

The reason silhouette recognition work so well in real life isn't because of illumination, it's because of CONTRAST. Under exactly the same lighting conditions, someone in dark clothing standing against a light background will be much more visible than if they were standing against a dark background.

 

This is why adding silhouette recognition to a game engine would pretty much require a render pass from the perspective of every AI near the player.

[Domarius]

grinningman, sillhouets of an object aren't created by light falling on it.

 

If you are deep into the pitch black tunnel, no light is hitting you.

 

If someone else in front of you can see the opening of the tunnel behind you, where everything outside is brightly lit, they will see your sillhouette, because you are blocking their view of the opening. That is all.

[OrbWeaver]

Grinningman is correct in a purely pedantic, literal way, in as much as the existence of a silhouette entails a difference between light that intercepts (and therefore "illuminates", if only very slightly) an object and light which doesn't.

 

This is nevertheless merely a semantic debate that has no relevance to the actual issue, which is whether the lightgem in its current incarnation automatically takes care of silhouettes (it doesn't).

[Domarius]

Yeah his theory was: to have a sillhouette, you have to have light hitting you, therefore the light gem is the perfect answer. I was trying to explain how this is not the case.

[cloud dew]

All you want the AI to know is light hitting the thief, and is a straight line of sight available between the player & AI

If it is true you could use the light gem. This is a far simpler way of getting that interaction from the AI. They are not going to go ooh look pretty gfx effect!

 

Without light he would be invisible. But with bright/moderate light either behind or in front he would be illuminated, provided, say a wall is not in the way.

This is not pedantic its fact, imagine standing the other side of the tunnel & the thief would be lit. If not then the quantity of the light coming down the tunnel is NOT enough for a sillhouette if you were then at the other end of the tunnel.

Go outside and try it in RL.

BTW I used to teach physics so don't bother arguing

 

 

So you dont need additional complex calculations to test for his visability, in order to get the same game play effect.

Just that for the light gem.

 

Oh I read a bit from the oblivion devs they had life like bow physics in the game , but dumbed it down as it was not entertaining.

Anyways GL ppl keep it up!

I think your mod is a great piece of work I hope you finish it.

Edited May 10, 2006 by cloud dew

[SneaksieDave]

An in-game object (where the effects of "light" have a finite transmission distance, even though it can be seen much further - yes it makes no real world sense) does not have to be lit from a side to obscure a viewer's ability to see the light from the other side.

[Gildoran]

In fact, the engine properly lights up your character, even if you are not directly in line with a lightsource.

I completely disagree with this assertion, at least with the D3 engine. However the mapper can set up other lights to simulate this to some extent.

[OrbWeaver]

Without light he would be invisible. But with bright/moderate light either behind or in front he would be illuminated, provided, say a wall is not in the way.

This is not pedantic its fact, imagine standing the other side of the tunnel & the thief would be lit. If not then the quantity of the light coming down the tunnel is NOT enough for a sillhouette if you were then at the other end of the tunnel.

Go outside and try it in RL.

BTW I used to teach physics so don't bother arguing

 

Nobody is disputing that this in real life, the existence of a object's silhouette implies that some light is hitting the object.

 

Grinningman's assumption was that this is also true in the Dark Mod lightgem code, which is incorrect. The lightgem only responds to light which falls on the player directly from an in-game light source, not theoretical light reflected off other game surfaces.

[ZylonBane]

Yah, the D3 engine doesn't do ray-tracing.

 

Even if it did though, the lightgem would not indicate silhouette conditions. It is true that when you're standing in front of something bright, more photons are hitting you than when you're standing in front of something dark (seeing how as that's pretty much the definition of the difference between bright and dark). However, in general this difference does not add up to a significant amount of illumination. As I noted above, it's all about the CONTRAST.

 

Consider this extreme example-- Say you're outside at night, not a cloud in the sky, no moon, and miles away from any artificial light sources. There's starlight, but for all practical purposes, there is no illumination. So look up at the stars (oooh, pretty). Now if something large were to obscure your view (say, a blimp), you'd see it. Specifically, you'd see a large blimp-shaped hole in the sky. That's how silhouetting works.

[demagogue]

An extreme case came to my mind, too (as if the case needed more help). When I visted one of those massive "tourist caves" once, they turned out the lights in one large cavern, and it was seriously *pitch* black except for one tiny, tiny red light from someone's camera (or cell phone) really stuck out, and I could tell when people were crossing in front of it because it would pulse in and out of blackness as people passed. Technically silhouette recognition, but from my p.o.v. it was from my memory of the light being there and then being swept in total darkness, not even contrast this time; realistically it was whatever miniscule amount of light was actually hitting him *exactly* in line with my line of sight on the other side ...hardly practical to check.

[grinningman]

What Orbweaver said.

 

I initially thought the idea would be a neat way to bypass having to worry about working out a whole bit of code just for silhouette detection, but given the way the light gem works, it isn't.

 

I'm not persuaded by Zylonbane's and Domarius' examples, but don't have time to get into a debate (until I finish what I'm procrastinating from, anyway). I think Demagogue's example would be closer to shadow detection than silhouette detection. Anyway, as Orbweaver said, much of this is semantic.

[ZylonBane]

I'm not persuaded by Zylonbane's and Domarius' examples, but don't have time to get into a debate

Considering the reasoning skills you've demonstrated thus far, that's most likely for the best.

[sparhawk]

Without light he would be invisible. But with bright/moderate light either behind or in front he would be illuminated, provided, say a wall is not in the way.

 

He might be illuminated but he doesn't need to. Of course silhouettes and lightsource obcclusion can easily be confused because for the RL consequence, it is pretty similar. Also the player would be lit on the wrong side, because if you see his silhouette he would be dark on the AI side, even if he is lit on the other side.

 

I think your mod is a great piece of work I hope you finish it.

 

Not much chance of stopping us now.

[sparhawk]

An extreme case came to my mind, too (as if the case needed more help). When I visted one of those massive "tourist caves" once, they turned out the lights in one large cavern, and it was seriously *pitch* black except for one tiny, tiny red light from someone's camera (or cell phone) really stuck out, and I could tell when people were crossing in front of it because it would pulse in and out of blackness as people passed. Technically silhouette recognition,

 

This is an example of light occlusion. The major difference IMO is. When you see the silhouette you can make out the shape, but with light occlusion you can't. You can only determine wether the light has is visible or not, and from this you draw the conclusion that something moved in front of the light. If somebody would randomly turn on and off this tiny light source, you might get the same impression.

[ZylonBane]

This is an example of light occlusion. The major difference IMO is.

There is no difference. A silhouette, by definition, occludes something lighter than itself. It doesn't matter whether the something is a direct or indirect light source.

 

grinningman's malfunction is that he seems convinced that the amount of back-lighting required to create a distinct silhouette is equal to the amount of front-lighting required to make the player directly visible.

[sparhawk]

There is a distinction, at least when it comes down to coding it.

 

If you have a proper silhouette, you need to check the contrast against the background, as you said previously. However, if you occlude the full light, you would have different effects, and the contrast would not be possible to determine it. It depends on the lightsource and the size and strength of it. You could get a halo effect, where contrasting would work. But as demagogue pointed out, you would also notice the lights vanishing and appearing, even if the lightsource would be pretty small and no silhouette would be visible.

[ZylonBane]

Considering that a decent real-time algorithm would just average the difference between frames with and without the player image, it doesn't really matter whether they're occluding a direct or indirect light source.

[grinningman]

grinningman's malfunction is that he seems convinced that the amount of back-lighting required to create a distinct silhouette is equal to the amount of front-lighting required to make the player directly visible.

 

Yes, that's what I've been trying to say. It's not obvious to me, even after your examples, that this is wrong (here's an invitation to all manner of witty put-downs, obviously).

 

I did think of an example where you're sitting in a lit room - you can look out a window to the night sky and see a silhouette against the stars even thought the star illumination is essentially zero compared to the room lights. So yeah, you're probably right.