2d topdown lighting

[asser_fahrenholz]

Hi

Just wanted to get some input on the following image:

Can this be done with a game where everything is quads ? I have close to zero gfx experience, so i’m just curious

Edit: Oh, just stumbled upon this: https://github.com/libgdx/box2dlights/tree/pseudo3d - so I guess it’s doable to some extend at least

[thecyberbob]

You’re kinda being a bit vague here. What aspect of that image are you trying to get? The glow around the center object? The shadows being cast off of the posts? Those colourful red and blue lights?

[asser_fahrenholz]

Fair enough.

The lighting aspects (mainly shadows). My game is currently 2d, in a plane, so was thinking it would be impossible to do any sort of shadows. But the link I found proves me wrong I hope. Will be interesting to see.

[Pesegato]

I think what you want is a 3d scene with a orthographic camera… do this and then you should be able to use jme shadow filters/renderers as if it were a 2d game.

[pspeed]

You can plot 2D shadows in 2D, sure. This is effectively what 2D games where your line of sight is limited have been doing for decades.

Even rogue/nethack had visibility ray casting and that was ASCII art. It’s no different really.

Edit: …heheh… now that I think about it, even Monkey Trap did this sort of visibility ray casting as you walked around to hide parts of the level you couldn’t see.

[jayfella]

I’ve played with this a lot a couple years back. I managed to get it working in jme, but I was making a terraria clone which has a mix of baked cellular automata + this.

mattdesl/lwjgl-basics

[asser_fahrenholz]

Does anyone have any pointers as to how to go about this in an ES based + network game? the client only knows about the visuals and audibles…

[jayfella]

It has absolutely nothing to do with an es or network. This is purely client visualization.

[asser_fahrenholz]

I know. But all of the implementations I can find uses some sort of physics-world/libgdx/box2d object to do the raycasting. In a networked game, the client doesn’t have this information ?

[jayfella]

I think you’re confused. The server tells you what goes where yeah. But the visual representation is entirely client side. You have all the data you need from the server to determine positions and directions. That’s as far as the server and physics system is involved. After that you must create a scene to represent that data. It can be basic or extensive. The lights, the shadows, etc… Are all purely for the visual gratification of the user. It is basically a shader and nothing more.

Just as the GitHub API will always give you the same JSON data, the visual website can be crap or beautiful. This lighting/shadow is the website. Just a visual representation of your game.

[pspeed]

Monkey Trap calculates this client side also. It doesn’t use the physics engine or anything and just casts its own rays. That’s not particularly difficult and it is super fast for cells in the level.

You can calculate it on the server too and just include it as part of your level data that you send to the client.

You possibly: “But I don’t send level data to the client…”

…Then you’d have to start. Just send the lighting information as a separate message or whatever. But really, unless you do it the simple ‘lighting info at the corners’ kind of way then it’s a lot of data to send.

Better to calculate on the client, really.

[jayfella]

If these are torches or character items you will have all necessary data. The sun will be protected since you should only be able to read it’s direction. Point lights are the same for either movable or static ones. The light will just be sent with the chunk or its child-transmissions (e.g. terrain first, then buildings, then light) in the case of a static one.

The only thing you need in any case is a couple of vectors - Position and direction - and a few floats - probably another vector - for radius etc so you can take advantage of its maths functions for local effects.

[JESTERRRRRR]

I think what you want is a 3d scene with a orthographic camera… do this and then you should be able to use jme shadow filters/renderers as if it were a 2d game.

Do this. Easiest way no extra stuff required.

[asser_fahrenholz]

Do this. Easiest way no extra stuff required.

I already have this, and my graphics are all quads in the plane that the camera is orthogonal to.

[asser_fahrenholz]

Thanks for the input everyone. I came to the same conclusion (that client already has the necessary information to produce shadows such as in the picture) - i just couldn’t grasp if it was possible when I want to do shadows in a plane (seems counter-intuitive to me somehow).

[asser_fahrenholz]

You can calculate it on the server too and just include it as part of your level data that you send to the client.

I already send level data to the client, but what is it I have to calculate on the server (or what are you referring to in the quote)…?

[Etherblood]

https://www.redblobgames.com/articles/visibility/
This is a nice interactive tutorial showing how you could compute 2d visibility.
It has examples with quads and you might also want to check out the attached source code.
gl

[ia97lies]

red blob games contains a lot of ver good articles, also about path finding algorithm and more. really worth to read

[asser_fahrenholz]

My initial confusion was: Should the shadows be cast ‘on’ something. But after reading about it, it’s just another mesh.

So, do I understand it correctly, that to ‘do’ shadows in JME, I could use a ShadowFilter (com.jme3.post.Filter) added as a filter in a FilterPostProcessor and then add that processor to the viewport. In the filter, I’d then override postFrame and go through all casters/occluders, keeping track of and positioning the shadow-meshes correctly?

I would need to keep track of all the lights in this filter as well, in order to colour/tint the shadows correctly.

[jayfella]

You have a batch limit yes. I wonder how close and faster it would be if you just ignored the up vector, though personally I’d go the material way, not postprocessor.