Color information from trace or from texture

[diegofloor]

Let's say I have a fully lit and textured scene and I want the color of a particular point, taking into consideration light. Is this information retrievable with some kind of trace? I was also wondering if rendering to texture could be explored in this task, by setting a camera looking where I want (with a low resolution etc) and then retrieving the information I want from the resulting texture. Is any of this possible?

[schizoslayer]

If you want just an RGB value then I don't think so. However if your plan is to create dynamic bounce lights then you could try a low res cubemap RTT, plug that into a lightfunction material and apply that to a white light which should achieve something similar.

Would probably be stupidly expensive though.

[diegofloor]

If you want just an RGB value then I don't think so.

That's sad news Not even using the render to texture idea?

However if your plan is to create dynamic bounce lights...

That's not the plan

I'm trying to achieve a visual detection system for a very old stealth project of mine. I've been jumping from engine to engine and none are flexible enough for this kind of task. Plain light detection is easy enough, but it's not possible to account for the radiosity baked. I know UDK generates automatically auxiliary lights to make the dynamic models more or less coherent with the baked radiosity, but we don't have access to these lights.

This isn't the first time I tried UDK for this project and failed. I came back because I thought about this alternative way of doing visual detection, using the line of sight of the AI and calculate the value difference with the player and without the player for a few pixels to decide whether he is detected or not. It's a neat idea, but probably expensive, that would also account for silhouette, something that wasn't possible in Thief and other stealth games.

Thanks for your input anyway. Let's see if someone else knows a way around this, or I'll have to make my own engine D:

[benfranke]

I don't think you can do what you're doing with the native trace functions, so you'll have to approach this differently.

You could iterate through all the list of visible actors, and for each light close by, calculate the distance (as a vector) between the player and the light. The closer he is to the light, the more detectable he is. To make the effect more realistic, I'd do something similar on the enemy class: Get the distance to the player's pawn and the closer the enemy gets, the higher the chance of being detected.

Pseudocode:

The Player's pawn:

var float visibility;

function calculateVisibility
{
foreach VisibleActors(class'MyLight', outLight, 1024) //iterate through the list of visible actors of class 'myLight' in a radius of 1024 units
{
visibility = 0; // Set detectability to 0 just to be safe

if(FastTrace(self.location, outLight.location) && VSize(PlayerController.Pawn.location - outLight.location) != 0) // The player might be close the light, but it might be around a corner and we do not want to divide by 0
{
visibility += 1 / abs(VSize(PlayerController.Pawn.location - outLight.location) // Increase detectability for every light
}
}
}

On your enemy:

var float proximity;

function calculateProximity
{
if (VSize(PlayerController.Pawn.location - self.Location != 0))
{
proximity = 1 / abs(VSize(PlayerController.Pawn.location - self.Location);

if (PlayerController.Pawn.visibility + proximity >= 1)
{
// Whatever happens now
}
}
}

You'd have to do this very often (probably in a tick function on both classes) plus iterating through the list of all visible actors is really expensive in terms of processing power though so it might not be a great solution.

[skwisdemon666]

You will need to use a for each iterator to check through all the lights in the level.

Then, if your guy is in the light radius, and there is nothing traced between him and the light, do some math with the distance to the light and the light's falloff exponent to calculate a value, and add this value for all lights in the scene. (0 for each light that he is not within the radius of) If the value is high enough, then he is visible.

You could even compare this to an alertness value of the enemy. You are just doing regular math, nothing too fancy, so it shouldn't be too costly. You could set it to run every third tick or so since you probably won't be moving too far between individual ticks.

That would take care of basic lighting affecting stealth, but if you have different camo for different scenery, umm.... I'm not sure yet how to compare color. I'm interested in doing something like this too, so I will post back when I find something.

[diegofloor]

Yes, that is the standard way of doing this. But then you can't use radiosity or the payer won't have a good visual indication of where are the shadows and lights, because the bounces aren't taking part in the calculation of visibility. It's a reasonable sacrifice, but it hurts to know there are all those light probes generated from the radiosity while being unable to retrieve their information.

I'll probably eventually settle for direct light only, but first I want to exhaust all possibilities. (then I'll probably go back to Unity too :P )

[benfranke]

There's no other way I can think of right now, plus I just noticed it doesn't take lighting intensity into account - far from perfect sadly.

In general, you will have to play with the values in your detectability algorithm a little. If the level is brighter with radiosity lighting than it would be without light bounces then detectability would be higher in general.
It is up to the level designer to match the lighting values to fit your algorithm, that is to make sure the player is not in a well-lit area but so far away from an insanely intense light that the detection algorithm returns 'not visible'.

[UnrealEverything]

There's no other way I can think of right now, plus I just noticed it doesn't take lighting intensity into account - far from perfect sadly.

You can easily use the lights lightcomponent brightness and the light specific properties (radius, direction, falloff, etc.) to make it much more accurate. It all depends on how perfect it needs to be.

[diegofloor]

The only way I can think of to take indirect light into consideration, without having access to the source code, obviously, is to leave it at the hands of the level designer, spreading volumes around the map and setting a parameter according to the neartby lit objects.

[nonder]

And what if you do trace, project hit location to screen and get RGB of this pixel (I don't know how is it in UScript but I think it is possible via TCP, DLL bind too)

[skwisdemon666]

If your game is based on stealth enough to warrant this, you could add a linear color variable to the static mesh class, like Averagecolor, and set it in editor when you import the mesh and textures, then check with a trace. To make level editing easier, you could probably make it so that the wireframe color gets set to this too...

Or you could just check the wireframe color of you static meshes to see if it is anything besides the default.

You could check the average color with a few traces and compare a a linear color value set on your pawn, as well as factor in the lighting as discussed above, and both together might be fairly accurate.