Color3 GetLightAtPoint(Vector3 point) for workspace/lighting

Feature Requests Engine Features
#1

Would be really useful if we had a function that let us know the “light” at a position.
It could return a Color3.

The Source engine has this:

Vector    CEngineClient::GetLightForPoint(const Vector &pos, bool bClamp)
{
	Vector vRet;
	ComputeLighting( pos, NULL, bClamp, vRet, NULL );
	return vRet;
}

and i was thinking something similar such as:

Color3 workspace:GetLightAtPoint(Vector3 point)

or

Color3 Lighting:GetLightAtPoint(Vector3 point)

Use cases?
Determining if you’re in the dark for stealth games,
Coloring particle effects according to the lighting,
many many more

Atleast think about this. This would be great

13 Likes
#2

Seems pretty helpful. It’s important to consider that they’re voxel-based, however, so the result might not be too accurate.

(I’m not an expert on these things though)

#3

Yes I know that.
I don’t know how roblox handles the stuff internally, but I’m pretty sure they know how much light and what color is it at each voxel. This could just be exposed in the Lua API

It could of course be:

workspace.Terrain:GetLightCell(x, y, z)

or perhaps an additional return value for GetCell?

2 Likes
#4

Another addition to this would be getting a table of all lightsources (that reach that point) with their lightstrength.
This would allow us to have (for example) light that heals a player, depending how strong the player is shined on.
(And if that property is enabled that makes part block light, have that be accounted for of course)

EDIT: A better example:
Having a survival game that uses temperature stuff.
A campfire’s light would produce a lot of heat, compared a flashlight, which might shine brighter but gives no heat.

1 Like
#5

It should be easier to implement this because it’s voxel based. I’m not entirely sure if this should be exposed though, because it might make it more difficult to upgrade lighting internals in the future.

#6

Great idea! This would be really useful for stealth mechanics in games. I am concerned that a client’s graphics settings could have a profound effect on an API like this though. Personally, I think it might make more sense to have this as a method of Lighting instead.

1 Like
#7

Ignoring collisions, you could possibly just do radius-based calculations from each light object based on the light object range. I did that once for detecting light intensity. Of course, that ignores global game lighting, so not as useful.

1 Like
#8

Yes, and there are ways to get a close approximate but the ways are terribly inefficient and overly complicated when we could just have an API for revealing pre-existing values

#9

Only problem with that is the exact start of your sentence: ignoring collissions.
(Well, global lightining is also ignored as you said later on)

#10

It’s been a while(year), anyone heard anything about this? :confused:

#11

In the light of the new lighting being worked on, I’d like to bump this to attention once more

EDIT: actually i should post in the future is bright -thread if i can find it

1 Like