How is the player visibility calculated?

[Skaruts]

I've been slowly trying to make a little stealth game on my own (in the Godot engine), largely inspired in Delver as well as Thief, but I'm not sure how to tackle lights and player visibility. There's a document by Sean Barret where he mentions they might have used floor lightmaps for this in the old Dark Engine, but I assume T:TDS and TDM use totally different methods, since lighting is dynamic.

 

Can someone give me some insights on how this stuff works?

 

 

 

 

 

[STiFU]

For the visibility calculation, the player is represented by an octahedron. This octahedron is rendered-to-texture to capture the incoming light, which is then accumulated to calculate the actual visibility.

[Skaruts]

Not sure I'm following. What do you mean by "rendered-to-texture"?

 

Also why an octahedron?

[nbohr1more]

Here is the whole process:

 

1) Create a new low resolution subview with screen cropped to the size of the octohedron from step 3

2) Cull all surfaces that do not cast shadows

3) Replace the player model with an octohedron (lowest number of polys to catch light from all directions) with a two-sided material (light affects both sides)

4) Spawn a camera inside the octohedron facing up

5) Capture a screenshot to a memory buffer (PBO)

6) Scan the screenshot for the brightest pixel and write out the value

7) Rotate the camera facing down and Capture another screenshot to the PBO

8) Scan the new screenshot for the brightest pixel and compare to step 6

9) Bias the brightness value with things like crouch offset, speed, holding a weapon, etc.

10) Send the final value to the AI algorithm to tell it how bright the player is if the player is in the line of sight

[HMart]

Not sure I'm following. What do you mean by "rendered-to-texture"?

 

Render to texture is the ability to render the 3D view of a camera into a 2D surface, in this case a texture, imagine a security camera view being shown in a monitor, that monitor is the texture. With this feature you can do neat stuff like, security cameras obviously, portals like those of Prey and Portal, mirrors, fancy skyboxes, etc.

[Skaruts]

Here is the whole process:

 

1) Create a new low resolution subview with screen cropped to the size of the octohedron from step 3

2) Cull all surfaces that do not cast shadows

3) Replace the player model with an octohedron (lowest number of polys to catch light from all directions) with a two-sided material (light affects both sides)

4) Spawn a camera inside the octohedron facing up

5) Capture a screenshot to a memory buffer (PBO)

6) Scan the screenshot for the brightest pixel and write out the value

7) Rotate the camera facing down and Capture another screenshot to the PBO

8) Scan the new screenshot for the brightest pixel and compare to step 6

9) Bias the brightness value with things like crouch offset, speed, holding a weapon, etc.

10) Send the final value to the AI algorithm to tell it how bright the player is if the player is in the line of sight

Wow that's a rather sophisticated process. More than I was expecting, at least. And yea, I can see the reasons for the octahedron then. Thanks.

 

Out of curiosity, do you know how it was done in Thief 3? (Or was it a similar process?)

 

I wonder if I could use some simpler alternative for my project, but I'm not sure what are the alternatives. I can see raytracing as a possibility, but I'm not sure how I could make it work properly. Someone suggested to me a while ago calculating it based on that and on the distance to the affecting lights.

 

 

Render to texture is the ability to render the 3D view of a camera into a 2D surface, in this case a texture, imagine a security camera view being shown in a monitor, that monitor is the texture. With this feature you can do neat stuff like, security cameras obviously, portals like those of Prey and Portal, mirrors, fancy skyboxes, etc.

Ah ok. I was thinking of that, but wasn't sure. Would've never guessed that would be the way to make Portal-like portals, though. That's why I wasn't sure, I wasn't seeing the connection.

Edited October 12, 2018 by Skaruts

[nbohr1more]

Thief 3 apparently alternately samples the brightness of 12 bone positions and weights them based on

some priority factors. The sampling probably amounts to running the entire render for a small number of pixels

or a single pixel.

 

I suppose we could make our system closer by cropping to single pixel values on the vertex points of the octohedron

and center points of the triangles as well. So it would be 8 single pixel screenshots in the up direction and 8 in the down.

 

Our lightgem cost is already so low now that it seems that it wouldn't be worth the effort (and precision loss) for this additional optimization.

 

Might be cool to test though...

[HMart]

Ah ok. I was thinking of that, but wasn't sure. Would've never guessed that would be the way to make Portal-like portals, though. That's why I wasn't sure, I wasn't seeing the connection.

 

Render to texture is only a part of a portal system, there's more to it, like teleporting the player, cloning the player movement into a clone, when he is entering the portal but has not traversed fully, so you can be in two places at the same time, etc.

Edited October 13, 2018 by HMart

[Skaruts]

What would be some alternative ways to do this?

[nbohr1more]

If the lights were all spherical then you could just trace to their center and lerp the falloff value. No need to render. That's basically what our tdm_lg_weak does but it's not accurate because we have 1D+2D lights that use projection and falloff images.

 

Another way would be to convert the light textures to low resolution arrays and populate the map with voxel data of the light volumes the player is inside of and sample those voxels.

[Skaruts]

I'll only have spherical lights, so I'll probably give tracing a try, then. I think I'll have to find a way to account for when the player is only partially in the light. I suppose that may involve several ray traces from, or to, the player's bounds.