light and shadows... drawing

Hey all,

Ashley - I have been playing around with the shadows and lights in the new beta release. Its really cool. however, I have one request so far (a simple one I think). Great work so far on it!

Currently, it is the shadows that are drawn, rather than the light. I think the reverse would be better in many situations. An option to choose what is drawn (either light or shadow) would be awsome. The way light effects had normally been done in the past in construct required a layer set to black (or whatever color shadows were going to be...) the layer would be set to force own texture and then the lights would be added to the layer with destination out. Basically lights cut a hole in the "darkness". If the darkness layer used multiply, you could make colored shadows and colored lights (blend mode is set to normal on the light and the light layer is set to multiply) the multiply method .

Essentially you can do the same when shadows are drawn but it takes more work than if the light is drawn. Mixing traditional lighting methods with the new shadow method is difficult due to the opposite workflows involved in each aspect...

If you use a normal method of lighting a layout and you draw the shadows, a few problems emerge. Namely one of them being that the tile map below the light gets shaded on blocks that shoudln't be. If you bring them up one layer then the don't get shaded by the overall light layer.

In cases where you wish to use screen or additive blending you have to use the shadow caster to cut out of an entire layer set to screen and filled with the light color of your choice. Sometimes, if complicated effects are desired it is impossible because you need to have layers within layers in order to get the desired effect.

This can all be solved simply by selecting what is drawn: Either light, or Shadow. No matter how you like to build up your effects, being locked in to drawing only shadow is difficult. If any one wants, I can post some capx demonstrating different lighting problems that would be better solved by drawing the light, rather than shadow. There are of course instances where drawing shadows is preferred, but so far I have found that I would prefer to draw the light so the it can be more easily combined with cutout lighting methods, multiply lighting methods, and screening/additive lighting methods. I hope this all made sense. It all ready requires 2 layers at least for reasonable lighting situations and having to have more doesn't make much sense if it can be avoided.

TLDR: Lights need to have the option to draw either light or shadow.. .

So the light would draw an area of white where the light can reach instead of black over the shadows?

You should already be able to get that with an opaque white layer with the shadow light plugin on it. You can use multiply blend with that. It should be straightforward, what is wrong with that exactly?

Ashley - the following scenarios should more effectively demonstrate what I mean. I also found out some other things as well.

Case:1 You want a situation where multiple lights are used. Because shadows draw instead of light you get an additive effect with the shadows. All the shadows draw despite that they are lit by another light. Using opacity to control the shadows doesn't really fix the problem because the shadows still build up even where they shouldn't. If light was drawn then you can use it to cut out of a black filled layer resulting in light falling how we expect it to.

SubCase 1a: This scenario also brings up another problem that indicates an additional feature is needed to the light and shadow behavior/attribute . Light fade distance and cutoff. You can easily do this at the moment by creating the black layer and using a sphere to stamp out a light circle. You then draw the shadows in and presto, you have a really neat area of light complete with awesome shadows. But then you want another light, and the whole model is broken. all of a sudden dark shadows cut across fields of light that they shouldn't. You can't even fix this by adding more layer.

Case 2: When using a layer to render light effects, including illumination areas and so on, the light layer usually has to be above, the tiles needing to be lit. A problem arises here in which the block that is casting a shadow actually gets covered by that shadow. You can't add in those blocks on the layer above light because then they will be just as light even in "dark areas". If light was drawn, you could draw it as black and then use draw the shadow casters as black on the same layer. Finally a white sphere sprite could be put on top of it all with appropriate blend mode to not cover any shadow area.

Currently, the shadow being drawn where the shadow caster is would be nice to toggle but not needed if you can draw light in stead of shadow.

----------------------------------------

In my mind, the addition of the light and shadow behavior is super awesome as it adds in a slew of professional effects to construct. It's very exciting. But adding in the ability to draw either shadow or light would make the system more robust and seems like an essential feature to me. It would really add to its flexibility. Other features such as light fade (linear fade at the least) and light effect distance would be really, really nice. I know you can do this via a build up of layers and sprites but wouldn't it be more cost effective to have it all together in terms of performance? Also it is imposible to have multiple lights behave as expected because of how you have to use layers to build them up. Including light distance/fade would solve this. Lastly, being able to reduce the arc that light shines would be cool to, but would be much more of a bell and whistle. Essentially being able to set the angle and radius in degrees of the light (for easily creating beams of light).

In conclusion I feel that the following options would really help create a strong light/shadow model thus increasing the behavior's value to the construct community. (in order of priority/need in my mind)

1. Draw either shadow or light (needed for flexibility and certain situations)

2. Light fade distance (Fade type (linear/expo/none), distance(in pixels) (needed for multiple lights with area of effect)

3. Angle of light (from 0-360) (for creating narrow beams of light)

I hope you will consider at least the first one (and the second would be super nice too), I shouldn't expect it would be too hard to implement and I think it is necessary. The list of found cases where drawing light would be better than shadow will only grow as people have time to work with it.

I can post capx demonstrating the above when I get home if the description isn't clear enough. I do have them already

Do you mean something like this?

http://ncase.me/sight-and-light/

Wouldn't this also fix the problems when a light source is too near a shadow caster? Plus when light appears to pass between the seam of two adjacent sprites?

If I understand correctly you can already convert the shadow plugin to render light by using a layer. Create a white layer, place the shadow light on it, and set the layer to additive blend mode. Bingo, a layer that renders light instead of darkness.

You can then customise that by further additive blending a circle on top (so shadows never appear within a radius), or cutting out a cone shape (to simulate an angle of light). You can do a lot with creative use of layers and blending, and I think it covers all those cases already.

Is it possible to recognize whether or not you are in shadow or light via events?

Ashley, I don't think I must have explained very clearly. I know you use a layer to effectively draw light instead of shadow. And I understand you can create a distance fade off with some clever blending, but because you already used an entire layer simply to convert the plugin so that it draws light, it becomes impossible to do other tricks given the way layers are applied.

Clever layering and blend modes (such as drawing bg last if you want it to be unaffected by light, with other blend modes on middle layers) creates cool effects. And you can certainly get just about any one effect. But that's just it, you can't get effects combined without a bit more flexibility. You can't have have multiple light sources with two light plugins, due to the way they draw shadow. I think my inability to clearly illustrate the problem via text is showing here. Unfortunately, I can't even show a capx demonstrating how to do the the cases I mentioned above because they are theoretical and I would need to be able to draw light straight from the plugin. You say you can solves those cases using creative layering and blendmodes/effects but the only thing that you said could be done was what I explained could be done. The key is that all the effects I mentioned can be done in isolation. But how can you have multiple lights that make sense given they way they are currently drawn? You need a layer for each additional light but that won't work unless you can group multiple layers and render them as one texture to whatever needs the light/shadow on top of .

Does any of this make sense?

HEy, Ashley I had an epiphany. Originally I thought I would change the plugin myself but realized it would take to long to figure out how you went about things, given its about 1000 lines of code. I've followed other tutorials on 2d lighting and understand the basics but I was lazy...

So instead I wrote a couple of lines of code and BLAM - I made a shader to invert the alpha channel. now prepare to be amazed by my ability ability to draw light.

____________________________________-

*EDIT***************

I'm not sure why but for some reason the shader doesn't work on the light plugin. It works on sprites but not the light. If I add the effect to the light plugin "set Color" followed by "AlphaFlip" then it works on the plugin... -> I may need to post this in another forum

Some very interesting stuff mentioned here.

Dru this example is awesome! I'll be damned if I got half a line of math, but the logic is clear.

I think that if gray-scale masking were possible, most of those problems would have being solved.

I like the ideas for per-light falloff and light cone. I 'd also like to see a condition that checks if an object exists within a shadowed area. This will be incredible useful for covering/uncovering stuff when they are not in direct light view (hiding behind shadows).

Ruskul - you might need to put the shadow light on a transparent layer with 'force own texture' set for inverting alpha to work, otherwise it will be rendering to an opaque surface and the alpha will never be different.

As for detecting objects in shadows: how do you actually define if an object is in a shadow? There are a variety of ways to do it: is the hotspot in the umbra, is the entire collision polygon in the umbra, is the entire bounding quad in the umbra, etc - and then what about penumbras? If it ever so slightly edges in to a very wide penumbra that probably shouldn't count as suddenly visible, but on the other hand an object just inside the light edge of a very wide penumbra should probably count as visible. I don't know how to accurately define that. The line-of-sight behavior can already make visibility checks, and it only looks at origins but you can make it do multiple checks around the edges of objects to come up with your own solution, so I don't think there needs to be a shadow-specific feature for that.

Ashley I am not sure how I can describe it, I'm not quite sure what is it that I miss from the current state and functionality of the shadow caster. I'll try my best to make my self clear:

1) The system draws shadows, so in essence it finds areas that are behind (in relation to the light source) the polygons of the shadow casting objects and draws stretched dark shapes to simulate shadows. So far so good. But what happens when an object should cast its own shadows, be visible but gets behind an other object that is "taller" than it, so it should be shaded by the taller object? How can we achieve that? I have a workaround with the line of sight, but it's far from ideal.

[attachment=0:1vg4odv4][/attachment:1vg4odv4]

2) We can colorize the shadows but the other way around would be more useful. I know that we can use other sprites with blending modes to fake the color and add falloff, but I believe that if the system worked by darkening everything out except for the parts that are in direct view with the light source, it would be more evident and useful. At least as an option. Again, I understand that we can do that by using a white layer, but then things are getting more complicating and as I mentioned many times in the forums already, masking in general is not Construct's best virtue. Using blending modes to mask layers with other layers is... a sore to say the least.

I hope that I make sense!

Isn't possible to recreate this http://ncase.me/sight-and-light/ with Construct 2?

— - I believe it is possible to create that image. You wouldn't be able to get the cell shaded effect with the "not quite lit, but not in shadow areas" (if that makes sense) it would have to be a soft shadow. You would need several layers to do it. Right off the top of my head it would be something like this:

(drawn from top to bottom) There are probably better/more efficient ways to do this...

1. Layer with the characters normal "lit" sprite. Include other stuff here to that needs to be covered by the shadow.

2. Shadow layer. Put the shadow/light plugin in this layer. The layer needs to have it's own texture forced. The light/shadow plugin must be drawn first. After it is drawn everything that you want drawn in the shadows needs to have blend mode set to source atop. the characters bones would go here in this manner

What it all does: First the game renders the scene as you would like it to normally appear. Then in another layer the shadow is drawn. Because this layer is set to force it as a texture it draws everything in the layer and then draws that layer to the main canvas. Shadows are drawn in this layer and after they are done the game draws stuff that should appear in the shadow. Because the blend mode of these other things is set to source atop, only areas that have already been drawn on (in this case, shadows) will be drawn on. Effectively, the shadow acts as a mask and only where it exists will stuff be drawn in this layer. Does that make sense?

Ashley - thanks for the suggestion! I tried that already though. The weirdest thing is that it works no matter how shader is used on a sprite. Regardless of how I set up the layers I can't get it to work the way I expect it to on the light plugin. If I use the set color shader on the plugin before flipping alpha it works. I'm going to have to dig around to see whats going on/make sure I even wrote my shader correctly.