This project is read-only.

getLightLevelAt(Vector2 v)

Feb 19, 2012 at 3:25 PM

Hello! Is there anything akin to this? I found reference among the Discussions somewhere to it maybe being implemented, but nothing more.

It'd be amazingly handy. Just a 0 -> 1 return for an x, y coordinate, to determine if something's in shadow or not.

Alternatively, any suggestions how to implement it in a nice fast way without waiting for it in an update?

Feb 19, 2012 at 5:46 PM
Edited Feb 19, 2012 at 5:52 PM

As far as I know there isn't.

Can you describe the context of what you would want to accomplish. Maybe there is a workaround available.

EDIT: Generating a line from the pixel to the lightsource and then checking if there's any shadow hull obstuction might work. http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm Also, make sure you have downloaded the latest build from the 'Source Code' page.

 

I have no idea whether this project is still alive or not. I read somewhere (main page blog) that krypton 3.0 would be out in Januari this year. Obviously it isn't but I sure hope developers will make it happen. :) Last build is December 2011 (I believe) so thats quite recent.

Feb 19, 2012 at 7:30 PM

This sounds like it would be pretty slow.. I would imagine that you iterate over all the lights and do intersection tests with their bounding boxes (or even better, radius tests) and if you are within it's AOI you would use some kind of formula to determine the light level there (taking ambient light into account). Taking shadowing into account would be a whole other problem. Maybe you could do some kind of ray cast against lighting hulls or even finding the angles between the shadow hulls and light positions and if they are within a certain range you could assume that the hull is blocking the light... These are all certainly feasible in my opinion and now that I'm at the end of this post I believe that it could be done in a reasonably efficient way.

On the activity of this project, I think that it is still going but the developers have a lot on their plate right now... I current have some time off myself finally for my own projects (I promised everyone that I'd post up a camera class but haven't gotten around to it yet so I feel kinda like a jackass atm lol).

Feb 21, 2012 at 11:08 AM
Edited Feb 21, 2012 at 12:54 PM
danthat wrote:

Hello! Is there anything akin to this? I found reference among the Discussions somewhere to it maybe being implemented, but nothing more.

It'd be amazingly handy. Just a 0 -> 1 return for an x, y coordinate, to determine if something's in shadow or not.

Alternatively, any suggestions how to implement it in a nice fast way without waiting for it in an update?

I think I remember reading somewhere that you are using Farseer in your project too. In that case, use the raycasting function from Farseer, which should be fast enough. In a previous build for my game I achieved what you are trying to do, here's how I did it:

The character needs three reference points attached: Top (at the head), Center, and Bottom (at the feet), these points are relative to the main body, so you can easily get their world coordinates using body.getWorldPosition() (or getWorldPoint(), I can't really remember the method's name right now). Then for each light, attach a sensor with the size of the lightrange.

Each time the sensor "collides" with the character (use the BeginContact method in the World's ContactManager for checking that), cast three rays from the light to each point of your character (Top, Center and Bottom). If at least one of the rays "hits" one of these points without coing through any obstacle, then you character is lit.

This method worked good enough for me.

Hope it helps :)

Feb 21, 2012 at 6:17 PM
danthat wrote:

Hello! Is there anything akin to this? I found reference among the Discussions somewhere to it maybe being implemented, but nothing more.

It'd be amazingly handy. Just a 0 -> 1 return for an x, y coordinate, to determine if something's in shadow or not.

Alternatively, any suggestions how to implement it in a nice fast way without waiting for it in an update?

Hi Dan! Hope all is going well.

I vaguely recall this discussion that you mention, and I believe we decided that this was something out of the scope for version 2.0. It made more sense that in the current state of the engine, deciding light collisions with objects/points should be handled by game logic for now. I'll conjure up Xixonia to correct me if I'm wrong :)

Pnikosis posited a great example, imho. But we're definitely open to consider inclusion of things that are important to you all.

Feb 21, 2012 at 6:28 PM

While I'm here, I might as well address the activity going on with this project.

As you may have gathered from other threads, both Xixonia and I have found ourselves very busy this year. He's been busy with school and work, while I've been finishing up the last semester of my degree and working full time at a local dev company. We'd hoped to put out version 3.0 this January, but we didn't finish the last push to make it a release. We would love some feedback on the source included in the Futures folder, and maybe with enough influence from you guys we can send it out.

Side note from what I just posted to Dan; I feel like I may have spoken too soon. There is a ticket open that *might* be what you're asking. I'll go over the new source and see if the interface is included.

Feb 22, 2012 at 11:16 AM

Hello! Thanks for your replies all.

Current plan is to have default zones of various light levels (0->1) and determine distance to light sources. It's independent of Krypton, but should do the job nicely. I just though, having scoured the forums first, there might be an elegant, more-trustworthy and more efficient way of doing in in Krypton. The engine as-is is so beautifully optimised, I'd hoped something like this had snuck in.

On the subject of Krypton falling by the wayside - I can't even begin to describe how much it has lifted the visual quality of my game. When lights in buildings flicker on as the sun goes down, it's a joy to be around. It'd be a huge shame if you didn't continue. :)

d

Feb 23, 2012 at 5:40 AM

It's such a joy to us to see how you all use Krypton, and we're really happy that the time spent optimizing the first build has given you all a handy tool. In no way are we trying to neglect further development of this engine, our time has simply been stretched very thin :(

We do have some greater plans for Krypton, some that might even make it into build 3.0.

Oh, and feel free to submit patches to the project if you guys want to help us along :) 

-Dindak

Feb 23, 2012 at 12:13 PM

I remember I made a couple of modifications for avoiding creating too much garbage (and making it to run smoothly on the Xbox). Not sure if I posted here, so I guess a patch would be a good idea :)

Mar 1, 2012 at 9:22 PM

Hi all. So I've found a solution to this that (so far) seems to work pretty well. It's operating outside of Krypton, thought I'd put it up here. It's actually a little like Pnikosis' above, but not using sensors.

What I'm doing is foreaching through each Light, and working out if I'm in range and if so, if I'm within the FoV and Angle.

If that's all true, I'm raycasting from the light to the three main character parts (head, torso, legs), to determine if any of them are in direct line of sight. If so, we're lit. If not, our light level is set as per Krypton's Ambient Light.

So, there's not much scope for finesse. But it should be able to cope with moving lights, that sort of thing. I'll let you know if it turns out I've bollocksed it up and it doesn't work very well. ;)

@danthat

Mar 17, 2012 at 11:07 AM

Hey!

In order to get the light level at a given point, I'm currently sampling the lightMap RenderTarget2D at the desired position. This works, and gives accurate results, but causes a /huge/ performance hit, apparently due to the need for communication between the CPU and GPU to complete this task. 

My code looks something like this:

Color[] lightPixel = new Color[1];
Vector2 playerInWorld = WorldToScreen(world.Player.Position);
Rectangle sourceRectangle = new Rectangle((int)playerInWorld.X, (int)playerInWorld.Y, 1, 1);
kryptonEngine.mLightMap.GetData(0, sourceRectangle, lightPixel, 0, 1);
float LightLevel = (float)lightPixel[0].R / 255f;

(all the lights are white, so I didn't bother getting the magnitude or anything).

Anyway, despite looking so benign, 50% of game time is spent inside the GetData function here; this is more than the amount of time spent in pathfinding, collision detection, collision resolution, and AI combined!

I can't use the above solutions without a fair amount of modification, as I need the actual light level, not just a check to see if lighting is above zero.

I suppose I could check the line segment between the point and each light, then, if in range, manually sample the light textures (stored in CPU memory, in this case) at the proper coordinates, and use that data to simulate what would be normally rendered on the GPU, but this seems overcomplicated.

Do you know of any way around this? I've tried looking online for how to properly sample a GPU-bound texture, but most examples seem incomplete, or responses answer a different question, like here: http://stackoverflow.com/questions/9604760/is-there-an-inexpensive-way-to-transfer-colour-data-from-a-rendertarget2d-on-a-p. I don't need completely up-to-date light levels, either. The data from the previous frame would be fine too.

Thanks!

Mar 19, 2012 at 4:55 PM

Meyermagic,

There's a gigantic overhead to using the RenderTarget.GetData method. Instead of getting a single pixel at a time, I'd suggest caching the *entire* texture the first time you need to use the method (or a more appropriate time, if you can find one) until the next frame is rendered. You can then checked this cached data instead of calling "GetData" numerous times.

That will improve the performance, but I'm not sure how much.

Mar 22, 2012 at 3:28 AM

Just realized this, but trying to do this based on the render target will limit the tests to the area where the light map has been rendered... which is probably not the best solution. Guess I didn't worry about this too much before. I was assuming the test area would always be within the render target's display area...

So basically, we've got a problem. What happens when we want to get the illumination of a point of screen? Simple enough, we just do what Dan suggested, and use MATHS. But alas, what happens if the MATHS change because the *light texture* changes?

As a result, we'd have to give each light the *ability* to have a different version of the MATHS. Anyone else smell the strategy pattern? Ok, well... I do. So unless someone else smells something other than than, I'm making waffles... Or.. umm... strategies... you get the idea.

Anyone?